You are on page 1of 13

Documento de Arquitectura del Software

Proyecto: AddressBook

Versión: 1.0.1

Identificador del documento: <DAS1>


Documento de Arquitectura del Software
AddressBook Versión: 1.0.1

Historial de Revisiones
Versión Fecha Autor Descripción
1.0.1 30/Novie Cristina Jenifer García
mbre/09 Loeza

Hackers Corporation, 2009 Pág. 2 de 13


Documento de Arquitectura del Software
AddressBook Versión: 1.0.1

Índice de Contenido

1 Introducción.................................................................................................................................................5
1.1 Alcance................................................................................................................................................5
1.2 Definiciones, Acrónimos y Abreviaturas...............................................................................................5
1.3 Documentos relacionados...................................................................................................................5

2 Resumen Arquitectónico .............................................................................................................................5


2.1 Hechos más Importantes.....................................................................................................................5
2.2 Estilo Arquitectónico............................................................................................................................6

3 Componentes Significativos de la Arquitectura del Sistema .......................................................................6


3.1 Presentación/Componentes de la Interfaz de Usuario.........................................................................6
3.2 Componentes Lógicos de la Aplicación...............................................................................................6
3.3 Componentes de Almacenamiento de Datos.......................................................................................6

4 Vista de Casos de Uso................................................................................................................................7

5 Vista Lógica.................................................................................................................................................7
5.1 Repartición del Procesamiento............................................................................................................8
5.2 Paquetes de Diseño significativos Arquitectónicamente......................................................................8
5.3 Realización de los Casos de Uso.......................................................................................................9

6 Vista de Procesos......................................................................................................................................10

7 Vista de Implementación ...........................................................................................................................10


7.1 Visión General...................................................................................................................................10
7.2 Capas................................................................................................................................................10

8 Vista de Implantación.................................................................................................................................11

9 Vista de Datos...........................................................................................................................................11

10 Integración...............................................................................................................................................11
10.1 Integración de los Componentes y su Comunicación......................................................................11
10.2 Mecanismos de la Arquitectura para Futuras Modificaciones o Extensiones..................................12

11 Escenarios de la Arquitectura..................................................................................................................12
11.1 Inicio de sistema..............................................................................................................................12
11.2 Apagado de sistema........................................................................................................................12

12 Lista de Control de la Arquitectura...........................................................................................................12

Hackers Corporation, 2009 Pág. 3 de 13


Documento de Arquitectura del Software
AddressBook Versión: 1.0.1

13 Aseguramiento de la Calidad...................................................................................................................13
13.1 Alcance del Plan de Calidad............................................................................................................13
13.2 Objetivos de Calidad........................................................................................................................13
13.2.1 Esenciales...............................................................................................................................13
13.2.2 Esperados................................................................................................................................13
13.2.3 Deseados.................................................................................................................................13

Hackers Corporation, 2009 Pág. 4 de 13


Documento de Arquitectura del Software

1 Introducción
1.1 Alcance

En este proyecto se realizará un software en el cual se puedan administrar los datos de personas para llevar
un control y mejor acceso.

Se tiene que tener en cuenta que cada contacto en el addressBook es una identidad propia que se
almacenara es una base de datos en donde se contendrá: Nombre, Dirección, Teléfono, Nombre del padre,
fecha de nacimiento, entre otros datos.

Con este documento se debe realizar la planeación, productos y requisitos o características del sistema
como tal y se deberá especificar a la mayor claridad posible para evitar un efecto lavadero.

1.2 Definiciones, Acrónimos y Abreviaturas

Especifique las definiciones, abreviaciones y siglas que tienen que ver con este documento a fin de
su correcto entendimiento, a su vez estas se deben reflejar en el Glosario del Sistema.

1.3 Documentos relacionados

Para poder visualizar las referencias a otros documentos, se debe de llenar la tabla que se muestra
a continuación:

Título Fecha Organización Identificador del


documento
<título> <dd/mm/aa> <nombre> <Id documento>

2 Resumen Arquitectónico
2.1 Hechos más Importantes

Se deberá insertar los datos a una BD relacional normalizada sobre la cual se podrá hacer las consultas y
mostrar los datos.

