DISEÑO DE SISTEMAS

UNIDAD 1 - PASO 2 - INGENIERÍA Y GESTIÓN DE REQUISITOS

PRESENTADO A:
MOISES DE JESUS RODRÍGUEZ BOLAÑO

ENTREGADO POR:
JESÚS DAVID MONTES GONZÁLEZ - CÓDIGO: 1.102.877.965
HEINER JAVIER PEREZ - CÓDIGO: 1.046.268.520

GRUPO: 301309_50

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS
CEAD COROZAL
OCTUBRE 16 DEL 2018
 INTRODUCCIÓN

Para determinar los requerimientos de sistemas, es necesario analizar los

hechos que se tienen a la mano. Las descripciones y la documentación

desarrollada como resultado del esfuerzo de búsqueda de hechos se estudian con

la finalidad de evaluar el funcionamiento del sistema en uso y establecer los

requerimientos que debe cumplir un nuevo diseño. Las conclusiones obtenidas

durante esta actividad forman la base para la transición hacia el diseño, así como

de otras actividades de desarrollo.

El presente trabajo contiene el desarrollo de la actividad del paso 2,

correspondiente a la Ingeniería y gestión de requisitos de acuerdo con lo dispuesto

en la respectiva guía de actividades.

Este ejercicio es fundamental para identificar los diversos elementos y

procesos que se deben tener en cuenta en el desarrollo de un sistema de

información. En su realización se puso en práctica el trabajo con patrones,

interfaces y diseño arquitectónico del sistema.

 OBJETIVOS

OBJETIVO GENERAL

Desarrollar el diseño para un sistema de información o producto informático de

alta calidad teniendo en cuenta los elementos y procesos necesarios en su

planeación para obtener los resultados deseados

OBJETIVOS ESPECÍFICOS

 Elaborar los patrones teniendo en cuenta los casos de uso para

describir adecuadamente los elementos que se deben incluir y los

procesos que se llevarán a cabo.

 Proporcionar detalles sobre arquitectura del software, estructuras de

datos, interfaces y componentes que se necesitan para implementar el

sistema

 Identificar las distintas representaciones de un software

 Elaborar un diccionario de los conceptos y términos técnicos empleados

en las interfaces para la base de datos del sistema.

Actividades para desarrollar

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

diseño de software y la codificación?

diseño de software codificación

 Desarrolla un diseño detallado  Realización del diseño detallado

del sistema, por alternativa del de cada programa
diseño planteado  Realizar revisiones del
 Elabora los requerimientos del documento de diseño de
sistema a requerimiento de programas y codificación
softwares  Es la programación, sobre el
 Evalúa las alternativas de diseño planteado en los
diseño, para cada alternativa requerimientos
 Produce el documento de  El que escribe código a partir de
diseño del sistema cero

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

La calidad software. es el grado con el que un sistema, componente o proceso

que cumple los requisitos funcionales definidos y las necesidades del cliente o
usuario. (IEEE, Std 610-1900). La calidad del software es el conjunto de

cualidades que lo caracterizan y que determinan su utilidad y existencia.

El software al no ser físico es difícil medir su función, ventajas y costes. Por lo

tanto, los procesos y los métodos para manejar, para supervisar, y para medir su

calidad pueden ser muy complejos.

Propiedades para poder evaluar un software

 Propiedades de calidad

 Características Operativas.

 Capacidad de Soportar Cambios.

 Adaptabilidad a Nuevos Entornos.

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

procedimiento que se usan para manipularlas.

Una abstracción se enfoca en la visión externa de un objeto, separa el

comportamiento específico de un objeto, a esta división que realiza se le conoce

como la barrera de abstracción, la cual se consigue aplicando el principio

de mínimo compromiso.

Una abstracción de datos es un conjunto de éstos con nombre que describe a

un objeto de datos. En el contexto de la abstracción de procedimiento abrir, puede

definirse una abstracción de datos llamada puerta. Como cualquier objeto de

datos, la abstracción de datos para puerta agruparía un conjunto de atributos que

describirían la puerta (tipo, dirección del abatimiento, mecanismo de apertura,

peso, dimensiones, etc.). Se concluye que la abstracción de procedimiento abrir

usaría información contenida en los atributos de la abstracción de datos puerta

 Abstracción de Entidades: Es un objeto que representa un modelo útil de

una entidad que se desea.

 Abstracción de Acciones: Un objeto que representa un conjunto de

operaciones y todas ellas desempeñan funciones del mismo tipo.

 Abstracción de Máquinas virtuales: Un objeto que agrupa operaciones,

todas ellas virtuales, utilizadas por algún nivel superior de control u

operaciones (entre ellos podríamos hablar de un circuito)

4. Describa con sus propias palabras la arquitectura de software.

La Arquitectura de Software es a grandes rasgos, una vista del sistema que

incluye los componentes principales del mismo, la conducta de esos componentes

según se la percibe desde el resto del sistema y las formas en que los

componentes interactúan y se coordinan para alcanzar la misión del sistema.

La Arquitectura de Software es la organización fundamental de un sistema

encarnada en sus componentes, las relaciones entre ellos y el ambiente y los

principios que orientan su diseño y evolución

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.

Patrones de Diseños Mas usados

 FACADE: Su objetivo es proporcionar una interface simple para un

subsistema complejo, o estructurar subsistemas en capas (En pocas

palabras creo una clase a través de la cual el sistema cliente accederá a lo

que yo quiera que acceda).

 SINGLETON: El patrón de diseño single ton (instancia única) está diseñado

para restringir la creación de objetos pertenecientes a una clase o el valor

de un tipo a un único objeto. Su intención consiste en garantizar que una

clase sólo tenga una instancia y proporcionar un punto de acceso global a

ella. (Obligo que solo se cree una instancia de una clase.)

 FACTORY: En diseño de software, el patrón de diseño Factory Method

consiste en utilizar una clase constructora (al estilo del Abstract Factory)

abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el

