tipos de arquitectura de software.

Arquitectura cliente servidor:

Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto.
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo. 

Beneficios:
Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo).
Reduce el tráfico en la Red.
Opera bajo sistemas abiertos.
Permite el uso de interfaces gráficas variadas y versátiles.

¿ Qué es el Cliente?
Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores.
Características:
El Cliente oculta al Servidor y la Red.
Detecta e intercepta peticiones de otras aplicaciones y puede redirigirlas.
Dedicado a la cesión del usuario ( Inicia...Termina ).
El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls).
Funciones Comunes del Cliente:
Mantener y procesar todo el dialogo con el usuario.
Manejo de pantallas.
Menús e interpretación de comandos.
Entrada de datos y validación.
Procesamiento de ayudas.
Recuperación de errores.

¿ Qué es el Servidor?
Conjunto de Hardware y Software que responde a los requerimientos de un cliente.
Tipos Comunes de Servidores:
Servidor de Archivos.
Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX).
Servidor de Comunicaciones
Servidor de Impresión.
Servidor de Terminal.
Servidor de Aplicaciones.
Funciones Comunes del Servidor:
Acceso, almacenamiento y organización de datos.
Actualización de datos almacenados.
Administración de recursos compartidos.
Ejecución de toda la lógica para procesar una transacción.
Procesamiento común de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación)

Arquitectura multiprocesador:

es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido.

El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional.

 Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software. Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

Para lograrlo, es necesario modificar varias facetas del sistema operativo, la organización del código de las propias aplicaciones, así como los lenguajes de programación.

Se configuran dos computadoras de gran capacidad interconectados electrónicamente entre si. Esta configuración recibe el nombre de multiproceso y se caracteriza porque permite proceso de datos continuo aún en el caso de que surjan problemas de funcionamiento en alguno de las computadoras.

Un ejemplo de este tipo de sistema se muestra en la figura 6.3. Éste es un modelo sencillo de un sistema de control de tráfico aéreo. Un conjunto de sensores distribuidos recolecta la información del flujo de tráfico y la procesa localmente antes de enviarla al cuarto de control. Los operadores toman decisiones utilizando esta información y dan instrucciones a un proceso de control de diversas luces de tráfico. En este ejemplo existen varios procesos lógicos para administrar los sensores, el cuarto de control y las luces de tráfico. Estos procesos lógicos son procesos sencillos a un grupo de procesos. En este ejemplo se ejecutan en procesadores diferentes.

Los sistemas de software compuestos de procesos múltiples no necesariamente son sistemas distribuidos. Si más de un procesador está disponible, entonces se puede implementar la distribución, pero los diseñadores del sistema no siempre consideran lo puntos de distribución durante el proceso de diseño. El enfoque de diseño para este tipo de sistemas es esencialmente el mismo que para los de tiempo real.

Los sistemas multiprocesador  son un tipo de arquitectura con una importancia creciente y ampliamente difundido. La mayoría de los constructores de computadores ofrece máquinas en las que están presentes más de una CPU, configuración que es hoy en día de uso habitual en casi todos los sistemas de tamaño medio y grande, incluso ya en ordenadores personales. Asimismo, los fabricantes de procesadores incorporan a sus arquitecturas, desde hace unos años, los mecanismos necesarios para que éstos se puedan emplear fácilmente, y con un coste reducido.

Arquitectura P2P:

En una red de par a par, los computadores en red actúan como socios en partes iguales, o pares. Como pares, cada computador puede tomar la función de cliente o de servidor. En algún momento, el computador A pedirá un archivo al computador B, el cual responderá entregándole el archivo al computador A. El computador A funciona como cliente, mientras que el B funciona como servidor. Más tarde, los computadores A y B cambiarán de papel. 

es una tecnologia que permite la transmision y difusion de material televisivo a traves de la red publica internet usando para ello una arquitectura P2P en la mayoria de los casos de tipo no estructurada - descentralizada. A diferencia de las arquitecturas de IPTV existentes las arquitecturas P2P-TV no cuentan con un servidor central para la distribucion del contenido, en esta los nodos que componen la red estan conectados entre si de forma aleatoria a traves de enlaces logicos, convirtiendo cada uno de estos en clientes y servidores de video simultaneamente, en la siguiente grafica podemos ver una arquitectura P2P-TV.

 

Aquí veremos un pequeño seminario sobre la arquitectura de software

La investigación sobre Arquitectura del Software y Usabilidad 


