Page 1

 

2013   Eviidencia de apren ndizajje. Len nguajje desscripto or  y y patr ones de arquitectura de so oftwarre

F Facilitador: Cu uitlahuac Varrgas Millán  A Alumno: Aleja andra Casteláán Germán  U Universidad A Abierta y a Disstancia de Mééxico  1 16/08/2013 


Evidencia de aprendizaje  Lenguaje descriptor y patrones de arquitectura de software  Objetivo  Para  demostrar  tu  conocimiento  acerca  de  los  tipos  de  patrones  arquitectónicos,  diseñarás  una  propuesta  de  arquitectura  que  sirva  para  solucionar  un  problema;  para  ello  considerarás  que  el  patrocinador  es  una  tienda  de  conveniencia,  analizarás  sus  requerimientos  de  software  y  lo  contrastarás  con  las  herramientas  de  diferentes  tipos  de  sistema,  siendo  capaz  de  elaborar  una  propuesta. 

Instrucciones Como parte de la evaluación de esta unidad, es necesario realizar en forma gráfica la arquitectura  de una tienda de conveniencia aplicando y justificando el uso del patrón específico.    Caso propuesto  “Una tienda de conveniencia necesita automatizar sus procesos de compra, venta y seguimiento de  clientes.  Lo desea hacer a través de venta en línea para sus clientes y que sus proveedores puedan acceder a  un sitio privado y vean automáticamente las existencias del producto que surten, al mismo tiempo  los  usuarios  podrán  comentar  sobre  su  experiencia  de  compra  en  línea  o  en  el  sitio;  estos  comentarios  los  podrán  hacer  a  través  de  un  equipo  de  cómputo  convencional  o  mediante  un  dispositivo móvil que será capaz de conectarse al sitio de la tienda.  El gerente de la tienda necesita que se obtengan tendencias de ventas y que se haga una posible  sugerencia a los compradores sobre la base a sus compras anteriores, y sobre todo considerando  su perfil (se entiende que el sistema deberá generar ese perfil en el que se incluya la edad, el sexo,  la ubicación, los amigos, las fotografías, su grado escolar y comentarios hechos).  Deberá  ser  fácil  de  usar  para  todos  los  usuarios  y  deberá  manejar  diferentes  tipos  de  roles  (administrador del sitio, gerente general, gerente de tienda, vendedor, proveedor, usuario normal)  y cada uno tendrá acceso a diferentes privilegios asignados por el administrador del sitio.”   

1. Tipos de patrones aplicables a la arquitectura de software  1.1 Descripción  Un patrón de arquitectura deberá entenderse como una guía que ofrecen solución a determinados  problemas ya conocidos, respecto a problemáticas fundadas en la ingeniería de software. También  expresa  de  manera  clara  la  relación  que  hay  entre  los  componentes  de  una  solución  basada  en  software y su esquema de organización estructural, incluyendo todos los subsistemas y acciones 

2


que deberá realizar cada uno de ellos, además de la manera correcta de comunicar el resultado de  esas acciones entre los mismos componentes, entre vistas o con otros sistemas externos. 

1.2 Análisis de patrones Patrón  arquitec‐ tónico 

Modelo Vista  Controla dor 

Layers o  Capas 

Descripción y contexto 

Patrones arquitectónicos Atributos de  Atributos de calidad  calidad en  asociados  conflicto 

Divide una aplicación  interactiva en tres  componentes. El modelo  contiene la información  central y los datos. Las  vistas despliegan  información al usuario. Los  controladores capturan la  entrada del usuario. Las  vistas y los controladores  constituyen la interfaz del  usuario. 

Funcionalidad (Características y  capacidades del  programa, Generalidad  de las funciones,  Seguridad del sistema,  Portabilidad  Exactitud)    Mantenibilidad  (Modificailidad,  Estabilidad, Capacidad  de pruebas) 