dedicado a la construcción de objetos de un subtipo de un tipo determinado.

Describa el patrón en forma breve.

En la aplicación del punto de venta, alguna clase necesita conocer el gran total

de la venta.

Comience asignando las responsabilidades comuna definición clara de ellas. A

partir de esta recomendación se plantea la pregunta:

¿Quién es el responsable de conocer el gran total de la venta?

Desde el punto de vista del patrón Experto, deberíamos buscar la clase De

objetos que posee la información necesaria para calcular el total. En conclusión,

para cumplir con la responsabilidad de conocer y dar el total de la venta, se

asignaron tres responsabilidades a las tres clases de objeto así: Venta (conoce

total de la venta) Ventas línea productos (conoce subtotal de la línea de productos)

Especificación de producto (conoce el precio del producto)

Diagramas de Interacción El patrón Experto

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 implementar un diseño modular como software monolítico cuando una

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

independiente de otras aplicaciones computacionales. Se logra combinándola

interfaz de usuario, la verificació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 rendimiento es que funciona más rápido, es fácil de

desarrollar y es eficiente, ya que se producen pocos cambios en el contexto.

7. ¿Cómo se relacionan los conceptos de acoplamiento y portabilidad del

software? Dé ejemplos que apoyen 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 un

acoplamiento 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 Mozilla Firefox, que

se puede ejecutar en cualquier dispositivo con acceso a internet.

8. Describa en breves palabras cada uno de los cuatro elementos del modelo del

diseño.

El diseño es la fase en donde se modela la estructura del sistema, es en esta

fase donde se toma toda la información obtenida en el análisis para crear los

cuatro elementos del diseño

Los cuatro elementos del diseño son:

 Diseño de datos

El diseño de datos se encarga de modelar las estructuras de datos que se

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

las relaciones entre las tablas.

En esta sección se hace uso de los diagramas de entidad relación y del diccionario

de datos.

 Diseño arquitectónico

El 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

El diseño de la interfaz describe la forma como el sistema interactuar 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.

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?

Cuando se piensa en la arquitectura de una construcción, llegan a la mente

muchos atributos distintos. En el nivel más sencillo, se considera la forma general

de la estructura física. Pero, en realidad, la arquitectura es mucho más que eso.

Es la manera en la que los distintos componen-tes del edificio se integran para

formar un todo cohesivo. Es la forma en la que la construcción se adapta a su

ambiente y se integra a los demás edificios en la localidad. Es el grado en el que

el edificio cumple con su propósito y en el que satisface las necesidades del

propietario. Es la sensación estética de la estructura “el efecto visual de la

edificación” y el modo en el que se combinan texturas, colores y materiales para

crear la fachada en el exterior y el “ambiente de vida” en el interior. Es los

pequeños detalles: diseño de las lámparas, tipo de piso, color de las cortinas… la

lista es casi interminable. Y, finalmente, es arte.

¿En qué se parecen las disciplinas de la arquitectura clásica y la del software?

En que ambas llevan son muy fundamental para desarrollar un sistema es

decir se necesita de una arquitectura y de una arquitectura de software

¿En qué difieren?

arquitectura clásica arquitectura software

 Visualiza el comportamiento del  arquitectura del software

sistema permiten la comunicación entre
todas las partes (participantes)
 el uso del lenguaje clásico interesadas en el desarrollo de
servía para responder con la un sistema basado en
nueva arquitectura a las computadora
necesidades de la sociedad
 La arquitectura resalta las
 la arquitectura clásica a semeja primeras decisiones que
los planos de un edificio o tendrán un efecto profundo en
construcción. todo el trabajo de ingeniería de
software

 La arquitectura “constituye un
 modelo relativamente pequeño
y asequible por la vía intelectual
sobre cómo está estructurado el
sistema

10. De ejemplos de:

 Arquitecturas centradas en los datos.

 Arquitecturas de flujo de datos.

 Arquitecturas orientadas a objetos

 Arquitecturas en capas.

Arquitecturas centradas en los datos.

Se puede definir como un almacén de datos donde se encuentra el centro de

la arquitectura condensada, donde los componentes tienen acceso a ello dando la

opción agregar, actualizar o eliminar y modificar de este almacén Con esta se

puede inhabilitar al infractor.

EJEMPLOS:

 Repositorio pasivo

 Repositorio activo

 Frameworks dinámicos

 Partes dinámicas funcionales

Arquitecturas de flujo de datos.

esta arquitectura se aplica cuando los datos de entrada son transformados a

través de una serie de componentes computacionales manipulativos en los datos

de salida

DESVENTAJA: 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 a6) y

limita el tamaño de la ventana de ejecución de 32 a200 instrucciones.

EJEMPLOS:

 Cada filtro trabaja de manera independiente de los componentes que se

encuentran situados antes o después de ella.

 Obtiene como resultado datos de salida en un formato especifico

Arquitecturas orientadas a objetos

Los componentes del sistema encapsulan datos y operaciones que deben

reutilizarse para manipular dichos datos, Permite la creación de sistemas de

información altamente escalables que reflejan el negocio de la organización, a su

vez brinda una forma bien definida de exposición e invocación de servicios

(comúnmente pero no exclusivamente), lo cual facilita la interacción entre

diferentes sistemas propios o de terceros.

EJEMPLOS:

 Aplicaciones básicas

Sistemas desarrollados bajo cualquier arquitectura o tecnología,

geográficamente dispersos y bajo cualquier figura de propiedad;

 De exposición de funcionalidades

Donde las funcionalidades de lacada aplicativa son expuestas en forma de

servicios (generalmente como servicios web);

  De integración de servicios

Facilitan el intercambio de datos entre elementos de la capa aplicativa

orientada a procesos empresariales internos o en colaboración;

 De composición de procesos

Que define el proceso en términos del negocio y sus necesidades, y que varía

en función del negocio;

 De entrega

Donde los servicios son desplegados a los usuarios finales.

Arquitecturas en capas.

Se definen como un conjunto de niveles o capas cada nivel interno que se