El interés por la relación entre Arquitectura del Software y usabilidad no es nuevo, pero recientemente han aparecido algunos trabajos que abren el camino a la práctica del resultado de las investigaciones. Este año, tanto en Viena, en la Conference on Human Factors in Computing Systems (CHI2004), como en Edimburgo, en la International Conference on Software Engineering (ICSE04), un equipo liderado por Len Bass ha impartido un tutorial sobre el tema, cuyo título es bastante ilustrativo: Avoiding “We can’t change THAT!”: Software Architecture & Usability (Cómo evitar “¡Esto no se puede cambiar!”: Arquitectura del Software y Usabilidad).


Patrones arquitecturales Bass continúa con una propuesta de patrón arquitectural para cada escenario (sobre el tema de patrones, consultad el artículo de Luis Villa, Patrones para el diseño de interfaz, publicado en Grancomo). El objetivo es doble:

• Facilitar a los expertos en usabilidad una checklist con escenarios que muestre aspectos de usabilidad importantes a tener en cuenta en tiempo de requerimientos.

• Facilitar a los arquitectos patrones que los guíen en el momento de dar soporte a los escenarios.

Otro documento interesante es: Patrones de Usabilidad: Mejora de la Usabilidad del Software desde el momento Arquitectónico (PDF), de Natalia Juristo y Maribel Sánchez-Segura. Una de las aportaciones más interesantes de este documento es que describe el procedimiento de obtención de los patrones de usabilidad que han de servir para construir los patrones arquitectónicos.

 la arquitectura de software también  es la estructura de ese sistema, que incluye componentes de software, las propiedades visibles externas de esos componentes, y las relaciones entre estos. El término también puede incluir la documentación sobre la arquitectura de software del sistema.
Una arquitectura software consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información. 

Arquitectura de software


un pequeño resumen sobre análisis y diseño de sistemas-arquitectura de software.

Usabilidad y Arquitectura del Software 

Sin embargo, a menudo hay que ir más lejos y no basta con tener en cuenta la presentación y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los entornos distribuidos, los transaccionales, los multicanal y aquéllos en los que puede haber miles de usuarios conectados simultáneamente, hay que tener en cuenta la usabilidad desde el inicio del diseño del sistema, es decir, desde lo que se denomina momento de Arquitectura del Software. 

Es bien sabido por los ingenieros del software que cuanto más tarde se detectan los problemas, más cuesta arreglarlos. ¿Cuántas veces nos ha pasado que, al diseñar una interfaz, desearíamos crear interacciones y diálogos que el entorno tecnológico no nos permite? Y siempre acabamos exclamando: ¡Pero si esto mismo lo hice en tal otro sitio! La respuesta de los técnicos no se hace esperar y, utilizando un vocabulario lleno de siglas y conceptos técnicos, nos dicen que en su plataforma esto no es posible. 

Me refiero a cosas como que el usuario pueda visualizar el progreso de sus peticiones, que pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que pueda cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar información que ha introducido anteriormente, y muchas otras cosas. 

Si analizamos estos escenarios de interacción, veremos que la causa de que no se puedan implementar es que no se tuvo en cuenta al usuario al inicio del diseño del sistema, es decir, en la Arquitectura del Software. 

¿Qué es la Arquitectura del Software?
 Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:

• Definir los módulos principales
• Definir las responsabilidades que tendrá cada uno de estos módulos
• Definir la interacción que existirá entre dichos módulos:
• Control y flujo de datos
• Secuenciación de la información
• Protocolos de interacción y comunicación
• Ubicación en el hardware

La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos posteriores del diseño. 

La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”. 

Ejemplos de Arquitectura del Software: J2EE y MVC 


 a continuación se muestran dos diagramas de arquitectura en un entorno J2EE. Ambos diagramas están disponibles en Designing Enterprise Applications with the J2EE Platform, Second Edition. 
El primer diagrama consiste en una vista lógica que muestra los componentes y servicios típicos de un entorno J2EE. 

El segundo diagrama es una vista de proceso que muestra las relaciones entre las capas model, view y controller de la arquitectura MVC bajo J2EE. 

Arquitectura de software


 debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".
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 arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

El Diseño integral de soluciones informáticas de acuerdo a los nuevos estándares de ingeniería de software es una labor muy relevante y estratégica dentro de su ciclo de vida.




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 ( 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).

Arquitecturas comunes 

Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:

• Monolítica
. Donde el software se estructura en grupos funcionales muy acoplados.

• Cliente-servidor
. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.

• Arquitectura de tres niveles
. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia).

Ciclo de vida RUP.

RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo de software 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 de integración continua y análisis estático de códigos), 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 implementacion de sistemas 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 esfuerzo 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.

Aqui veremos un ejemplo del diagrama de caso de uso.

Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

Actores

Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

Casos de Uso

Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema

Relaciones entre Casos de Uso

Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

En este veremos un diagrama de clase UML.

Un diagrama de clases esta compuesto por los siguientes elementos:

• Clase: atributos, métodos y visibilidad.

• Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

• Clase

• 

• Superior

 Contiene el nombre de la Clase

• Intermedio

 Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).

• Inferior

 Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

ejemplo de diagrama de secuencia

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas:

De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).

Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Ciclo de vida SCRUM.

SCRUM es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Scrum se promueve como complemento de otras metodologías, incluyendo XP, MSF o RUP

Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, implementacion y demás técnicas. Se define como un proceso de magnitud y control que implementa técnicas de control de procesos.

Scrum se basa en los siguientes principios ágiles:

· Colaboración estrecha con el cliente

· Predisposición y respuesta al cambio

· Personas sobre procesos

· Desarrollo incremental con entregas funcionales frecuentes

· Comunicación verbal directa entre los implicados en el proyecto

· Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y                       compromiso

· Simplicidad: Supresión de artefactos innecesarios en la gestión del proyecto

Este gráfico esquematiza perfectamente los roles, artefactos y el pro.

Ciclo de vida.

El Sprint es el período de tiempo durante el que se desarrolla un incremento de funcionalidad:

· Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeñas carreras.

· La duración máxima de un sprint es de 30 días.

· Durante el sprint no se puede modificar el trabajo que se ha acordado en el Sprint Backlog.

· Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el SCRUM   Master si decide que no es viable por algunas de las razones siguientes:

 La tecnología acordada no funciona

 Las circunstancias del negocio han cambiado

 El equipo ha tenido interferencias

Product Backlog:

 Listado con los requerimientos del sistema. Contiene: característica, requerimientos de desarrollo (no funcionales), tareas investigativas, bugs.

 Es responsabilidad del Propietario del producto:

 Es una combinación de funcionalidades y tareas

 Es un documento dinámico que incorpora constantemente las necesidades del sistema. Se mantiene durante todo el ciclo de vida (hasta el retiro del sistema).

Sprint Backlog

Tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de funcionalidad.

Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo

En Scrum se debe ir registrando los tiempos día a día para poder armar el gráfico de avance del proyecto

El equipo agrega tareas cuando lo crea necesario, pudiendo eliminar las que considere innecesarias, y ajusta estimaciones a medida se avanza

de este lenguaje UML se desprenden:
diagrama de caso de uso
diagrama de clase
diagrama de secuencia
diagrama de actividades
entre otros.
-diagrama de caso de uso: un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.


-diagrama de clase:es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.


-diagrama de secuencia: Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.


-diagrama de actividades: representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.

UML.

el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad, Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

este vídeo habla todo lo de siclo de vida en cascada, es muy interesante ya que describe las faces principales, también mustra uno de los principales modelos en cascadas etc.

todo sobre análisis y diseño.

empezare hablando de la ingeniería de software es área de la ciencias de la computación que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelve problemas de todo tipo, la ingeniería de software no solo una disciplina que debe seguirse para proyectos de software que se encuentren pensando dentro de ciertas áreas, por el contrario trata con áreas muy diversas de las ciencias de la computación tales como construcción de compiladores,sistemas operativos o desarrollos en Internet.la ingeniería de software abarca todas las faces del siclo de vida del desarrollo de cualquier tipo de sistemas de información aplicables a áreas tales como los negocios, investigación científica, producción, logística etc.

un aspecto muy importante de ingeniería de software es que proporciona parámetros formales para lo que se conoce como gestión de proyectos de software. esto se refiere a que ingeniería de software proporciona diversas métricas y metodología que pueden usarse como especificaciones para todo lo referente a la administración del personal involucrado en proyectos de software, siclos de vida de un proyecto de software, costo de un proyecto y en si todo el aspecto administrativo que implica desarrollar software.

deacuerdo con pressman ingenieria en general es el analisisn diseño, construccion, verificacion y gestion de entidades tecnicas, en general todo proceso de ingeniería debe comenzar por contestar las siguientes preguntas; ¿cual es el problema a resolver?, ¿cuales son las caracteristicas  de la entidad que se utiliza para resolver el problema?.

la ingeniería de software se basa en análisis, diseño, desarrollo e implementación; en el análisis se utilizan las técnicas de recolección de hechos, dentro de esa esta:

