DDRS_U2_A2_ABAF

Vista previa del material en texto

Abraham Yafté Ascencio Frías 
# CONTROL: AL11513379 | DESARROLLO DE SOFTWARE 
Seleccionando un 
estilo 
DISEÑO Y ARQUITECTURA DE SOFTWARE 
UNIVERSIDAD ABIERTA Y A DISTANCIA DE MÉXICO 
 
 
 
 
pág. 1 
 
 
Contenido 
1.Introducción ..................................................................................................................................... 2 
2.Instrucciones .................................................................................................................................... 2 
3.Desarrollo ......................................................................................................................................... 3 
3.1 Requerimientos ........................................................................................................................ 3 
3.2 Estilo arquitectónico ................................................................................................................. 4 
3.3 Justificación .............................................................................................................................. 4 
3.4 Actividades del proceso de diseño ........................................................................................... 4 
3.5 ADL adecuado ........................................................................................................................... 6 
4.Conclusión ........................................................................................................................................ 6 
5.Bibliografía ....................................................................................................................................... 7 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
pág. 2 
 
1.Introducción 
El alumno ha analizado lo correspondiente tanto a estilos de diseño como previamente a los 
procesos para hacer el diseño de software; con ello el alumno ya tiene una interrelación de 
todos los conceptos y como aplicarlos. El alumno realizará la practica con la finalidad de 
verlos aplicados a un caso de estudio en concreto. Para finalizar el alumno creara sus propios 
conceptos y definiciones los cuales se verán implícitos en el resultado de la presente 
actividad. El alumno generará conclusiones de la actividad. 
2.Instrucciones 
Analiza detenidamente el caso de estudio y realiza los siguientes puntos: 
1. Identifica los requerimientos funcionales y no funcionales derivados del caso de 
estudio. 
2. Determina un estilo arquitectónico que sea el indicado para el desarrollo del modelo 
de arquitectura del caso de estudio. 
3. Redacta una justificación acerca de tu elección de modelo para solventar el caso de 
estudio presentado. 
4. Menciona y explica cada uno de los pasos del proceso de diseño del software y 
describe las actividades que deben realizarse para la obtención del diseño final. 
5. Identifica y explica el ADL (lenguaje de definición de arquitectura) de distribución 
libre más apropiado para aplicar en el caso. Justifica tu respuesta 
Caso de estudio: 
Descripción 
Un comercio de venta de Café “Café Calenda” de la Ciudad de Oaxaca desea un sistema para 
administrar las ventas de sus productos. A los dueños del negocio, administradores y clientes 
les interesa tener acceso al sistema. 
• Dueños. Podrán acceder desde cualquier lugar. 
• Administradores. Únicamente en el establecimiento físico. 
• Clientes. Tendrán tabletas en sus lugares en la que revisarán sus 
consumos. 
Los dueños y administradores deben acceder con todos los privilegios. 
 
pág. 3 
 
• Pueden ver información de todos los clientes, productos consumidos, 
precios, etcétera. 
• Menú de productos. 
• Inventario. 
• Lista de empleados. 
• Reportes. 
• Estadísticas. 
Los clientes 
• Consumo y precios. 
• Menú. 
• Factura. 
Considera que el software, de manera general debe: 
• Administrar ventas. 
• Gestionar inventario. 
• Administrar privilegios de usuarios con acceso al sistema. 
• Historial de ventas. 
• Gráficas 
3.Desarrollo 
3.1 Requerimientos 
Tabla 1. Requerimientos funcionales y no funcionales de Café Calenda 
Requerimiento Funcional No 
funcional 
Área de oportunidad dirigida 
Administración de 
ventas 
X Consumo y precios, menú, factura, información por 
cliente. 
Gestión de 
inventario 
X Menú de productos 
Administrador de 
privilegios 
X Brindar acceso (dueños, administradores y clientes) 
Historial de ventas X Reportes, lista de empleados 
Graficas X Estadísticas 
Compatibilidad de 
hardware 
 X Compatibilidad con la tecnología de tabletas 
Interconectividad X Base de datos conectada a internet para acceder desde 
cualquier punto 
Compatibilidad de 
software 
 X Compatibilidad con SO de escritorio 
 
pág. 4 
 
Compatibilidad de 
archivos de salida 
 X Generación de reportes en formato compatible PDF 
3.2 Estilo arquitectónico 
Se propone usar una arquitectura del estilo cliente-servidor por la notable aplicación que va 
a tener productivamente, ya que es requerido tener una base de datos y la forma en que la 
programación va a trabajar es en función a consultas y cambios dentro de la misma base de 
datos. Por lo que comprendiendo que se necesita una interfaz que actúa como cliente con 
acceso a un servidor de datos, tenemos que este estilo de arquitectura es la que más de adapta 
a ello. 
3.3 Justificación 
• Será una aplicación donde un servidor soporte a múltiples clientes; caca cliente 
tendrá su nivel de autorización para hacer cambios dentro de la base de datos. 
• Con el uso de la aplicación en un área local, con la característica de lograr una 
comunicación a través de internet para poder controlarla en el caso de los dueños o 
administradores. 
• Se debe visualizar desde cualquier lugar, por lo que se debe tener en cuenta el 
soporte para dispositivos distintos. 
• La interfaz grafica ayudará a los usuarios a hacer consultas en la base de datos de 
una manera intuitiva y sencilla. 
3.4 Actividades del proceso de diseño 
Las actividades que se realizan en este proceso conforme a lo establecido por Ian 
Sommerville (2005) son las siguientes: 
1. Dividir requerimientos 
Los requerimientos identificados y solicitados por el cliente, resultado de la fase de análisis, 
conforman el elemento de entrada de la fase de diseño. El fin de la primera actividad del 
diseño es dividir los requerimientos obtenidos en grupos afines que pueden estar dados por 
áreas de funcionalidad, procesos (reglas de negocio, procedimientos de bases de datos, 
reportes, etc.) o cualquier otra subdivisión que el diseñador considere adecuada. 
En el caso actual, lo logramos en el punto 3.1 de la presente actividad, donde podemos ver 
una tabla con los requerimientos funcionales y no funcionales que nos describen 
 