atraviesa se aproxima más al nivel del conjunto de instrucción es máquina.

Sistemas en capas puros. Cada capa solo puede comunicarse con las vecinas.

Esta solución, aunque menos eficiente facilítala portabilidad en los diseños

EJEMPLOS:
  Aplicaciones de línea de negocios (LOB), como contabilidad, y sistemas de

gestión de clientes.

 Aplicaciones web Corporativas y sitios Web

 Aplicaciones corporativas de escritorio o clientes inteligentes con servidores

centralizados de aplicación con lógica de negocios.

 Los siguientes son algunas variaciones del estilo de arquitectura basado en

capas

11. Algunos de los estilos arquitectónicos citados en la pregunta 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?

El entorno de ejecución de una aplicación puede estar distribuido en distintos

elementos nodos es aconsejable y beneficioso descomponer la aplicación en

capas, correspondientes a los nodos donde podría tener que ejecutarse. Los

beneficios de dicha descomposición son varios, entre los cuales se mencionan:

  Se puede comprender una capa como un todo coherente, sin necesidad de

conocer las restantes.

 Se puede sustituir una capa con implementaciones alternativas de los

mismos servicios básicos.

 Se minimizan las dependencias entre las capas

 Las capas son un buen sitio para la estandarización

 Una vez implementada una capa, se la puede utilizar para muchos

servicios de alto nivel.

La descomposición más habitual es decir el patrón usualmente empleado es dividir

la aplicación en tres capas:

 Lógica de presentación, que se ocupa de toda la interacción entre el

usuario y el software, pudiendo tratarse de un sistema de menús muy

simple o una interfaz gráfica de usuario relativamente compleja

 La lógica del dominio, también conocida como la lógica de negocio, que es

todo lo que necesita conocer la aplicación para poder trabajar con el

dominio en cuestión. Implica realizar cálculos basados en datos de entrada

o almacenados, validación de cualquier dato proveniente de la capa de

presentación y la ejecución de algoritmos específicos en función de los

comandos de la presentación
  La lógica de fuente de datos, que se ocupa de comunicarse con otros

sistemas que se encargan de tareas en representación de la aplicación.

Estos pueden ser monitores de transacciones, otras aplicaciones, sistemas

de mensajes, etc.

12. Los términos estilo arquitectónico, patrón arquitectónico surgen con frecuencia

en los análisis de la arquitectura del software. Investigue y describa en qué difiere

cada uno de ellos de los demás.

Estilo arquitectónico.

Estilo arquitectónico de software en los últimos años es, sin duda, el de los

patrones (patterns), tanto en lo que concierne a los patrones de diseño como a los

de arquitectura. Inmediatamente después, en una relación a veces de

complementariedad, otras de oposición, se encuentra la sistematización de los

llamados estilos arquitectónicos. Cada vez que alguien celebra la mayoría de edad

de la arquitectura de software, y aunque señale otros logros como la codificación

de los ADLs o las técnicas de refinamiento, esos dos temas se destacan más que

cualesquiera otros [Gar00] [Shaw01]. Sin embargo, sólo en contadas ocasiones la

literatura técnica existente se ocupa de analizar el vínculo entre estilos y patrones

[Shaw94] [SG95] [SC96] [BMR+96] [MKM+97] [Hil01a] [Hil01b]. Se los yuxtapone

cada vez que se enumeran las ideas y herramientas disponibles, se señala con

frecuencia su aire de familia, pero no se articula formal y sistemáticamente su

relación. Habrá que admitir desde el vamos que ambos asuntos preocupan y

tienen como destinatarios a distintas clases de profesionales, o diferentes

stakeholders, como ahora se recomienda llamar: quienes trabajan con estilos

favorecen un tratamiento estructural que concierne más bien a la teoría, la

investigación académica y la arquitectura en el nivel de abstracción más elevado,

mientras que quienes se ocupan de patrones se ocupan de cuestiones que están

más cerca del diseño, la práctica, la implementación, el proceso, el refinamiento, el

código. Los patrones coronan una práctica de diseño que se origina antes que la

arquitectura de software se distinguiera como discurso en perpetuo estado de

formación y proclamara su independencia de la ingeniería en general y el

modelado en particular. Los estilos, en cambio, expresan la arquitectura en el

sentido más formal y teórico, constituyendo un tópico esencial de lo que Goguen

ha llamado el campo “seco” de la disciplina [Gog92]. Más adelante volveremos

sobre esta distinción. Conviene caracterizar el escenario que ha motivado la

aparición del concepto de estilo, antes siquiera de intentar definirlo. Desde los

inicios de la arquitectura de software, se observó que en la práctica del diseño y la

implementación ciertas regularidades de configuración aparecían una y otra vez

como respuesta a similares demandas.

El número de esas formas no parecía ser muy grande. Muy pronto se las llamó

estilos, por analogía con el uso del término en arquitectura de edificios. Un estilo

describe entonces una clase de arquitectura, o piezas identificables de las

arquitecturas empíricamente dadas. Esas piezas se encuentran repetidamente en

la práctica, trasuntando la existencia de decisiones 3 estructurales coherentes.

Una vez que se han identificado los estilos, es lógico y natural pensar en re-

utilizarlos en situaciones semejantes que se presenten en el futuro [Kaz01]. Igual

que los patrones de arquitectura y diseño, todos los estilos tienen un nombre:

cliente-servidor, modelo-vista-controlador, tubería-filtros, arquitectura en capas…

Como conceptos, los estilos fueron formulados por primera vez cuando el

escenario tecnológico era sustancialmente distinto del que se manifiesta hoy en

día. Es por eso que en este estudio se analizarán las definiciones de los estilos

arquitectónicos que se han propuesto, así como su posición en el campo de las

vistas de arquitectura, su lugar en la metodología y su relación con los patrones,

tomando en consideración las innovaciones experimentadas por el campo de los

estilos desde su formulación inicial en 1992, coincidente con el instante que la

