MATERIA:

DESARROLLO DE PROYECTOS DE SOFTWARE

UNIDAD I:

CONCEPTOS INTRODUCTORIOS

PRESENTA: LUIS HERNANDEZ JUAN BENIGNO OROZCO OROZCO JOSE VILLALANA RUIZ SARAI

CARRERA:

ING. EN SISTEMAS COMPUTACIONALES

HEROICA CIUDAD DE JUCHITN DE ZARAGOZA, OAXACA, 14 DE FEBRERO DE 2012.

1.1 LA ARQUITECTURA DE 4+1 VISTAS.

Una arquitectura de Software tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco. Toda arquitectura debe poderse implementar en una arquitectura fsica, que consiste en determinar que computadora tendr asignada cierta tarea para satisfacer la funcionalidad y ejecucin de los requisitos del sistema; as como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad, disponibilidad, etc. Actualmente se ha puesto de moda el trmino Arquitectura, diseo de arquitectura y por supuesto el modelo Arquitectura 4 + 1 de Pilippe (Philipe) Kruchten, pero surge la siguiente pregunta a qu se refiere este modelo? Primero vamos a definir que es una vista, segn Pilippe (Philipe) Kruchten Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva. Entonces una vista es la descripcin de un objeto desde un punto de vista especfico.

Entonces, para hacer un diseo completo de la Arquitectura de Software debemos documentar nuestro sistema en diferentes Vistas o ngulos, aqu es donde viene el uso del modelo 4 + 1 de Pilippe Kruchten. 1. Arquitectura Lgica : En la Vista Lgica hablamos principalmente de los requerimientos funcionales del sistema y de lo que el sistema debe de hacer, las funciones y servicios que se han definido. Nos vamos a enfocar a lo que hemos definido como dominio de la aplicacin, lo que son las clases y objetos principales que formaran el corazn de nuestra aplicacin. Esta vista la vamos a complementar con los diagramas UML: Diagrama de Clases Diagrama de Paquetes 2. Arquitectura de Procesos 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 Estilo: pueden usarse tuberas y filtros (pipes and filtres) o Cliente Servidor (con variantes de mltiples clientes simple servidor y mltiples clientes mltiples servidores) 3. Arquitectura de Desarrollo 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 . Y destacar que podr describirse la vista de desarrollo por completo solamente despus de haber identificado todos los elementos software. 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 capa. 4. Arquitectura Fsica 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 fsicos Varias configuraciones fsicas pueden usarse. La correspondencia del software a los nodos debe ser altamente flexible y tener el mnimo impacto en el cdigo fuente. 5. 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 sistema 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. 6. Relacin entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo no es una metodologa si que sugiere un mtodo de trabajo. Parece lgico que la vista de escenarios o casos de uso sea la de arranque, y que de ah se pase a la vista lgica. Desde la vista lgica afrontaremos la de desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecucin. Para con

todo concluir en la vista fsica. Todo ello, obviamente, con sus correspondientes y tpicas iteraciones. 7. Arquitectura y UML Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su translacin 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 a menudo produce confusin al diseador que en la actualidad quiere modelar una arquitectura con ambas herramientas.

1.2 DESARROLLO ORIENTADO A OBJETOS.

El desarrollo eficaz de un proyecto de software se centra en las cuatro Ps: personal, producto, proceso y proyecto. PERSONAL: La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado es de suma importancia. De hecho, el factor humano es tan importante que el Instituto de Ingeniera del Software ha desarrollado un Modelo de madurez de la capacidad de gestin de personal (MMCGP) para aumentar la preparacin de organizaciones del software para llevar a cabo las cada vez ms complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software El modelo de madurez de gestin de personal define las siguientes reas clave prcticas para el personal que desarrolla software: reclutamiento, seleccin, gestin de rendimiento, entrenamiento, retribucin, desarrollo de la carrera, diseo de la organizacin y del trabajo y desarrollo cultural y de espritu de equipo. PRODUCTO Antes de poder planificar un proyecto, se deberan establecer los objetivos y el mbito del producto, se deberan considerar soluciones alternativas e identificar las dificultades tcnicas y de gestin. Sin esta informacin, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoracin efectiva del riesgo, una subdivisin realista de las tareas del proyecto o una planificacin del proyecto asequible que proporcione una indicacin fiable del progreso. El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su mbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniera del sistema o del negocio. Los objetivos identifican las metas generales del proyecto sin considerar cmo se conseguirn (desde el punto de vista del cliente). El mbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, ms importante, intenta abordar estas caractersticas de una manera cuantitativa.

