lunes, 14 de diciembre de 2009

CARACTERIZACION DE COMPONENTES


·         Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios y que permita su clasificación.
·         Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.
·         Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.
·         Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.
·         Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.
·         Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
·         Es genérico: Sus servicios debe servir para varias aplicaciones.
·         Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
·         Independiente de la plataforma: Hardware, Software, S.O.
·         Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
·         Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
·         Completo: Un requerimiento esta completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la Información suficiente para su comprensión.
·         Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
·         No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
·         Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

sábado, 12 de diciembre de 2009

COMPONENTES DE SOFTWARE



Definición de un componente de software.- "Un componente de software (CS) es una unidad de composición con interfaces especificadas en forma de contrato y con dependencias de contexto explícitas. Un componente de software puede ser desplegado (deployed) o instalado independientemente y es sujeto a ser composición por terceras entidades".
Vamos lo que quiere decir esta definición es que un CS puede ser instalado en algún lugar (llámese software o sistema) pero que tiene que cumplir con ciertas especificaciones (interfaces) o bien bajo cierto contexto (tecnología posiblemente), ejemplos de CS sería por ejemplo, los assemblies de .NET, los EJB's de J2EE, los applets de Java, incluso los Java Beans.
Como ven estos están muy atados a ciertas tecnologías, de aquí surgen ciertas metodologías como la MDA (Model Driven Architecture) que busca diseñar sistemas en base a modelos o componentes, y que al momento de pasarlo a un sistema, con una serie de traductores se podría ya hacer a la tecnología deseada, como J2EE y .NET por ejemplo.
Un componente de software tiene las siguientes características:
·         Es una unidad ejecutable que puede ser implantada independientemente (esto de implantado es que puede ser instalado, en ingles deployment).
·         Puede ser sujeto de composición por terceras partes, es decir, una compañía o un desarrollador puede llegar y tomar el componente y agregarlo a lo que esté haciendo, o sea haría una composición de componentes.
Un componente no tiene estado (al menos externamente visible)
·         Se puede tomar a los componentes de software como una analogía a los componentes electrónicos, la idea de esto es tener diversos componentes que puedan ser tomados para hacer un sistema más grande, así como tomar procesadores, integrados, memorias, etc. para hacer una computadora por ejemplo.
Existen diversos modelos de componentes, los más conocidos son .NET, EJB (Enterprise Java Beans) y CCM (CORBA Component Model).
El paradigma de desarrollo orientado a componentes es un campo emergente, en donde hay muchas cosas dichas pero nada que esté bien definido y que nos pueda servir como receta.

GRANULARIDAD
La granularidad de sincronización, o frecuencia, entre procesos en el sistema, es una buena manera de caracterizar multiprocesadores y ubicarlos en un contexto con otras arquitecturas. Se pueden distinguir cinco categorías de paralelismo que difieren en el grado de granularidad. Estas categorías se encuentran resumidas así:
Tamaño de grano
Descripción
Intervalo de sincronizacion (instrucciones )
Fino
Paralelismo inherente en un único flujo de instrucciones.
< 20
Medio
Procesamiento paralelo o multitarea dentro de una aplicación individual.
20-200
Grueso
Multiprocesamiento de procesos concurrentes en un entorno multiprogramado.
200-2000
Muy grueso
Proceso distribuido por los nodos de una red para formar un solo entorno de computación.
2000-1M
Independiente
Varios procesos no relacionados
(N/A)

 Procesos y granularidad de la sincronización
 Paralelismo de Grano Fino: El paralelismo de grado fino representa un uso mucho más complejo del paralelismo que es encontrado en el uso de hebras. Aunque muchos  trabajos han sido  hechos en aplicaciones   altamente paralelas, es un área especializada y fragmentada, con muchos enfoques diferentes.
