Actividad 1
VISTAS PRINCIPALES DE ARQUITECTURA DE SOFTWARE
El
Modelo de 4+1 Vistas
El
modelo 4+1 describe la arquitectura del software usando cinco vistas
concurrentes. Tal como se muestra en la Figura 1, cada vista se
refiere a un conjunto de intereses de diferentes stakeholders del
sistema.
La
vista lógica describe el modelo de objetos del diseño cuando se usa
un método de diseño orientado a objetos. Para diseñar una
aplicación muy orientada a los datos, se puede usar un enfoque
alternativo para desarrollar algún otro tipo de vista lógica, tal
como diagramas de entidad-relación.
La
vista de procesos describe los aspectos de concurrencia y
sincronización del diseño.
La
vista física describe el mapeo del software en el hardware y refleja
los aspectos de distribución.
La
vista de desarrollo describe la organización estática del software
en su ambiente de desarrollo.
La
Arquitectura Lógica
a
arquitectura lógica apoya principalmente los requisitos funcionales
–lo que el sistema debe brindar en términos de servicios a sus
usuarios. El sistema se descompone en una serie de abstracciones
clave, tomadas (principalmente) del dominio del problema en la forma
de objetos o clases de objetos. Aquí se aplican los principios de
abstracción, encapsulamiento y herencia. Esta descomposición no
solo se hace para potenciar el análisis funcional, sino también
sirve para identificar mecanismos y elementos de diseño comunes a
diversas partes del sistema.
La notación para la vista lógica se deriva de la notación de Booch. Esta se simplifica considerablemente de tal modo de tener en cuenta solamente los items relevantes para la arquitectura. En particular, los numerosos adornos disponibles son bastante inútiles a este nivel del diseño. Usamos Rational Rose para a poyar el diseño lógico de la arquitectura
La figura 3 Muestra las principales clases que forman parte de la arquitectura de una muestra de PBX que desarrollaron en Alcatel.
Un PBX establece comunicaciones entre terminales. Un terminal puede ser un teléfono una linea troncal(una linea a la oficina central), Una linea de unión (Un PBX privado o una linea PBX).
La
Vista de Procesos
La
arquitectura de procesos se describe en varios niveles de
abstracción, donde cada nivel se refiere a distintos intereses. El
nivel más alto la arquitectura de procesos puede verse como un
conjunto de redes lógicas de programas comunicantes (llamados
“procesos”) ejecutándose en forma independiente, y distribuidos
a lo largo de un conjunto de recursos de hardware conectados mediante
un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse para
apoyar la separación de la operación del sistema en línea del
sistema fuera de líneas, como también para apoyar la coexistencia
de versiones de software de simulación o de prueba.
Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente (i.e., comenzar, recuperar, reconfigurar, y detener). Además, los procesos pueden replicarse para aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad.
Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente (i.e., comenzar, recuperar, reconfigurar, y detener). Además, los procesos pueden replicarse para aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad.
Vista
de Desarrollo
La
vista de desarrollo se centra en la organización real de los módulos
de software en el ambiente de desarrollo del software. El software se
empaqueta en partes pequeñas –bibliotecas de programas o
subsistemas– que pueden ser desarrollados por uno o un grupo
pequeño de desarrolladores. Los subsistemas se organizan en una
jerarquía de capas, cada una de las cuales brinda una interfaz
estrecha y bien definida hacia las capas superiores.
La
vista de desarrollo de un sistema se representa en diagramas de
módulos o subsistemas que muestran las relaciones exporta e importa.
La arquitectura de desarrollo completa sólo puede describirse
completamente cuando todos los elementos del software han sido
identificados. Sin embargo, es posible listar las reglas que rigen la
arquitectura de desarrollo – partición, agrupamiento, visibilidad–
antes de conocer todos los elementos.
La notación tal como se muestra en la figura 6 utilizamos una variable de la notación de Booch limitándonos aquellos items relevantes de la arquitectura.
Ejemplo de a Arquitectura de Desarrollo: La figura 7 representa la Organización del desarrollo en cinco capas de linea de productos de sistemas de control de trafico aéreo desarrollados por Hughes Aircraft de Canadá. Esta es la arquitectura de desarrollo correspondiente a la arquitectura lógica.
Arquitectura
Física
Mapeando
el software al hardware
La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identificados –redes, procesos, tareas y objetos– requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre el código fuente en si.
La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identificados –redes, procesos, tareas y objetos– requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre el código fuente en si.
Los diagramas físicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto toman diversas formas,con o sin el mapeo de la vista de procesos.
Ejemplo de diagrama Físico La figura 9 muestra una configuración de hardware posible para un gran PABX.
Actividad 2
Sistema
Contable Para Una Empresa
<!--[if!
supportLists]--> .<!--[endif]-->Requerimientos
del software
<!--[if!
supportLists]--> o <!--[endif]-->Sistema
Operativo Windows XP
<!--[if!
supportLists]--> o <!--[endif]-->Flash
player 9
<!--[if!
supportLists]--> o <!--[endif]-->Virtual
box 4.2
<!--[if!
supportLists]--> o <!--[endif]-->Requerimientos
funcionales
<!--[if!
supportLists]--> o <!--[endif]-->Procesos
de negocios: Para este sistema es necesario la interaccion de varios
actores y áreas, como son: cajas, atención al usuario, cartera,
recaudo, tesorería; esto con el fin de encontrar una interacción entre los procesos para tener un producto final que es la
contabilidad de la empresa
Actividad 3
REQUERIMIENTOS
NO FUNCIONALES:
Disponibilidad:
según la necesidad de los usuarios estará disponible la Base de
Datos, teniendo en cuenta las características de acceso de cada
usuario
Seguridad:
según la clasificación de los roles de los usuarios, podrán tener
acceso para la modificación y consulta de la Base de Datos
Modificabilidad:
a necesidad de los usuarios el software podrá ser modificado, no sin
antes de un previo análisis de las mejoras y sus requerimientos.
Usabilidad:
Software de fácil aprendizaje y manejo.
RESTRICCIONES
DEL NEGOCIO:
Tiempo:
El tiempo de vida útil de este software es acorde a las necesidades
de la empresa
Legales:
En acogida a normas legales, impuestas por el estado y por la empresa
Actividad 4
No hay comentarios:
Publicar un comentario