miércoles, 29 de agosto de 2012

Capitulo 6 - DISEÑANDO PRODUCTOS DESEABLES PARA EL CONSUMIDOR


DISEÑANDO PRODUCTOS DESEABLES PARA EL CONSUMIDOR

Lo que nos hace ver y analizar esta lectura es que hace unos 15 o 10 años las compañías, empresas, desarrolladores de software y en general el comercio entero no tomaban  en cuenta lo que querían o necesitaban las personas en sus productos. Al pasar del tiempo fueron dándose cuenta que dependiendo de las cualidades, experiencias y necesidades de sus clientes tenían que ser desarrollados y creados los productos, para que ellos como clientes se sintieran satisfechos con dichos productos.

Con los años las necesidades de las personas van aumentando y nosotros como arquitectos y desarrolladores de software tenemos que estar al tanto de que es lo que les gusta a los clientes dependiendo de lo que también necesitan o desean.

Maslow presenta una jerarquía de necesidades humanas (1.2) y otra de necesidades de consumidor (1.3)



Autorrealización
 Estima
Pertenencia y Amor
Seguridad
Fisiológicas
    (1.2)
  
  
Placer
Usabilidad
Funcionalidad
    (1.3)


Estos dos cuadros de necesidades deben tenerse muy en cuenta a la hora de desarrollar cualquier tipo de producto para los consumidores.



Se habla de 4 placeres importantes con los cuales los clientes se relacionan con los productos. Al desarrollar un producto tenemos que pensar en:

1. Físicos: Se refieren a lo que nos hace sentir bien físicamente, lo que sentimos con los órganos. (Estar en forma, relajarse, ingerir alcohol, comer)
2. Sociales: Derivado de las relaciones sociales e interacciones que podamos tener con los demás. (Compañía, buenas relaciones personales, estatus)
3. Psicológicos: Reacciones cognitivas y emocionales. (Alivio del Estrés, estimulaciones)
4. Ideológicos:Valores derivados del arte música, naturaleza.(Decencia, responsabilidad)


Con el tiempo se desarrollaron productos que nos producen placer y tranquilidad, como el control remoto del televisor, máquina de afeitar eléctrica, teclado de computador.

Se puede concluir que los arquitectos de Software tenemos que conocer, entender lo que desean y necesitan los usuarios cuando de trabajar en un proyecto se trata.

martes, 21 de agosto de 2012


Logro de Cualidades: CAPITULO 5

En este capítulo se describe una guía para que un arquitecto de software pueda  lograr unos atributos de calidad bien definidos para el sistema en el cual se encuentre trabajando. El logro de estas cualidades depende de las decisiones de diseño fundamentales.                             
Una táctica es una decisión de diseño que influye en el control de una respuesta del atributo de calidad.                                                                                        
Un diseño de sistema consiste en una colección de decisiones. Algunas de estas decisiones ayudan a controlar las respuestas de atributos de calidad, otros asegurar el logro de la funcionalidad del sistema.

En el capítulo se presenta una organización de las tácticas por unos atributos de calidad, ya mencionados en el capitulo anterior, los cuales son: Disponibilidad, modificalidad, desempeño, seguridad, testeabilidad, y usabilidad, cada uno de estos atributos maneja un grupo de tacticas. La organización está destinada a proporcionar una ruta para buscar las tácticas apropiadas.

Tácticas del Atributo de Disponibilidad:
Muchas de las tácticas que se discuten están disponibles dentro de entornos de ejecución estándar, tales como sistemas operativos, servidores de aplicaciones, bases de datos y sistemas de gestión. Las tácticas utilizadas para que lograr los efectos de usar una en particular se deben considerar durante el diseño y la evaluación. Todos los enfoques del mantenimiento de  la disponibilidad implican algún tipo de redundancia, algún tipo de monitores de la salud para detectar un fallo, y algún tipo de recuperación cuando se detecta una falla.

Las siguientes son Tácticas para el Reconocimiento de Fallas en el Atributo de la Disponibilidad:

Detección de fallos:

Ping/echo: Cuando un componente usa un ping espera recibir de vuelta un eco, en un tiempo predefinido. Pueden ser organizados en una jerarquía, en la que el detector de nivel más bajo pings los procesos de software con los que comparte un procesador, y los detectores de fallas de alto nivel ping a los niveles inferiores.

