Arquitectura del Software

Oscar Len Vargas Alzate

http://www.uml.org/

Lenguaje Unificado de Modelado (UML, por sus siglas en ingls,

Unified Modeling Language) es el lenguaje de modelado de sistemas
de software ms conocido y utilizado en la actualidad; an cuando
todava no es un estndar oficial, est respaldado por el OMG
(Object Management Group).
UML es un lenguaje para hacer modelos y es independiente de los
mtodos de anlisis y diseo.
Permite no solo el manejo de la estructura de la aplicacin, el
comportamiento y la arquitectura, sino tambin de procesos de
negocio y estructura de datos nica, as como unificar cada paso del
desarrollo y la integracin de modelado de negocio, a travs del
modelado de arquitectura y aplicacin, para el desarrollo, el
despliegue, el mantenimiento , y la evolucin.

Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema

de software. UML ofrece un estndar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos de negocios y
funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programacin, esquemas de bases de datos y componentes de software
reutilizables.
Los principales beneficios de UML son:
* Mejores tiempos totales de desarrollo (de 50 % o ms).
* Modelar sistemas utilizando conceptos orientados a objetos.
* Establecer conceptos y artefactos ejecutables.
* Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica.
* Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas.
* Mejor soporte a la planeacin y al control de proyectos.
* Alta reutilizacin y minimizacin de costos.

Es muy complejo capturar la arquitectura software en un slo modelo (o

diagrama). Para manejar esta complejidad se representan diferentes
aspectos y caractersticas de la arquitectura en mltiples vistas. Una vista es
una presentacin de un modelo, la cual es una descripcin completa de un
sistema desde una particular perspectiva.

El modelo ms aceptado a la hora de establecer las vistas necesarias para

describir una arquitectura software es el modelo 4+1 (Kruchten, 1995), el
cual define 4 vistas principales:
Vista Lgica: modelo de objetos, clases, entidad relacin, entre otros.
Vista de Proceso: modelo de concurrencia y sincronizacin.
Vista de Desarrollo: organizacin esttica del software en su entorno de
desarrollo (libreras, componentes, entre otros).
Vista Fsica: modelo de correspondencia software hardware.

Requerimientos Funcionales
(Que debe hacer el Sistema)

Describen la interaccin entre el sistema y su ambiente

independientemente de su Implementacin.

El ambiente incluye al usuario y cualquier otro sistema externo

que interacta con el sistema.
Deben estar redactados de tal forma que sean comprensibles
para usuarios sin conocimientos tcnicos avanzados.
Ejemplo:
RF1: Se podr Insertar, Consultar, Modificar y borrar informacin de
las tablas maestras. (El borrado se podr realizar si la integridad
referencial lo permite).

Requerimientos no funcionales
(Cmo debe ser el Sistema)

Describen aspectos del sistema que son visibles por el usuario que no incluyen
una relacin directa con el comportamiento funcional del sistema. Han de
especificarse cuantitativamente, siempre que sea posible
(para que se pueda verificar su cumplimiento).
Definen propiedades emergentes del sistema, tales como el tiempo de
respuesta, las necesidades de Desempeo, almacenamiento, flexibilidad,
fiabilidad, seguridad, control de acceso, portabilidad, modularidad, eficiencia,
parametrizacin, escalabilidad, disponibilidad, estabilidad, operatividad,
mantenibilidad.

Ejemplo:
RNF1: Los tiempos de respuesta relacionados con formularios de manejo de
informacin adicin, modificacin, eliminacin, consulta de registros,
autenticacin y emisin de avisos y confirmaciones por parte del usuario, en
forma general, no debe ser superior a 2.5 segundos, los informes y consultas
que presenten una complejidad mediana no deber exceder el tiempo de 4
segundos.

Reglas del negocio

Albergan todas las normas y procedimientos de la empresa y pueden
integrarse con los procesos de manera directa sin perder por ello su
independencia.
Las reglas de negocio expresan una poltica de negocio mediante un
vocabulario formal y una serie de sentencias si-entonces. Describen,
limitan o controlan un determinado aspecto del negocio.

Pueden ser requisitos funcionales, restringir los existentes o definir

clculos particulares. Si las reglas del negocio no se satisfacen, el
sistema puede no trabajar de forma satisfactoria.

Ejemplo:
RN1: Un cliente al que facturamos ms de US$ 10.000 al ao es un
cliente de tipo "A", a los clientes de tipo "A" les aplicamos un
descuento del 10% en pedidos superiores a US$1.000.

REQUERIMIENTOS FUNCIONALES
- Registrar propuesta.
- Evaluar propuesta.
- Inscribir proyecto
- Generar Listado de propuestas aprobadas,
rechazadas, liberadas y proyectos.