-entrevista

-cuestionario

-observación

-revisión de documentos

mas adelante hablare de cada una de ellas,

en el diseño se trabaja toda la parte de la apariencia del software también se trabaja con UML.

que son:

-los casos de usos

-diagrama de secuencia

-diagrama de clase

en este caso estamos utilizando los casos de uso que comprende la interacción entre el usuario y el sistema compuesto por actores.

esto es mas o menos un ejemplo de los casos de usos.

en el desarrollo define las jornadas de programación dependiendo del modelo que estemos utilizando. y en la implementación introduce la fase de prueba y mantenimiento,utilizando un plan de contingencia.

entrando un poco en el tema de los siclos de vida hablare de cada uno de los métodos de este que son:

-Cascada

-RUP

-SCRUM

-Formales

-Evolutivo

-Espiral

-XP

el siclo de vida en Cascada este es el más básico de todos los modelos, y sirve como bloque de construcción para  los  demás  modelos  de  ciclo de  vida.  La  visión del  modelo  cascada del 

desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una  fase  contribuye a  la  satisfacción de  metas  de esa  fase o  quizás  a una subsecuencia de metas de la fase.

El modelo de ciclo de vida cascada, captura algunos principios básicos:

• Planear un proyecto antes de embarcarse en él.

•  Definir  el  comportamiento externo deseado del sistema antes de diseñar su arquitectura   interna.

• Documentar los resultados de cada actividad.

• Diseñar un sistema antes de codificarlo.

• Testear un sistema después de construirlo.

Una de  las contribuciones  más  importantes  del  modelo  cascada es  para  los 

administradores, posibilitándoles avanzar en el desarrollo,aunque en una escala 

muy cerrada.

Bueno el RUP es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

 El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor insistencia en las distintas actividades. Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la de limitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una Línea Base de la arquitectura.

ahora les diré los que es un SCRUM es una metodología para la gestión de proyectos. Es considerada una metodología ágil para el desarrollo de software, si bien SCRUM puede ser aplicado para la administración de proyectos de prácticamente cualquier índole.

 todo el desarrollo ocurre en iteraciones de duración fija. Estas iteraciones de duración fija se denominan Sprint. La duración del Sprint, de entre 2 y 4 semanas, se establece al comienzo del proyecto, y se mantiene durante toda la vida del mismo. Esto es importante para hacer uso de las métricas que provee SCRUM. Durante cada Sprint el equipo desarrolla una porción del sistema. Lo destacable del Sprint es que este desarrollo incremental es con calidad productiva, y cumple algún requerimiento del usuario. De esta manera, al finalizar cada Sprint se tiene una porción del producto con calidad productiva, que el usuario puede decidir poner en producción.

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo,  el  esfuerzo de desarrollo es  iterativo.  Tan pronto  como uno completa un esfuerzo de desarrollo,  otro  comienza. Además,  en  cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

• Determinar qué quieres lograr.

• Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por 

cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.

• Seguir la alternativa seleccionada en el paso 2.

• Establecer qué tienes terminado.

El modelo espiral captura algunos principios básicos:

• Decidir qué problema se quiere resolver antes de viajar a resolverlo.

•  Examinar  tus  múltiples  alternativas  de acción  y  elegir  una de  las  más convenientes 

 • Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.

• No ser tan ingenuo para pensar que el sistema que estás construyendo será el sistema que el cliente necesita, y

• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

el  modelo de desarrollo evolutivo (algunas  veces  denominado  como prototipado evolutivo)  construye una serie de grandes  versiones sucesivas  de un producto.  Sin embargo,  mientras  que  la  aproximación incremental presupone que el conjunto completo de requerimientos es conocido al  comenzar,  el modelo evolutivo asume  que los  requerimientos  no son completamente conocidos al inicio del proyecto. En el  modelo evolutivo,  los  requerimientos son  cuidadosamente examinados,  y  sólo esos  que  son bien  comprendidos son  seleccionados  para el  primer incremento.  Los  desarrolladores construyen una  implementación parcial  del 

sistema que recibe sólo estos requerimientos. El  sistema es  entonces  desarrollado,  los  usuarios  lo usan,  y  proveen  retroalimentación a  los  desarrolladores.  Basada en esta  retroalimentación,  la especificación de requerimientos  es  actualizada,  y  una  segunda  versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente. Note  que el  desarrollo evolutivo es  100%  compatible  con el modelo  cascada.

estas son algunos de los modelos de los siclos de vida mas adelante colocare toda la información que se muestra en el contenido.