Heartbeat: En este caso uno de los componentes emite periódicamente un mensaje de latido y otro componente de escucha. Si el latido del corazón falla, el componente de origen ha fallado y un componente de corrección de error es notificado. El latido del corazón también puede transportar datos.

Excepciones: Un método para el reconocimiento de fallos es encontrar una excepción, que se inicia cuando una de las clases de falla se reconoce.
Las tácticas de ping / echo y el ritmo cardíaco operan entre procesos distintos, y la táctica excepción opera dentro de un único proceso.

RECUPERACION DE ERRORES:

Consiste en la preparación para la recuperación y hacer la reparación del sistema. Algunas tácticas de preparación y reparación son las siguientes:

Votación: Este método se utiliza para corregir fallos en el funcionamiento de los algoritmos o fracaso de un procesador y se utiliza a menudo en control de sistemas

Redundancia activa (arranque en caliente): Todos los componentes redundantes responden a eventos en paralelo. Por lo tanto, todos están en el mismo estado. La respuesta de un solo componente se utiliza y el resto se descartan.  Redundancia activa se utiliza a menudo en una configuración cliente / servidor, como los sistemas de gestión de bases de datos, donde las respuestas rápidas son necesarias incluso cuando se produce un fallo.

Redundancia pasiva (arranque en caliente / redundancia doble / triple redundancia): Uno de los componentes (el primario) responde a los eventos e informa a los demás componentes de las actualizaciones de estado que deben hacer. Cuando se produce un fallo, el sistema primero debe asegurarse de que el estado de copia de seguridad es lo suficientemente fresco antes de reanudar los servicios. Este enfoque se utiliza también en sistemas de control, a menudo cuando las entradas vienen sobre canales de comunicación o de los sensores y tiene que ser cambiado desde la copia primaria de seguridad en caso de fallo.

Repuesto: Una plataforma de computación en espera de repuesto está configurado para sustituir muchos componentes diferentes fallidos. Esto se utiliza a menudo como la estación de trabajo cliente en espera, donde el usuario puede moverse cuando se produce un fallo. El tiempo de inactividad para esta táctica es de minutos.

Operación Sombra: Un componente que falló anteriormente se puede ejecutar en modo "sombra" por un corto tiempo para asegurarse de que imita el comportamiento de los componentes de trabajo antes de restaurarlo al servicio.

Estado de re sincronización: Las tácticas de redundancia pasiva y activa requieren que el componente que está siendo restaurado a su estado ha mejorado antes de su retorno al servicio. El enfoque de actualización dependerá del tiempo de inactividad que puede ser sostenido, el tamaño de la actualización, y el número de mensajes necesarios para la actualización.

Checkpoint / rollback: Un punto de control es una grabación de un estado coherente creado ya sea periódicamente o en respuesta a eventos específicos.

PREVENCION DE FALLOS

Puesta fuera de servicio. Esta táctica elimina un componente del sistema en operación para someterse a algunas actividades para evitar los fallos previstos.

Transacciones: Una transacción es la agrupación de varias etapas sucesivas de tal manera que todo el conjunto se puede deshacer de una vez. Las transacciones se utilizan para evitar que los datos se vean afectados si un paso en un proceso falla y también para evitar colisiones entre varios procesos simultáneos que acceden a los mismos datos.

Proceso monitor: Una vez que un fallo en un proceso  se ha detectado, un proceso de seguimiento puede eliminar el proceso y crear una nueva instancia del mismo, inicializado en un estado apropiado como en la táctica de repuesto.
Se deben conocer y poner en práctica estas tácticas en los diferentes ambientes y situaciones. Estas se deben aplicar previamente para hallar una manera fácil y adecuada para presentar una estrategia que nos disminuya errores, prevenga fallos y además sea un sistema confiable. Analizando estas tácticas desde cualquier situación antes o después de diseñar una buena arquitectura nos permite confiar mas y establecer un mejor sistema.

Se deben conocer y poner en práctica estas tácticas en los diferentes ambientes y situaciones. Estas se deben aplicar previamente para hallar una manera fácil y adecuada para presentar una estrategia que nos disminuya errores, prevenga fallos y además sea un sistema confiable. Analizando estas tácticas desde cualquier situación antes o después de diseñar una buena arquitectura nos permite confiar mas y establecer un mejor sistema.