Una vez que se han entendido los objetivos y el mbito del producto, se consideran soluciones alternativas.

PROCESO Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeo nmero de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamao o complejidad. Diferentes conjuntos de tareas permiten a las actividades estructurales adaptarse a las caractersticas del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras -tales como la garanta de calidad del software, gestin de la configuracin del software y medicin- cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.

PROYECTO Dirigimos los proyectos de software planificados y controlados por una razn principal -es la nica manera conocida de gestionar la complejidad-. Y todava seguimos esforzndonos. En 1998, los datos de la industria del software indicaron que el 26 por 100 de proyectos de software fallaron completamente y que el 46 por 100 experimentaron un desbordamiento en la planificacin y en el coste. Aunque la proporcin de xito para los proyectos de software ha mejorado un poco, nuestra proporcin de fracaso de proyecto permanece ms alto del que debera ser. Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de seales de peligro comunes; comprender los factores del xito crticos que conducen a la gestin correcta del proyecto y desarrollar un enfoque de sentido comn para planificar, supervisar y controlar el proyecto. DESARROLLO ORIENTADO A OBJETOS Vivimos en un mundo de objetos. Estos objetos existen a nuestro alrededor. Por esto no es sorprendente que se proponga una visin orientada a objetos para la creacin de software de computadora, una abstraccin que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los aos sesenta. Durante los aos 90, la ingeniera del software orientada a objetos se convirti en el paradigma de eleccin para muchos productores de software y para un creciente nmero de sistemas de informacin y profesionales de la ingeniera.

Qu es? Hay muchas formas de enfocar un problema utilizando una solucin basada en el software. Un enfoque muy utilizado es la visin orientada a objetos. El dominio del problema se caracteriza mediante un conjunto de objetos con atributos y comportamientos especficos. Los objetos son manipulados mediante una coleccin de funciones (mtodos, operaciones o servicios) y se comunican entre ellos mediante un protocolo de mensajes.

