jueves, 31 de mayo de 2012


12  SEMANA – ANALISIS Y DISEÑO DE SOFTWARE 

CLASIFICACIÓN DE ESTILOS
Los estilos arquitectónicos se clasifican en los siguientes grupos:

1. SISTEMAS BASADOS EN FLUJOS
1. Filtros y Pipes
2. Procesamiento por lotes

2. SISTEMAS CALL/RETURN
1. Sistemas Principal/subrutinas
2. Sistemas OO
3. Capas jerárquicas

3. COMPONENTES INDEPENDIENTES
1. Procesos de comunicación
2. Cliente / Servidor
3. Sistemas de Acontecimientos o Eventos

4. MÁQUINAS VIRTUALES
1. Interpretes
2. Sistemas basados en el conocimiento

5. SISTEMAS CENTRADOS EN DATOS
1. Bases de Datos (Repositorios)
2. Sistemas de HiperTexto
3. Sistemas de pizarra

martes, 29 de mayo de 2012


11  SEMANA – ANALISIS Y DISEÑO DE SOFTWARE 

Modelos o vistas
Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:
§  La visión estática: describe qué componentes tiene la arquitectura.
§  La visión funcional: describe qué hace cada componente.
§  La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí.
Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).



10  SEMANA – ANALISIS Y DISEÑO DE SOFTWARE 

Arquitectura
La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.
§  Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco
§  Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
§  La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una  física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.


lunes, 23 de abril de 2012

9 SEMANA – ANALISIS Y DISEÑO DE SOFTWARE


Desarrollo de software. Ciclo de vida RUP (Rational Unified Process)
RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo desoftware y después en función de la naturaleza del mismo haces las adaptaciones oportunas (sin salirte de las fronteras que te marca la metodología porque de lo contrario estaríamos hablando de algo que no sería RUP).
RUP sigue principios de ingeniería del software para la obtención de sistemas de información de calidad y de esta forma proporcionar una alternativa que permita evitar que los productos que se obtengan caigan en los aspectos que caracterizan a la crisis del software (todavía muy presente en nuestros días).
RUP sigue una estrategia de ciclo de vida iterativo e incremental, pero de una forma un tanto peculiar, como vamos a ver a continuación.
El ciclo de vida RUP se divide en 4 fases: Iniciación, Elaboración, Construcción y Transición.
En cada fase se realizan una o más iteraciones (con el objeto de ir perfeccionando los objetivos, mediante el feedback del usuario) y hasta que no finaliza una fase no se comienza con la siguiente. Por regla general, la fase en la que se realizan más iteraciones es la Contrucción.
En cada fase se refinan los objetivos de las fases anteriores en el proceso de conseguir el objetivo o objetivos de la fase, por ejemplo, en la fase de construcción se pueden modificar, añadir o eliminar requisitos, casos de uso, etc… lo que tiene un impacto en lo obtenido en fases anteriores, acercándonos cada vez más a un sistema que satisfaga las necesidades de los usuarios.
En cada fase y en cada iteración se realiza un ciclo de vida en cascada con las siguientes etapas: Análisis, Diseño, Construcción (las tareas de programación que se realizan, sobre todo las fases de Construcción y Transición son perfectamente compatibles con la utilización de técnicas deintegración continua y análisis estático de código), Pruebas/Integración/Implantación. El alcance del ciclo de vida depende en la fase en la que nos encontremos, es decir, aunque se realice un ciclo de vida en cascada en la fase de Iniciación, lo más probable es que no se llegue a construir nada o se llegue a algún a hacer algún prototipo de muy alto nivel.
Los objetivos que se persiguen en cada fase son los siguientes:
- Iniciación: Obtención de los objetivos, catálogo de requisitos, identificación de casos de uso.
- Elaboración: Refinamiento de los objetivos de la fase anterior, casos de uso, análisis, diseño, definición y establecimiento de la arquitectura base del sistema.
- Construcción: Refinamiento de los objetivos de las fases anteriores y construcción del sistema de información.
- Transición: Refinamiento de los objetivos de las fases anteriores e implantación del sistema de información (preparación del producto para su entrega y pasos a producción de versiones no finales (porque hay que hacer ajustes) y de la versión final prevista).
Por tanto, como se comentó anteriormente, en cada etapa y en cada iteración se perfeccionan los productos previos que hayan requerido algún cambio, todo eso mientras se intentan conseguir los objetivos concretos de la fase. De esta forma el ciclo de vida RUP sigue un modelo adaptativo de desarrollo de software.
De esta forma, el reparto de esfuerzos entre actividades varían de una fase a otra.