martes, 14 de agosto de 2012


CAPITULO 3: PUNTOS DE VISTA Y VISTAS


Es necesario representar sistemas complejos de manera comprensible  y manejable para las partes interesadas y para abordar el sistema es necesario hacerlo desde diferentes direcciones simultáneamente, para ello la arquitectura es particionada en distintas vistas interrelacionadas que describen cada aspecto separado del sistema, todas unidas describen el sistema total.

Todas las vistas ilustran las características de la funcionalidad del sistema y las propiedades de calidad y  demuestran que este cumple con sus objetivos.

Una vista  arquitectónica es una manera de representar los aspectos o elementos de la arquitectura que son relevantes y en consecuencia para los grupos para los cuales el asunto es importante. Una visión es una representación de uno o muchos aspectos estructurales de una arquitectura que ilustra cómo la arquitectura trata asuntos  en manos de uno o más de sus grupos de interés.

Un punto de vista es una colección de patrones, plantillas y convenciones para la construcción de un tipo de vista. En él se definen los actores cuyos intereses  reflejan las directrices, principios y modelos de plantillas para la construcción de sus puntos de vista

El objetivo del concepto de punto de vista es poner a disposición una biblioteca de plantillas y patrones que se pueden utilizar para guiar la creación de un punto de vista arquitectónico que se puede insertar en una arquitectura.


Los puntos de vista arquitectónicos proveen un marco para capturar conocimiento arquitectónico reutilizable que puede ser usado como guía de creación de un tipo particular de arquitectura.


Un punto de vista define los objetivos, público y el contenido de una clase
de vistas  y define los asuntos  que la vista de esta clase se abordará. Una vista se ajusta a un punto de vista y así se comunica la resolución de un número de asunto. Una arquitectura comprende varias vistas.





Entre los beneficios:

-       Separación de asuntos: Ayuda al diseño, análisis y procesos de comunicación ayudando a enfocar en cada aspecto por separado.

-       Comunicación con los grupos interesados: Los grupos se pueden guiar rápidamente a los diferentes partes de la arquitectura  sobre la base de sus intereses particulares, y cada vista puede presentarse utilizando el lenguaje y la notación adecuada a la
conocimientos, experiencia, y los asuntos de los lectores,

-       Manejo de la complejidad: El arquitecto puede centrarse en cada  aspecto por separado y ayudando a conquistar la complejidad que resulta de su combinación.

-       Mejorar un foco de desarrollo: Al separar las diferentes vistas de los aspectos del sistema que son particularmente importantes para el equipo de desarrollo, ayuda a asegurar que el sistema se esta construyendo correctamente.



Existen 6 núcleos de puntos de Vista para la arquitectura del sistema:

-       Funcional: Describe los elementos funcionales del sistema sus responsabilidades, interfaces e interacciones primarias

-  Información: Describe la manera como la arquitectura almacena, manipulan administra y distribuye la información,

-  Concurrencia: Describe la estructura concurrente del sistema y el mapa funcional de los elementos a unidades de concurrencia que identifica las partes del sistema y como estas la controlan y coordinan.

-       Desarrollo: Describe la arquitectura que soporta el proceso de desarrollo de software

-  Implementación: Describe el ambiente en el cual el sistema en el cual el sistema será implementado , incluyendo y capturando las dependencias que el sistema tiene en  su ambiente de ejecución

-     Operacional: Describe como el sistema será usado, administrado y soportados cuando esta ejecutándose en un ambiente de producción.




CAPTHER 4:  PERSPECTIVAS ARQUITECTÓNICAS


Una perspectiva arquitectónica es una colección de actividades, tácticas y guías que son usadas para asegurar que un sistema exhiba un grupo de atributos que requiere ser considerados a lo largo de un número de vistas de sistemas arquitectónicos.

Las perspectivas permiten sistematizar los atributos de calidad y revisa los modelos arquitectónicos para asegurar que la arquitectura exhiba las propiedades requeridas: Identificar, prototipos, pruebas, y seleccionar las tácticas para hacer frente a los casos en que la arquitectura no los maneje.  Las perspectivas dan un contexto y formaliza este proceso.



