arquitectura de software

vistas principales de la arquitectura de software

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.

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.

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

.Requerimientos del software

o Sistema Operativo Windows XP

o Flash player 9

o Virtual box 4.2

o Requerimientos funcionales

o 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

link crucigrama

https://www.dropbox.com/s/jysmlmsbm5lk12e/crucigrama1.htm

CARTILLA 2

Mecanismos comunes en UML

Se aplican en forma consistente a través de todo el lenguaje.

· 1. especificaciones.

· 2. adornos.

· 3. divisiones comunes.

· 4. mecanismos de extensibilidad.

Especificaciones: detrás de un icono de clase hay una especificación que proporciona el conjunto completo de atributos, operaciones y comportamiento que incluye la clase. La notación gráfica de UML se utiliza para visualizar un sistema, la especificación de UML se utiliza para expresar los detalles del sistema. Proporcionar una base semántica que incluye a todos los modelos de un sistema y cada parte está relacionado con las otras de manera consistente.

Adornos: se pueden incluir detalles como abstracción, visibilidad de sus atributos y operaciones.

Divisiones comunes.

· División entre clase y objeto: una clase es una abstracción, un objeto es una manifestación concreta de esa abstracción.

· División entre interfaz e implementación: una interfaz declara un contrato y una implementación re presenta una realización concreta de ese contrato.

· División entre tipo y rol: el tipo declara la clase de una entidad como un objeto, un atributo, un parámetro. Un rol describe el significado de una entidad en un contexto, como una clase, un componente ó una colaboración.

MECANISMOS DE EXTENSIBILIDAD

· 1. estereotipos.

· 2. valores etiquetados.

· 3. restricciones.

Estereotipo: extiende el vocabulario UML.

Valor etiquetado: extiende las propiedades de un estereotipo permitiendo añadir nueva información en la especificación de ese estereotipo.

Restricción: extiende la semántica de un bloque de construcción.

Arquitectura

Es el conjunto de decisiones significativas sobre:

· la organización de un sistema software.

· La selección de elementos estructurales y sus interfaces a través de los cuales se construye el sistema.

· Su comportamiento, cómo se especifica en las colaboraciones entre esos elementos.

· La composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente más grandes.

· El estilo arquitectónico que guía esta organización.

La arquitectura del software no tiene que ver solamente con la estructura y el comportamiento, sino también con el uso, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas y tecnológicas y los compromisos entre alternativas, así como los aspectos estéticos.

Vista de casos de uso: comprende los casos de uso que describen el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas.

Vista de diseño: comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solución. Esta vista soporta principalmente los requisitos funcionales del sistema, entendiendo por ellos los servicios que el sistema debería proporcionar a sus usuarios finales.

Vista de interacción: muestra el flujo de control entre sus diversas partes, incluyendo los posibles mecanismos de concurrencia y sincronización.

Vista de implementación: comprende los artefactos que se utilizan para ensamblar y poner en producción el sistema físico.

Vista de despliegue: contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema.

Ciclo de vida del desarrollo de software

UML es bastante independiente del proceso, sin embargo lo ideal es un proceso que sea:

· Dirigido por los casos de uso.

· Centrado en la arquitectura.

· Iterativo e incremental.

Dirigido por los casos de uso: se utilizan como un artefacto básico para establecer el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.

Centrado en la arquitectura: la arquitectura del sistema se utiliza como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema en desarrollo.

Iterativo: es aquel que involucra la gestión de un flujo de versiones ejecutables.

Incremental: es aquel que implica la integración continua de la arquitectura del sistema para producir esas versiones, donde cada nuevo ejecutable incorpora mejoras incrementales sobre los otros. En conjunto, un proceso iterativo e incremental está dirigido por el riesgo, lo que significa que cada nueva versión se encarga de atacar y reducir los riesgos más significativos del proyecto.

concepción: es la primera fase del proceso, cuando la idea principal para el desarrollo se lleva al punto de estar suficientemente bien fundamentada para garantizar la entrada en la fase de elaboración.

Elaboración: es la segunda fase del proceso, cuando se definen los requisitos del producto y su arquitectura.

Construcción: es la tercer fase del proceso, cuando el software se lleva desde una base arquitectónica ejecutable hasta su disponibilidad para la comunidad de usuarios. Aquí los requisitos del sistema y los criterios de evaluación son constantemente reexaminados frente a las necesidades del proyecto.

