ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

1.1 La arquitectura el modelo 4+1

Arquitectura: conjunto de decisiones significativas acerca de la organizacin de un sistema software, la seleccin de los elementos estructurales a partir de los cuales se compone el sistema. Las interfaces entre ellos, su comportamiento, sus colaboraciones, y sus composicin. La arquitectura de software trata el diseo e implementacin de la estructura de alto nivel de software:El proceso de software incluye todas las actividades relativas del desarrollo de software. Las actividades de lato nivel de especificacin del software, el desarrollo, la validacin, fiabilidad, escalabilidad, disponibilidad,etc. Perry y Wolf (1992) describen una arquitectura software como : Arquitectura Software= {Elementos, Formas, Fundamentos/Restricciones } Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particularidad perspectiva (kruchten, 1995). El modelo 4+1 describe una arquitectura software: Vista Lgica (Logical View ), modelo de objetos, clases, entidad-relacin, etc. Vista de Proceso (Process View ), modelo de concurrencia y sincronizacin. Vista de Desarrollo (Development View ), organizacion esttica del software en su entrono de desarrollo(libreras, componentes, .ear, .jar, etc.). Vista Fsica (Physical View ), modelo de correspondencia software hardware(aspectos de distribucin en mquinas, por ejemplo ) End-user Functionality Programmers Software management

Integrators Performance Scalability

System engineers Topology Communications

Y una vista ms, la +1, que se muestra y traza en cada vista, por ejemplo, cada vista puede definir un conjunto de elementos para su uso(componentes, contenedores y conectores ).

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

1. Arquitectura Lgica (Logical Architecture)

Soporta el anlisis y la especificacin de los requisitos funcionales: lo que el sistema debera proporcionar en trminos de servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave tomadas mayormente del dominio del problema, en forma de objetos o clases. En esta vista se usan comnmente los diagramas de clases, los de interaccin y objetos. Notacin: La notacin ms usada es UML, y dentro de esta diagramas de clases y paquetes. Estilo: El estilo ms usado para la vista lgica es el Orientado a Objetos.

2. Arquitectura de Procesos (Process Architecture)

Se tratan algunos requisitos no funcionales. Ejecucin, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista tambin especifica que hilo de control ejecuta cada operacin identificada en cada clase identificada en la vista lgica. La vista se centra por tanto en la concurrencia y distribucin de procesos. Notacin: La notacin ms usada es UML, y dentro de esta diagramas estados, actividad y similares. Estilo: pueden encajar varios estilos. Por ejemplo, tomando la taxonoma de Garlan y Shaw (1993), pueden usarse tuberas y filtros (pipes and filtres) o Cliente Servidor (con variantes de mltiples clientes simple servidor y mltiples clientes mltiples servidores). Para sistemas ms complejos puede usarse un estilo similar a la ISIS system's process groups, como describe Kenneth Birman (1994) .

3. Arquitectura de Desarrollo (Development Architecture)

La vista de desarrollo o despliegue se enfoca en la organizacin de los mdulos software en el entorno de desarrollo. El software es empaquetado en pequeos trozos (libreras de programa, subsistemas, componentes, etc.), los subsistemas se organizan en capas jerrquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores La vista de desarrollo toma por tanto requisitos internos relacionados con facilidad de desarrollo, gestin del software (reparto de requisitos, trabajo del equipo), evaluacin de costes, planificacin, monitorizacin del progreso del proyecto, reutilizacin, portabilidad, seguridad y restricciones impuestas por las herramientas o por el lenguaje de programacin Esta organizacin del software se suele apoyar en diagramas de mdulos o de subsistemas que muestran las relaciones de exportacin (export) e importacin (import). Y destacar que podr describirse la vista de desarrollo por completo solamente despus de haber identificado todos los elementos software.

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