IEEE identifica como el del nacimiento de la arquitectura de software en sentido

estricto. Desde que surgieran tanto la disciplina como los estilos no sólo se han

generalizado arquitecturas de cliente-servidor, sino que experimentaron su auge

primero las configuraciones en varias capas y luego las basadas en componentes,

en recursos (la Web) y en servicios (los Web services). Las metodologías de

ingeniería también experimentaron evoluciones naturales y hasta revoluciones

extremas, de modo que habrá que analizar en algún momento si ciertas prácticas

que antes se daban por sentadas siguen o no en pie y en qué estado de salud se

encuentran; y como el trabajo que se está leyendo se realiza en un momento en

que son unos cuantos los que hablan de crisis, habrá que ver si las ideas en juego

tienden a acentuar los problemas o constituyen una vía de solución. En el estudio

que sigue se analizará el repertorio de los estilos como un asunto de inherente

interés descriptivo, taxonómico y heurístico. También se ahondará en su relación

con patrones y usos como una forma de vincular la teoría con la práctica, aunque

se sepa que sus mundos conceptuales difieren. Lo importante aquí es que la

teoría del arquitecto derive en la práctica de la implementación de sistemas, que

en ocasiones se presenta como dominada por un pragmatismo propio de hackers

o fundamentalistas de la orientación a objetos, como si la empiria de la

implementación no se coordinara con ningún orden de carácter teórico (aparte de

los objetos, por supuesto), o como si el conocimiento experto que se pretende re-

utilizar en el bajo nivel no pudiera dar cuenta de sus propias razones estructurales.

El marco en el que se desenvuelve el presente estudio es el de la estrategia de

arquitectura de Microsoft, que en los últimos años ha hecho hincapié en las

arquitecturas basadas en servicios y en patrones de diseño.

El propósito es no sólo delimitar y tipificar un campo tan estrechamente

relacionado con esa estrategia como pudiera ser el de las investigaciones

académicas en arquitectura, sino establecer una nomenclatura de formas

arquitectónicas que la documentación que ha comunicado la estrategia global de

Microsoft no tuvo oportunidad de poner en foco, dando por sentadas la mayor

parte de las cuestiones de naturaleza teórica y concentrándose en la práctica

[Platt02]. Este texto servirá entonces como puente entre (1) una estrategia

particular de arquitectura, (2) instancias de aplicación de estilos en productos,

lenguajes y sistemas de Microsoft y (3) el dominio teórico de la arquitectura de

software en general.
DIFERENCIA

La diferencia entre estilos y patrones arquitectónicos no ha sido aclarada.

Bengtsson (1999) plantea la existencia de dos grandes vertientes, que surgen de

la discusión de los términos. Shaw y Garlan (1996) utilizan indistintamente los

términos estilo arquitectónico y patrón arquitectónico. Por otro lado, Buschmann et

al. (1996) establece diferencias sutiles entre ambos conceptos. De cualquier

forma, los estilos y los patrones establecen un vocabulario común, y brindan

soporte a los ingenieros para conseguir una solución que haya sido aplicada con

éxito anteriormente, ante ciertas situaciones de diseño. Además, su aplicación en

el diseño de la arquitectura del sistema es determinante para la satisfacción de los

requerimientos de calidad.

En vista de la existencia de las dos vertientes, es necesario establecer las

posibles diferencias y las razones por las cuales se asume que los términos estilo

arquitectónico y patrón arquitectónico son distintos. De igual manera, se busca

resaltar los atributos de calidad propiciados tanto por los estilos como por los

patrones arquitectónicos y de diseño.

 Shaw y Garlan, definen estilo arquitectónico como una familia de sistemas

de software en términos de un patrón de organización estructural, que

define un vocabulario de componentes y tipos de conectores y un conjunto

de restricciones de cómo pueden ser combinadas. Para muchos estilos

puede existir uno o más modelos semánticos que especifiquen cómo

determinar las propiedades generales del sistema partiendo de las

propiedades de sus partes.

Buschmann et al, definen el estilo arquitectónico como una familia de

sistemas de software en términos de su organización estructural. Expresa

componentes y las relaciones entre estos, con las restricciones de su

aplicación y la composición asociada, así como también las reglas para su

construcción. Así mismo, se considera como un tipo particular de estructura

fundamental para un sistema de software, conjuntamente con un método

asociado que especifica cómo construirlo. Éste incluye información acerca

de cuándo usar la arquitectura que describe, sus invariantes y

especializaciones, así como las consecuencias de su aplicación.

ambas definiciones parecen expresar la misma idea. La diferencia entre los

planteamientos de Shaw y Garlan y Buschmann et al. viene dada por la

amplitud de la noción de componente en cada una de las 20 definiciones.

Buschmann, asume como componentes a subsistemas conformados por

otros componentes más sencillos, mientras que Shaw y Garlan utilizan la

noción de componente como elementos simples, ya sean de dato o de

proceso. En virtud de esto, la diferencia entre ambas definiciones gira en

torno al nivel de abstracción, dado que Buschmann, plantean un grado

mayor en su concepto de estilo arquitectónico, sugiriendo una estructura

genérica para la organización de componentes de ciertas familias de

 sistemas, independientemente del contexto en que éstas se desarrollen de

acuerdo a Bass, los principales estilos arquitectónicos, los atributos de

calidad que propician y los atributos que se ven afectados negativamente

(atributos en conflicto)

Atributos Atributos en
Estilo Descripción
asociados conflicto
Sistemas en los cuales Integrabilidad Desempeño
cierto número de clientes Escalabilidad
Datos accede y actualiza datos Modificabilida
centralizados compartidos de un d
repositorio de manera
frecuente.
El sistema es visto como Reusabilidad Desempeño
una serie de Modificabilida
transformaciones sobre d
piezas sucesivas de datos Mantenibilidad
de entrada. El dato ingresa
Flujo de Datos
en el sistema, y fluye entre
los componentes, de uno en
uno, hasta que se le asigne
un destino final (salida o
repositorio).
Simulan alguna Portabilidad Desempeño
funcionalidad que no es
Máquinas
nativa al hardware o
Virtuales
software sobre el que está
implementado.
Llamada y El sistema se constituye de Modificabilida Mantenibilidad
 un programa principal que d Desempeño