Transición: es la cuarta fase del proceso, cuando el software es puesto en las manos de la comunidad de usuarios.

El ciclo de vida del desarrollo de software puede caracterizarse por involucrar un flujo continuo de versiones ejecutables de la arquitectura del sistema con correcciones entre ellas , después de cada iteración.

ACTIVIDAD 2

GRÁFICO 1

GRÁFICO 2

ACTIVIDAD 3

ACTIVIDAD 4

link crucigrama

https://www.dropbox.com/s/k8hcwen0u1338be/cartilla2.htm

CARTILLA 3

DESCRIPCIÓN DE UN CASO DE USO

Ejercicio 1:

Del siguiente diagrama de caso de uso, construir el respectivo formato de descripción de caso de uso:

Caso de Uso	Consultar Resultados
Actores	Administrador y Sistema
Tipo	Esencial
Referencias
Precondición	Que el Administrador este en la base de datos
Pos condición	N/A
Autor	Darío García		Fecha		14/08/2013	Versión		1
Propósito
Consultar Resultados
Resumen
El administrador consulta los resultados
Curso Normal	Paso	Acción
	1	Iniciar sesión
	2	Validar inicio de sesión
	3	Buscar resultados
	4	Procesar búsqueda de resultados
	5	Mostrar Búsqueda de Resultados
Cursos Alternos	Paso	Acción
	2A	Usuario Incorrecto, Solicitar la digitación de un usuario habilitado
	2B	Contraseña incorrecta, Solicitud de una contraseña correcta
	2C	Usuario y contraseña incorrectos, solicitar la digitación de usuario y contraseñas correctas
	5A	No se encuentran resultados, ir al paso 3 y solicitar la digitación de datos correctos de búsqueda y repetir el paso 4.
Otros Datos
Frecuencia Esperada	100 por hora			Rendimiento
Importancia	Alta			Urgencia			Alta
Estado	Pendiente por revisión			Estabilidad			Moderada

Ejercicio 2:

Del siguiente diagrama de caso de uso, construir el respectivo formato de descripción de caso de uso.

Caso de Uso	Consultar Registro
Actores	Administrador y Sistema
Tipo	Esencial
Referencias
Precondición	Que el Administrador este en la base de datos
Postcondición	N/A
Autor	Darío García		Fecha		14/08/2013	Versión		1
Propósito
Consultar registros
Resumen
El administrador inicia sesión y busca un registro, el sistema consulta registro y muestra registro.
Curso Normal	Paso	Acción
	1	Iniciar sesión
	2	Validar inicio de sesión
	3	Buscar registros
	4	Procesar consulta de registros
	5	Mostrar consulta de registros
Cursos Alternos	Paso	Acción
	2A	Usuario Incorrecto, Solicitar la digitación de un usuario habilitado
	2B	Contraseña incorrecta, Solicitud de una contraseña correcta
	2C	Usuario y contraseña incorrectos, solicitar la digitación de usuario y contraseñas correctas
	5A	No se encuentran registros con los datos especificados, ir al paso 3 y solicitar la digitación de datos correctos de búsqueda y repetir el paso 4.
Otros Datos
Frecuencia Esperada	100 por hora			Rendimiento
Importancia	Alta			Urgencia			Alta
Estado	Pendiente por revisión			Estabilidad			Moderada

EJERCICIO 3.

Del siguiente formato de descripción, dibujar el respectivo caso de uso.

EJERCICIO 4.

Del siguiente formato de descripción, dibujar el respectivo caso de uso.

EJERCICIO 5.

Una biblioteca tiene copias de libros. Estos últimos se caracterizan por su nombre, tipo (novela, teatro, poesía, ensayo), editorial, año y autor.

Ø Los autores se caracterizan por su nombre, nacionalidad y fecha de nacimiento.

Ø Cada copia tiene un identificador, y puede estar en la biblioteca, prestada, reservada, con retraso o en reparación.

Ø Los lectores pueden tener un máximo de 3 libros en préstamo.

Ø Cada libro se presta un máximo de 30 días, por cada día de retraso, se impone una “multa” de dos días sin posibilidad de coger un libro.

Ø Realiza el diagrama de colaboración para el método devolver().

EJERCICIO 6.

Identificar las clases relevantes y realizar el diagrama de secuencia para el siguiente caso de uso, que corresponde a la realización de una llamada desde un teléfono móvil.