Notacin: La notacin ms usada es UML, y dentro de esta diagramas de componentes y paquetes. Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de desarrollo. Una regla de diseo es que un subsistema puede solamente depender de subsistemas en la misma capa o en las menores. Esto minimiza las dependencias entre mdulos a favor de una ms simple estrategia capa capas

4. Arquitectura Fsica (Physical Architecture)

La vista fsica se centra en los requisitos no funcionales, tales como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecucin y escalabilidad. Y tambin presenta cmo los procesos, objetos, etc., corresponden a nodos de proceso: Componentes: nodos de proceso. Conectores: LAN, WAN, bus, etc. Contenedores: subsistemas fsico Varias configuraciones fsicas pueden usarse. La correspondencia de el software a los nodos debe ser altamente flexible y tener el mnimo impacto en el cdigo fuente.

Escenarios (Scenarios)
La vista de escenarios corresponde con instancias de casos de uso que unifican todas las vistas. As, desde casos de uso se debiera poder hacer una trazabilidad a todos los componentes del sis tema software, viendo, por ejemplo, que mquinas, o clases, o componentes, o .jar, o procesos, son los responsables de que el sistema cubra una cierta funcionalidad.

Arquitectura y UML
Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su traslacin a un lenguaje de modelado concreto como UML. Hay que tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no exista una clara relacin entre ambos, lo que amenudo produce confusin al diseador que en la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de resumen la traslacin se presenta en la siguiente tabla:

Vista Escenarios Lgica Desarrollo Fsica Procesos

UML Casos de Uso Clases, de Estados y Colaboracin Componentes Despliegue Actividad, Estados, Secuencia

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

1.2 DESARROLLO ORIENTADO A OBJETOS

La Ingeniera del Software y la Orientacin a Objetos son dos reas cuya interseccin produce un amplio abanico de tcnicas y metodologas que pretenden facilitar la construccin de software . La OO se basa en tres principios bsicos: todo son objetos, encapsulamiento / ocultacin y herencia / polimorfismo. El primer principio indica la unidad bsica de trabajo. El segundo permite englobar en un mismo concepto a los datos y a las operaciones. El tercero permite agrupar y tratar de igual forma a objetos similares. Tras esta simplicidad, la metodologa de desarrollo OO inclua entre sus bondades una muy prometedora: permite abarcar las siguientes fases de un proyecto software: Por un lado Anlisis y Diseo (OOAD) y por otro Programacin (POO) 1. Realizar un Diagrama de Casos de Uso. Este paso es sencillo, hay que tener en cuenta que cada Caso de Uso representa una funcionalidad del software (o sea que terminar siendo alguna web page o formulario segn sea el caso) que vamos a construir, de manera que, tantos casos de Uso tengamos debemos plasmarlos en alguna pantalla de nuestro software. 2. Priorizar los Casos de Uso a trabajar. Pongamos los casos de uso en una lista colocando los ms importantes al inicio y los menos importantes al final. Ojo, para el cliente, todos son importantes pero hay que darle un nmero de orden a cada Caso de Uso y tratemos de hacer los casos de uso por partes, es decir, primero hacemos los 5 o 10 primeros y despus los 5 o 10 siguientes y despus los que siguen. esto se llama iteraciones. Es decir que nuestro desarrollo ser por iteraciones y cuantas iteraciones hagamos depender de cuantos requerimientos tengamos, pero de esto hay que advertirle al cliente, para ir entregando el proyecto por partes, adems que el desarrollo mejora, el cliente va usando las opciones que desea con menos tiempo de espera. 3. Generar los Documentos de Caso de Uso. Un diagrama de Casos de Uso, no sirve si no viene acompaado de un Documento que describa lo que hace el Caso de Uso. Esedocumento debe ser generado por el Analista del proyecto y debe tener mas o menos la siguiente estructura:
o Descripcin Breve. De lo que hace el Caso de Uso. o Precondiciones. Condiciones que deben ser cumplidas antes de ejecutar el Caso de Uso. o Flujo Bsico. Descripcin paso a paso de las acciones a realizar por el Usuario cuando trabaja de forma correcta en este Caso de Uso. o Flujo Alternativo. Detalle de los pasos que seguir el usuario cuando no trabaje de forma correcta en este requerimiento, ejemplo: validaciones, etc. o PostCondiciones. Las acciones que se deben realizar despus de que se ha terminado de ejecutar el Caso de Uso. o Interfaz Grfica. Prototipo de como debe quedar la pantalla del caso de uso para ser vista por los usuarios.