Entre las perspectivas más importantes están: Seguridad, Desempeño y Escalabilidad, Disponibilidad, Resistencia y Evolución.

Las perspectivas están todas estructuradas por:

Aplicabilidad: Explica cual de las vistas se ve más afectada aplicando la perspectiva:

Asuntos: Esta información define los atributos de calidad que la perspectiva aborda.

Actividades: Los casos para aplicar la perspectiva a las vistas. Identificando los atributos de calidad importantes, analizando las vistas contra las propiedades haciendo al final un diseño que mejora las vistas.

Tácticas Arquitectónicas: Es enfoque establecido y probado que puede ser usado como ayuda para mejorar un atributo de calidad particular.

Problemas: Explica las cosas mas comunes que pueden fallar y da una guía de como reconocerlas y abordarlas.

Lista de verificación: Provee una lista de preguntas que ayudan  a asegurar que se esta
Las vistas arquitectónicas contienen la descripción de la arquitectura mientras las perspectivas guían a través del proceso de análisis y modificación para asegurar que se exhiben los atributos de calidad.

Consecuencias

-       Percepción:  La aplicación de una perspectiva casi siempre conduce a la creación de algún tipo de modelo que proporciona una idea de la capacidad del sistema para cumplir con una propiedad de calidad requerida.


-       Mejoras: Si la arquitectura no va a cumplir con alguna de sus propiedades de calidad, la arquitectura necesita ser mejorada, puede que necesite cambiar un modelo existente en la vista, crear modelos adicionales para desarrollar aún más el contenido de la vista, o tal vez hacer ambas cosas.


Los artefactos: Son salidas de una perspectiva de valor significativo y duradero son importantes como información de apoyo arquitectónico. Son un valioso resultado de la aplicación de una perspectiva y deben ser preservados.

Beneficios:

La perspectiva proporciona convenciones comunes, medidas, o incluso un la notación o lenguaje que se pueden utilizar para describir las cualidades del sistema.
La perspectiva define los asuntos que guían la decisión arquitectónica para ayudar a asegurar que la arquitectura resultante exhiba los atributos de calidad. La perspectiva describe cómo se puede validar la arquitectura para demostrar que cumpla con los requisitos en cada uno de los puntos de vista.

La perspectiva puede ofrecer soluciones a problemas comunes reconocidos,
lo que ayuda a compartir el conocimiento entre los arquitectos.

Es necesario solo aplicar las perspectivas más relevantes para su vista basando la selección en los asuntos de los interesados, la importancia relevante de los diferentes atributos de calidad a los mismos, y su propia experiencia y el juicio.
También utilizamos las perspectivas como un medio de captura de los problemas comunes y la búsqueda de soluciones a los mismos. Hay muchos puntos de vista, y no es generalmente posible o conveniente aplicar todas las perspectivas a todas las vistas.




miércoles, 8 de agosto de 2012

CAPITULO 4 - ATRIBUTOS DE CALIDAD



Atributos de Calidad – Arquitectura de Software: CAPITULO 4


Los atributos de calidad hacen referencia a los objetivos que se esperan alcanzar con la arquitectura de software. Estas cualidades están por encima de la funcionalidad, que es la declaración básica de las capacidades del sistema, los servicios, y el comportamiento.
La Funcionalidad es la capacidad del sistema para hacer el trabajo para el cual fue destinado. Una tarea requiere que muchos o la mayoría de los trabajos del sistema de los elementos en forma coordinada para completar el trabajo.
El logro de los atributos de calidad se debe considerar  en todo el diseño, implementación y despliegue de la arquitectura de Software. Los atributos de calidad nunca se pueden lograr de manera aislada. El logro de cualquiera de ellos tiene un efecto, a veces positivas y negativas, a veces, en el logro de los demás. Es necesario crear escenarios generales  para lograr atributos de calidad de manera organizada.

Los atributos de calidad se dividen en tres Clases:

1.               Atributos del Sistema:

Disponibilidad: es la probabilidad de que el sistema sea operativo cuando se necesita. Se refiere a un fallo del sistema y sus consecuencias asociadas. Este fallo se genera cuando el sistema ya no ofrece un servicio de acuerdo con su especificación.

