Professional Documents
Culture Documents
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
ALUMNO : Csar Zrate Prez N 05091054 PROFESOR: Jess ngel Pea Ramrez
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
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:
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
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
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
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
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
[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