Paralelismo de Grano Medio: Una aplicación puede ser efectivamente implementada como una colección de hebras  con un paralelismo simple. En este caso, el paralelismo potencial de una aplicación debe ser explícitamente especificado por el programador. Generalmente  se necesitará un alto grado de coordinación e interacción entre las hebras de una aplicación, elevando a un nivel medio de sincronización.
Mientras que el paralelismo independiente, de grano grueso y de grano muy grueso pueda verse respaldados tanto en un monoprocesador  multiprogramado como en un multiprocesador con poco o ningún impacto sobre la función de planificación, se debe revisar la planificación cuando se trata de la planificación de hilos. Puesto que los diversos hilos de una planificación interactúan de forma muy frecuente, las decisiones de planificación que involucran a un hilo pueden afectar al rendimiento de la aplicación completa.
Paralelismo de Grano Grueso y muy grueso: Con esta clase de paralelismo existe sincronización entre procesos pero a nivel muy grosero. Esta clase de situación es fácilmente entendible como un grupo de procesos concurrentes  ejecutándose en un monoprocesador multiprogramado y puede ser soportado en un multiprocesador con un pequeño o no cambio al software del usuario.
Un ejemplo simple de una aplicación que puede aprovechar la presencia de un microprocesador. Los autores han desarrollado un programa que recibe una especificación de los archivos que necesitan ser recopilados para reconstruir una parte del software y determinan cuales de estas compilaciones (normalmente todas) pueden ejecutarse simultáneamente el programa crea entonces un proceso para cada compilación paralela. Los resultados indican que la aceleración en un multiprocesador  supera la que realmente la que podría esperarse añadiendo simplemente el número de procesadores usados, debido a las sinergias en las caches del disco y compartir el código del compilador, que se carga en la memoria solo una vez.
En general, cualquier conjunto de procesos concurrentes que necesiten comunicarse o sincronizarse puede aprovechar el uso de las arquitecturas  de los multiprocesadores. Un sistema distribuido puede ofrecer un soporte adecuado en caso de interacciones poco frecuentes entre los procesos. Sin embargo, si la interacción es algo más frecuente, la sobrecargada de comunicaciones a través de la red puede anular parte de la posible aceleración. En este caso, la organización del multiprocesador ofrece el soporte más efectivo.
Paralelismo Independiente: Entre los procesos no existe una sincronización explícita. Cada uno representa una separación, una aplicación independiente. El uso típico de este tipo de paralelismo es en los sistemas de tiempo compartido.
Cada usuario está ejecutando una aplicación en particular, como un procesador de textos o una hoja de cálculo. El multiprocesador ofrece el mismo servicio que un procesador multiprogramado. Como hay más de un procesador disponible, el tiempo medio de respuesta a los usuarios será menor.
Es posible alcanzar un aumento similar de rendimiento proporcionado a cada usuario un computador personal o una estación de trabajo. Si van a compartirse archivos o alguna información, entonces se deben conectar los sistemas individuales  en un sistema distribuido soportado por una red. Por otro lado, un único sistema multiprocesador ofrece, en muchos casos, un coste mejor que un sistema distribuido, pudiendo así mejorar los discos y otros periféricos.

POLIMORFISMO

Definición de polimorfismo.- La palabra polimorfismo proviene del griego y significa que posee varias formas diferentes. Este es uno de los conceptos esenciales de una programación orientada a objetos. Así como la herencia está relacionada con las clases y su jerarquía, el polimorfismo se relaciona con los métodos.
En general, hay tres tipos de polimorfismo:

Polimorfismo paramétrico (también llamado polimorfismo de plantillas)
Polimorfismo de inclusión (también llamado redefinición o subtipado)


Polimorfismo de sobrecarga
El polimorfismo de sobrecarga ocurre cuando las funciones del mismo nombre existen, con funcionalidad similar, en clases que son completamente independientes una de otra (éstas no tienen que ser clases secundarias de la clase objeto). Por ejemplo, la clase complex, la clase image y la clase link pueden todas tener la función "display". Esto significa que no necesitamos preocuparnos sobre el tipo de objeto con el que estamos trabajando si todo lo que deseamos es verlo en la pantalla.
Por lo tanto, el polimorfismo de sobrecarga nos permite definir operadores cuyos comportamientos varían de acuerdo a los parámetros que se les aplican.

Polimorfismo paramétrico
El polimorfismo paramétrico es la capacidad para definir varias funciones utilizando el mismo nombre, pero usando parámetros diferentes (nombre y/o tipo). El polimorfismo paramétrico selecciona automáticamente el método correcto a aplicar en función del tipo de datos pasados en el parámetro.

Polimorfismo de subtipado