Consiste en estructurar  aplicaciones que pueden  ser descompuestas en  grupos de subtareas, las  cuales se clasifican de  acuerdo a un nivel  particular de abstracción. 

Reusabilidad (Modularidad,  Independencia del  sistema,  Independencia de  máquina)    Portabilidad  (Adaptabilidad,  Instlabilidad,  Reemplazabilidad)    Facilidad de Prueba  (Simplicidad,  Instrumentación) 

Mantenibilidad (Cuando las  capas no son  independientes  del todo) 

Ventajas

Facilita la tarea de  desarrollo de  aplicaciones.                    Hace a los sistemas más  mantenibles, flexibles y  adaptables.  Múltiples vistas para el  mismo modelo.    Vistas sincronizadas.    Vistas y controladores  intercambiables  Reutilización de niveles.     Soporte para la  estandarización.     Los cambios en el código  son locales a cada nivel,  lo que permite el diseño  de arquitecturas  escalables (que pueden  ampliarse con facilidad  en caso de que las  necesidades aumenten).    Separación de la lógica  de negocios de la lógica  de diseño. 

Desventajas Mayor complejidad.   Relación estrecha  entre vista y  controladores.    Ineficiencia en el  acceso a los datos  desde la vista.    Cambios inevitables a  las vistas y  controladores al  portarlos.    Difícil de usar MVC  con herramientas  gráficas modernas.  Si los servicios no  están bien  organizados, el  sistema podría tener  problemas de  mantenibilidad,  adaptabilidad y  escalabilidad.    Pocos niveles no  explotan el potencial  de reúso,  portabilidad e  intercambiabilidad.  Muchos niveles crean  complejidad e  ineficiencia 

3


2. Solución preliminar de la arquitectura de software sobre la base de los  requerimientos del usuario   

2.1 Descripción    Recordemos  que  la  Arquitectura  de  Software  (AS)  es  una  conjunción  de  ADL,  patrones  arquitectónicos y visitas, dando como resultado una AS completa y robusta.  Entendamos  al enfoque arquitectónico como la capacidad de arquitecto de software para poder  describir un problema, este problema o problemas vienen derivados de los requerimientos que el  cliente  pide  para  poder  satisfacer  su  necesidad  (se  listan  a  continuación),  en  términos  de  un  lenguaje comúnmente aceptado y con los términos adecuados, es decir, saber cómo modelar un  software desde “el punto de vista estructural”.    

2.2 Requerimientos del Software     Requerimientos de software  El  diseño  de  software  es  un  proceso  mediante  el  que  se  traducen  los  requisitos  en  una  representación del software.  Posteriores refinamientos conducen a una representación de diseño  que se acerca mucho al código fuente.  REQUERIMIENTOS FUNCIONALES, “El qué, no el cómo”:  a) b) c) d) e)

Automatizar procesos de compra, venta y seguimiento de clientes  Venta en línea para clientes  Acceso a sitio privado a proveedores para consultar existencias  Sección de opinión del cliente  Control de tendencias de ventas 

ATRIBUTOS DE CALIDAD, “El cómo, no el qué”:  a) Interfaz    deberá  adaptarse  a  diferentes  dispositivos  (móvil  u  ordenador  con  acceso  a  internet)  b) Sugerencia a compradores con base a compras anteriores y perfil  c) El software contará con un módulo de ayuda de cada uno de los procsos y ventanas que  facilite su uso. 

4