Una característica importante del RUP es que todo el proceso está guiado por los casos de uso, algo que resulta lógico cuando hablamos de modelos incrementales, ya que están orientados al usuario y como tal es importante tener siempre presente el esquema de interacción usuarios/sistema, los cuales vienen definidos por los casos de uso y sus escenarios.
RUP pretende la obtención de productos de muy alta calidad (extendiéndose esta no solo al cumplimiento de las expectativas del usuario, sino a la obtención de productos con una deuda técnica aceptable), si bien sus características: varias fases, múltiples iteraciones por fases, pueden provocar que el proceso de desarrollo sea costoso y que no se adapte a proyectos de pequeña escala, aunque el hecho de que siga un esquema incremental permitiría dar flexibilidad en el caso de que fuera necesario.
Personalmente prefiero la aplicación de ciclos de vida iterativos incrementales de una forma más directa, sin aplicar múltiples iteraciones para liberar una nueva versión del producto, si bien el ciclo de vida RUP es muy potente y sigue la misma estrategia, es decir, aproximarse al proceso real de desarrollo de software en el cual el producto va creciendo conforme los usuarios van comprendiendo cómo queda el sistema.

  

sábado, 21 de abril de 2012


VIDEO DE MODELAMIENTO DE REFERENCIA RUP O CICLO DE VIDA RUP




VIDEO DE DIAGRAMA DE SECUENCIA




viernes, 6 de abril de 2012

8 SEMANA – ANALISIS Y DISEÑO DE SOFTWARE



ESPECIFICACIONES TECNICAS DE SOFTWARE "NOTAS IUCESMAG"


El software a estudiar es posiblemente el que se utiliza en la IUCESMAG cabe aclarar que no es el sotware real es solo un ejemplo para comprender mas a fondo como trabajar unaTABLA DE REQUERIMIENTOS.
EJEMPLO:
F = requerimientos fucionales.
U= requerimientos no funcionales.
ESPECIFICACIONES TECNICAS DE SOFTWARE "NOTAS IUCESMAG"


TABLA DE REQUERIMIENTOS.


DIAGRAMA DE CASO DE USO DEL SOFTWARE ANTERIORMENTE DESCRITO:



domingo, 1 de abril de 2012

7 SEMANA -  ANALISIS Y DISEÑO DE SOFTWARE

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

A menudo  los requerimientos de sistema de software se clasifican en funcionales y no funcionales o como requerimientos de dominio.

requerimientos funcionales 

son declaraciones de los servicios que proveera el sistema de la manera en que este reaccionara a entradas particulares. en algunos casos los requerimientos funcionales de los sistemas tambien declaran explicitamente lo que el sistema no debe hacer.

los requerimientos fucionales de un sistema describen la fucnionalidad o los servicios que se espera que este provea. estos dependen de el tipo de software y del sistema que se desarrolle y de los psibles usuarios del software.

requerimientos no funcionales

son restricciones de los servicios  o funciones ofrecidos por el sistema . incluyen restricciones de tiempo sobre el proceso de desarrollo, estandares etc.
son aquellos requerimientos que no se refieren directamente a las funciones especificas que entrega el sistema sino a las propiedades emergentes de este como la fiabilidad la respuesta en el tiempo y la capacidad de almacenamiento. de forma alternativa definen las restricciones del sistema de datos que se utiliza en la interface del sistema. 
EJEMPLO USO :