Calidad de Software

Todas las metodologías y herramientas tienen un único fin producir software de gran calidad

• Definiciones de calidad del software:

– “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente” R.S. Pressman (1992).

– “El conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas” ISO 8402 (UNE 66-001-92).

Aseguramiento de calidad del software

(Software Quality Assurance)

• El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad.
• El aseguramiento de calidad del software se diseña para cada aplicación antes de comenzar a desarrollarla y no después.
• Algunos autores prefieren decir garantía de calidad en vez de aseguramiento.
– Garantía, puede confundir con garantía de productos
– Aseguramiento pretende dar confianza en que el producto tiene calidad
• El aseguramiento de calidad del software está presente en
– Métodos y herramientas de análisis, diseño, programación y prueba
– Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software
– Estrategias de prueba multiescala
– Control de la documentación del software y de los cambios realizados
– Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos)
– Mecanismos de medida (métricas)
– Registro de auditorias y realización de informes
• Actividades para el aseguramiento- de calidad del software
– Métricas de software para el control del proyecto
– Verificación y validación del software a lo largo del ciclo de vida
• Incluye las pruebas y los procesos de revisión e inspección
– La gestión de la configuración del software

Fuente: Calidad del Software (Conferencia, 21 de Octubre de 1999 – Grupo GIDIS – Universidad Nacional de la Pampa)

Anuncios
Publicado en Uncategorized | Deja un comentario

Arquitectura Cliente-Servidor

 

Es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta.

  • Clientes pesados / Servidores ligeros: La mayor parte de la funcionalidad  de la aplicación se implementa en el cliente. 

„ * Los servidores son mecanismo de acceso a recursos compartidos.
„ * Mayor flexibilidad para aplicaciones que implementan nuevas funcionalidades.
„    Ejemplos: Servidores de bases de datos o servidores de ficheros.

  • Clientes ligeros / Servidores pesados: La mayor parte de la funcionalidad se implementa en los servidores.

„ * Incrementar la reusabilidad del código.
„ * Son mas fáciles de desplegar y administrar.
„ * Se basan en servidores mas abstractos que reducen el flujo por la red.
„ * En vez de proporcionar datos, exportan procedimientos.
„    Ejemplos: Servidores de transacciones y servidores web.

Publicado en Uncategorized | Deja un comentario

SaaS y ASP

Active Server Pages (ASP)

También conocido como ASP clásico, es una tecnología de Microsoft del tipo “lado del servidor” para páginas web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Services (IIS).

La tecnología ASP está estrechamente relacionada con el modelo tecnológico y de negocio de su fabricante. Intenta ser solución para un modelo de programación rápida ya que “programar en ASP es como programar en Visual Basic y C#“, por supuesto con muchas limitaciones y algunas ventajas específicas en entornos web.

Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados como algunos controles ActiveX así como componentes del lado del servidor, tales como CDONTS, por ejemplo, que permite la interacción de los scripts con el servidor SMTP que integra IIS.

Se facilita la programación de sitios web mediante varios objetos integrados, como por ejemplo un objeto de sesión basada en cookies, que mantiene las variables mientras se pasa de página a página.

Está limitada (la tecnología ASP) a funcionar solo en Microsoft Windows,2 pues requiere el servidor IIS; aunque en las versiones “9x” de Microsoft Windows era posible instalar Microsoft Personal Web Server  (PWS) y de esa manera usar asp.3 También puede instalarse software de terceros como por ejemplo Baby Web Server .

Por lo que su uso es cuestionado por la mayoría de los programadores web, quienes prefieren otros lenguajes de programación del lado del servidor como por ejemplo PHPPerlJava etc.

Software as a Service (SaaS)

El Software como Servicio, SaaS (Software as a Service) es un modelo de distribuir aplicaciones de computación por medio de la Internet. Los usuarios de las aplicaciones de software SaaS no pagan licencias para instalarlo en sus computadoras. En lugar de ello paga una suma mensual por usarlo. El término SaaS se ha convertido en el preferido de la industria, reemplazando a los que se han estado utilizando como “On-Demand” o “Utility Computing”.
 