d) El software deberá ser capaz de detectar algún error de autentificación, por lo que en caso  dado lanzará una página indicando al usuario que vuelva a introducir el nombre de usuario  y contraseña, logrando un sistema seguro.    ADL a implementar:    UML    A pesar de que UML no forma parte de los lenguajes formales de modelado, ha perdurado a través  de los tiempos. Además de ser conocido por buena parte de personas enroladas en el diseño de  software.  • En los últimos años, Unified Modeling Language (UML), ha conseguido un rol importante  en el proceso  de desarrollo de software en la actualidad. La unificación  del  método de  diseño y las notaciones, ha ampliado, entre otras cosas, el mercado de  herramientas CASE  que soportan el proceso de diseño de arquitecturas de software.     • UML  ofrece  soporte  para  clases,  clases  abstractas,  relaciones,  comportamiento  por   interacción,  empaquetamiento,  entre  otros.  Estos  elementos  se  pueden  representar   mediante nueve tipos de diagramas que se pueden utilizar para describir un ADL, que son:  de  clases,  de  objetos,  de  casos  de  uso,  de  secuencia,  de  colaboración,  de  estados,  de  actividades, de componentes y de desarrollo.    • UML  permite  establecer  estandarización  del    Modelo  arquitectónico,  además  es    para  aquellos analistas familiarizados con este estándar.     • UML 2.0 ha introducido mejoras. Esto se debe a que el modelo de estructura compuesta  permite  especificar  la  arquitectura  del  software  siguiendo  una  más  adecuada  que  la  notación  basada  en  componentes  de  UML  1.X,  introduciendo  conceptos  para  la  composición  de  componentes,  por  ejemplo  el  concepto  de  puerto  que  mejora  la  encapsulación de los componente y los conectores como relación entre componentes.    • UML tiene una alta capacidad expresiva lo que posibilita representar todos los aspectos de  la arquitectura Web.    • Su capacidad para representar el sistema a diferentes niveles de abstracción, así cada uno  de los miembros de desarrollo, arquitectos, diseñadores y analistas pueden enfocarse en  los problemas que les ocupa, olvidándose de los demás aspectos.    • Los  modelos  pueden  ser  intercambiables  entre  diferentes  herramientas  que  tengan  soporte  de  UML,  así  los  modelos  pueden  ser  reutilizados  e  intercambiados  entre  diferentes equipos y compañías. 

5


2.3 Propuesta de arquitectura    Para continuar definiendo la propuesta de la arquitectura se deben tener patrones arquitectónicos  a los cuales adherirse, éstos nos darán la pauta para poder tener una guía sobre cuál es la mejor  manera  de  solventar  la  situación  que  presentan  los  requerimientos  antes  señalados,  basado  en  experiencias  anteriores  al  resolver  problemas  similares  con  la  finalidad  de  poder  describir  de  manera correcta una estructura que soportara al software (a la solución) por completo.    De  los  patrones  arquitectónicos  antes  mencionados  (Modelo  Vista  Controlador  y  Capas)  el  que  más  se  ajusta  a  nuestras  necesidades  es  el  patrón  Modelo  Vista  Controlador,  en  el  cual  nos  adentraremos con mayor detenimiento.  Patrón  Contexto 

Problema

Solución

Modelo Vista Controlador  “Desarrollar  software  con  una  interfaz  Humano‐computador  para  tienda  de  conveniencia  cuya  prioridad  es    automatizar  sus  procesos  de  compra,  venta  y  seguimiento de clientes”  Se requiere solventar venta en línea para clientes. Facilitar acceso de proveedores a  sitio para análisis de existencias de producto. Promover la interacción directa con el  cliente  mediante  aplicación  de  internet,  a  través  de  equipo  de  cómputo  o  dispositivo móvil. Realizar sugerencias al cliente de acuerdo a perfil generado por el  propio sistema.  El  diseño  de  aplicaciones  disponibles  en  la  web  ha  facilitado  en  gran  medida  la  administración de empresas y el impacto en el mercado.   En  la  actualidad  MVC  es  bastante  utilizado  en  marcos  de  aplicación  Orientado  a  Objetos, como es el caso de la tienda de conveniencia. Se hace la recomendación de  utilizar  Java  Swing,  el  cual  implementa  al  patrón  MVC  como  base  de  diseño.  Con  ello  damos  solución  al  problema  de  portabilidad  que  MVC  por  sí  solo  presenta  como atributo de calidad en conflicto. 