tiene el control del sistema Escalabilidad
y varios subprogramas que Desempeño
Retorno
se comunican con éste
mediante el uso de
llamadas.
Consiste en un número de Modificabilida Desempeño
Componentes procesos u objetos d Integrabilidad
Independiente independientes que se Escalabilidad
s comunican a través de
mensajes.

Un planteamiento reciente, propuesto por Bass et al. (1999), consiste en los estilos

arquitectónicos basados en atributos (ABAS), que se establecen como una

extensión de la noción de estilo arquitectónico, mediante la asociación de modelos

analíticos de atributos de calidad. En este sentido, los autores proponen que estos

estilos incluyen un razonamiento cualitativo o cuantitativo, basado en modelos

específicos de atributos de calidad.

Un estilo arquitectónico basado en atributos incluye:

 La topología de los tipos de componentes y una descripción del patrón de

los datos y control de interacción entre ellos, de acuerdo con la definición

estándar.
  Un modelo específico de atributos de calidad que provee un método de

razonamiento acerca del comportamiento de los tipos de componentes que

interactúan en el patrón definido.

 El razonamiento que resulta de la aplicación del modelo específico de

atributos de calidad a la interacción de los tipos de componentes

Bass et al. (1999) proponen los estilos arquitectónicos como elementos

importantes para el diseño, en tanto estos pueden ser elegidos basándose en el

entendimiento de las metas de calidad del sistema en construcción. En este

sentido, su planteamiento incluye la extensión del concepto de estilo

arquitectónico, incluyendo modelos analíticos de atributos de calidad.

Un estilo arquitectónico basado en atributos (ABAS) consta de cinco partes.

Elemento Descripción
Describe el problema de diseño que el ABAS pretende
Descripción resolver, incluyendo el atributo de calidad de interés, el
del problema contexto de uso, y requerimientos específicos relevantes al
atributo de calidad asociado
Medidas del Contiene los aspectos medibles del modelo de atributos de
atributo de calidad. Incluye una discusión de los eventos que causan que
calidad la arquitectura responda o cambie
Descripción del estilo arquitectónico en términos de
Estilo
componentes, conectores, propiedades de los componentes y
Arquitectónic
conexiones, así como patrones de datos y control de
o
interacciones
 Parámetros de Especificación del estilo arquitectónico en términos de los
atributos de parámetros del modelo de calidad
calidad
Descripción de cómo los modelos de atributos de calidad
están formalmente relacionados con los elementos del estilo
Análisis
arquitectónico y las conclusiones acerca del comportamiento
arquitectónico que se desprende de los modelos

Patrón Arquitectónico.

Buschmann et al. (1996) define patrón como una regla que consta de tres

partes, la cual expresa una relación entre un contexto, un problema y una

solución. En líneas generales, un patrón sigue el siguiente esquema:

 Contexto. Es una situación de diseño en la que aparece un problema

de diseño.

 Problema. Es un conjunto de fuerzas que aparecen repetidamente en el

contexto.

 Solución. Es una configuración que equilibra estas fuerzas. Ésta

abarca:

 Estructura con componentes y relaciones.

 Comportamiento a tiempo de ejecución: aspectos dinámicos

de la solución, como la colaboración entre componentes, la

comunicación entre ellos, etc.

 Partiendo de esta definición, propone los patrones arquitectónicos como

descripción de un problema particular y recurrente de diseño, que aparece en

contextos de diseño específico, y presenta un esquema genérico demostrado con

éxito para su solución. El esquema de solución se especifica mediante la

descripción de los componentes que la constituyen, sus responsabilidades y

desarrollos, así como también la forma como estos colaboran entre sí.

Así mismo, Buschmann et al. (1996) plantean que los patrones arquitectónicos

expresan el esquema de organización estructural fundamental para sistemas de

software. Provee un conjunto de subsistemas predefinidos, especifica sus

responsabilidades e incluye reglas y pautas para la organización de las relaciones

entre ellos. Propone que son plantillas para arquitecturas de software concretas,

que especifican las propiedades estructurales de una aplicación - con amplitud de

todo el sistema - y tienen un impacto en la arquitectura de subsistemas. La

selección de un patrón arquitectónico es, por lo tanto, una decisión fundamental de

diseño en el desarrollo de un sistema de software. Visto de esta manera, el

concepto de patrón arquitectónico propuesto por Buschmann et al. (1996) equivale

al establecido por Shaw y Garlan (1996) para estilo arquitectónico, quienes tratan

indistintamente estos dos términos.

Barbacci et al. (1997) hacen la analogía de la construcción de una arquitectura

de un sistema complejo como la inclusión de instancias de más de un patrón

arquitectónico, compuestos de maneras arbitrarias. La colección de patrones

arquitectónicos debe ser estudiada en términos de factores de calidad e intereses,

en anticipación a su uso. Esto quiere decir que un patrón puede ser analizado
previamente, con la intención de seleccionar el que mejor se adapte a los

requerimientos de calidad que debe cumplir el sistema. De manera similar,

Barbacci et al. (1997) proponen que debe estudiarse la composición de los

patrones, dado que ésta puede dificultar aspectos como el análisis, o poner en

conflicto otros atributos de calidad.

Algunos patrones arquitectónicos, además de los atributos que propician y los

atributos en conflicto, de acuerdo con Buschmann et al. (1996).

Patrón
Atributos Atributos en
arquitectónic Descripción
asociados conflicto
o
Consiste en estructurar
aplicaciones que pueden
Reusabilidad
ser descompuestas en
Portabilidad Desempeño
Layers grupos de subtareas, las
Facilidad de Mantenibilidad
cuales se clasifican de
Prueba
acuerdo con un nivel
particular de abstracción.
Pipes and Provee una estructura Reusabilidad Desempeño
Filters para los sistemas que Mantenibilidad
procesan un flujo de
datos. Cada paso de
procesamiento está
encapsulado en un
componente filtro (filter).
El dato pasa a través de
conexiones (pipes), entre
 filtros adyacentes.