El concepto de “software as a service”, SAAS, es simple. Se basa en que los datos y programas se almacenan en un ambiente seguro centralizado, que es de fácil acceso y sencilla administración. Cada usuario en la red tiene su propio perfil, accesible desde un directorio común, sin estar atado a una computadora especifica. Los usuarios almacenan sus datos en un repositorio central y no en maquinas locales. Las aplicaciones y servicios son manejadas desde ese directorio común, con accesos predefinidos de acuerdo a los roles de los usuarios, en su grupo correspondiente.


Hemos sido testigos de muchas tecnologías que han provocado enormes cambios. Algunas de ellas han tenido impactos profundos sobre nuestra vida diaria y la forma que funcionan nuestros negocios. Algunas han perdurado, otras desaparecieron como un relámpago. Nos son tan comunes, que nos damos cuenta de ellas, porque las tomamos como naturales.

El software como servicio es un modelo en el cual el vendedor del software proporciona una versión de la misma en un servidor en la Web de la Internet. Esta aplicación puede accederse por los clientes en un Sitio Web, pagado por uso, por proyecto o por suscripción. Salesforce.com es un ejemplo notable del modelo de SaaS. El modelo SaaS ofrece ventajas significativas a los vendedores de software y a sus clientes.

El modelo de SaaS ofrece a clientes una formula costo eficiente, eliminando la necesidad de invertir altas sumas en la compra de licencias de software. También elimina los costos y riesgos de instalar, dar soporte y mantenimiento de hardware en computadoras de la empresa y de mantener personal necesario. Además, el acceso del usuario y el rendimiento de las aplicaciones pueden mejorarse dramáticamente con los sistemas basados en la Web disponibles 24 horas diarias, 7 días a la semana.

El modelo de SaaS abre nuevos mercados a los vendedores de software. Las compañías establecidas del software pueden ensanchar sus mercados, al ofrecer soluciones SaaS a Pequeños y Medianos Empresarios. Estos no pueden invertir grandes sumas iniciales, pero si pueden pagar montos mensuales razonables, como los permite el SaaS, o en demanda.

El software como servicio (SaaS) está demostrando tener gran potencial de impactar nuestras vidas diarias de muchas formas. Por ejemplo, una pequeña empresa en Guatemala o Quito, puede ahora tener acceso inmediato a un mercado internacional, incluyendo sus productos en eBay, sin pagar nada.
 
Muchas PYMEs de Latinoamerica no ha podido automatizar su fuerza de venta debido al costo de las licencias del software y al hardware requerido. Ahora, gracias a salesforce.com, puede tener un sistema CRM, por US$59.00 por usuario por mes. Las familias pueden ahora compartir las fotos con los amigos a través del país con servicios tienen gusto de Ofoto. La lista crece sin cesar. 

Los ejemplos anteriores tienen elementos comunes:

  •  El software se paga a medida que se usa.

  •  El usuario no requiere software o hardware que comprar, instalar y mantener.

  •  Aparte de una PC, sin mayores requisitos y conexión del Internet, el resto es proporcionado por el vendedor del sistema SaaS.

Estas diferencias críticas entre el modelo de SaaS y el modelo tradicional de licencia están conduciendo a la adopción de SaaS. En el modelo tradicional el cliente adquiere una licencia perpetua y asume la responsabilidad de manejar el software. En este modelo hay un alto costo inicial asociado a la compra de la licencia, así como la responsabilidad de la puesta en marcha y del mantenimiento correspondiente. El ROI es a menudo considerablemente largo. Debido a los rápidos cambios tecnológicos, las costosas aplicaciones de software se convierten rápidamente en obsoletas.

Al encontrarse los datos y las aplicaciones en servidores centralizados accedidos remotamente, permite a todos los usuarios tener las últimas versiones actualizadas. Los datos por su parte se encuentran completamente seguros, dado que ningún dato se encuentra almacenado en computadoras locales de los usuarios. A la vez se elimina la dependencia de los técnicos locales, o de los viajes que deben hacer para solucionar problemas.

Sea como se le termine llamando es sin duda el futuro de la industria del software. Las ventajas de uso inmediato, pagarlo por uso, actualizaciones inmediatas, recuperación instantánea de fallas y no tener que preocuparse del mantenimiento han capturado de inmediato al mercado.

Los servcioos SaaS más utilizado en este momento son las aplicaciones de Administración de Relaciones con el Cliente, CRM, las cuales permiten automatizar la gestión de ventas y las de servicio al cliente.
 
Los programas de CRM en demanda son actualmente liderados por SalesForce y Oracle-Siebel, NetSuite, y RightNow.

 