2.3.1 Justificación de uso de patrón Modelo Vista Controlador    MVC es un patrón de diseño que considera dividir una aplicación en tres módulos claramente  identificable y con funcionalidad bien definida: El Modelo, las Vistas y el Controlador. 

6


7


Justificación:   9 La aplicación está implementada modularmente  9 Sus vistas muestran información actualizada siempre.  9 El programador no debe preocuparse de solicitar que las vistas se actualicen, ya que este  proceso es realizado automáticamente por el modelo de la aplicación  9 Si  se  desea  hacer  una  modificación  al  modelo  del  dominio,  como  aumentar  métodos  o  datos  contenidos,  sólo  debe  modificarse  el  modelo  y  las  interfaces  del  mismo  con  las  vistas, no todo el mecanismo de comunicación y de actualización entre modelos.  9 Las modificaciones a las vistas no afectan en absoluto a los otros módulos de la aplicación.  9 MVC  es  bastante  utilizado  en  la  actualidad  en  marcos  de  aplicación  orientados  a  objeto  desarrollados para construir aplicaciones de gran tamaño; Java Swing, siguen este patrón  de diseño.  9 MVC está demostrando ser un patrón de diseño bien elaborado pues las aplicaciones que  lo  implementan  presentan  una  extensibilidad  y  una  mantenibilidad  únicas  comparadas  con otras aplicaciones basadas en otros patrones.     Recordemos que uno de los requerimientos del usuario es la disponibilidad del servicio en internet  con acceso a través de dispositivos móviles o pc´s. Para resolver este requerimiento se recomienda  la implementación de Java Swing.  Java  es  un  lenguaje  orientado  a  objetos  desarrollado  por  Sun  Microsystems  que  tiene  como  características fundamentales su portabilidad a un gran número de plataformas, su simplicidad y  su extenso conjunto de librerías.  La  librería  de  interfaces  gráficas  de  usuario  que  viene  en  el  SDK  (Software  Development  Kit)  de  Java se llama Java Swing y tiene estas características sobresalientes:  9 Implementa bastantes componentes visuales (botones, campos de texto, tablas, barras de  menús, árboles, etc.).  9 Los componentes provistos por Java Swing son independientes de la plataforma donde se  ejecuta la aplicación, por tanto, la portabilidad de las aplicaciones desarrolladas con Swing  está garantizada.  9 Permite  “conectar”  y  “desconectar”  estilos  de  interfaz  de  usuario  (llamados  “look  and  feels”)  que  modifican  la  forma  en  que  se  muestra  y  se  comporta  toda  la  interfaz  de  usuario, así, la misma aplicación puede verse como una aplicación Windows o como una  aplicación Motif, simplemente conmutando el look and feel en tiempo de ejecución.   

8


9 Cumple con n el diseño dee JavaBeans q que hace que los componeentes de esta librería pued dan  ser utilizado os en entorno os de desarro ollo integrados (IDEs) como o JBuilder, Sun Forte for Jaava  o Eclipse.  9 Su arquitectura está pro ofundamente  basada en M MVC, lo que proporciona un alto grado  de  extensibilidad y de perso onalización dee los compon nentes de la librería.     Si  bieen  su  arquittectura  se  fundamente  f en  el  patró ón  MVC,  preesenta  algun nas  diferencias  significcativas  en  su  implementaación.  La  difeerencia  más  notoria  es  que  el  controlador  y  la  vissta  están  implementad i dos  como  un  único  elemeento  denomin nado  “delegaado  de  interffaz  de  usuario o”.  Cada  componente  c unto  de  dato os  (modelo  del  d dominio)  a  través  de  un  está  asociado  a  un  conju modelo o  de  aplicaciión  y  del  delegado  de  in nterfaz.  Este  delegado  ha  sido  diseñado  debido  a  la  incapacidad de programar un co ontrolador geenérico con cconocimiento  de la vista a la que hubieera  o  controlar,  por  p tanto,  cad da  componen nte  tiene  aso ociado  un  delegado  de  intterfaz  que  a  su  podido vez, esstá asociado aa un modelo d de aplicación que proporcciona toda la iinformación q que el delegado  requiere y que notiifica al compo onente si algún cambio see ha dado en  el modelo del dominio, p por  mplementa el modelo MVC C en una implementación por componeente.  tanto, Java Swing im

