KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

DIFERENCIA ENTRE PAGINA WEB Y SOFTWARE P/WEB Un software para web es la herramienta que utilizaremos para realizar nuestra pgina web por lo tanto una pgina web es el producto ya realizado. PROGRAMACIN EN N CAPAS La programacin por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separacin de la lgica de negocios de la lgica de diseo; un ejemplo bsico de esto consiste en separar la capa de datos de la capa de presentacin al usuario. El diseo ms utilizado actualmente es el diseo en tres niveles (o en tres capas) es buena. Capas y Niveles 1. Capa de presentacin: es la que ve el usuario (tambin se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la informacin y captura la informacin del usuario en un mnimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Tambin es conocida como interfaz grfica y debe tener la caracterstica de ser "amigable" (entendible y fcil de usar) para el usuario. Esta capa se comunica nicamente con la capa de negocio. 2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envan las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lgica del negocio) porque es aqu donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentacin, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de l. Tambin se consideran aqu los programas de aplicacin. 3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Est formada por uno o ms gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio. Todas estas capas pueden residir en un nico ordenador, si bien lo ms usual es que haya una multitud de ordenadores en donde reside la capa de presentacin (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o ms ordenadores. As, si el tamao o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirn las peticiones del ordenador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separacin, esta capa de negocio podra residir en uno o ms ordenadores que realizaran solicitudes a una nica base de datos. En sistemas muy complejos se

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

llega a tener una serie de ordenadores sobre los cuales corre la capa de negocio, y otra serie de ordenadores sobre los cuales corre la base de datos.

En una arquitectura de tres niveles, los trminos "capas" y "niveles" no significan lo mismo ni son similares. El trmino "capa" hace referencia a la forma como una solucin es segmentada desde el punto de vista lgico:

Presentacin. (Conocida como capa Web) Lgica de Negocio. (Conocida como capa Aplicativa) Datos. (Conocida como capa de Base de Datos)

En cambio, el trmino "nivel" corresponde a la forma en que las capas lgicas se encuentran distribuidas de forma fsica. Por ejemplo:

Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en un solo ordenador (Presentacin+lgica+datos). Se dice que la arquitectura de la solucin es de tres capas y un nivel. Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en dos ordenadores (presentacin+lgica por un lado; lgica+datos por el otro lado). Se dice que la arquitectura de la solucin es de tres capas y dos niveles.

DESARROLLO DE SOFTWARE PARA WEB MODELO DE 4+1 El modelo 4+1 de Kruchten, es un modelo de vistas [1] diseado por el profesor Philippe Kruchten y que encaja con el estndar IEEE 1471-2000 que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de mltiples puntos de vista. Una vista no es ms que una representacin de todo el sistema software desde una determinada perspectiva, y un punto de vista se define como un conjunto de reglas (o normas) para realizar y entender las vistas. Lo que propone Kruchten es que un sistema software se ha de documentar y mostrar (tal y como se propone en el estndar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar entre s con una vista ms, que es la denominada vista +1. Estas 4 vista las denomin Kruchten como: vista

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

lgica, vista de procesos, vista de despliegue y vista fsica y la vista +1 que tiene la funcin de relacionar las 4 vistas citadas, la denomin vista de escenario. Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se est documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del sistema software. A continuacin, pasamos a explicar que informacin ha de haber en la documentacin de cada una

de estas vistas. Vista Lgica: En esta vista se representa la funcionalidad que el sistema proporcionara a los usuarios finales. Es decir, se ha de representar lo que el sistema debe hacer, y las funciones y servicios que ofrece. Para completar la documentacin de esta vista se pueden incluir los diagramas de clases, de comunicacin o de secuencia de UML.

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

Vista de Despliegue: En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de la gestin del software; o en otras palabras, se va a mostrar cmo est dividido el sistema software en componentes y las dependencias que hay entre esos componentes. Para completar la documentacin de esta vista se pueden incluir los diagramas de componentes y de paquetes de UML.

Vista de Procesos: En esta vista se muestran los procesos que hay en el sistema y la forma en la que se comunican estos procesos; es decir, se representa desde la perspectiva de un integrador de sistemas, el flujo de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Para completar la documentacin de esta vista se puede incluir el diagrama de actividad de UML.

Vista Fsica: En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes fsicos del sistema as como las conexiones

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

fsicas entre esos componentes que conforman la solucin (incluyendo los servicios). Para completar la documentacin de esta vista se puede incluir el diagrama de despliegue de UML.

+1 Vista de Escenarios: Esta vista va a ser representada por los casos de uso software y va a tener la funcin de unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver cmo se van ligando las otras 4 vistas, con lo que tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc., para realizar cada caso de uso. Para completar la documentacin de esta vista se pueden incluir el diagrama de casos de uso de UML.

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

ELEMENTOS QUE CONLLEVA LA ARQUITECTURA DE SOFTWARE Componentes. Realizan cmputos y almacenamiento de datos. Interaccionan unos con otros durante la ejecucin. DESARROLLO ORIENTADO A OBJETOS P/WEB La programacin Orientada a objetos (POO) es una forma especial de programar, ms cercana a como expresaramos las cosas en la vida real que otros tipos de programacin. Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en trminos de objetos, propiedades, mtodos y otras cosas que veremos rpidamente para aclarar conceptos y dar una pequea base que permita soltarnos un poco con este tipo de programacin. DIAGRAMA DE CLASES Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos. Los diagramas de clase se usan en el diseo del modelo esttico para ver un sistema. Para las dems partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son tambin la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalacin (Deployment). Los diagramas de clase son importantes no solo para la visualizacin, especificacin y documentacin del modelo estructural, pero tambin para la construccin de sistemas ejecutables. Ingeniera hacia adelante e ingeniera inversa. La construccin de software tiene muchas caractersticas similares, excepto, que la calidad (Fluidez) de software, uno tiene la habilidad de definir la construccin de bloques bsicos para ir detallando (scratch).

Contenido
Un diagrama de clases comnmente con tiene lo siguiente:

Clases Interfaces Colaboraciones Dependencia

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

Generalizacin Relaciones de asociacin

Los otros diagramas de clase pueden contener notas y restricciones. Los diagramas de clase pueden tambin contener paquetes o subsistemas ambos de los cuales son usados para agrupar elementos de su modelo. Algunas veces se quieren instancias de lugar en el diagrama de clases, como tambin especialmente cuando se quiere visualizar el tipo de una instancia (posibilidad dinmica).

Usos comunes:
- Modelado del diseo esttico de un sistema. Esta vista en primer lugar soporta los requerimientos funcionales de un sistema - el servicio del sistema debera de proveer este a los usuarios finales. Para el modelo de diseo esttico de la vista de un sistema, tpicamente se usan diagramas de clases en alguna de estas tres alternativas: 1. Modelo del vocabulario de un sistema. El modelo del vocabulario de un sistema involucra tomar decisiones acerca de las cuales son parte del sistema y cuales quedan fuera del ambiente. Los diagramas de clase especifican estas abstracciones y sus responsabilidades. 2. Modelado simple de colaboraciones. Una colaboracin es una sociedad de clases, interfaces, y otros elementos, estos trabajan juntos para proveer igual comportamiento de colaboracin, esto es ms grande que la suma de todos los elementos. Por ejemplo, cuando se est modelando la semntica de una transaccin en un sistema distribuido, no se puede fijar la vista en una simple clase, para entender cul ir. Esta semntica es llevada fuera por un conjunto de clases que trabajan juntas. Los diagramas de clases se usan para visualizar y especificar este conjunto de clases y sus relaciones. 3. Modelo lgico del esquema de la base de datos. Pensar en un esquema como la heliografa (dibujo) para el diseo conceptual de una base de datos. En muchos dominios se quiere almacenar mucha informacin persistente en una base de datos relacional o en base de datos orientada a objetos. Se pueden modelar esquemas para estas bases de datos usando diagramas de clases. Modelado lgico del esquema de la base de datos. Muchos de los sistemas a modelar tienen objetos persistentes, con lo cual por medio de ellos pueden ser almacenados en una base de datos para recuperarse mas tarde. Muy frecuentemente se usa una base de datos Relacional, una base de datos orientada a objetos, o un hbrido BD relacional/objetos para almacenar lo persistente. El UML soporta tambin el modelo lgico del esquema de la base de dato, como tambin la base de datos fsica.

KAREN ROMERO CALLEJA INGENIERIA EN SISTEMAS COMPUTACIONALES DESARROLLO DE SOFTWARE PARA WEB

En UML los diagramas de clase son un super conjunto de los diagramas ER(Entidad-Relacin), comnmente las herramientas de modelado para el diseo lgico de la base de datos. Donde clsicamente los diagramas E-R se contraen en los datos, los diagramas de clase van mas all por permitir el modelado del comportamiento tambin. En la base de datos fsica, esas operaciones lgicas son generalmente asignadas entre los triggers o procedimientos almacenados.

Para modelar un esquema.

Identificar las clases en el modelo cuyos estados sean los ms trascendentes en el tiempo de vida de sus aplicaciones. Crear un diagrama de clases y marcar aquellas que sean persistentes. Expandir los detalles estructurales de esas clases, en general, estas especificaciones de detalles de sus atributos y centrarse en las asociaciones y en sus cardinalidades eso estructura esas clases. Observar para el modelo comn ese complicado diseo fsico de la base de datos, tal como asociaciones cclicas, asociaciones uno-a-uno, uno-amuchos y asociaciones muchos-a-muchos. Donde necesariamente se crea una abstraccin intermedia para simplificar la estructura lgica. Considerar tambin el comportamiento de esas clases para expandir operaciones, esto es importante para el acceso a datos y la integridad de los datos. En general, se provee la mejor separacin concerniente, reglas de negocios concernientes con la manipulacin de conjuntos de objetos que deberan ser encapsulados en una capa acerca de esas clases persistentes. Donde posiblemente, el uso de herramientas ayudan a transformar el diseo lgico a diseo fsico.