Documento Arquitectura Del Software 1.2

Pgina 1 de 14
Simoncito Jos ngel Moya Malav
[Sistema de Gestin y Control Administrativo para la Escuela de Educacin Inicial Simoncito Jos ngel Moya Malav] (SIGECAS) Documento de Arquitectura del Software Versin [1.2]
Documento de Arquitectura del Software: (SIGECAS) Elaborado por: Pereira Mario, La Rosa Jeranny, Mundarain Jean, Lpez Jos, Martnez Luis.
Versin [1.2] Revisado por:
Fecha: 23/01/2012 Aprobado por:
Pgina 2 de 14
Historial de Revisiones
Fecha
Versin
Descripcin Primera versin, por lo cual no tiene correcciones.
Autor La Rosa, Jeranny Pereira, Mario Lpez, Jos Martnez, Luis Mundarain, Jean La Rosa, Jeranny Pereira, Mario Jos Lpez Martnez, Luis Mundarain, Jean La Rosa, Jeranny Pereira, Mario Jos Lpez Martnez, Luis Mundarain, Jean
08/06/2011
1.0
23/07/2011
1.1
Correcciones
23/01/2012
1.2
Correcciones: Eliminado Diagrama WAE, agregado estilo y patrn de arquitectura, agregado logo de la institucin
Pgina 3 de 14
ndice de Contenido
Contenido 1. Informacin General 1.1 Gerencias Solicitantes 1.2 Cdigo del Proyecto 1.3Nombre del Proyecto 1.4 Beneficiario 2. Introduccin 2.1 Propsito 2.2 Alcance 2.3 Definiciones, Acrnimos y Abreviaturas. 2.4 Estndares Aplicados 3. Resumen Arquitectnico 3.1. Objetivos de la Arquitectura Seleccionada. 4. Componentes Significativos de la Arquitectura del Sistema. 5. Vista de Casos de Uso 5.1. Modelo de Casos de Uso 6. Vista Lgica 6.1. Diagrama de Clase 7. Vista de Implementacin 7.1. Diagrama de Componente 7.2. Modelo de Datos
Pg. 4 4 4 4 4 4 4 5 5 5 5 6 6 7 7 8 8 9 10 10
Pgina 4 de 14
Documento de Arquitectura del Software
1. Informacin General 1.1 Gerencias Solicitantes:Simoncito Jos ngel Moya Malav 1.2 Cdigo del Proyecto:SIGECAS 1.3 Nombre del Proyecto: Sistema de Gestin y Control Administrativo para la Escuela de Educacin Inicial Simoncito Jos ngel Moya Malav 1.4 Beneficiario:Simoncito Jos ngel Moya Malav
2. Introduccin La visualizacin, especificacin, construccin y documentacin del un sistema debe realizarse desde varias perspectivas (usuario, analista, desarrollador, entre otras) cada una de ellas presenta el sistema de forma diferente en diversos momentos a lo largo del proyecto, es por ello que se plantea en este documento describir el sistema a travs de cinco vistas interrelacionadas (Vista Caso de Uso, Vista Lgica, Vista de Implementacin, Vista de Despliegue y Vista de Proceso).
La arquitectura de software no tiene que ver solamente con la estructura y el comportamiento, sino tambin con el uso, la funcionalidad, el rendimiento, la capacidad de adaptacin, la reutilizacin, la capacidad de ser comprendido y las restricciones tecnolgicas, as como los aspectos estticos de la aplicacin.
2.1. Propsito El Documento de Arquitectura de Software presenta la arquitectura del sistema a travs de diferentes vistas, cada una de las cuales ilustra un aspecto en particular del software desarrollado. Se pretende de esta forma que el documento brinde al lector una visin global y comprensible del diseo general.
Pgina 5 de 14
2.2. Alcance El documento se centra en el desarrollo de las vistas lgicas del sistema. Se incluyen losaspectos fundamentales del resto de las vistas y se omiten aquellas que no se considerenpertinentes como es el caso de la vista de procesos y los diagramas de entidad relacin.
En cuanto a los componentes externos que se mencionen, se incluye una descripcin de losmismos en el nivel que se considere apropiado y se indican las referencias donde consultar msinformacin sobre los mismos.
2.3. Definiciones, Acrnimos y Abreviaturas Ver artefacto (Glosario de Trminos, versin 1.2)
2.4. Estndares Aplicados UML 2.0 Estndar de Codificacin del CNTI. Estndar W3C. ISO
3. Resumen Arquitectnico Segn Hofmeister et al. (1996) expresa que, en la medida que los sistemas de software crecen en complejidad, bien sea por nmero de requerimientos o por el impacto de los mismos, se hace necesario establecer medios para el manejo de esta complejidad. En general, la tcnica es descomponer el sistema en piezas que agrupan aspectos especficos del mismo, producto de un proceso de abstraccin (Bass et al., 1998) y que al organizarse de cierta manera constituyen la base de la solucin de un problema en particular.
La mayora de los autores entre ellos (Hofmeister et al., 1996; Booch et al., 1999; Bass et al., 1998; entre otros) coinciden en que una arquitectura de software define la
Documento de Arquitectura del Software: (SIGECAS) Elaborado por: Pereira Mario, La Rosa Jeranny, Mundarain Jean, Lpez Jos, Martnez Luis. Versin [1.2] Revisado por: Fecha: 23/01/2012 Aprobado por:
Pgina 6 de 14
estructura del sistema. Esta estructura se constituye de componentes - mdulos o piezas de cdigo que nacen de la nocin de abstraccin, cumpliendo funciones especficas, e interactuando entre s con un comportamiento definido.
3.1. Arquitectura Seleccionada Para el diseo del sistema, se ha seleccionado la arquitectura cliente servidor de tres (3) capas tambin conocida como arquitectura de tres niveles. La cual es una especializacin 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 presentacin (interfaz de usuario), otra para el clculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia).
3.2. Estilo Arquitectnico Para Sommerville (2005) el estilo arquitectnico es una familia de sistemas (cierto tipo de sistemas) en trminos de patrones estructurales, de control, de comunicacin, etctera. En particular, de acuerdo a los distintos autores el estilo arquitectnico define un vocabulario de tipos de componentes y conectores.
Por el tipo de arquitectura seleccionada anteriormente el sistema usara un estilo arquitectnico basado en capas.
El objetivo principal del estilo capas, es la separacin de la lgica de negocio y la lgica de diseo, donde se puede trabajar con 2 capas, 3 capas hasta n capas. Siendo nuestro sistema de 3 capas, las cuales son:
1. Capa de presentacin: Es la encargada de interactuar con el usuario y se corresponde con lo que tradicionalmente se conoce como interfaz de usuario, esta capa se comunica nicamente con la capa de negocio. 2. Capa de negocio o aplicacin o intermedia: Es donde se localiza la lgica del negocio. Esta capa recibe la peticin del usuario a travs de
Pgina 7 de 14
la capa de presentacin y se encarga de darle curso, recurriendo normalmente a los repositorios de informacin, dicha capa es donde se implementan las reglas del negocio, las validaciones y clculos. 3. Capa de acceso a datos: Es la encargada de acceder a los repositorios o fuentes de informacin. Esta capa se encuentra localizada en un servidor separado conocido como servidor de base de datos.
3.3. Patrn Arquitectnico Segn Buschmann et al. (1996) define patrn como una regla que consta de tres partes, la cual expresa una relacin entre un contexto, un problema y una solucin.
Partiendo de esta definicin, propone los patrones arquitectnicos como descripcin de un problema particular y recurrente de diseo, que aparece en contextos de diseo especfico, y presenta un esquema genrico demostrado con xito para su solucin. El esquema de solucin se especifica mediante la descripcin de los componentes que la constituyen, sus responsabilidades y desarrollos, as como tambin la forma como estos colaboran entre s.
Diferenciando al estilo con el patrn se podra decir que; el estilo est asociado a formas generales de organizacin - sistemas orientados al objeto mientras que los patrones estarn asociados a formas ms concretas, que tienen que ver con la especializacin que adoptan los objetos y clases de acuerdo al tipo de aplicacin o entorno tecnolgico, a tcnicas conocidas por su eficiencia para resolver ciertos problemas, etc. Para el sistema se ha implementado el Patrn MVC (Modelo Vista Controlador)
3.4. Objetivos de la Arquitectura Seleccionada