pág. 5 
 
implícitamente y explícitamente el dialogo con el cliente sobre lo que necesita para su 
negocio. 
2. Identificar subsistemas 
Es muy común que los grupos de requerimientos resultantes estén relacionados con los 
subsistemas. Estos subsistemas deben identificarse de tal manera que cumplan cabalmente 
con los requerimientos ya sea de manera individual o colectiva. Cabe mencionar que esta 
actividad puede verse influenciada por factores organizacionales y del entorno. Se identifican 
el marco para el control y comunicación entre los subsistemas. 
En el caso se podría apreciar englobando las distintas interfaces que van a usar los distintos 
usuarios; es decir no es lo mismo la interfaz del administrador, que la del cliente y que la del 
dueño; cada una es distinta y también lo es en funcionalidad, por lo cual a cada una se le 
puede asignar un subsistema especifico. 
3. Asignar requerimientos a los subsistemas 
Deben describir las funciones que serán realizadas por cada subsistema. Se puede deducir 
que en la practica no siempre resulta igual la división de requerimientos a la identificación 
de los subsistemas, incluso existenocasiones que debe realizar una reanálisis de ciertos 
requerimientos para adaptarlos, dentro de un proceso iterativo a los subsistemas 
identificados. 
En el caso es analizar como es que cada uno de los subsistemas va a funcionar, esto se puede 
apreciar quizá en el nivel de autorización que cada usuario va a tener para controlar el sistema 
completo. 
4. Especificar la funcionalidad de los subsistemas 
Determinar su funcionalidad, así como especificar las relaciones y formas de interconexión 
de los mismos. Debe existir una especificación abstracta de los servicios que provee y las 
restricciones bajo las cuales se va a operar. 
En el caso, para este punto ya sabemos que va a hacer cada subsistema y la manera de 
proceder es vincularlos técnicamente en el software para que su funcionalidad en conjunto 
 
pág. 6 
 
represente la funcionalidad completa del sistema, que es la finalidad y lo que el cliente 
requiere. 
5. Definir las interfaces de los subsistemas 
Se realiza el diseño requerido para la interface de cada uno de los subsistemas previamente 
definidos, lo que permitirá desarrollarlos en paralelo. El diseño de las formas de interface de 
usuario es un componente importante en el proceso que incluso puede influenciar otras 
decisiones sobre el mismo diseño. Para el diseño de interfaces se toman en cuenta aspectos 
como visibilidad del estatus del sistema, consistencia, flexibilidad y eficiencia de uso, ayuda 
a los usuarios sobre el sistema, entre otros. 
En este caso ya contemplando lo que se necesita en cada subsistema, se crea desde la parte 
grafica e implementando la funcionalidad de cada uno de los usuarios; así mismo se planea 
que todas las interfaces sean amigables e intuitivas para lograr la satisfacción del cliente. 
3.5 ADL adecuado 
Recomendaría el ADL Acme por su basta compatibilidad, tanto para otros ADLs como para 
lenguajes de programación como lo es Java, el cual para el caso que se requieren interfaces 
y conexiones, seria adecuado usar debido a sus ventajas de ser un lenguaje orientado a 
objetos. 
Además, Acme es libre y por lo tanto de uso gratuito; siendo la aplicación no muy 
demandante debido a la funcionalidad que tiene, Acme puede representar un ADL adecuada 
para utilizar en el caso. 
4.Conclusión 
Los estilos de arquitectura nos ayudan a definir como proceder para resolver un problema, 
como se vio en la actividad, principalmente parte de un modo de acoger el problema para 
poder brindarle una solución. 
Por su parte la metodología de diseño es mas hecho a cuando tenemos esa estructura que nos 
da la arquitectura, es la manera de proceder para lograr el fin deseado que en nuestro caso es 
l software funcional y con los requerimientos satisfechos de lo que el cliente nos solicitó. 
 
pág. 7 
 
Considero ambas herramientas esenciales para hacer una definición de un proyecto buena y 
obtener los resultados mas óptimos para la satisfacción del cliente. 
5.Bibliografía 
EcuRed. (1 de Noviembre de 2019). Acme. Obtenido de EcuRed: https://www.ecured.cu/Acme 
Reynoso, C., & Kicillof, N. (4 de Marzo de 2014). De Lenguajes de descripción arquitectónica de 
Sofware (ADL). Obtenido de Willy.net: 
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:adl.pdf 
Reynoso, C., & Kicillog, N. (2004). Estilos y patrones en la estrategia de arquitectura de Microsoft. 
Buenos Aires: Universidad de Buenos Aires. 
Sommerville, I. (2005). Ingeniería del software . Madrid: Pearson Educación. 
Unversidad Abierta y a Distancia de México. (2015). Unidad 2. Elementos de diseño de arquitectura 
de software. D.F.: DCEIT.