Se tendrá una clase en donde estén almacenadas todas las consultas y solamente se invocara.
Vamos a tener una clase de conexión.

Un Formulario con todos los botones que se necesitan en la manipulación de sistema.

Se colocará una clase de validación de data.


Se podrá en el programa agregar nuevo, editar, borrar, guardar, cancelar y cerrar, estos serán los botones
que acompañara nuestra aplicación.

2.2 Estilo Arquitectónico

Es una aplicación en arquitectura en capas en la cual se esta teniendo las 3 capas que son: Presentación,
Negocio y Datos.

El usuario tiene la interface activa en la cual puede interactuar con ella y a la vez la interface puede capturar
los datos introducidos para posterior mente procesarla.

La capa de proceso porque en el momento que el usuario quiere procesar la información lo puede hacer al
presionar un botón y el sistema procesa los datos para mostrar la información.

La capa de datos porque tenemos una parte del sistema que se encarga de acceder a ellos y en esta misma
residen los datos como en la base de datos y esta formada por el gestor de base de datos.

3 Componentes Significativos de la Arquitectura del Sistema


3.1 Presentación/Componentes de la Interfaz de Usuario

C-00: Interface Principal


Descripción: En la interface se encontrara los elementos necesarios para la
administración de la addressBook
Requerimientos: Ninguno en especifico.
Interfaces Disponibles: Solamente la principal del addressbook en donde contendrá todo lo
necesario para las funciones antes especificadas.

3.2 Componentes Lógicos de la Aplicación

C-10: NOMBRE DEL COMPONENTE


Descripción: Descripción
Requerimientos: Sistema operativo, RAM, etc.
Interfaces Disponibles: Describa brevemente las interfaces

3.3 Componentes de Almacenamiento de Datos

C-20: Clase de addressDataManager, DataManager y BD


Descripción: En este Componente se encuentra todas las consultas para la base
de datos tanto para mostrar data como para guardar y actualizar la
data, así mismo una base de datos en la cual se almacenara la
data, de la misma manera se tiene una clase para la conexión a
base de datos que es la DataManager y se encarga también de
ejecutar las consultas.
Requerimientos: Sistemas con posibilidad de carga de gestor de datos SQL, con los
requerimientos mínimos de cobertura para el mismo.
Interfaces Disponibles: Esta clase no contiene interface ya que lo único que contiene son
las consultas para la ejecución del programa.
4 Vista de Casos de Uso
El principal caso de uso que tiene el sistema es que administra las Direcciones y teléfonos del usuario, de
manera que tendrá como funciones extendidas el ADDNEW, EDIT, DELETE, SAVE, CANCEL, CLOSE y
SEARCH BY NAME.

El ADDNEW se encargara de crear un nuevo registro en la base de datos con la información recopilada del
usuario y después de haber creado el registro lo mostrara en el datagrid.

El EDITE será el responsable de editar la información existente sobre un registro y actualizará la


información.

DELETE será el encargado de borrar la información que al usuario no le sirva al momento que el usuario
crea conveniente.

SAVE será el responsable de que cuando se introduzcan datos en el formulario almacenarlos en la base de
datos desde el ADDNEW y el EDIT.

CANCEL se dedicará únicamente a cancelar las acciones arriba mencionadas y limpiara los campos.

CLOSE cerrará todo la aplicación por completo sin guardar lo que este escrito en los campos.
Nota: TODA LA DATA SERÁ REVISADA POR UNA CLASE PARA VERIFICAR QUE SEA DE OS
VALORES CORRESPONDIENTES Y POSTERIOR PASAR A LA CLASE DE
ADDRESSDATAMANAGER PARA ALMACENARLA EN LA BD.

5 Vista Lógica
Clase Data Manager:
Contienen todas las consultas que se harán para la función del sistema como son:
• public static void DeleteAddressData( System.Int32 RecId ): para el
borrado de la data de un registro.
• public static void CreateAddressData( AddressData addressData ): Inserta
la data de un registro en la BD.
• public static void UpdateAddressData( AddressData addressData ): Actualiza
la información de la data de un registro al momento e hacer una
modificación.
• public static AddressData GetAddressData( System.Int32 RecId ): obtiene la
data de un registro segun el identificador.

