3. Estilos de Arquitectura
Son una transformación que se impone al diseño
de todo el sistema. El objetivo es establecer una
estructura para todos los componentes del
sistema
4. Arquitectura ADL
ADL-Lenguaje descriptivo de modelado
arquitectónico de software que se focaliza en la
estructura de alto nivel de la aplicación antes
que en los detalles de implementación de sus
módulos concretos. Su abreviatura es ADL
5. Frameworks, Vistas, Proceso,
Metodologias, Abstraccion y Escenarios
Arquitectura Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador => Modelo =>
Vista), ya que debemos fragmentar nuestra programación. Tenemos que contemplar estos aspectos
básicos en cuanto a la implementación de nuestro sistema:
Modelo Este miembro del controlador maneja las operaciones lógicas, y de manejo de información
(previamente enviada por su ancestro), para resultar de una forma explicable y sin titubeos. Cada
miembro debe ser meticulosamente llamado, con su correcto nombre y en principio, con su verdadera
naturaleza: el manejo de información, su complementación directa. VistaAl final, a este miembro de la
familia le corresponde dibujar, o expresar la última forma de los datos: la interfaz gráfica que interactúa
con el usuario final del programa (GUI). Después de todo, a este miembro le toca evidenciar la
información obtenida hasta hacerla llegar al controlador. Solo (e inicialmente), nos espera demostrar la
información. Controlador Con este apartado podemos controlar el acceso (incluso todo) a
nuestra aplicación, y esto puede incluir: archivos, scripts, y/o programas; cualquier tipo de información
que permita la interfaz. Así, podremos diversificar nuestro contenido de forma dinámica, y estática (a la
vez); pues, sólo debemos controlar ciertos aspectos (como se ha mencionado antes).
Estructura Dentro del controlador, modelo o vista podemos manejar lo siguiente: datos. Depende de
nosotros como interpretar y manejar estos 'datos'. Ahora, sabemos que el único dato de una dirección
estática web es: conseguir un archivo físico en el disco duro o de internet, entre otros. e interpretado o
no, el servidor responde.
El modelo, al igual que el controlador y la vista, maneja todos los datos que se relacionen consigo (solo
es el proceso medio de la separación por capas que ofrece la arquitectura MVC). Y sólo la vista, puede
demostrar dicha información. Con lo cual ya hemos generado la jerarquía de nuestro programa:
Controlador, Modelo y Vista.
6. Campos de Arquitectura
Arquitectura de las computadoras
La cibernetica
la robotica
la computacion
Base de datosMinería de datos
Almacén de datos
Sistema de gestión de base de
datos
Modelo relacional
Computación científica
Bioinformática
Computación Cuántica
Neurociencia computacional
Comunicación y seguridad
Red de computadoras
Servidores
Seguridad informática
Compiladores y lenguajes de
programación
Compilador
Lenguajes de programación
Teoría de lenguajes de programación
Semántica formal
Ingeniería de software
ingeniería de software
Programación
Diseño de algoritmos
Análisis de algoritmos
Ingeniería inversa
Inteligencia artificial
Inteligencia artificial
Razonamiento automatizado
Robótica
8. Diferencias entre Arquitectura y
Diseño
Una postura afirma que arquitectura y diseño son lo
mismo.
Otra, en cambio, alega que la arquitectura se
encuentra en un nivel de abstracción por
encima del diseño, o es simplemente otro paso (un
artefacto) en el proceso de desarrollo de software.
Una tercera establece que la arquitectura es algo
nuevo y en alguna medida diferente del diseño
(pero de qué manera y en qué medida se dejan sin
especificar)
9. Repositorios
Existen unos cuantos repositorios de información arquitectónica, cuyas direcciones
son
más o menos permanentes. El más importante hoy en día parece ser el del Software
Engineering Institute en la Universidad Carnegie Mellon de Pittsburgh, Pennsylvania
(http://www.sei.cmu.edu/ata/ata_init.html). El sitio del SEI incluye abundante
literatura
académica y todas las especificaciones o recomendaciones metodológicas.
Entre los organismos que definen estándares, son esenciales los servicios de
información
de RM-ODP en http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html,
TOGAF
en http://www.software.org/pub/architecture/togaf.asp, DoDAF (hogar del C4ISR) en
http://www.software.org/pub/architecture/dodaf.asp. El estándar IEEE 1471-2000 se
puede encontrar en http://www.techstreet.com/cgi-bin/detail?product_id=879737. El
marco de referencia empresarial de Zachman se puede acceder desde
http://www.software.org/pub/architecture/zachman.asp.
10. Estilos Arquitectonicos
La mayoría de las arquitecturas de software de sistemas grandes no
utilizan un único estilo, por tanto, se pueden diseñarse diferentes
partes del sistema utilizando distintos estilos arquitectónicos, de este
modo se obtiene una arquitectura compuesta gracias a la combinación
de los diferentes estilos.
CUALIDADES DEL SOFTWARE QUE PROPICIAN
CLASIFICACIÓN DE LOS ESTILOS ARQUITECTÓNICOS
PRINCIPALES ESTILOS ARQUITECTÓNICOS
ESTILOS DE FLUJO DE DATOS
ESTILOS CENTRADOS EN DATOS
ESTILOS DE LLAMADA Y RETORNO
ESTILOS DERIVADOS ESTILOS DE CÓDIGO MÓVIL
ESTILOS HETEREOGÉNEOS
ESTILOS PER TO PER
CRITERIOS PARA LA SELECCIÓN DE UN ESTILO ARQUITECTÓNICO
11. Patrones Arquitectonicos
Programación por capas
Tres niveles
Pipeline
Invocación implícita
Arquitectura en pizarra
Arquitectura dirigida por eventos, Presentaciónabstracción-control
Peer-to-peer
Arquitectura orientada a servicios
Objetos desnudos
Modelo Vista Controlador
12. Patrones de Diseño
Los patrones de diseño pretenden:
Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
Formalizar un vocabulario común entre diseñadores.
Estandarizar el modo en que se realiza el diseño.
Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existente.
Asimismo, no pretenden:
Imponer ciertas alternativas de diseño frente a otras.
Eliminar la creatividad inherente al proceso de diseño.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el
mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que
en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones
puede ser un error".