un elemento d denominado “administrad dor  En la fiigura anteriorr se observa ttambién la exxistencia de u de  interfaz  de  usu uario”  (“UI  manager”);  m e este  elementto  permite  conectar  c un  look  and  feeel  omponente visualizado y aalmacena tam mbién informaación general a la apariencia  específfico a cada co de  los  componente es  en  su  visualización  (color  de  fondo o  por  defecto o,  tipo  de  letra  por  defecto,  S están  manejados  por  el  mism mo  tipos  de  bordes,  etc.).  Todos  los  componentes  de  Swing  adminiistrador de in nterfaz de usu uario.  Los mo odelos implem mentados en  Swing están  clasificados een dos catego orías: Modelo os de estado  de  interfaz de usuario y modelos dee datos. Los m modelos de estado de inteerfaz definen el estado visu ual  presionado o  información  de  de un  componente, como por eejemplo, el esstado de un  botón está p ms seleccionaados en determinada listaa. Los modelo os de datos reepresentan in nformación q que  los ítem está  contextualiza c a Esstos  modelo os  de  datoss  sirven  com mo  puente  de  da  en  la  aplicación.  comun nicación entre e el modelo del dominio y el delegado d de interfaz dee un componeente. 

9


2.3.2 Diagrama de la arquitectura propuesta 

Diagrama de Casos de uso    Los  casos  de  uso  permiten  expresar  gráficamente  las  relaciones  entre  los  diferentes  usos  del  sistema y sus participantes o actores. 

 

Diagrama de Clases    Los diagramas de clase son utilizados para mostrar las relaciones entre las clases que involucran el  sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenido.  Muestran la estructura interna de un sistema. En este caso elegimos las clases involucradas en el  proceso de compra venta: 

10


Gráfico d G  de estado en pro oceso de  venta  El Diaggrama de Estaados especificca la secuenciia de estadoss que pasa el caso de uso, en esta ocasiión  el procceso de comp pra‐venta en  línea, o pued de ser un objjeto a lo largo o de su vida.  Se indican q qué  evento os hacen que  se pase de u un estado a o otro y cuáles sson las respu uestas y accio ones que da p por  resultaado.   

11


3. Contrastando arquitectura y patrón de diseño   

3.1 Descripción de las diferencias       Arquitectura de Software es el conjunto de decisiones significativas sobre la organización  de un  sistema de software que define los principios que guían el desarrollo, los componentes principales  del sistema, sus responsabilidades y la forma en que se interrelacionan.    Un  patrón  de  arquitectura  de  software  es  un  esquema  genérico  probado  para  solucionar  un  problema  particular,  que  surge  o  es  recurrente  en  un  contexto  específico.  Este  esquema  se  especifica describiendo los componentes, con sus responsabilidades y relaciones. Además describe  restricciones, manera de comunicarse entre componentes, seguridad, viaje de datos y el protocolo  de transmisión de datos a usar.    El  patrón  de  arquitectura  de  software  es  un  esquema  genérico  probado  creado  con  el  fin  de  no  reinventar soluciones a problemas ya conocidos, reusando la experiencia del diseño.        A  continuación  se  plantea  la  diferencia  entre  el  estilo  Arquitectónico  y  el  Patrón  arquitectónico,  recordando que algunos autores han decidido tomarlo como términos indistintos, sin embargo, es  conveniente identificar las distinciones:     

Estilo Arquitectónico

Patrón Arquitectónico 