Aplica para problemas
cuya solución utiliza
estrategias no
Modificabilidad
determinísticas. Varios Desempeño
Mantenibilidad
Blackboard subsistemas ensamblan Facilidad de
Reusabilidad
su conocimiento para Prueba
Integridad
construir una posible
solución parcial ó
aproximada.
Puede ser usado para
estructurar sistemas de
software distribuido con
componentes
desacoplados que Modificabilidad
interactúan por Portabilidad
invocaciones a servicios Reusabilidad
Broker Desempeño
remotos. Un componente Escalabilidad
broker es responsable de Interoperabilida
coordinar la comunicación, d
como el reenvío de
solicitudes, así como
también la transmisión de
resultados y excepciones.
Model- Divide una aplicación Funcionalidad Desempeño
ViewControler interactiva en tres Mantenibilidad Portabilidad
componentes. El modelo
(model) contiene la
información central y los
datos. Las vistas (view)
despliegan información al
 usuario. Los controladores
(controlers) capturan la
entrada del usuario. Las
vistas y los controladores
constituyen la interfaz del
usuario.

Patrones arquitectónicos y atributos de calidad

Patrón
Atributos Atributos en
arquitectónic Descripción
asociados conflicto
o
Define una estructura para
sistemas de software
interactivos de agentes de
cooperación organizados
Presentation de forma jerárquica. Cada
Modificabilidad
agente es responsable de Desempeño
Abstraction Escalabilidad
un aspecto específico de Mantenibilidad
Integrabilidad
Control la funcionalidad de la
aplicación y consiste de
tres componentes:
presentación, abstracción
y control.
Microkernel Aplica para sistemas de Portabilidad Desempeño
software que deben estar Escalabilidad
en capacidad de adaptar Confiablidad
los requerimientos de Disponibilidad
cambio del sistema.
Separa un núcleo
 funcional mínimo del resto
de la funcionalidad y de
partes específicas
pertenecientes al cliente.
Provee un mecanismo
para sistemas cuya
estructura y
comportamiento cambia
dinámicamente. Soporta la
Reflection Modificabilidad Desempeño
modificación de aspectos
fundamentales como
estructuras tipo y
mecanismos de llamadas
a funciones.

Con la intención de hacer una comparación clara entre estilo arquitectónico y

patrón arquitectónico, la tabla 11 presenta las diferencias entre estos conceptos,

construida a partir del planteamiento de Buschmann.

Estilo Arquitectónico Patrón Arquitectónico

Existen en varios rangos de escala,
Sólo describe el esqueleto estructural
comenzando con patrones que definen
y general para aplicaciones
la estructura básica de una aplicación
Partiendo de la definición de patrón,
Son independientes del contexto al
requieren de la especificación de un
que puedan ser aplicados
contexto del problema

Cada estilo es independiente de los Depende de patrones más pequeños

 que contiene, patrones con los que
otros interactúa, o de patrones que lo
contengan
Expresa un problema recurrente de
Expresan técnicas de diseño desde
diseño muy específico, y presenta una
una perspectiva que es independiente
solución para él, desde el punto de vista
de la situación actual de diseño
del contexto en el que se presenta
Son una categorización de sistemas Son soluciones generale

Un patrón de diseño provee un esquema para refinar los subsistemas o

componentes de un sistema de software, o las relaciones entre ellos. Describe la

estructura comúnmente recurrente de los componentes en comunicación, que

resuelve un problema general de diseño en un contexto particular (Buschman et

al., 1996).

Son menores en escala que los patrones arquitectónicos, y tienden a ser

independientes de los lenguajes y paradigmas de programación. Su aplicación no

tiene efectos en la estructura fundamental del sistema, pero sí sobre la de un

subsistema (Buschman et al., 1996), debido a que especifica a un mayor nivel de

detalle.

la relación de abstracción existente entre los conceptos de estilo

arquitectónico, patrón arquitectónico y patrón de diseño. En ella se representa el

planteamiento de Buschmann et al. (1996), que propone el desarrollo de

arquitecturas de software como un sistema de patrones, y distintos niveles de

abstracción.
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 de

control distinta? 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?

 La aplicación que estoy familiarizado es la del SES de la registradora

nacional.

¿Cómo se administra el control dentro de la arquitectura?

Se administra el control de una manera que en los espacios que son de carácter y

cuando ingresan números o símbolos, manda un mensaje de error a los usuarios

que deben ingresar solo letras. También no deja seguir si hacen faltas datos en los

campos de obligación.

¿Existe una jerarquía de control distinta?

Si, que la aplicación no deja ingresar al usuario cuando escribe su usuario en

mayúscula, también no deja guardar en la base de datos los seriales repetidos.

¿Cómo se comunican los datos entre los componentes?

Se comunican en general, el cual se pueden comparar con los datos de las demás

registradurías en línea ya que están conectadas a la base de datos nacional.

¿El flujo de datos es continuo o los objetos de datos pasan al sistema en

forma esporádica?

El flujo de datos en continuo porque cada tramite que se realiza queda guardado

en la base de datos local y la nacional.

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.

Componente de Software, un elemento de un sistema software que ofrece un

conjunto de servicios, o funcionalidades, a través de interfaces definidas.

Características

Un componente de software debe poseer las siguientes características:

 Ser reutilizable.

 Ser intercambiable.

 Poseer interfaces definidas.

 Ser cohesivos

Implementaciones
 Los componentes de software son la piedra angular de diferentes paradigmas

de programación. Esto ha generado la aparición en el mercado de diferentes

especificaciones que plantean la forma de construir, utilizar y distribuir

componentes. Entre las más extendidas se encuentran:

En la especificación UML, es una unidad modular con interfaces bien

definidas, que es reemplazable dentro del contexto. Así, un componente define su

comportamiento en términos de interfaces proveídas y requeridas; y dicho

componente será totalmente reemplazable por otro que cumpla con las interfaces

declaradas.

UML no coloca ninguna restricción respecto a la granularidad del componente,

de esta forma un componente podrá ser tan simple como un convertidor de

moneda o tan complejo como un sistema de ayuda semántico.

Los lenguajes de programación en que estos momentos estoy manejando

son:

PYTHON: define sus componentes como son los tipos de datos, operaciones

aritméticas, comentarios entre otras.

C#: sus componentes son los identificadores, los operadores (aritméticos,

lógicas, relacionales, asignación), los tipos de datos, variables, constantes,

estructuras de condónales y estructuras de condicionales múltiples.

 PHP: en estas son el separador de instrucciones, comentarios, tipos de datos,

variables y constante, operadores, explosiones, funciones, estructura de control,

arrays, referencias, class y objetos.

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?

Por qué en la programación orientada a objeto es difícil modificar y extender

los programas, pues suele haber datos compartidos por varios subprogramas, que

introducen interacciones ocultas entre ellos

16. Investigue sobre los tipos de cohesión y los tipos de acoplamiento

Cohesión: La cohesión hace referencia a la forma en que agrupamos

unidades de software (módulos, subrutinas…) en una unidad mayor. Por ejemplo:

la forma en que se agrupan funciones en una biblioteca de funciones o la forma en

que se agrupan métodos en una clase, etc.

El consenso general para una buena programación o un buen diseño es que la

cohesión debe ser alta. Es decir, mientras más cohesionados estén los elementos

agrupados, mejor.
La cohesión en un sistema de información puede ser de los siguientes tipos:

 Cohesión casual

 Cohesión lógica

 Cohesión temporal

 Cohesión procedural

 Cohesión de comunicaciones

 Cohesión secuencial

 Cohesión funcional

Acoplamiento: Grado de interdependencia entre las unidades de

software(módulos, funciones, subrutinas, bibliotecas, etc.) de un sistema

informático. El acoplamiento da la idea de lo dependiente que son las unidades de

software entre sí, es decir, el grado en que una unidad puede funcionar sin recurrir

a otras.

Por ejemplo, dos funciones son absolutamente independientes entre sí (es decir,

el nivel más bajo de acoplamiento) cuando una puede hacer su trabajo

completamente sin recurrir a la otra. En este caso se dice que ambas están

desacopladas.

Los tipos de acoplamientos son:

 Acoplamiento normal
  Acoplamiento externo

 Acoplamiento común

 Acoplamiento de contenido

17. ¿Qué es un componente de web App?

Las páginas webs utilizan para comunicarse con nuestros navegadores el

protocolo HTTP o HTTPS. 

En nuestra app nos puede interesar en determinadas circunstancias usar

HTTP para enviar/recibir datos a/desde un servidor web. Para conseguir esto con

App Inventor podemos utilizar el visor web si sólo queremos obtener una página

web, por ejemplo, el resultado de una búsqueda, o el componente Web si

queremos, por ejemplo, enviar los datos de un formulario de acceso a un sitio

web(login).

En Gallery os he dejado una aplicación en App Inventor que pretende ser una

prueba de cómo utilizar tanto el visor web como el componente web. 

Dicha aplicación presenta un par de simples botones y permite al usuario que

busque algo en Google (método GET de HTTP, implementado por un simple visor

web) o que mande unos datos de autenticación a un servidor web (método POST

de HTTP, implementado por el componente web). 

 Me parece interesante ilustrar cómo realizar el envío de datos con el

componente web ya que son muchas las personas que no tienen muy claro el

tema de los bloques, construir las cabeceras HTTP que tienen que poner para

mandar datos al servidor y que este los procese, etc.

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

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

programación.

Partiendo de que La programación estructurada es una teoría de programación

que consiste en construir programas de fácil comprensión.

La programación estructurada es especialmente útil, cuando se necesitan

realizar correcciones o modificaciones después de haber concluido un programa o

aplicación. Al haberse utilizado la programación estructurada, es mucho más

sencillo entender la codificación del programa, que se habrá hecho en diferentes

secciones.

Los tres lenguajes modernos de la programación estructurada tenemos a

JAVASCRIPT, PHP y PYTHON.

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.

componente codificado pequeño y represéntelo con 1

Ingeniería de sistemas basada en componentes Hace referencia a un conjunto

de componentes de software estandarizados preconstruidos que se hacen

disponibles para encajar en un estilo arquitectónico específico para cierto dominio

de aplicación.

En el contexto de la ingeniería del software la reutilización es una idea tanto

antigua como nueva. Los programadores han reutilizado ideas, abstracciones y

procesos desde los primeros días de la computación, pero el enfoque original para

la reutilización era específico. En la actualidad, los complejos sistemas de alta

calidad basados en computadoras se deben construir en un tiempo muy corto y

demanda un enfoque más organizado de la reutilización.

diagrama de actividades, 2
 El Lenguaje Unificado de Modelado incluye varios subconjuntos de diagramas,

incluidos los diagramas de estructuras, los diagramas de interacción y los

diagramas de comportamiento. Los diagramas de actividades, junto con los

diagramas de casos de uso y los diagramas de máquina de estados, son

considerados diagramas de comportamiento porque describen lo que debe

suceder en el sistema que se está modelando.

Las partes interesadas tienen muchos asuntos que manejar, por lo que es

importante una comunicación clara y concisa. Los diagramas de actividades

ayudan a que las personas en las áreas de negocios y desarrollo de una

organización se integren para comprender el mismo proceso y comportamiento.

Usarás un conjunto de símbolos especializados —incluidos aquellos para pasos

de inicio, finalización, fusión y recepción en el flujo— para crear un diagrama de

actividades, lo cual cubriremos con más detalle dentro de esta guía de diagramas