¿Qué implicaciones tiene el modelo SaaS?

  • Desaparece el concepto de licencia, se pasa a hablar de pago por uso. De manera que los clientes se “suscriben” al servicio aportado para poder utilizar las aplicaciones ofrecidas en modalidad SaaS.
  • El software no se distribuye in-house, sino a través de la red.
  • La aplicación está hosteada, de manera que da servicio a muchos clientes.
  • El hecho de que la aplicación esté hosteada implica que no se abre de una infraestructura privada, sino de una infraestructura pública que permite que muchas empresas puedan suscribirse al servicio.
  • Es un modelo descentralizado de uso de aplicacione software.
  • Permite una escalabilidad sin límites.

Hasta aquí todo parece más o menos claro, pero seguro que alguno se preguntará: ¿y SaaS no es lo que ya teníamos con el modelo ASP?La respuesta es que no, ya que:

  • ASP sigue un modelo de licencias frente a SaaS dónde se paga por uso.
  • ASP es un modelo pensado para ofrecer aplicaciones a unos pocos usuarios. Con SaaS, el servicio se ofrece a tantos usuarios como suscriptores.
  • ASP utiliza normalmente una infraestructura privada frente a SaaS que utiliza una infraestructura pública.

Para resumir, en un modelo SaaS:

  • El foco es el servicio frente a hablar de tecnología, aplicaciones, etc.
  • Los clientes pasan a ser virtuales.
  • Hablamos de plataformas de N clientes.
  • El cliente sale claramente beneficiado del modelo:
    • Menor coste e inversión inicial.
    • Menor riesgo.
    • Alta escalabilidad asegurada.
    • El cliente se centra en el negocio.
    • Aumenta la seguridad.
    • La respuesta ante los cambios es muy rápida.
Publicado en Uncategorized | Deja un comentario

El Patrón MVC (Modelo Vista Controlador)

El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos (Modelo, Vista y Controlador). El Patrón MVC se ve frecuentemente en aplicaciones Web, donde la Vista es la página HTML y el código que provee de datos dinámicos a la página; el Modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio; el Controlador es el responsable de recibir los eventos de entrada desde la Vista.

Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc.

Veamos cada componente:

Modelo

Es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comprar un número de unidades negativo, o calculando los totales e impuestos del carrito de compra. Esto quiere decir que aquí se operan los datos y las reglas de negocio asociadas al sistema,
incluyendo el análisis sintáctico y el procesamiento de los datos de entrada y
de los datos de salida.

El Modelo es el responsable de:

  • Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
  • Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: “Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor”.
  • Lleva un registro de las vistas y controladores del sistema.
  • Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero batch que actualiza los datos, un temporizador que desencadena una inserción, etc.). Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es la navegación web, que responde a las entradas del usuario, pero no detecta los cambios en datos del servidor.

Vista

Este presenta el Modelo, usualmente la interfaz de usuario. La vista es la capa de la aplicación que ve el usuario en un formato adecuado para interactuar, en otras palabras, es nuestra interfase grafica.

Las vistas son responsables de:

  • Recibir datos del modelo y los muestra al usuario.
  • Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
  • Pueden dar el servicio de “Actualización()”, para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

Controlador

El Controlador es la capa que controla todo lo que puede realizar nuestra aplicación. Responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Está compuesto por acciones que se representan con funciones en una clase. Por ejemplo, yo tengo mi controlador llamado “Clientes”, y este controlador puede realizar las acciones “Crear”,”Editar”,”Listar” entre otras.

El controlador es responsable de:

  • Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
  • Contiene reglas de gestión de eventos, del tipo “SI Evento Z, entonces Acción W”. Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método “Actualizar()”. Una petición al modelo puede ser “Obtener_tiempo_de_entrega( nueva_orden_de_venta )”.

A continuación, el diagrama de secuencia del Patrón Vista Controlador:

  1. El usuario introduce el evento.
  2. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista).
  3. El modelo (si es necesario) llama a la vista para su actualización.
  4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
  5. El Controlador recibe el control.

Ventajas y Desventajas

La popularidad de este diseño se debe mas que todo a que es mucho mas fácil organizar aplicaciones grandes.