Existen en varios rangos de escala,  Sólo describe el esqueleto estructural y general  comenzando con patrones que definen la  para las aplicaciones  estructura básica de una aplicación.  Partiendo de la definición de patrón, requieren  Son independientes del contexto al que puedan  de la especificación de un contexto del  ser aplicados  problema  Depende de patrones más pequeños que  Cada estilo es independiente de los otros  contiene, patrones con los que interactúa o de  patrones que lo contengan  Expresa un problema recurrente de diseño muy  Expresan técnicas de diseño desde una  específico y presenta una solución para él,  perspectiva que es independiente de la  desde el punto de vista del contexto en el que  situación actual de diseño  se presenta.  Son soluciones generales a problemas  Son una categorización de sistemas  comunes.     

 

12


Conclusiones           Después de haber analizado los requerimientos funcionales y atributos de calidad se ha llegado a  la  conclusión  de  que  para  la  solución  del  problema  de  la  tienda  de  conveniencia,  en  el  que  la  prioridad  es  atender  el  proceso  de  compra‐venta  por  internet,  se  ha  elegido  el  patrón  arquitectónico  de  “Modelo‐Vista‐Controlador”.  Este  patrón  ha  sido  la  base  en  el  diseño  de  aplicaciones  disponibles  en  la  web.  Además  ha  facilitado  en  gran  medida  la  administración  de  empresas y el impacto en el mercado    Recordemos que conocer los patrones arquitectónicos, su correcto uso y aplicación dentro de la  solución  de  un  problema  en  un  ámbito  específico  ayuda  a  encontrar  una  solución  confiable,  dirigiendo al proyecto por la mejor de las alternativas.      No  es  estrictamente  riguroso  que  un  proyecto  se  encuentre  enmarcado  en  un  solo  patón.  Cada  patrón  depende  de  los  patrones  más  pequeños  que  contiene  y  de  los  más  grandes  donde  está  contenido. Distintos aspectos de un sistema pueden resolverse con distintos patrones. 

13


Refer R renciaas con nsultaadas   

quitectura  Clases__13_y_14_Paatrones_y_Arq https:///www.u‐curssos.cl/ingenieeria/2005/2/C CC51A/1/matterial_docente/   

Modelación Orientaada al Proceso o para SOA, P Parte 2: Patro ones de proceesos  Diseño os para aplicar la infraestru uctura de desscomposición a nuevas situ uaciones  http:///www.ibm.co om/developerrworks/ssa/w webservices/library/ar‐proccmod2/   

ocumentos/PSS‐6116/Guia% %20Arquitecttura%20v.2.pdf  http:///prof.usb.ve/llmendoza/Do    

14


Tesis Doctoral  D Web b  SA:  Un  Méétodo  de  Deesarrollo  Diriggido  por  Modelos  de  Arq quitectura  paara  Aplicacciones  Web.  Grupo  de  Investigación n  IWAD,  Deepartamento  de  Lenguajees  y  Sistemas.  Univerrsidad de Alicaante. Santiago Meliá.  http:///www.dlsi.ua.es/~santi/paapers/thesis_d definitiva.PDF      http://w www.ucbcba.e edu.bo/Publiccaciones/revisstas/actanova a/documentoss/v2n4/v2.n4.bascon.pdf

http:///prezi.com/sxx9c3vosjugs/ccaracteristicass‐de‐manteniibilidad‐y‐porrtabilidad‐dell‐software/    El patrón de diseño Modelo‐Vista‐Controlado or (MVC) y su implementacción en Java SSwing. Ernestto  Bascón n Pantoja, Dessarrollador dee software, Jaalasoft.  http:///www.ucbcbaa.edu.bo/Pub blicaciones/reevistas/actano ova/documen ntos/v2n4/v2.n4.bascon.pdf   

15

Lenguaje descriptor y patrones de arquitectura de software  
Read more
Read more
Similar to
Popular now
Just for you