Modificabilidad: está relacionado con el costo de cambios en el sistema, estos cambios pueden darse en cualquier aspecto, en las funciones, la plataforma, el entorno en el que opera, las cualidades de sus objetos, y su capacidad. Se pueden hacer cambios a la aplicación durante la compilación, durante la construcción, durante la configuración o durante la ejecución Los cambios los puede hacer un promotor, un usuario final, o un administrador del sistema.

Rendimiento: está relacionado al tiempo. Corresponde al tiempo que tarda el sistema para responder cuando se produce un evento. La satisfacción de la solicitud de servicio requiere de recursos para ser consumido. Mientras esto sucede el sistema puede hacer al mismo tiempo las demás solicitudes de servicio.

Seguridad: es la capacidad del sistema para resistir el uso no autorizado sin dejar de ofrecer sus servicios a los usuarios legítimos. Se caracteriza por previsión, confidencialidad, integridad, seguridad, disponibilidad, no repudio y de auditoría en el sistema.

Contrastabilidad del Software: Se refiere a la probabilidad que se producirá un error en la ejecución de la prueba de un sistema. Con las pruebas se pueden ahorrar el 40% del costo de desarrollo. Las pruebas se realizan por varios desarrolladores, probadores, verificadores o usuarios, y es el último paso de varias partes del ciclo de vida del software. Las porciones del código, el diseño, o el sistema completo pueden ser probados.

Usabilidad: tiene que ver con la facilidad que el sistema le da al usuario para realizar una tarea deseada y el tipo de apoyo que le sistema le da al usuario.

2.               Atributos  del Negocio:

Estos atributos se centran en el precio, el calendario, el mercado y las consideraciones de marketing. Hace referencia al tiempo de comercialización, costos y beneficios, vida útil proyectada del sistema, mercado de destino. Despliegue previsto. Integración con sistemas heredados.

Cualidades del Negocio:
·         Time to market: Cuando hay competitividad en el Mercado el buen desarrollo se vuelve indispensable.
·         Costo y Beneficio: Diferentes arquitecturas producirán diferentes costos, una arquitectura flexible será más costosa.
·         Vida útil prevista del sistema: Si el sistema está estimado para una larga vida, es modificable, escalable y portable, empieza a ser un sistema más importante.
·         Objetivo del Mercado: Portabilidad y funcionalidad serán la llave del éxito de una Buena participación en el Mercado.
·         Implementación de Horario: Si el producto se presenta con una funcionalidad base y luego con muchas  funciones, este será importante. Sistema expandible.
·         Integración con sistemas Antiguos: Es importante que si un sistema nuevo se tiene que integrar con uno antiguo, hay que definir los mecanismos correctos de integración para que más adelante no tenga implicaciones negativas e impactos en el mercado.

3.               Atributos acerca de la Arquitectura en sí misma:

La integridad conceptual es la visión que unifica el diseño del sistema en todos los niveles

Exactitud e integridad son esenciales para la arquitectura permitiendo que todos los requisitos del sistema y las limitaciones de tiempo de ejecución de los recursos se cumplan.

Edificabilidad, Se refiere a la facilidad de construir un sistema con base a una  arquitectura en módulos, con criterio de asignación de los módulos a los equipos de desarrollo, y la limitación de las dependencias entre los módulos.

Escenarios de Atributos de Calidad

Sample performance scenario