Las ventajas

  • Clara separación entre interfaz, lógica de negocio y de presentación, que además provoca parte de las ventajas siguientes.
  • Sencillez para crear distintas representaciones de los mismos datos.
  • Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD).
  • Reutilización de los componentes.
  • Simplicidad en el mantenimiento de los sistemas.
  • Facilidad para desarrollar prototipos rápidos.
  • Los desarrollos suelen ser más escalables.

Las desventajas:

  • Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC.
  • La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de modelos más simples como Webforms.
  • La distribución de componentes obliga a crear y mantener un mayor número de ficheros.
Fuentes: http://prestashop5estrellas.wordpress.com
Publicado en Uncategorized | Etiquetado , , , | Deja un comentario

Diagramas: Componentes y Despliegue

Diagrama de componentes

Representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidasmódulosejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinamica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Diagrama de Despliegue

Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un clúster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

  • Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.
  • Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.
  • Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

Fuentes: http://es.wikipedia.org
Publicado en Uncategorized | Deja un comentario

Estilo arquitectónico

En el texto fundacional de la AS, Perry y Wolf establecen el razonamiento sobre estilos de arquitectura como uno de los aspectos fundamentales de la disciplina. Un estilo es un concepto descriptivo que define una forma de articulación u organización arquitectónica. El conjunto de los estilos cataloga las formas básicas posibles de estructuras de software, mientras que las formas complejas se articulan mediante composición de los estilos fundamentales.
Sucintamente descritos, los estilos conjugan elementos (o “componentes”), conectores, configuraciones y restricciones. Al estipular los conectores como elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se sitúa en un orden de discurso y de método que el modelado orientado a objetos en general y UML en  particular no cubren satisfactoriamente. La descripción de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje de descripción arquitectónica o en lenguajes formales de especificación.

Conviene caracterizar el escenario que ha motivado la aparición del concepto de estilo, antes siquiera de intentar definirlo. Desde los inicios de la arquitectura de software, se observó que en la práctica del diseño y la implementación ciertas regularidades de configuración aparecían una y otra vez como respuesta a similares demandas. El número de esas formas no parecía ser muy grande. Muy pronto se las llamó estilos, por analogía con el uso del término en arquitectura de edificios. Un estilo describe entonces una clase de arquitectura, o piezas identificables de las arquitecturas empíricamente dadas. Esas piezas se encuentran repetidamente en la práctica, trasuntando la existencia de decisiones estructurales coherentes. 

Igual que los patrones de arquitectura y diseño, todos los estilos tienen un nombre:  cliente-servidor, modelo-vista-controlador, tubería-filtros, arquitectura en capas…

Con la intención de hacer una comparación clara entre estilo arquitectónico y
patrón arquitectónico, la tabla 11 presenta las diferencias entre estos conceptos,
construida a partir del planteamiento de Buschmann et al. (1996).

 

       

La figura 1.1 presenta la relación de abstracción existente entre los conceptos de estilo arquitectónico, patrón arquitectónico y patrón de diseño. En ella se representa el planteamiento de Buschmann et al. (1996), que propone el desarrollo de arquitecturas de software como un sistema de patrones, y distintos niveles de abstracción.

Fuentes: 

  • Introducción a la Arquitectura de Software (Carlos Billy Reynoso)
  • Estilos y Patrones en la Estrategia de Arquitectura de Microsoft (Carlos Billy Reynoso)
Publicado en Uncategorized | Deja un comentario

Bajo acoplamiento y Alta cohesión

 

Bajo acoplamiento

El bajo acoplamiento entre las unidades de software es el estado ideal que siempre se intenta obtener para lograr una buena programación o un buen diseño. Cuanto menos dependiente sean las partes que constituyen un sistema informático, mejor será el resultado. Sin embargo, es imposible un desacoplamiento total de las unidades.

Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases.

 

Alta Cohesión

La cohesión  “la medida de la cantidad de una entidad (o componente de clase) que apoya un propósito singular dentro de un sistema”. (Knoernschild página 174). 

la alta o baja cohesión se refiere a que tan relacionados están los componentes de un objeto. Es decir cuando en una clase, métodos y atributos tengan sentido que estén juntos.

Bajo acoplamiento y Alta cohesión

Los conceptos de cohesión y acoplamiento no están íntimamente relacionados, sin embargo se recomienda tener un mayor grado de cohesión con un menor grado de acoplamiento. De esta forma se tiene menor dependencia y se especifican los propósitos de cada objeto en el sistema.

 

 

Publicado en Uncategorized | Etiquetado , , , | Deja un comentario