La habilidad para redefinir un método en clases que se hereda de una clase base se llama especialización. Por lo tanto, se puede llamar un método de objeto sin tener que conocer su tipo intrínseco: esto es polimorfismo de subtipado. Permite no tomar en cuenta detalles de las clases especializadas de una familia de objetos, enmascarándolos con una interfaz común (siendo esta la clase básica).
Imagine un juego de ajedrez con los objetos rey, reina, alfil, caballo, torre y peón, cada uno heredando el objeto pieza.
 
El método movimiento podría, usando polimorfismo de subtipado, hacer el movimiento correspondiente de acuerdo a la clase objeto que se llama. Esto permite al programa realizar el movimiento.de_pieza sin tener que verse conectado con cada tipo de pieza en particular.


NOTA: Leer la información, consultar términos que no conoce. Esto le servirá como refuerzo a los temas tratados en clase.


viernes, 30 de octubre de 2009

Video de Arquitectura de Software



Revisar el siguiente video y manifestar sus comentarios sobre el tema, realizar una investigacion sobre algún tema que se trata en el video.   

viernes, 23 de octubre de 2009

Plan Analítico

UNIVERSIDAD ESTATAL DE BOLÍVAR
FACULTAD D E CIENCIAS ADMINISTRATIVAS GESTIÓN EMPRESARIAL E INFORMÁTICA
PLAN ANALÍTICO


1. DATOS DE IDENTIFICACION

ESCUELA:             SISTEMAS
CARRERA:            INGENIERIA EN SISTEMAS COMPUTACIONALES
ASIGNATURA:     ARQUITECTURA DE DESARROLLO DE SOFTWARE
PROFESORA:     Ing. MONICA BONILLA
CURSO:               DECIMO SEMESTRE
MODALIDAD: PRESENCIAL
HORAS:            96 HORAS
REQUISITO:  PROYECTOS DE INGENIERIA DE SOFTWARE
AÑO LECTIVO: 2009-2010

2. FUNDAMENTACION DE LA ASIGNATURA

La arquitectura de desarrollo de software nos permite utilizar enfoques orientados a componentes , conociendo los aspectos organizacionales y prácticos para la instauración de estrategias basadas en componentes.

La asignatura aporta tecnologías para el desarrollo guiado por las arquitecturas con el propósito de construir sistemas que brinden un mejor soporte a las organizaciones.

3. OBJETIVOS

a. OBJETIVOS INSTRUCTIVOS

 Ser consciente de la importancia de la arquitectura de software
 Conocer los componentes de modularidad.
 Establecer la mejor arquitectura en la resolución de problemas.

b. OBJETIVOS EDUCATIVOS

 Desarrollar sistemas utilizando enfoques orientados a componentes.
 Aplicar los aspectos de mantenibilidad, escalabilidad, modularidad y desempeño.
 Utilizar las tecnologías para desarrollo guiado por las arquitecturas con el propósito de construir sistemas con mejor soporte.


4. SISTEMA DE HABILIDADES

El estudiante será capaz de:

 Entender la arquitectura de software, las relaciones entre componentes y los requisitos funcionales y de calidad.
 Reconocer el conjunto de cualidades importantes en un producto de software.
 Aprender a enfocar el desarrollo de software basado en módulos que colaboren entre si.
 Reconocer las características y capacidades de distintas tecnologías para la elaboración y uso de componentes.
 Efectuar análisis de escalabilidad, mantenibilidad y desempeño a las estrategias de implantación.
 Elaborar diferentes vistas arquitectónicas de un sistema y analizar las características de los componentes resultantes.

5. DISTRIBUCION POR FORMAS DE ENSEÑANZA



6.METODOLOGÍA
Exposición de los temas en el salón de clase por parte del docente.
Tareas escritas para promover la práctica de los temas vistos.
Auto estudio de temas complementarios.
Los alumnos llevarán a cabo investigaciones sobre propuestas particulares para el desarrollo basado en componentes.


7.EVALUACIÓN
Se realizara de forma permanente, sistemática y continua.
Se evaluaran los ejercicios y prácticas de los temas tratados.
Evaluación de un proyecto final.

8.BIBLIOGRAFÍA

Ingeniería de Software, Presman, Tercera edición.