Clase DataManager:
En esta clase se tiene el código que se encargara de todas las consultas los registros que se encuentran
según los criterios se colocaran en la grilla.

Clase AddressData:
Se encarga de verificar la información y convertirla en texto para su guardado posterior.

Clase AddresBook:
Esta clase es la principal donde se encuentra el Main y es el punto de entrada de la aplicación, y en el cual
se encuentran los eventos click y demás que ejecutan los objetos BTN, y el evento load_form que se carga
al iniciar la aplicación, entre los métodos principales se encuentran:

• private void LoadAddressGrid(): sirve para cargar los datos en un datagrid


de la base de datos.
• private void SetEditState ( bool edit ): es para verificar el estado de
edición que es activar o desactivar los botones según la función de
manipulación de la aplicación.
• private void ClearFields(): es para limpiar los campos del formulario.
• private void btnCancel_Click(object sender, System.EventArgs e): es el
evento relacionado con el que se cancelan las acciones en proceso.
• private void btnAdd_Click(object sender, System.EventArgs e): ejecuta los
métodos correspondientes para la preparación del formulario para su
almacenamiento posterior.
• private void btnEdit_Click(object sender, System.EventArgs e): tiene
contenidos los metodos y preparaciones de los campos para la edicion de un
registro.
• private void btnDelete_Click(object sender, System.EventArgs e): contiene
los metodos y todo lo necesario para el borrado de un registro del
sistema.
• private void btnSave_Click(object sender, System.EventArgs e): guarda los
datos del registro en la base de datos.

5.1 Repartición del Procesamiento

AddresBook

AddressDataMana
DataManager AddressData eStatus Util IdManager
ger

5.2 Paquetes de Diseño significativos Arquitectónicamente

AddNew:
Esta parte solamente prepara el formulario para la inserción de datos por lo cual solamente invoca su clase
donde está el método para limpiar los campos y pone el focus en el txtnombre.
AddresBook

Save:
Este sección del sistema realizara el guardado de datos al momento de realizar una actualización o un
registro nuevo y sus clases relacionadas son:

AddressDataMana
frmAddressBook AddressData DataManager
ger

eStatus

5.3 Realización de los Casos de Uso

AddNew
«extends»

«extends»
Edit

«extends»
Delete
Actor1
«extends»

Save
6 Vista de Procesos

frmAddress
-object sender, System.EventArgs e AddressData
+private void btnSave_Click(object sender, System.EventArgs e)() -DataRow dr
+AddressData addressdata;() +eStatus()
+LoadAddressGrid();()

eStatus
DataMannager -public enum eStatus
-string ConnectionString,string query, string tableName +Delete()
+Approved()
+public static DataTable ExecuteQuery()()
+New()
+public static void ExecuteNonQuery ()()
+Pendding()
+Modified()

AddressDataManager

+public static void DeleteAddressData ()()


+public static void CreateAddressData()()
+public static void UpdateAddressData ()
+public static AddressData GetAddressData()()
+public static DataTable GetAddressDatass()()
+public static DataTable GetAddressess()

7 Vista de Implementación
7.1 Visión General

Nombrar y definir los contenidos de las distintas capas, las reglas que controlan la inserción dentro
de una capa y las restricciones entre capas.

Además, se debe reflejar un diagrama de componentes que muestre las relaciones que existen
entre capas.

7.2 Capas

• Capa de acceso a datos: en esta capa se realiza un acceso a base de datos en Access enla cual se
extraen todos los datos para mostrarlos de un manera esquemática según un Identificador.

AddressDataMana
frmAddressBook AddressData DataManager
ger

eStatus BD

Lógica de Negocio: esta capa prepara los datos para los procesos subsecuentes según la necesidad de el
uso.
AddressDataMana
frmAddressBook AddressData DataManager
ger

eStatus

• Capa de Presentación: Aquí se presentan los datos según la lógica del negocio.

AddressDataMana
frmAddressBook AddressData DataManager
ger