4. Generar los Diagramas de Secuencia. Los diagramas de Secuencia de UML permiten conocer la forma en la que los objetos se comunicarn en una pantalla (Web Page, Formulario, Requerimiento o Caso de Uso, como prefieran llamarle) para cumplir su objetivo. Aunque no es indispensable hacer este grfico es muy recomendable pues ayuda a entender como se comunicarn los diferentes objetos entre s. Esta labor

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

ayudar tambin a que el Arquitecto de Software comprenda mejor lo que debe hacer.

5. Disear el FrameWork del proyecto. Esto significa que el Arquitecto de Software del proyecto har su trabajo, el cual consiste en disear las clases que se usarn en todo el Software. Este trabajo es bastante delicado ya que el mal diseo de las clases involucra que no se programen las funcionalidades de cada clase de forma correcta. Esto conllevar a escribir un Spaghetti Code, que signifca que el cdigo estar enredado (para ser mas simples). Esta etapa de diseo adems debe ser revisada con cuidado y si es posible utilizar algn Patrn de Diseo de Software, pues en buena hora, hay que aplicarlo. 6. Creacin de la Base de Datos. El diagrama de Clases de UML puede servir como Base para el diseo de la Base de Datos del proyecto, claro, solo utilizando la Capa de Datos, es decir, las clases de estereotipo Entidad. 7. Construir la mscara de nuestro WebSite o Aplicacin Windows. Mientras los pasos 4, 5 y 6 se estn realizando, un poco aparte, el personal a cargo del Diseo del Sistema, sobretodo en el caso del diseo web, pueden ir desarrollando las plantillas para la creacin de las pginas web ayudndose de los grficos de las GUIs que se encuentran en los Documentos de Casos de Uso. 8. Programar las funcionalidades de los Casos de Uso. Una vez estn terminadas las clases, entonces se empezar a programar las funcionalidades de los Casos de Uso, para ello los programadores tomarn como referencia los documentos de Casos de Uso que el o los analistas desarrollaron y basndose en el Diagrama de Secuencia y en las clases diseadas por el Arquitecto escribirn el cdigo necesario para que esta opcin, es decir el caso de uso funcione. 9. Probar los Requerimientos del Software. Aunque el Documento de Casos de Uso muestre detalladamente la forma en la que debe funcionar el requerimiento y pese a los diagramas y todo, siempre se escaparn algunos detalles que se deben corregir en una etapa de pruebas exhaustivas, pero estas etapas no deben ser hechos por las personas que programaron los Casos de Uso, es mucho mejor que lo haga otra persona. 10. Integrar los requerimientos concluidos. Ahora si, despus de esto, ya es momento de unir lo que se hizo (es lo mas probable porque el cdigo no lo escribe un solo programador, no normalmente) y ponerlo a disposicin de los usuarios.

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