Consiste en seis partes.
·         Fuente de Estimulo: Una entidad como (una persona, un computador, o algún otro que genere un estimulo.
·         Estimulo: Es una condición que necesita ser considerara cuando  llega a un sistema.
·         Alrededor (Ambiente): Estimulo sucede en ciertas condiciones. El sistema puede ser recargado cuando el estimulo ocurre o cuando una condición es verdadera.
·         Artefacto: Algún artefacto es estimulado puede ser todo el sistema o ciertas partes de ella.
·         Respuesta: Respuesta tomada cuando llega el estimulo.
·         Respuesta de Medición: Cuando la respuesta ocurre debe ser medida y manejable y así el requerimiento puede ser medido.



viernes, 3 de agosto de 2012


Caso A7-E- Avionics Systems


El caso A7-E  marca un presendete muy importante para la Arquitectura de Software siendo un buen ejemplo del diseño de un proyecto orientado al éxito de un sistema de aviación. Este Caso de estudio gira en torno de la descomposición, usos y procesos como método de diseño de la solución. Para llegar a su fin fue necesario contar con un equipo conformado por un experto en el tema de la Aviacion, que apoyó al Arquirecto de Software ya que es indispensable el conocimiento y dominio  del tema junto al encargado de la construcción del software.

El caso de A-7E aplica una arquitectura de software muy bien desarrollada, este software llevaba incluido una gran cantidad de técnicas de diseño implementación y técnicas de ejecución de software, lo implementaron en una maquina de IBM. En este caso se denotan la integración de módulos y diferentes estructuras relacionadas para mayor productividad y respuesta en tiempo real que era lo que buscaban ellos (científicos e ingenieros).

Cuando implementaron arquitectura de software en este caso tuvieron que tener en cuenta recursos, costos y alcances como en cualquier otro proyecto, lo cual hace que el proyecto funcione o no.

Todo parte del levantamiento y correcto planteamiento de los requerimientos funcionales y no funcionales de software  para lograr el objetivo como el alto rendimiento por exigir una ejecución del programa en tiempo real y  lograr asi mismo modificabilidad de este sistema a los cambios que puedan presentarse.
A pesar de que este software no fue implementado, duro mas de 6 años, un proyecto muy largo, ha servido de  base de muchos otros que posteriormente tomaron el diseño y llegaron a un fin satisfactorio. Un proyecto de este tipo de importancia requiere mucho conocimiento, recursos económicos y de personal y un nivel alto de eficiencia por parte de los integrantes.



miércoles, 1 de agosto de 2012

Software Arquitecture In Practice - Capitulo 2


Que es la Arquitectura de Software?




Cuando un proyecto cuenta con una Arquitectura de sistema este llegará crecer y desarrollarse como se espera ya que esta es requerida tanto para el proceso de desarrollo como de mantenimiento del sistema.
Es necesario explorar el valor de la arquitectura de software como influye esta en el desarrollo de un proyecto y el valor retornado a la empresa.
Se podria definir la Aquitectura de Sistemas de Software de computador como la estructura o estructuras del sistema que implica elementos de software, estos siempre con propiedades visibles y las reaciones entre estos.
La arquitectura es una abstraccion de un sistema que suprime los detalles de los elementos que no afecta al modo en que se utiliza, y nos da claridad sobre los sistemas que  pueden comprometer mas de una estructura ya que una estructura no es la arquitectura.
Todos sistema de computador con software tiene una arquitectura de software porque cada sistema que puede ser mostrado comprende elementos y una relacion entre ellos y teniendo en cuenta que el comportamiento de los elementos es lo que permite su interaccion siempre este es parte de la arquitectura
El estudio de arquitectura de software se ha desarrollado mediante la observación de los principios de diseño que los diseñadores han seguido al trabajar  en sistemas reales.
Todos sistema tiene una una arquitectura que puede ser estudiada independientemente de cualquier conocimiento que se tenga del proceso en que se diseño o evoluciono su arquitectura.

Las etapas representan el resultado de un conjunto de decisiones arquitectónicas:

-          Patrón: Un patrón puede ser pensado como un conjunto de restricciones sobre una arquitectura de los tipos de elementos y sus patrones de interacción y estas restricciones definen un conjunto o una familia de arquitecturas que las satisfacen
son conceptos útiles que captan elementos de una arquitectura. Cada uno es el resultado de las decisiones iniciales del diseño, los patrones presentan atributos de calidad. Esta es la razón por la arquitecto elige un patrón particular y no una al azar.

-        Modelo de Referencia: una descomposición estándar de un problema conocido en partes que ayudan a   resolver el problema.




-          Arquietectura de referencia: es el mapeo de que la funcionalidad a un sistema de descomposición
Un arquitecto de software debe diseñar un sistema que ofrece la concurrencia, portabilidad, modificabilidad, usabilidad, seguridad, y similares, y que refleja la consideración de las ventajas y desventajas entre estas necesidades.


La arquitectura de software es importante por:

-       La comunicación entre las partes interesadas. Arquitectura de software representa una abstracción de un sistema común donde  todos los actores del sistema pueden usarlo  como base para el entendimiento mutuo donde, diferentes intereses se pueden expresar, negociar y resuelver a un nivel que es intelectualmente manejable incluso para sistemas grandes y complejos.

Las primeras decisiones de diseño. Arquitectura de software, manifiesta las primeras decisiones de diseño sobre un sistema.es el primer punto en el que las decisiones de diseño que rigen el sistema a ser construido pueden ser analizadas.

Estas primeras decisiones son las más difíciles crear correctamente y la más difícil de cambiar más adelante en el proceso de desarrollo, y tienen los efectos más profundos.

-          La abstracción transferible de un sistema. Arquitectura de software constituye una parte relativamente pequeña, el modelo de intelectual este modelo es transferible a través de sistemas. En particular, se puede aplicar a otros sistemas que exhiben atributo de calidad similar y los requisitos funcionales y pueden promover a gran escala de re-uso.


Las estructuras arquitectonicas se dividen segun la naturaleza de sus elementos:

-          Estructuras de Modulo: los elementos son los módulos, que son unidades de ejecución. Los módulos representan una forma basada de considerar el sistema a través del codigo. Se les asigna áreas de responsabilidad funcional

• ¿Cómo es el sistema que se estructura como un conjunto de unidades de código (módulos)?
-          Descomposicion
-          Uso
-          Capas
-          Clases o Generalizacion

-          Estructuras de Componente y conector: los elementos son los componentes de tiempo de ejecución (que son las principales unidades de computación) y conectores (que son los vehículos de comunicación entre los componentes).
• ¿Cómo esta estructurado el sistema como un conjunto de elementos que tienen un comportamiento en tiempo de ejecución (los componentes) y las interacciones (conectores)?
-Procesos deComunicacio
-Concurrencia
-Datos compartidos
- Cliete-Servidor

-          Estructuras de Dsitribucion: muestran la relación entre los elementos de software y los elementos en uno o más entornos externos en el que el software es creado y ejecutado

• ¿Cómo esta el sistema relaconado con las estructuras non-software en su entorno (es decir, las CPU, los sistemas de archivos, redes, equipos de desarrollo, etc)?
-Despliegue
-Implementacion
-Asignacion de Trabajo

En Las estructura del sistema hay propiedades del sistema, además de su funcionalidad, como la distribución física, el proceso de comunicación y sincronización, que deben ser considerados a nivel arquitectónico. Cada estructura ofrece un método para razonar acerca de algunos de los atributos de calidad pertinentes.

Aunque las estructuras pueden dar diferentes perspectivas del sistema, estas no son independientes. Los Elementos de una se relacionan con elementos de otra, y tenemos que razonar acerca de estas relaciones.

Las estructuras representan los puntos primarios de ingeniería de apalancamiento de una arquitectura. Las estructuras individuales traen con ellos el poder de manipular uno o más atributos de calidad. Ellas representan un poderoso de separación de las preocupacpermiten separar las necesidades o preocupacion para enfocarlas en la creación de la arquitectura


Metodo Para validar que las estructuras no estaban en conflicto una con otra:

• Lógico. Los elementos son abstracciones "clave", que se manifiestan en el mundo orientado a objetos como objetos o clases de objetos. Esta es una vista en módulo.

• Proceso. Este punto de vista aborda la concurrencia y la distribución de funciones. Es una vista de componente-y-conector.

• Desarrollo. Esta vista muestra la organización de módulos de software, bibliotecas, subsistemas, y unidades de desarrollo. Es una vista de asignación, el mapeo de software para el entorno de desarrollo.

• Física. Este punto de vista de otros elementos traza en el procesamiento y nodos de comunicación y es también un punto de vista de la asignación (que otros llaman el punto de vista de despliegue).


En la lectura se conocieron diferentes conceptos sobre las diferentes  Arquitecturas que existen, lo que es mas claro es que la Arquitectura de Software se apropia de todos los procesos y estructuras que se encuentran en un sistema, estudia la comunicación y relación entre ellas. La arquitectura de software define los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos.







La arquitectura de software nos provee un lenguaje común que se puede expresar, resolver, negociar, manejar, ordenar y entender los diferentes tipos de sistemas, esta es muy importante porque nos permite modelar posibles soluciones y ver los diferentes procesos y estructuras de un sistema, es por eso que así de esa manera podemos desarrollar grandes proyectos y dar soluciones rápidas y eficientes a un problema sistémico.