eStatus BD

8 Vista de Implantación
No Aplica.

9 Vista de Datos

10 Integración
10.1 Integración de los Componentes y su Comunicación

La llama a los procedimientos o métodos serán por medio de llamas a los mimos según el lenguaje de
programación, no se necesitaran sistemas externos para llamadas a procedimientos.

La base de datos será accesada por medio de un Adaptador SQL y se ejecutara por medio de un
executenonquery y la cadena de conexión será por medio de la clase Configuration.
10.2 Mecanismos de la Arquitectura para Futuras Modificaciones o Extensiones

En este apartado se debe responder la siguiente pregunta:


¿Qué mecanismos arquitecturales se utilizan para facilitar futuras extensiones o modificaciones?
Podríamos cambiar la base de datos cambiando los controladores. De otra forma las extensiones
y las modificaciones solo pueden ser hechas a nivel de diseño.
Nuevos componentes de plugin pueden ser cargados dinámicamente, mientras satisfagan la API
de plugins. De otra manera, no será posible añadir o cambiar componentes, debido a que esta
arquitectura utiliza dependencias directas entre sus componentes en lugar de invocación implícita.
Las extensiones y modificaciones pueden ser hechas a nivel de diseño, pero añadir estos cambios
requiere recompilación y tiempo fuera de línea.

11 Escenarios de la Arquitectura
11.1 Inicio de sistema

Leer Datos y
Editar Estado de Selección de
Limpiar campos colocarlos en la
Botones primer registro
Grilla

11.2 Apagado de sistema

Cerrar Formulario

12 Lista de Control de la Arquitectura


Evalúe su arquitectura respecto a cada uno de sus objetivos. A Continuación se colocan algunos
ejemplos:

Facilidad de Integración
Sí. En este sistema, todos los componentes están diseñados para trabajar juntos. Y los
componentes rehusados son integrados con interfaces simples.

Expansibilidad
Se pueden agregar después módulos en donde se haga un manejo mas integral de direcciones y
teléfonos múltiples debido a que algunas personas tienen múltiples teléfonos y direcciones.

Ajuste a la Capacidad
Este sistema se adapto a la capacidad de las necesidades del cliente ya que el no es necesario
que cuente con una maquina especializada para sistemas de este tipo, ya que no requiere muchos
recursos debido a que la base de datos esta creada en Access y no necesita un gestor de BD,
además el sistema está desarrollado en C# lo que le da la seguridad de que esta diseñado a
ciertas necesidades de red y bajo consumo de recursos.

Del Acuerdo entre el Equipo de Desarrollo y los Involucrados


Sí, cada uno entiende
13 Aseguramiento de la Calidad
13.1 Alcance del Plan de Calidad

• Agregar Registros
• Modificar registros
• Eliminar Registros

13.2 Objetivos de Calidad

Entregar un producto que sea económico, el más útil y satisfactorio para el cliente en el cual se pueda
reducir la máxima cantidad de errores y optimizar los recursos para el desarrollo.

13.2.1 Esenciales
• Funcionalidad > Corrección
• Funcionalidad > Robustez

13.2.2 Esperados
• Funcionalidad > Exactitud
• Funcionalidad > Compatibilidad
• Funcionalidad > Corrección medible
• Usabilidad > Comprensibilidad y Legibilidad
• Usabilidad > Apoyo para tareas
• Usabilidad > Eficiencia
• Usabilidad > Seguridad
• Usabilidad > Consistencia y Familiaridad
• Usabilidad > Satisfacción Subjetiva

13.2.3 Deseados
• Confiabilidad > Consistencia en carga
• Confiabilidad > Consistencia bajo concurrencia
• Confiabilidad > Disponibilidad bajo carga
• Confiabilidad > Longevidad
• Eficiencia
• Escalabilidad
• Escalabilidad > Desempeño bajo carga
• Escalabilidad > Grandes volúmenes de datos
• Operabilidad
• Capacidad de mantenimiento > Comprensibilidad
• Capacidad de mantenimiento > Capacidad de evolución
• Capacidad de mantenimiento > Capacidad de prueba

You might also like