de actividades.
un diagrama de flujo, 3

Un diagrama de flujo es un diagrama que describe un proceso, sistema o

algoritmo informático. Se usan ampliamente en numerosos campos para

documentar, estudiar, planificar, mejorar y comunicar procesos que suelen ser

complejos en diagramas claros y fáciles de comprender. Los diagramas de flujo

emplean rectángulos, óvalos, diamantes y otras numerosas figuras para definir el

tipo de paso, junto con flechas conectoras que establecen el flujo y la secuencia.

Pueden variar desde diagramas simples y dibujados a mano hasta diagramas

exhaustivos creados por computadora que describen múltiples pasos y rutas. Si

tomamos en cuenta todas las diversas figuras de los diagramas de flujo, son uno
de los diagramas más comunes del mundo, usados por personas con y sin

conocimiento técnico en una variedad de campos. Los diagramas de flujo a veces

se denominan con nombres más especializados, como "diagrama de flujo de

procesos", "mapa de procesos", "diagrama de flujo funcional", "mapa de procesos

de negocios", "notación y modelado de procesos de negocio (BPMN)" o "diagrama

de flujo de procesos (PFD)". Están relacionados con otros diagramas populares,

como los diagramas de flujo de datos (DFD) y los diagramas de actividad de

lenguaje unificado de modelado (UML).

una tabla de decisión

Una decisión es una resolución que se toma entre varias alternativas. Es una

alternativa seleccionada entre varias que permite alcanzar un estado deseado en

respuesta a un problema.

La teoría de decisiones indica que se debe tomar una buena decisión de

acuerdo a un determinado problema. Se debe establecer primero que se quiere

alcanzar a lograr para plantearse una serie de alternativas que permitan escoger

la más conveniente para solucionar el problema. La decisión es efectiva o

eficiente, cuando satisface en la totalidad, o al menos en un alto porcentaje, el

objetivo o fin deseado y en el momento oportuno en que la decisión debe ser

tomada.

Estructura de la tabla de decisión

La tabla de decisión está integrada por cuatro secciones:

1. Identificación de Condiciones: señala aquellas que son más relevantes.

Se detalla una condición por renglón. Se llaman condiciones a situaciones

variables que pueden ocurrir

2. Entradas de Condiciones: indican qué valor, si es que lo hay, se debe

asociar para una determinada condición. Se indican valores de las

condiciones indicadas en la primera sección, dependiendo del tipo de tabla

de decisión (de entrada limitada o extendida) que se construya para

representar el proceso. 

3. Identificación de Acciones: enlista el conjunto de todos los pasos que se

deben seguir cuando se presenta cierta condición. Se llaman acciones a los

distintos comportamientos que se asumirán en función de los valores que

 tomen las condiciones. Se escriben en el orden en que deben ser

ejecutadas. 

4. Entradas de Acciones: muestran las acciones específicas del conjunto

que deben emprender cuando ciertas condiciones o combinaciones de

éstas son verdaderas.

LDP

Distribución de etiquetas: LDP Un nodo establece comunicación con los

vecinos Se distribuyen las etiquetas contra corriente: Dos modos: bajo petición o

automático Posible multiplicidad de caminos etiquetados de un origen a un destino

Se decide (tabla de reenvío) según la decisión del protocolo de encaminamiento IP

Retención de etiquetas: Conservativa: sólo se guardan las etiquetas de los

caminos etiquetados a utilizar Liberal: se guardan todas las aprendidas, aunque no

sean del camino etiquetado a utilizar −→ mayor velocidad ante cambios ˜ ı ´

Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion

20. ¿Por qué es importante la “lotificación” en el proceso de revisión del diseño en

el nivel de componentes?

Es importante ya que todo se encuentra divido por lotes y así le sería más fácil

tanto el usuario y al programador entender la estructura como está diseñado el

sistema.
 CONCLUSIONES

En el presente trabajo se diseñó un sistema de información logramos

comprender y poner en práctica los elementos y procesos necesarios para la

elaboración de un sistema, donde teníamos que responder preguntas tales como

patrones, interfaces, diseño arquitectónico de la red y del sistema y el diccionario

de datos, al igual que se proponen gestores de base de datos todo esto con la

finalidad de afianzarnos con el tema

En el desarrollo de curso Diseño de sistemas nos enfocamos mas en la parte

teórica como el Concepto de diseño, Diseño de la arquitectura y Diseño en el nivel

de los componentes todo esto con la finalidad de tener mas conocimiento al

momento de afrontar el curso de base de datos

 REFERENCIA BIBLIOGRAFICAS

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

[ CITATION Rey17 \l 9226 ]Carlos Reynoso, Nicolás Kicillof, (2017). Estilos y Patrones

Estrategia de Arquitectura de Microsoft: UNIVERSIDAD DE BUENOS

AIRES. Recuperado de:

http://carlosreynoso.com.ar/archivos/arquitectura/Estilos.PDF

Mohammad Al-Sabt, Matthew Evans, Geethika Agastya, Dayasankar Saminathan,

Vijay Srinivasan y Larry Brader. “Testing Software Patterns”. Microsoft

Patterns & Practices, Version 1.0.0.

 http://msdn.microsoft.com/architecture/patterns/Tsp/default.aspx, Octubre

de 2003.

UNAD (2017). Requirements Enginnering and management. [Video file].

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

[ CITATION Jim08 \l 9226 ]. Estilos Arquitectónicos, Recuperado de:

http://estilosarquitectonicos.blogspot.com/

Diccionario de la lengua española 2005 (2010). wordreference.com,

ed. «software», https://es.wikipedia.org/wiki/Software. (diccionario). Espasa-

Calpe. Consultado el 1 de febrero de 2010.

[ CITATION Moi18 \l 9226 ] . Ingeniería de requisitos y gestión. UNAD. Diseño

Sistemas. Recuperado de: https://drive.google.com/drive/folders/0B4iL-

y4KU5f5YjJsOEl1MlVOMUE?usp=sharing