Pgina 8 de 14
Se instala una interfaz de usuario en la computadora del usuario final (el cliente).La arquitectura basada en WEB transforma la interfaz de bsqueda existente (el explorador de WEB), en la interfaz del usuario final.
No hay programas de compatibilidad.El desarrollo puede llevarse a cabo en varios niveles y en caso que sobrevenga algn cambio.
4. Componentes Significativos de la Arquitectura del Sistema Descripcin: Requerimientos: C-00: Interfaz de Usuario Estar construida con las siguientes tecnologas: HTML, javascript, CSS, php 5 Sistema Operativo Canaima 3.0, Memoria Ram1024MB, procesador Pentium IV, disco duro 80 GB, Navegador Web. Monitor 15 pulgadas. Protocolos de Comunicacin: HTTP C-01: Base de Datos Servidor de base de datos de cdigo abierto PostgreSQL Sistema Operativo Canaima 3.0, Memoria Ram1024MB, procesador Pentium IV, disco duro 80 GB, Navegador Web. Monitor 15 pulgadas. Protocolos de Comunicacin: HTTP
Interfaces Disponibles:
Descripcin: Requerimientos:
Interfaces Disponibles: 5. Vista de Casos de Uso
La Vista de Casos de Uso presenta un subconjunto del Modelo de Caos de Uso. Describe los casos de uso o escenarios que representen funcionalidades centrales del sistema final Estos casos de uso, en conjunto con los requerimientos no funcionales, permiten descubrir y disear la arquitectura del sistema.
5.1. Modelo de Casos de Uso
Pgina 9 de 14
5.1.1. Diagrama general de Casos de Uso SIGECAS.
5.1.2. Caso de uso Ingresar Estudiante.
Pgina 10 de 14
5.1.3. Caso de uso Registrar Personal.
5.1.4. Caso de uso Controlar Asistencia.
Pgina 11 de 14
5.1.5. Caso de uso Gestionar Informacin del Plantel.
5.1.6. Caso de uso Gestionar Usuario del Sistema.
6. Vista Lgica Estas vistas estn conformadas por Diagrama de Paquetes, Paquetes de Diseo significativos Arquitectnicamente, Diagrama de clase, Diagramas de clase agrupado
Pgina 12 de 14
por paquete, y Diagramas WAE. Para esta versin 1.2 de este documento solo incluiremos una pequea parte del diagrama de clase.
6.1 Diagrama de Clase
Diagrama General de Clases del Sistema(SIGECAS)
7. Vista de Implementacin Esta vista esta compuesta por Diagrama de Componentes, integracin de componentes del sistema, beneficios de la arquitectura para futuras modificaciones o
Pgina 13 de 14
extensiones. Para esta versin 1.2 mostraremos solamente el Diagrama de Componente.
7.1. Diagrama de Componente
7.2. Modelo de Datos Esta vista esta constituida por el Diagrama de Entidad-relacin. Para esta versin (1.2) se incluir una parte ya que est en proceso de modificacin.
Pgina 14 de 14

Documento Arquitectura Del Software 1.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Documento Arquitectura Del Software 1.2

Uploaded by

Copyright:

Available Formats

Pgina 1 de 14

Simoncito Jos ngel Moya Malav

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

Descripcin Primera versin, por lo cual no tiene correcciones.

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

Documento de Arquitectura del Software

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

3.4. Objetivos de la Arquitectura Seleccionada

Interfaces Disponibles: 5. Vista de Casos de Uso

5.1. Modelo de Casos de Uso

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

5.1.1. Diagrama general de Casos de Uso SIGECAS.

5.1.2. Caso de uso Ingresar Estudiante.

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

5.1.3. Caso de uso Registrar Personal.

5.1.4. Caso de uso Controlar Asistencia.

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

5.1.5. Caso de uso Gestionar Informacin del Plantel.

5.1.6. Caso de uso Gestionar Usuario del Sistema.

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

6.1 Diagrama de Clase

Diagrama General de Clases del Sistema(SIGECAS)

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

extensiones. Para esta versin 1.2 mostraremos solamente el Diagrama de Componente.

7.1. Diagrama de Componente

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

Versin [1.2] Revisado por:

Fecha: 23/01/2012 Aprobado por:

You might also like