Los objetos se clasifican mediante clases y subclases. Un objeto encapsula tanto datos como los procesos que se aplican a esos datos. Esta importante caracterstica permite construir clases de objetos e inherentemente construir bibliotecas de objetos y clases reutilizables. Cules son los pasos? El desarrollo del software orientado a objetos sigue los mismos pasos que el enfoque convencional. El anlisis identifica las clases y objetos relevantes en el dominio del problema, el diseo proporciona detalles sobre la arquitectura, las interfaces y los componentes, la implementacin transforma el diseo en cdigo, y las pruebas chequean tanto la arquitectura como las interfaces y los componentes. Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciacin es la lectura de estas definiciones y la creacin de un objeto a partir de ellas. Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos mtodos y variables pblicas declaradas en C. Los componentes registrados como "privados" (private) tambin se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as para mantener hegemnico el ideal de OOP. Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (mtodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase. Mtodo: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un mtodo puede producir un

cambio en las propiedades del objeto, o la generacin de un "evento" con un nuevo mensaje para otro objeto del sistema. Evento: Es un suceso en el sistema (tal como una interaccin del usuario con la mquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede desencadenar un objeto, es decir la accin que genera. Mensaje: una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus mtodos con ciertos parmetros asociados al evento que lo gener. Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus caractersticas predeterminadas, y cuyo valor puede ser alterado por la ejecucin de algn mtodo. Estado interno: es una variable que se declara privada, que puede ser nicamente accedida y alterada por un mtodo del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Componentes de un objeto: atributos, identidad, relaciones y mtodos.

Identificacin de un objeto: un objeto se representa por medio de una tabla o entidad que est compuesta por sus atributos y funciones correspondientes. DIAGRAMA UML Los diagramas UML se representan de la siguiente manera: CLASE Atributos

Metodos

Ejemplo de Diagrama UML: Se pretende disear la siguiente clase:

Ventana +tamao: int +visibilidad: Boolean -cierraVentana() -esconder() -crear()

1.3 DIAGRAMACIN.
Puede afirmarse que la diagramacin naci junto con los diferentes mtodos de reproduccin grfica utilizados por el ser humano, desde la poca en que los chinos, hace aproximadamente 1000 aos, obtenan grabados e impriman con xilografa. La xilografa fue la precursora de la imprenta y consista bsicamente en grabar sobre madera, con herramientas punzocortantes, dibujos previamente elaborados. Posteriormente se aplicaba una capa de pintura sobre la superficie, con la cual a su vez se imprima el papel a base de presin. Posteriormente en Europa, escribas y copistas elaboraban libros en serie (bsicamente la Biblia) de manera manual, sentados alrededor de un lector que dictaba los textos. Luego se decoraban con dibujos a color. All por 1440, Johannes Guttenberg crea la imprenta con caracteres mviles fundidos. En 1475 se imprimieron los primeros libros con este proceso. En el siglo XVIII, resurgi la imprenta y la diagramacin de impresos comenz a tomar gran auge, como arte y ciencia, hasta nuestros das. El desarrollo tecnolgico de la computacin ha favorecido la rapidez, la eficiencia, la calidad y el diseo de los ms variados impresos; los que a su vez, han incrementado la competencia global de textos. El primer paso en el diseo de objetos o procesos es la representacin mediante diagramas de su estructura, funcionamiento y comportamiento, concretando as las primeras ideas abstractas. En el caso de productos interactivos con interfaz, como por ejemplo los sitios web, esta interfaz tambin es objeto de diagramacin, especificando cul ser la organizacin y estructuracin visual de los diferentes elementos. Los diagramas se deben realizar a partir de la informacin recogida durante las etapas de investigacin de la audiencia, en las que se estudia a los usuarios con el objetivo de crear un producto que satisfaga sus necesidades. En qu consiste la 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. 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 blueprints 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. 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. wireframe 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) Estos tipos de diagramas se realizan tambin de forma iterativa con el usuario y dems miembros del equipo de desarrollo. Aunque para la realizacin de estos diagramas existen aplicaciones software especializadas, tambin es posible realizarlos en papel (paper prototype). Software para hacer diagramas Existen diferentes aplicaciones software que se utilizan para la confeccin de diagramas. Para una mejor comprensin de los mismos se han clasificado en 2 grupos: los que originalmente fueron ideados para hacer diagramas, y los que originalmente no fueron pensados para diagramacin, pero que tambin pueden usarse con este objetivo ya que son poderosas herramientas de diseo grfico. Algunas aplicaciones software que fueron ideadas para hacer diagramas: Smart Draw? (http://www.smartdraw.com) Microsoft Visio (http://www.microsoft.com) iGrafx Flowcharter (http://www.igrafx.de) DENIM & Silk. (http://guir.berkeley.edu/projects/denim/) Mindmanager (http://www.mindjet.com) Freemind (http://freemind.sourceforge.net/) Omni Graffle? (OSX) (http://www.omnigroup.com) Aplicaciones software que no fueron ideadas especficamente para hacer diagramas: Corel Draw (http://www.corel.com) Adobe [antes Macromedia] Freehand (http://www.adobe.com) Adobe Illustrator (http://www.adobe.com) Un propuesta propia 0 A partir de la experiencia del autor, se propone un sistema de diagramacin con una notacin que va de lo general a lo concreto, conformada por figuras ampliamente utilizadas por los creadores de productos digitales desde tiempos pasados. Se proponen tres tipos de diagramas de acuerdo a las funciones principales que cumple un arquitecto de informacin en el diseo de un producto digital:

Diagramas de organizacin Para hacer los diagramas de funcionamiento y los diagramas de presentacin ms trabajados visualmente, con el objetivo de representar el comportamiento interactivo del producto. Diagrama de funcionamiento El diagrama de funcionamiento es la representacin de las estructuras con los flujos de navegacin. Este diagrama tiene un nivel de acabado superior al anterior y complementa al mismo. Debe ser el que muestre los niveles de navegacin as como los tipos de navegacin en el producto. Diagrama de presentacin El diagrama de presentacin es el que debe mostrar las formas de organizacin visual de los contenidos en las pginas principales, por ejemplo: la pgina inicial, las pginas interiores, pginas de productos, etc. Este diagrama no pretende representar el diseo grfico o diseo visual en detalle, sino especificar el esqueleto organizativo de la