1.3 DIAGRAMACIN
La diagramacin, a la cual nos referimos, consiste en la representacin de los contenidos que tendr un producto digital, y las relaciones entre dichos contenidos. Desde sus orgenes los seres humanos representaron escenas de caza, danzas rituales y otros aspectos de su vida. La representacin forma parte de la naturaleza cognitiva humana, y es lgico que el hombre, en su devenir histrico, haya usado esta capacidad para plasmar en algn soporte, ideas concebidas mentalmente. La representacin se ha usado desde los comienzos del diseo de software, en forma de organigramas, diagramas de flujo de datos, rboles de decisin, etc. Al evolucionar las interfaces grficas de usuario, las labores de representacin se ampliaron con los llamados guiones de navegacin y guiones de interaccin, los cuales consistan en diagramas que representaban el funcionamiento de los productos electrnicos que se generaban en ese momento. La evolucin de los productos digitales, unida al crecimiento geomtrico de la informacin que soportan, ha originado la necesidad de ampliar estas formas de representacin con otras nuevas, o de enriquecer las existentes. Es por esto que se ha generalizado el uso de los esquemas de representacin entre arquitectos de informacin, enfocados a los aspectos organizativos y representativos de la informacin. Hay que sealar que durante el proceso de Arquitectura de Informacin se usan otras formas de representacin, con diferentes objetivos. Por ejemplo, en la aplicacin de la tcnica de Card Sorting se pueden generar dendogramas y grficos de escalamiento multidimensional; otro ejemplo seran las representaciones de las estructuras mentales de los usuarios tras una tormenta de ideas (brainstorming); o los organigramas de la empresa por la cual se crea el producto digital. Los diagramas a los que se refiere este artculo son los que se usan en arquitectura de informacin para proponer cmo ser el producto final. Esencialmente se refieren a la organizacin de los contenidos del producto, al funcionamiento bsico del mismo, y la ubicacin que tendrn estos contenidos en la interfaz. Los autores angloparlantes, pioneros en los temas del diseo y representacin del software, dividen estos diagramas en 2 tipos:
Blueprints Wireframes

Como sustituto del trmino Blueprint a veces se usa el de Architecture Map, que significa Mapa de Arquitectura. Tambin como trmino similar a wireframe se usan otros trminos como mockup y prototype (maqueta y prototipo). (Rosenfeld & Morville, Wodtke, Snyder) El primer grupo de diagramas (blueprints), tiene como objetivo representar "las principales reas de organizacin y rotulado" (Rosenfeld & Morville), y estn enfocados a los aspectos estructurales y de funcionamiento del producto. Generalmente se representan con textos, cajas y flechas.

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez

Desarrollo de proyectos de software Fecha 10 / febrero /2010

Estos planos o blueprints parten de lo general a lo particular, de lo abstracto a lo concreto. Su funcin es explicitar iterativamente las decisiones de diseo, con el objetivo de comunicar dichas decisiones al resto de miembros del equipo de desarrollo, o al cliente final. Christina Wodtke conceptualiza los Blueprint como: "Un plano de diseo es justamente una buena idea llevada a la realidad a travs de la escritura". El segundo grupo de diagramas (wireframe, mockup o prototype) tienen el objetivo de "mostrar el contenido de las pginas" (Rosenfeld & Morville), concretando los elementos que se plantearon en los primeros planos (blueprints) y ubicndolos en las pginas o pantallas del producto final. Este segundo grupo de diagramas estn comprendidos como prototipos de baja fidelidad, ya que se realizan en "blanco y negro" y no muestran el diseo grfico del producto ni la funcionalidad de sus cdigos de programacin. Los niveles de prototipos son: Prototipos de baja fidelidad o estticos (wireframes, mockup) Prototipos de fidelidad intermedia (diseo grfico) Prototipos de alta fidelidad o dinmicos (Web, HTML)

ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez BIBLIOGRAFIA

Desarrollo de proyectos de software Fecha 10 / febrero /2010

[1] http://jgarzas.googlepages.com/4mas1 09/02/2010 [2] http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html 09/02/2010 [3] El Proceso Unificado de Desarrollo de Software A.U.S Gustavo Torossi [4] Ingeniera del Software Sptima Edicin IAN SOMMERVILLE edit. Pearson [5]http://www.iti.es/media/about/docs/tic/05/2004-10-ISOO.pdf 8/02/2010