Arquitectura de SW - BOOK

ARQUITECTURA
DE
SOFTWARE
Desarrollo de Aplicaciones
Informticas
Ing. Patricio Michael Paccha A._
Ingeniero En Sistemas Informticos Y Computacin_

Diplomado Superior De Cuarto Nivel En Gerencia Estratgica de Mercadeo_
UNIVERSIDAD TECNOLGICA
SAN ANTONIO DE MACHALA
ESCUELA DE INFORMTICA
MODALIDAD SEMIPRESENCIAL
CARRERA DE SISTEMAS INFORMATICOS

SEXTO SEMESTRE
PBX:
(593) 072 961 200 Ext.
FAX:
(593) 072 961 200 Ext.
E-Mail:
pat_mic@hotmail.com
Ingeniero En Sistemas Informticos Y Computacin.

Msn:
Diplomado Superior De Cuarto Nivel En Gerencia Estratgica De
Skype
Mercadeo
Magister en ingeniera del software (egresado)
Docente Investigador de la UTSAM EI
pat_mic@hotmail.com
Ing. Patricio Michael Paccha Angamarca.
pat_mic@hotmail.com
Arquitectura de Software
MODULO GUA
Arquitectura del software
Al formar parte de Microsoft Faculty Connection, en calidad de profesor comparto las novedades
tecnolgicas, noticias, herramientas, descargar currcula especializada as como recibir software gratuito de
Microsoft y otorgar los mismo con el propsito educativo e investigativo; de tal forma que, el compendio de
contenidos de la presente forman parte de libros y documentos con Copyleft y estn organizados segn
artculos de la nube (Autor: Carlos Billy Reynoso - UNIVERSIDAD DE BUENOS AIRES) los cuales son ampliados
y se han implementado nuevos temas, talleres y actividades practicas segn la planificacin que de
contenidos de la Escuela de Informtica, que permita al estudiante lograr las destrezas que se necesitan
como asignatura OPTATIVA, conforme las planificaciones institucionales de la UTSAM.
Introduccin
A diferencia de un programador, el Arquitecto de Software debe dominar la mayor cantidad de tecnologas
de software y prcticas de diseo, para as poder tomar decisiones adecuadas para garantizar el mejor
desempeo, reuso, robustez, portabilidad, flexibilidad, escalabilidad y mantenibilidad de las aplicaciones.
Estas decisiones sobre la estructura y dinmica de la aplicacin son plasmadas en una notacin formal
estandarizada como lo es UML; sobre todo si se utilizan las nuevas tecnologas, en especial con los lenguajes
orientados a objetos.
El arquitecto de software es el lder tcnico del equipo, el rol natural al que debe aspirar un programador
experimentado que desea tomar decisiones tcnicas relevantes en el desarrollo de un sistema. Es el
principal tomador de decisiones respecto a la manera en que ser construda la aplicacin por los
programadores del equipo. El lder de proyecto se apoya totalmente en este rol para alcanzar el xito del
proyecto optimizando el uso de la tecnologa para desarrollar la solucin correcta que proporcionar valor
real a sus usuarios y al negocio al que le dar soporte.
Hay dos formas de convertirse en arquitecto: aprendiendo a definir las soluciones con base en la propia
experiencia (el camino largo), o reutilizando el conocimiento de los expertos a nivel mundial plasmado en
patrones de arquitecura y diseo (el camino corto). En este curso, los conocedores de la tecnologa
orientada a objetos y UML aprenden el camino corto mediante el aprendizaje de patrones explicados de una
forma interesante y amena.
Aprendern adems a modelar su aplicacin utilizando Enterprise Architect, herramienta de modelado de
UML que les permite la aplicacin automtica de los patrones de diseo ms importantes.
Objetivo:
Desarrollar arquitectos de software que sean capaces de establecer los lineamientos formales de
construccin para el desarrollo de aplicaciones robustas. El arquitecto de software es el lder tcnico del
equipo, el rol natural al que debe aspirar un programador experimentado que desea tomar decisiones
tcnicas relevantes en el desarrollo de un sistema. Es el principal tomador de decisiones respecto a la
manera en que ser construda la aplicacin por los programadores del equipo. El lder de proyecto se apoya
totalmente en este rol para alcanzar el xito del proyecto optimizando el uso de la tecnologa para
desarrollar la solucin correcta que proporcionar valor real a sus usuarios y al negocio al que le dar
soporte.
ARQUITECTURA DEL SOFTWARE
UNIDAD I
ARQUITECTURA DE SOFTWARE
Definicin
En los inicios de la informtica, la programacin se consideraba un arte y se desarrollaba como tal, debido a
la dificultad que entraaba para la mayora de las personas, pero con el tiempo se han ido descubriendo y
desarrollando formas y guas generales, con base a las cuales se puedan resolver los problemas. A estas, se
les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o
construccin, estas indican la estructura, funcionamiento e interaccin entre las partes del software. En el
libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es
un nivel de diseo que hace foco en aspectos "ms all de los algoritmos y estructuras de datos de la
1
computacin; el diseo y especificacin de la estructura global del sistema es un nuevo tipo de problema".
Arquitectura
Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos
son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin
otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interaccin con otros sistemas de
informacin. Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para
implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con
ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por
ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en
tiempo real.
La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea
de computacin, sus interfaces y la comunicacin entre ellos. Toda arquitectura debe ser implementable en
una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada
tarea.
La arquitectura de software, tiene que ver con el diseo y la implementacin de estructuras de software de
alto nivel. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos de forma adecuada
para satisfacer la mayor funcionalidad y requerimientos de desempeo de un sistema, as como
requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.
Kruchten, Philippe
Como lo ha dicho Jan Bosch, un arquitecto prctico: Existe una considerable diferencia entre la percepcin
acadmica de la ARQUITECTURA DE SOFTWARE y la prctica industrial. Es interesante advertir que a veces
los problema que la industria identifica como los ms importantes y difciles, no se identifican o se
consideran no-problemas en la academia [Bos00].
http://es.wikipedia.org/wiki/Arquitectura_de_software
Introduccin
Por otra parte, en la estrategia de Microsoft se ha desarrollado un marco de referencia global y genrico
para el desarrollo de soluciones, Microsoft Solutions Framework, MSF y bajo el paraguas (explcito) de
arquitectura, se encuentra adems un buen nmero de aportes en materia de patrones de diseo y
lineamientos para implementarlos en el Framework .NET, primordialmente en modelos orientados a
servicios. En ese contexto, delimitado por un marco necesariamente general (ms afn a IT Management que
a arquitectura o ingeniera) y por una prctica sumamente concreta, las cuestiones tericas y las
metodologas especficas basadas en arquitectura han quedado sin elaborar.
Definiciones
Existen grandes compilaciones de definiciones alternativas o contrapuestas, como la coleccin que se
encuentra en el SEI (http://www.sei.cmu.edu/architecture/definitions.html), a la que cada quien puede
agregar la suya.
En general, las definiciones entremezclan despreocupadamente (1) el trabajo dinmico de estipulacin de la

arquitectura dentro del proceso de ingeniera o el diseo (su lugar en el ciclo de vida), (2) la configuracin o
topologa esttica de sistemas de software contemplada desde un elevado nivel de abstraccin y (3) la
caracterizacin de la disciplina que se ocupa de uno de esos dos asuntos, o de ambos.
Una definicin reconocida es la de Clements [Cle96a]: La Arquitectura de software es, a grandes rasgos, una
vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes
segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se
coordinan para alcanzar la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el
ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las
abstracciones.
En una definicin semejante, hay que aclararlo, la idea de componente no es la de la correspondiente

tecnologa de desarrollo (COM, CORBA Component Model, EJB), sino la de elemento propio de un estilo. Un
componente es una cosa, una entidad, a la que los arquitectos prefieren llamar componente antes que
objeto, por razones que se vern en otros documentos de esta serie pero que ya es obvio imaginar cules
han de ser.
En una definicin tal vez demasiado amplia, David Garlan [Gar00] establece que la Arquitectura de software
constituye un puente entre el requerimiento y el cdigo, ocupando el lugar que en los grficos antiguos se
reservaba para el diseo. La definicin oficial de Arquitectura de software se ha acordado que sea la que
brinda el documento de IEEE Std 1471-2000, adoptada tambin por Microsoft, que reza as:
Aunque las literaturas de ambos campos rara vez convergen, entendemos que es productivo contrastar esa
definicin con la de ingeniera de software, conforme al estndar IEEE 610.12.1990:
La aplicacin de una estrategia sistemtica, disciplinada y cuantificable al desarrollo, aplicacin y
mantenimiento del software; esto es, la aplicacin de la ingeniera al software.
La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus

componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin.
Obsrvese entonces que la nocin clave de la arquitectura es la organizacin (un concepto cualitativo o
estructural), mientras que la ingeniera tiene fundamentalmente que ver con una sistematicidad susceptible
de cuantificarse.
Historia de la Arquitectura de Software

En los aos 1960 ya se acariciaba el concepto de arquitectura de software en los crculos de investigacin
(por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los aos 1990 tras reconocerse la
denominada crisis del software y como tema de inters de la incipiente disciplina de la ingeniera del
software.
Cada vez que se narra la historia de la arquitectura de software o de la ingeniera de software, se reconoce
que en un principio, hacia 1968, Edsger Dijkstra, propuso que se estableciera una estructuracin correcta de
los sistemas de software antes de lanzarse a programar, escribiendo cdigo de cualquier manera (Dijkstra
Enero de 1983). Dijkstra, quien sostena que las ciencias de la computacin eran una rama aplicada de las
matemticas y sugera seguir pasos formales para descomponer problemas mayores, fue uno de los
introductores de la nocin de sistemas operativos organizados en capas que se comunican slo con las capas
adyacentes y que se superponen como capas de cebolla. Invent o ayud a precisar adems docenas de
conceptos: el algoritmo de camino ms corto, los stacks, los vectores, los semforos, los abrazos mortales.
De sus ensayos arranca la tradicin de hacer referencia a niveles de abstraccin que ha sido tan comn en
la arquitectura subsiguiente. Aunque Dijkstra no utiliza el trmino arquitectura para describir el diseo
conceptual del software, sus conceptos sientan las bases para lo que luego expresaran Niklaus Wirth (Wirth
Abril de 1971) como stepwise refinement y DeRemer y Kron (Kron 1976) como programming-in-the large o
programacin en grande, ideas que poco a poco iran decantando entre los ingenieros primero y los
arquitectos despus.
Una novedad importante en la dcada de 1970 fue el advenimiento del diseo estructurado y de los
primeros modelos explcitos de desarrollo de software. Estos modelos comenzaron a basarse en una
estrategia ms orgnica, evolutiva, cclica, dejando atrs las metforas del desarrollo en cascada que se
inspiraban ms bien en la lnea de montaje de la ingeniera del hardware y la manufactura. Poco a poco el
diseo se fue independizando de la implementacin, y se forjaron herramientas, tcnicas y lenguajes de
modelado especficos.
En la misma poca, otro precursor importante, David Parnas, demostr que los criterios seleccionados en la
descomposicin de un sistema impactan en la estructura de los programas y propuso diversos principios de
diseo que deban seguirse a fin de obtener una estructura adecuada. Parnas desarroll temas tales como
mdulos con ocultamiento de informacin, estructuras de software y familias de programas (Parnas
Diciembre de 1972), enfatizando siempre la bsqueda de calidad del software.
En la conferencia de la NATO de 1969, un ao despus de la sesin en que se fundara la ingeniera de

software, P. I. Sharp formul estas sorprendentes apreciaciones comentando las ideas de Dijkstra:
Pienso que tenemos algo, aparte de la ingeniera de software, algo de lo que hemos hablado muy poco
pero que deberamos poner sobre el tapete y concentrar la atencin en ello, es la cuestin de la arquitectura
de software. La arquitectura es diferente de la ingeniera, ejemplo de lo que quiero decir, echemos una
mirada a OS/360. Partes de OS, si vamos al detalle, han utilizado tcnicas que hemos acordado constituyen
buena prctica de programacin. La razn de que OS sea un amontonamiento amorfo de programas es que
no tuvo arquitecto. Su diseo fue delegado a series de grupos de ingenieros, cada uno de los cuales invent
su propia arquitectura. Y cuando esos pedazos se clavaron todos juntos no produjeron una tersa y bella
pieza de software (Sharp 27 al 31 de Octubre de 1969).
En 1972, Parnas public un ensayo en el que discuta la forma en que la modularidad en el diseo de
sistemas poda mejorar la flexibilidad y el control conceptual del sistema, acortando los tiempos de
desarrollo. Introdujo entonces el concepto de ocultamiento de informacin (information hiding), uno de los
principios de diseo fundamentales en diseo de software an en la actualidad. En la segunda de las
descomposiciones que propone Parnas comienza a utilizarse el ocultamiento de informacin como criterio.
Cada mdulo deviene entonces una caja negra para los dems mdulos del sistema, los cuales podrn
acceder a aqul a travs de interfaces bien definidas, en gran medida invariables.
En 1975, Brooks, diseador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de
arquitectura del sistema para designar la especificacin completa y detallada de la interfaz de usuario y
consideraba que el arquitecto es un agente del usuario (Jr. 1975). Tambin distingua entre arquitectura e
implementacin; mientras aquella deca qu hacer, la implementacin se ocupa de cmo.
Como escriben Clements y Northrop en esta poca (Northrop Febrero de 1996) en todo el desenvolvimiento
ulterior de la disciplina permanecera en primer plano esta misma idea: la estructura es primordial (structure
matters), y la eleccin de la estructura correcta ha de ser crtica para el xito del desarrollo de una solucin.
La eleccin de la estructura correcta sintetiza, como ninguna otra expresin, el programa y la razn de ser
de la AS.En la dcada de 1980, fue surgiendo nuevo paradigma, el de la programacin orientada a objetos.
Paralelamente, hacia fines de la dcada de 1980 y comienzos de la siguiente, la expresin arquitectura de
software comienza a aparecer nuevamente en la literatura para hacer referencia a la configuracin
morfolgica de una aplicacin.
El primer estudio en que aparece la expresin arquitectura de software en el sentido en que hoy lo
conocemos es sin duda el de Perry y Wolf; ocurri en 1992, aunque el trabajo se fue gestando desde 1989.
En l, los autores proponen concebir la arquitectura del software por analoga con la arquitectura de
edificios, una analoga de la que luego algunos abusaron (WWISA 1999), otros encontraron til y para unos
pocos ha devenido inaceptable (Reed 2001).
La dcada de 1990, fue la dcada de la arquitectura de software, dando cumplimiento a las profecas de
Perry y Wolf, fue sin duda la dcada de consolidacin y diseminacin de la arquitectura del software en una
escala sin precedentes. Las contribuciones ms importantes surgieron en torno del instituto de ingeniera de
la informacin de la Universidad Carnegie Mellon (CMU SEI). En la misma dcada, demasiado prdiga en
acontecimientos, surge tambin la programacin basada en componentes, que en su momento de mayor
impacto impuls a algunos arquitectos mayores, como Paul Clements (Clements Enero de 1996.), a afirmar
que la arquitectura del software promova un modelo que deba ser ms de integracin de componentes
pre-programados que de programacin.
En el transcurso de los aos, la complejidad y tamao de los sistemas software se fue incrementado de
manera espectacular. La capacidad para responder rpidamente ante los cambios y optimizar los procesos
de negocio es un factor clave para la competitividad y el crecimiento de las organizaciones.
Cada vez ms las organizaciones dependen de su infraestructura de IT para alcanzar sus objetivos, pero en
un entorno competitivo como el actual, aprovechar las oportunidades de negocio exige moverse con
rapidez. Sin embargo, con frecuencia las Tecnologas de Informacin no permiten estas respuestas rpidas ni
disponen de la flexibilidad necesaria para competir de forma efectiva. Un alto porcentaje de las ineficiencias
organizativas tienen un mismo origen: el predominio de procesos manuales con un nivel de error elevado,
Evolucin de la Arquitectura de Software.
sistemas ineficaces para compartir la informacin en el seno de la organizacin; las ineficiencias propias del
servicio a clientes, etc.
En la raz de todas estas deficiencias est la informacin. No como un problema de escasez de informacin
sino de la imposibilidad de presentar la informacin de forma sencilla y til a los usuarios y directivos de una
manera coherente y sistemtica. En ltima instancia, esto se debe a que las aplicaciones no compartan
informaciones entre ellas y, por consiguiente, no pueden aportar una visin general de los procesos de
negocio cuando stos abarcan varias reas funcionales.
Lo que se necesita es una herramienta basada en estndares para integrar sistemas y aplicaciones
heterogneos sobre una serie de plataformas y protocolos de comunicacin heterogneos, as como una
metodologa bien establecida para lograr el nivel ptimo de integracin, de manera que la infraestructura
subyacente facilite los cambios posteriores que puedan surgir como respuesta a la evolucin en las
necesidades de la empresa.
As surgi La Arquitectura Orientada a Servicios (SOA, Service Oriented Architecture) fue descrita por
primera vez por Gartner en 1996.
W3C: Conjunto de componentes que pueden ser invocados, cuyas descripciones de interfaces se
pueden publicar y descubrir
CBDI rechaza esa definicin: Los componentes pueden no ser conjuntos.
La definicin slo considera los componentes y no la prctica o el arte de construir la arquitectura
CBDI: Estilo resultante de polticas, prcticas y frameworks que permiten que la funcionalidad de
una aplicacin se pueda proveer y consumir como conjuntos de servicios, con una granularidad
relevante para el consumidor. Los servicios pueden invocarse, publicarse y descubrirse y estn
abstrados de su implementacin utilizando una sola forma estndar de interface.
IBM: Modelo de componente que interrelaciona las diferentes unidades funcionales de las
aplicaciones, denominadas servicios, a travs de interfaces y contratos bien definidos entre esos
servicios. La interfaz se define de forma neutral, y debera ser independiente de la plataforma
hardware, del sistema operativo y del lenguaje de programacin utilizado. Esto permite a los
servicios, construidos sobre sistemas heterogneos, interactuar entre ellos de una manera
uniforme u universal.
BEA: Una forma de modulizar los sistemas y aplicaciones en componentes de negocio que pueden
combinarse, con interfaces bien definidas para responder a las necesidades de la empresa.
Wikipedia: Es un concepto de arquitectura de software que define la utilizacin de servicios para
dar soporte a los requerimientos de software del usuario, proporciona una metodologa y un marco
de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de
integracin y consolidacin.
Tomando como partida todas estas definiciones y sus puntos en comunes, SOA para mi no es mas que: una
filosofa de diseo que permite un mejor alineamiento de las Tecnologas de Informacin (IT) con las
necesidades de negocio, dndole la posibilidad a los clientes de responder de forma ms rpida y adaptarse
adecuadamente a las presiones del mercado, establece un marco de diseo para la integracin de
aplicaciones independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales
se ofrecen como servicio .
10
SOA en la Industria
La recompensa potencial de SOA es enorme para las empresas que entiendan esta evolucin y se muevan
hacia estas arquitecturas. La tecnologa de computacin distribuida promete ser lo suficientemente flexible
y elegante para responder a las necesidades de negocios y proporcionar la agilidad de negocios que las
compaas han anhelado tanto tiempo, pero siempre ha estado fuera de alcance. (Bloomberg 2004).
La mejor solucin a la integracin de negocios.... SOA ha surgido como la mejor manera de afrontar el
desafo de hacer ms con menos recursos. Promete hacer la re-utilizacin y la integracin mucho ms
fciles, ayudando a reducir el tiempo de desarrollo y aumentando la agilidad organizacional. No
sorprendentemente, el 80% de las organizaciones de IT estn implementando aplicaciones usando SOA con
web services subyacentes. SOA proporciona mayor flexibilidad para afrontar los cambios tanto en el
ambiente de negocios como en la infraestructura tecnolgica. (Luis Felipe Cabrera Setiembre 2004)
SOA es la prxima ola de desarrollo de aplicaciones. Es ms rpida, mejor y ms barata.

Comprender el rol y el significado de SOA, ms all del hype simplista, es imperativo para
cualquier arquitecto de software empresarial. ... Hacia 2008, SOA y Web Services sern
implementados juntos en ms del 75% de los proyectos que utilicen SOA y Web Services
(probabilidad 0.7).
Hacia 2008, ms del 75% de los paquetes de aplicacin de ese entonces sern nativamente SOA o
expondrn interfaces SOA a travs de una capa de envoltura de interfaces (probabilidad 0.8).
Hacia 2008, SOA ser la prctica prevalente de ingeniera de software, acabando con los 40 aos
de dominacin de las arquitecturas monolticas (probabilidad 0.7).
Giga recomienda a los arquitectos considerar SOA como la prioridad nmero uno en sus esfuerzos
de planeamiento arquitectnico. (IT 2003)
Programacin Estructurada Objetos Componentes Servicios, Granularidad Muy Fina Fina Intermedia Gruesa
Reusabilidad Baja Baja Intermedia Alta Acoplamiento Fuerte Fuerte Dbil Muy Dbil
Dependencias Tiempo de Compilacin Tiempo deCompilacin Tiempo de Compilacin Run-Time
mbito de Comunicacin Intra -Aplicacin Intra-Aplicacin Inter-Aplicacin Inter-Empresas.
Mejorar la toma de decisiones. Al integrar el acceso a los servicios e informacin de negocio dentro
de un conjunto de aplicaciones dinmicas compuestas, los directivos disponen de ms informacin
y de mejor calidad (ms exacta y actualizada), lo que posibilita a las organizaciones poder
reaccionar de manera ms gil y rpida cuando surgen problemas o cambios.
Mejorar la productividad de los empleados. Un acceso ptimo a los sistemas, la informacin y la

posibilidad de mejorar los procesos permiten a las empresas aumentar la productividad individual
de los empleados.
Potenciar las relaciones con clientes y proveedores. Las ventajas de SOA trascienden las fronteras
de la organizacin, los procesos de fusin y compra de empresas se hacen ms rentables al ser ms
sencilla la integracin de sistemas y aplicaciones diferentes. Con SOA se puede conseguir mejorar la
capacidad de respuesta a los clientes, habilitando por ejemplo portales unificados de servicios.
Desde el punto de vista de los departamentos de IT, la orientacin a servicios supone un marco conceptual
mediante el cual se puede simplificar la creacin y mantenimiento de sistemas, aplicaciones integradas, y
Beneficios de SOA. Los beneficios de SOA para una organizacin se plasman a dos niveles distintos: al del
usuario corporativo y a nivel de la organizacin de IT. Desde el punto de vista de la empresa, SOA permite el
desarrollo de una nueva generacin de aplicaciones dinmicas que resuelven una gran cantidad de
problemas de alto nivel, fundamentales para el crecimiento y la competitividad. Las soluciones SOA
permiten entre otras cosas:
11
una frmula para alinear los recursos de IT con el modelo de negocio y las necesidades de cambio que le
afectan.
Aplicaciones ms productivas y flexibles. La estrategia de orientacin a servicios permite a IT

conseguir una mayor productividad de los recursos de IT existentes, como pueden ser las
aplicaciones y sistemas ya instalados e incluso los ms antiguos. La orientacin a servicios permite
adems el desarrollo de una nueva generacin de aplicaciones compuestas que ofrecen
capacidades avanzadas y multifuncionales para las organizaciones con independencia de las
plataformas y lenguajes de programacin que soportan los procesos.
Desarrollo de aplicaciones ms rpido y econmico. El diseo de servicios basado en estndares
facilita la creacin de un repositorio de servicios reutilizables que se pueden combinar en servicios
de mayor nivel y aplicaciones compuestas en respuesta a nuevas necesidades de la empresa. Con
ello se reduce el coste del desarrollo de soluciones y de los ciclos de prueba, se eliminan
redundancias y se consigue su puesta en valor en menos tiempo.
Aplicaciones ms seguras y manejables. Las soluciones orientadas a servicios proporcionan una
infraestructura comn (y una documentacin comn tambin) para desarrollar servicios seguros,
predecibles y gestionables. SOA facilita la posibilidad de aadir nuevos servicios y funcionalidades
para gestionar los procesos de negocio crticos. Se accede a los servicios y no a las aplicaciones,
adems puesto que se utilizan mecanismos de autenticacin y autorizacin robustos en todos los
servicios la estrategia de SOA permite dotarse de un nivel de seguridad superior.
Los elementos bsicos que conforman SOA son:
Consumidores.
Bus de Servicios.
Repositorio de Servicios.
Servidores.
En el siglo XXI, la arquitectura del software aparece dominada por estrategias orientadas a lneas de
productos y por establecer modalidades de anlisis, diseo, verificacin, refinamiento, recuperacin, diseo
basado en escenarios, estudios de casos y hasta justificacin econmica, redefiniendo todas las
metodologas ligadas al ciclo de vida en trminos arquitectnicos. Todo lo que se ha hecho en ingeniera
debe formularse de nuevo, integrando la arquitectura del software en el conjunto. La produccin de estas
nuevas metodologas ha sido masiva, y una vez ms tiene como epicentro el trabajo del Software
Engineering Institute en Carnegie Mellon. La aparicin de las metodologas basadas en arquitectura, junto
con la popularizacin de los mtodos giles en general y Extreme Programming en particular, han causado
un reordenamiento del campo de los mtodos, hasta entonces dominados por las estrategias de diseo de
peso pesado. Despus de la Arquitectura de Software y de las tcticas radicales, las metodologas nunca
volvern a ser las mismas.
La semblanza que se ha trazado no es ms que una visin selectiva de las etapas recorridas por la
Arquitectura de Software. Los lineamientos de ese proceso podran dibujarse de maneras distintas, ya sea
enfatizando los hallazgos formales, las intuiciones dominantes de cada perodo o las diferencias que median
entre la abstraccin cualitativa de la arquitectura y las cuantificaciones que han sido la norma en ingeniera
de software.
Uno de los acontecimientos arquitectnicos ms importantes del ao 2000 fue la hoy clebre tesis de Roy
Fielding que present el modelo REST, el cual establece definitivamente el tema de las tecnologas de
Internet y los modelos orientados a servicios y recursos en el centro de las preocupaciones de la disciplina
[Fie00]. En el mismo ao se publica la versin definitiva de la recomendacin IEEE Std 1471, que procura
homogeneizar y ordenar la nomenclatura de descripcin arquitectnica y homologa los estilos como un
modelo fundamental de representacin conceptual.
12
Funciones Principales de un Arquitecto de Software

Pienso que de alguna forma todos tenemos un poco Arquitectos de Software, desde este punto de vista he
recopilado estas funciones:
Arquitectura: Definicin de arquitectura de los sistemas, vista fsica, vista lgica, principios de
arquitectura, seguridad, etc.
Seleccin de Software: Pilas de aplicaciones, bases de datos, libreras, frameworks, estndares
tecnolgicos, etc.
Seleccin de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperacin, etc.
Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc.
Liderazgo: Liderazgo Tcnico, responsabilidad y autoridad, direccin de equipos, etc.
Coaching y Mentoring: Ayuda sobre problemas tcnicos, ayuda en la evolucin profesional, etc.
Metodologa de Proyectos: Estructura de Proyectos, Metodologas (Waterfall, Scrum, RUP, XP...).
Procesos de Desarrollo: Control de versiones de cdigo fuente, procesos de construccin,
integracin continua, automatizacin de pruebas y otros procesos y herramientas de desarrollo.
Prcticas y Estndares: Estndares de codificacin y libros blancos, seleccin de herramientas, etc.
Diseo, Desarrollo y Pruebas: Diagramas UML, codificacin, pruebas unitarias, etc.
Experiencia: Conocimiento sobre tecnologas y arquitecturas.
Estar al da en cuanto a tendencias tecnolgicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.
Dentro del proceso de desarrollo de software de un sistema uno de los temas importantes a tratar es la
arquitectura de software, es la parte de la ingeniera de software que se dedica al estudio, anlisis y
descripcin para formalizar el esquema global de un sistema, poniendo nfasis en el estudio de las
interacciones entre sus elementos bsicos, denominados componentes.
Un arquitecto de software debe tener la capacidad para responder rpidamente cambios y optimizar los
procesos de negocio que es un factor clave para la competitividad y el crecimiento de las organizaciones. La
Arquitectura Orientada a Servicios (SOA, Service Oriented Architecture) es una filosofa de diseo que
permite un mejor alineamiento de las Tecnologas de Informacin (IT) con las necesidades de negocio,
permitiendo a los usuarios de forma ms rpida adaptarse adecuadamente a las presiones del mercado.
Modelos o vistas
Cada paradigma de desarrollo exige diferente nmero y tipo de vistas o modelos para describir una
arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier
arquitectura:
La visin esttica: describe qu componentes tiene la arquitectura.

La visin funcional: describe qu hace cada componente.
La visin dinmica: describe cmo se comportan los componentes a lo largo del tiempo y como
interactan entre s.
Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de
estos aspectos se describe de una manera ms comprensible si se utilizan distintos modelos o vistas. Es
importante destacar que cada uno de ellos constituye una descripcin parcial de una misma arquitectura y
es deseable que exista cierto solapamiento entre ellos. Esto es as porque todas las vistas deben ser
coherentes entre s, evidente dado que describen la misma cosa.
13
Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El
ms obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los
diagramas de flujo de datos, etc. Estos lenguajes son apropiados nicamente para un modelo o vista.
Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado
de modelado) como lenguaje nico para todos los modelos o vistas. Sin embargo, un lenguaje generalista
corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de informacin (o
expresarlas de manera incomprensible).
Antes el nmero y variedad de definiciones existentes de Arquitectura de software, Mary Shaw y David
Garlan [SG95] proporcionaron una sistematizacin iluminadora, explicando las diferencias entre definiciones
en funcin de distintas clases de modelos. Destilando las definiciones y los puntos de vista implcitos o
explcitos, los autores clasifican los modelos de esta forma:
1) Modelos estructurales: Sostienen que la de Arquitectura de software est compuesta por componentes,
conexiones entre ellos y (usualmente) otros aspectos tales como configuracin, estilo, restricciones,
semntica, anlisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes. El
trabajo en esta rea est caracterizado por el desarrollo de lenguajes de descripcin arquitectnica (ADLs).
2) Modelos de framework: Son similares a la vista estructural, pero su nfasis primario radica en la
(usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su
composicin. Los modelos de framework a menudo se refieren a dominios o clases de problemas
especficos. El trabajo que ejemplifica esta variante incluye arquitecturas de software especficas de
dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes especficos, como
PRISM.
3) Modelos dinmicos: Enfatizan la cualidad conductual de los sistemas. Dinmico puede referirse a los
cambios en la configuracin del sistema, o a la dinmica involucrada en el progreso de la computacin, tales
como valores cambiantes de datos.
4) Modelos de proceso: Se concentran en la construccin de la arquitectura, y en los pasos o procesos
involucrados en esa construccin. En esta perspectiva, la arquitectura es el resultado de seguir un
argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programacin de
procesos para derivar arquitecturas.
5) Modelos funcionales: Una minora considera la arquitectura como un conjunto de componentes
funcionales, organizados en capas que proporcionan servicios hacia arriba. Es tal vez til pensar en esta
visin como un framework particular.
Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de
informacin. Lo habitual es adoptar una arquitectura conocida en funcin de sus ventajas e inconvenientes
para cada caso en concreto. As, las arquitecturas ms universales son:
Monoltica. Donde el software se estructura en grupos funcionales muy acoplados.

Cliente-servidor. Donde el software reparte su carga de cmputo en dos partes independientes
pero sin reparto claro de funciones.
Arquitecturas ms comunes
14
Arquitectura de tres niveles. Especializacin de la arquitectura cliente-servidor donde la carga se

divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentacin
(interfaz de usuario), otra para el clculo (donde se encuentra modelado el negocio) y otra para el
almacenamiento (persistencia). Una capa solamente tiene relacin con la siguiente.
Otras arquitecturas afines menos conocidas son:
En pipeline.
Entre pares.
En pizarra.
Orientada a servicios.
Dirigida por eventos.
Mquinas virtuales
Ninguna de estas vistas excluye a las otras, ni representa un conflicto fundamental sobre lo que es o debe
ser la Arquitectura de Software. Por el contrario, representan un espectro en la comunidad de investigacin
sobre distintos nfasis que pueden aplicarse a la arquitectura: sobre sus partes constituyentes, su totalidad,
la forma en que se comporta una vez construida, o el proceso de su construccin.
Tomadas en su conjunto, destacan ms bien un consenso. Independientemente de las discrepancias entre

las diversas definiciones, es comn entre todos los autores el concepto de la arquitectura como un punto de
vista que concierne a un alto nivel de abstraccin. Revisamos las diversas definiciones del concepto de
abstraccin en un apartado especfico ms adelante en este estudio.
Es casi seguro que la percepcin de la Arquitectura de Software que prevalece entre quienes no han tenido
contacto con ella, as como los estereotipos dominantes sobre su naturaleza, o los nombres que se
escogeran como sus personalidades ms importantes, difieren sustancialmente de lo que es el caso en el
interior de la especialidad. Este sera acaso un ejercicio digno de llevarse a cabo alguna vez.
15
Conceptos fundamentales
Ms all de que hoy existan numerosos conceptos en el plano detallado de las tcnicas y metodologas, la
Arquitectura de Software se articula alrededor de unos pocos conceptos y principios esenciales y unas pocas
herramientas caractersticas.
Estilos
En el texto fundacional de la Arquitectura de Software, 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 articulacin u organizacin arquitectnica. El conjunto de los estilos
cataloga las formas bsicas posibles de estructuras de software, mientras que las formas complejas se
articulan mediante composicin de los estilos fundamentales.
Sucintamente descriptos, los estilos conjugan elementos (o componentes, como se los llama aqu),
conectores, configuraciones y restricciones. Al estipular los conectores como elemento de juicio de primera
clase, el concepto de estilo, incidentalmente, se sita en un orden de discurso y de mtodo que el modelado
orientado a objetos en general y UML en particular no cubren satisfactoriamente. La descripcin de un estilo
se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje de
descripcin arquitectnica o en lenguajes formales de especificacin.
A diferencia de los patrones de diseos, que son centenares, los estilos se ordenan en seis o siete clases
fundamentales y unos veinte ejemplares, como mximo. Es digno de sealarse el empeo por subsumir
todas las formas existentes de aplicaciones en un conjunto de dimensiones tan modestas. Las arquitecturas
complejas o compuestas resultan del agregado o la composicin de estilos ms bsicos. Algunos estilos
tpicos son las arquitecturas basadas en flujo de datos, las peer-to-peer, las de invocacin implcita, las
jerrquicas, las centradas en datos o las de intrprete-mquina virtual.
Hemos tratado el tema de las definiciones, los catlogos de estilos, las propiedades de cada uno, el lugar de
los estilos en la Arquitectura de Software y su relacin con los patrones de diseo y con la estrategia
arquitectnica de Microsoft en un documento separado, en torno del cual se podrn discutir las cuestiones
relacionadas con ellos.
Los lenguajes de descripcin de arquitecturas, o ADLs, ocupan una parte importante del trabajo
arquitectnico desde la fundacin de la disciplina. Se trata de un conjunto de propuestas de variado nivel de
rigurosidad, casi todas ellas de extraccin acadmica, que fueron surgiendo desde comienzos de la dcada
de 1990 hasta la actualidad, ms o menos en contemporaneidad con el proyecto de unificacin de los
lenguajes de modelado bajo la forma de UML. Los ADL difiere sustancialmente de UML, que al menos en su
versin 1.x se estima inadecuado en su capacidad para expresar conectores en particular y en su modelo
semntico en general para las clases de descripcin y anlisis que se requieren. Los ADLs permiten modelar
una arquitectura mucho antes que se lleve a cabo la programacin de las aplicaciones que la componen,
analizar su adecuacin, determinar sus puntos crticos y eventualmente simular su comportamiento.
Los ADLs son bien conocidos en los estudios universitarios de arquitectura del software, pero muy pocos
arquitectos de industria parecen conocerlos y son menos an quienes los utilizan como instrumento en el
Lenguajes de descripcin arquitectnica
16
diseo arquitectnico de sus proyectos. Hay unos veinte ADLs de primera magnitud y tal vez unos cuarenta
o cincuenta propuestos en ponencias que no han resistido el paso del tiempo o que no han encontrado su
camino en el mercado. Se han analizado esos lenguajes descriptivos en un documento aparte, en el cual se
invita asimismo a su discusin.
Frameworks y Vistas
En esta seccin se examinarn primero las propuestas sobre organizacin de vistas desarrolladas en el
contexto de los frameworks ms influyentes. En segundo lugar, se analizar algo ms formalmente la
historia y el significado del concepto de vistas en s, ya que en la mayor parte de la literatura no acadmica
la significacin precisa del concepto y su funcin tcnica se suelen dar por sentadas o se definen a la ligera y
de formas cambiantes.
Existen unos cuantos organismos de estndares (ISO, CEN, IEEE, OMG) que han codificado diferentes
aspectos de la Arquitectura de Software, cuando no la Arquitectura de Software en su totalidad, con el
objetivo de homogeneizar la terminologa, los modelos y los procedimientos. Los emergentes del trabajo de
sus comits son especificaciones y recomendaciones de variada naturaleza, como RM-ODP, RUP, RDS, MDA,
MOF, MEMO, XMI o IEEE 1471-2000. Casi cualquier combinacin de tres o cuatro letras del alfabeto
corresponde al acrnimo de algn estndar a tener en cuenta. La Arquitectura de Software hace mencin
eventual de esas doctrinas y los acadmicos ocupan sillas preferenciales en los organismos, pero su
tratamiento exhaustivo en la literatura de investigacin decididamente no califica como uno de los grandes
temas prioritarios. Las recomendaciones de los marcos se tratan con sumo respeto pero tambin con alguna
reticencia, tal vez porque se estima que los organismos privilegiaran ms un acuerdo regido por una
necesidad de equidistancia que una adecuada fundamentacin formal, porque cualquier versin del
estndar que se mencione en un paper habr caducado cuando se lo publique, o por alguna otra razn que
dejamos abierta para que se discuta.
Hay una excepcin, sin embargo. Tanto los marcos arquitectnicos como las metodologas de modelado de
los organismos acostumbran ordenar las diferentes perspectivas de una arquitectura en trminos de vistas
(views). La mayora de los frameworks y estrategias reconoce entre tres y seis vistas, que son las que se
incluyen en el cuadro. Una vista es, para definirla sucintamente, un subconjunto resultante de practicar una
seleccin o abstraccin sobre una realidad, desde un punto de vista determinado [Hil99].
El marco de referencia para la arquitectura empresarial de John Zachman [Zac87] identifica 36 vistas en
la arquitectura (celdas) basadas en seis niveles (scope, empresa, sistema lgico, tecnologa,
representacin detallada y funcionamiento empresarial) y seis aspectos (datos, funcin, red, gente, tiempo,
motivacin). En el uso corriente de la Arquitectura de software se ha estimado que este modelo es
Tabla 1 - Vistas en los marcos de referencia
17
excesivamente rgido y sobre-articulado. Parecera existir cierto consenso sobre su excesiva ambicin y su
posible obsolescencia.
El Modelo de Referencia para Procesamiento Distribuido Abierto (RM-ODP) es un estndar de ISO y de
ITU (ex-CCITT) que define un marco para la especificacin arquitectnica de grandes sistemas distribuidos.
Define, entre otras cosas, cinco puntos de vista (viewpoints) para un sistema y su entorno: empresa,
informacin, computacin, ingeniera y tecnologa. Los cinco puntos de vista no corresponden a etapas de
proceso de desarrollo o refinamiento. De los cuatro estndares bsicos que componen el modelo, los dos
primeros se refieren a la motivacin general del mismo y a sus fundamentos conceptuales y analticos; el
tercero (ISO/IEC 10746-3; UTI-T X.903) a la arquitectura, definiendo los puntos de vistas referidos; y el
cuarto (ISO/IEC 10746-4; UTI-T X.904) a la formalizacin de la semntica arquitectnica. RM-ODP se supone
neutral en relacin con la metodologa, las formas de modelado y la tecnologa a implementarse, pero
recomienda el uso de lenguajes formales de especificacin como LOTOS, ESTELLE, SDL o Z. Se supone que un
modelo pensado con similares propsitos, como CORBA, debera ser 100% conforme con la referencia, pero
en verdad no es as; CORBA, por ejemplo, no proporciona soporte para el viewpoint empresarial, su modelo
computacional revela desviaciones significativas del ISO/IEC o el UTI-T correspondiente, su modelo de
binding es ms restringido (carece de multicast o plug and play) y aunque hay RFPs que documentan estas
divergencias, hasta donde puede saberse permanecen an sin resolver; en los viewpoints de ingeniera y
tecnologa las discrepancias son menores, pero son muchsimas, y en ninguno hay concordancia en la
nomenclatura [DIR99]. Los modelos mayores de industria como COM o J2EE son todava ms divergentes y
las verificaciones de conformidad son un trmite extremadamente complejo. RM-ODP, adems, no
especifica nada acerca de conectores entre sistemas, integracin de tecnologas legacy o soporte de
sistemas multiparadigmas [Bez98].
Hoy en da la interoperabilidad se garantiza ms a travs de tecnologas comunes de formato y protocolo
ligadas a XML, SOAP, BPEL4WS o WS-I (o mediante MDA, o programando un wrapper) que por conformidad
con esta clase de recomendaciones en todos los puntos de un proceso distribuido.
C4ISR Architecture Framework es el marco de referencia arquitectnico promovido por el Departamento
de Defensa de Estados Unidos (DoD). Algunos de los otros marcos listados en esta seccin se inspiran en l,
como es el caso de TOGAF. En la versin 2 de C4I, completada en diciembre de 1997, la definicin de
arquitectura reconocida es exactamente la misma que despus se promulgara como cannica en IEEE 1471.
Las vistas arquitectnicas homologadas son la Operacional (que identifica relaciones y necesidades de
informacin), la de Sistemas (que vincula capacidades y caractersticas a requerimientos operacionales) y la
Tcnica (que prescribe estndares y convenciones).
En 1995 Philippe Kruchten propuso su clebre modelo 4+1, vinculado al Rational Unified Process (RUP),
que define cuatro vistas diferentes de la arquitectura de software: (1) La vista lgica, que comprende las
abstracciones fundamentales del sistema a partir del dominio de problemas. (2) La vista de proceso: el
conjunto de procesos de ejecucin independiente a partir de las abstracciones anteriores. (3) La vista fsica:
un mapeado del software sobre el hardware. (4) La vista de desarrollo: la organizacin esttica de mdulos
en el entorno de desarrollo. El quinto elemento considera todos los anteriores en el contexto de casos de
El marco de referencia arquitectnico de The Open Group (TOGAF) reconoce cuatro componentes
principales, uno de los cuales es un framework de alto nivel que a su vez define cuatro vistas: Arquitectura
de Negocios, Arquitectura de Datos/Informacin, Arquitectura de Aplicacin y Arquitectura Tecnolgica. The
Open Group propone un modelo de descripcin arquitectnica, Architecture Description Method (ADM) que
se supone independiente de las tcnicas de modelado, aunque en la versin 7 se propone Metis como
herramienta.
18
uso [Kru95]. Lo que acadmicamente se define como arquitectura del software concierne a las dos primeras
vistas. El modelo 4+1 se percibe hoy como un intento se reformular una arquitectura estructural y
descriptiva en trminos de objeto y de UML. Con todo, las cuatro vistas de Kruchten forman parte del
repertorio estndar de los practicantes de la disciplina.
En su introduccin a UML (1.3), Grady Booch, James Rumbaugh e Ivar Jacobson han formulado un
esquema de cinco vistas interrelacionadas que conforman la arquitectura de software, caracterizada en
trminos parecidos a los que uno esperara encontrar en el discurso de la vertiente estructuralista. En esta
perpectiva, la arquitectura de software (a la que se dedican muy pocas pginas) es un conjunto de
decisiones significativas sobre (1) la organizacin de un sistema de software; (2) la seleccin de elementos
estructurales y sus interfaces a travs de los cuales se constituye el sistema; (3) su comportamiento, segn
resulta de las colaboraciones entre esos elementos; (4) la composicin de esos elementos estructurales y de
comportamiento en subsistemas progresivamente mayores; (5) el estilo arquitectnico que gua esta
organizacin: los elementos estticos y dinmicos y sus interfaces, sus colaboraciones y su composicin. Los
autores proporcionan luego un esquema de cinco vistas posibles de la arquitectura de un sistema: (1) La
vista de casos de uso, como la perciben los usuarios, analistas y encargados de las pruebas; (2) la vista de
diseo que comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su
solucin; (3) la vista de procesos que conforman los hilos y procesos que forman los mecanismos de
sincronizacin y concurrencia; (4) la vista de implementacin que incluye los componentes y archivos sobre
el sistema fsico; (5) la vista de despliegue que comprende los nodos que forma la topologa de hardware
sobre la que se ejecuta el sistema [BRJ99: 26-27]. Aunque las vistas no estn expresadas en los mismos
trminos estructuralistas que campean en su caracterizacin de la arquitectura, y aunque la relacin entre
vistas y decisiones arquitectnicas es de simple yuxtaposicin informal de ideas antes que de integracin
rigurosa, es natural inferir que las vistas que ms claramente se vinculan con la semntica arquitectnica son
la de diseo y la de proceso.
Bass, Clements y Kazman presentan en 1998 una taxonoma de nueve vistas, decididamente sesgadas
hacia el diseo concreto y la implementacin: (1) Estructura de mdulo; las unidades son asignaciones de
tareas. (2) Estructura lgica o conceptual. Las unidades son abstracciones de los requerimientos funcionales
del sistema. (3) Estructura de procesos o de coordinacin. Las unidades son procesos o threads. (4)
Estructura fsica. (5) Estructura de uso. Las unidades son procedimientos o mdulos, vinculados por
relaciones de presuncin-de-presencia-correcta. (6) Estructura de llamados. Las unidades son usualmente
(sub)procedimientos, vinculados por invocaciones o llamados. (7) Flujo de datos. Las unidades son
programas o mdulos, la relacin es de envo de datos. (8) Flujo de control; las unidades son programas,
mdulos o estados del sistema. (9) Estructura de clases. Las unidades son objetos [BCK98]. Esta taxonoma
de vista no coincide con ninguna otra.
En los albores de la moderna prctica de los patrones, Buschmann y otros presentan listas discrepantes
de vistas en su texto popularmente conocido como POSA [BMR+96]. En la primera se las llama
arquitecturas, y son: (1) Arquitectura conceptual: componentes, conectores; (2) Arquitectura de mdulos:
subsistemas, mdulos, exportaciones, importaciones; (3) Arquitectura de cdigo: archivos, directorios,
bibliotecas, inclusiones; (4) Arquitectura de ejecucin: tareas, hilos, procesos. La segunda lista de vistas, por
su parte, incluye: (1) Vista lgica: el modelo de objetos del diseo, o un modelo correspondiente tal como un
diagrama de relacin; (2) Vista de proceso: aspectos de concurrencia y sincronizacin; (3) Vista fsica: el
mapeo del software en el hardware y sus aspectos distribuidos; (4) Vista de desarrollo: la organizacin
esttica del software en su entorno de desarrollo. Esta segunda lista coincide con el modelo 4+1 de
Kruchten, pero sin tanto nfasis en el quinto elemento.
19
La recomendacin IEEE Std 1471-2000 procura establecer una base comn para la descripcin de
arquitecturas de software, e implementa para ello tres trminos bsicos, que son arquitectura, vista y punto
de vista. La arquitectura se define como la organizacin fundamental de un sistema, encarnada en sus
componentes, las relaciones entre ellos y con su entorno, y los principios que gobiernan su diseo y
evolucin. Los elementos que resultan definitorios en la utilidad, costo y riego de un sistema son en
ocasiones fsicos y otras veces lgicos. En otros casos ms, son principios permanentes o patrones que
generan estructuras organizacionales duraderas. Trminos como vista o punto de vista son tambin
centrales. En la recomendacin se los utiliza en un sentido ligeramente distinto al del uso comn. Aunque
reflejan el uso establecido en los estndares y en la investigacin de ingeniera, el propsito del estndar es
introducir un grado de formalizacin homogeneizando informalmente la nomenclatura. En dicha
nomenclatura, un punto de vista (viewpoint) define un patrn o plantilla (template) para representar un
conjunto de incumbencias (concerns) relativo a una arquitectura, mientras que una vista (view) es la
representacin concreta de un sistema en particular desde una perspectiva unitaria. Un punto de vista
permite la formalizacin de grupos de modelos. Una vista tambin se compone de modelos, aunque posee
tambin atributos adicionales. Los modelos proporcionan la descripcin especfica, o contenido, de una
arquitectura. Por ejemplo, una vista estructural consistira de un conjunto de modelos de la estructura del
sistema. Los elementos de tales modelos incluiran componentes identificables y sus interfaces, as como
interconexiones entre los componentes. La concordancia entre la recomendacin de IEEE y el concepto de
estilo se establece con claridad en trminos del llamado punto de vista estructural. Otros puntos de vista
reconocidos en la recomendacin son el conductual y el de interconexin fsica. El punto de vista estructural
ha sido motivado (afirman los redactores del estndar) por el trabajo en lenguajes de descripcin
arquitectnica (ADLs). El punto de vista estructural, dicen, se ha desarrollado en el campo de la arquitectura
del software desde 1994 y es hoy de amplio uso.
Ahora que se han examinado cules son las vistas que proponen los diferentes frameworks, habra que
precisar mejor el significado especficamente arquitectnico de las vistas. Como expresa Rich Hilliard [Hil99],
a quien seguimos en este tratamiento, aunque expresiones tales como mltiples vistas son algo as como el
Santo Grial de la ingeniera de software, de requerimientos y de sistemas, su estatus en la arquitectura del
software es bastante ms oscuro. Las razones para ello son mltiples. En primer lugar, no existe una
fundamentacin coherente para su uso en la disciplina. En segundo trmino, muchos estudiosos las
consideran problemticas, porque la existencia de mltiples vistas introduce problemas de integracin y
consistencia entre las diferentes vistas. Sin embargo, los arquitectos practicantes las usan de todas maneras,
porque simplifican la visualizacin de sistemas complejos.
La idea de contemplar un sistema complejo desde mltiples puntos de vista no es nativa de la arquitectura
del software contempornea, ni es una invencin de Kruchten, sino que se origina por lo menos en la
dcada de 1970, en el trabajo de Douglas Ross sobre anlisis estructurado [Ross77]. La motivacin para
introducir mltiples vistas radica en la separacin de incumbencias (separations of concerns). Las vistas se
introdujeron como una herramienta conceptual para poder manejar la complejidad de lo que ya por aquel
La estrategia de arquitectura de Microsoft define, en consonancia con las conceptualizaciones ms

generalizadas, cuatro vistas, ocasionalmente llamadas tambin arquitecturas: Negocios, Aplicacin,
Informacin y Tecnologa [Platt02]. La vista que aqu interesa es la de la aplicacin, que incluye, entre otras
cosas: (1) Descripciones de servicios automatizados que dan soporte a los procesos de negocios; (2)
descripciones de las interacciones e interdependencias (interfaces) de los sistemas aplicativos de la
organizacin, y (3) planes para el desarrollo de nuevas aplicaciones y la revisin de las antiguas, basados en
los objetivos de la empresa y la evolucin de las plataformas tecnolgicas. Cada arquitectura, a su vez, se
articula en vistas tambin familiares desde los das de OMT que son (1) la Vista Conceptual, cercana a la
semntica de negocios y a la percepcin de los usuarios no tcnicos; (2) la Vista Lgica, que define los
componentes funcionales y su relacin en el interior de un sistema, en base a la cual los arquitectos
construyen modelos de aplicacin que representan la perspectiva lgica de la arquitectura de una
aplicacin; (3) la Vista Fsica, que es la menos abstracta y que ilustra los componentes especficos de una
implementacin y sus relaciones.
20
entonces se llamaban artefactos, tales como especificaciones de requerimientos o modelos de diseo. En las
contribuciones ms tempranas, las mltiples vistas de un modelo se basaban en perspectivas fijas, puntos
de vistas o viewpoints; casi siempre los puntos de vista eran dos, el funcional y el de datos, ninguno de los
cuales aparece en arquitectura.
En la dcada de 1980, sin embargo, las vistas comenzaron a multiplicarse, al punto que se realizaron surveys
interdisciplinarios y se organizaron conferencias especficas sobre la cuestin, como Viewpoints96. No hay
un lmite necesario para el nmero de vistas posibles, ni un procedimiento formal para establecer lo que una
vista debe o no abstraer. El estndar IEEE 1471 no delimita el nmero posible de vistas, ya que se estima que
no puede haber acuerdo en ello, pero seala lineamientos para su constitucin y considera que un viewpoint
es a una vista como una clase es a un objeto.
Hay una lista corta de vistas que se usa en los textos generales de arquitectura del software y una lista
larga que gira en torno de UML, el cual especifica nueve clases de diagramas correspondientes a ocho
vistas, como se indica en el cuadro. Diferentes textos de los mismos autores, por ejemplo [BRJ99] y [RJB00],
utilizan distintas terminologas no conciliadas; vistas y puntos de vista no siempre se caracterizan como
conceptos distintos y el uso de la terminologa, an en el interior de cada texto, es informal e inconsistente.
Es difcil creer que esto se encuentra unificado de alguna manera. Cuando los promotores de UML hablan
de arquitectura, a instancias de Kruchten, cambian su modelo de vistas por uno que se refiere no a puntos
de perspectiva o a incumbencias de los participantes, sino a niveles de abstraccin; pero an as, como se ha
visto, su definicin de arquitectura difiere de la definicin estndar.
Como lo subraya Hilliard, en sus textos iniciales la modalidad clsica de la arquitectura del software,
encarnada en Garlan y Shaw, no habla de vistas en absoluto; la arquitectura del software clsica se funda en
una vista singular e implcita, de carcter estructural. Muchos arquitectos de la corriente principal evitan
hablar de vistas, porque cuando las ellas proliferan se hace necesario o bien elaborar lenguajes formales
especficos para tratar cada una de ellas, o bien multiplicar salvajemente las extensiones del lenguaje
unificado. Sin duda las vistas son una simplificacin conveniente, o ms bien un principio de orden; pero su
abundancia y sus complicadas relaciones recprocas generan tambin nuevos rdenes de complejidad.
Podra discutirse el concepto y la articulacin de las diferentes vistas un largo rato, y de hecho los muchos
simposios que han habido sobre el particular fueron de inters pero inconcluyentes. Se acostumbra poner
Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]
21
las vistas que denotan niveles de abstraccin en cuadros superpuestos, por ejemplo, como si fueran
anlogas a las capas del modelo OSI, pero son ambas representaciones estrictamente homlogas?
Constituye el conjunto de las vistas un sistema? Por qu cada vez que se enumeran los artefactos
caractersticos de cada vista aparece la palabra etctera o la expresin elementos principales?
Procesos y Metodologas
En los diferentes marcos, las vistas estticas se corresponden con las perspectivas particulares de los
diferentes participantes (stakeholders), mientras que las vistas dinmicas tienen que ver con etapas del
proceso, ciclo de vida o metodologa, caracterizadas como requerimiento, anlisis, diseo (o construccin, o
modelado), implementacin, integracin (prueba de conformidad, testing, evaluacin).
La terminologa, lo mismo que la articulacin temporal del proceso o el ciclo, depende de cada marco.
Llegando al territorio de la metodologa, hay que decir que durante varios aos la arquitectura del software
discurri sin elaborarlas ms que circunstancialmente, como si se estimara compatible con las prcticas
establecidas en ingeniera de software, cualesquiera fuesen: RUP, RAD, RDS, ARIS, PERA, CIMOSA, GRAI,
GERAM, CMM. Hoy en da la metodologa dominante en la industria es tal vez el Modelo de Madurez de la
Capacidad (CMM), unque el SEI no la considera formalmente como tal.
Desde 1998 y cada vez con mayor intensidad, sin embargo, el SEI y otros organismos comenzaron a elaborar
mtodos especficos de procesos de ingeniera que sistematizan el rol de la arquitectura en la totalidad del
proceso, desde la elicitacin de requerimientos hasta la terminacin. Algunos de esos mtodos son
Architecture Based Design (ABD), Software Architecture Analysis Method (SAAM), Quality Attribute
Workshops (QAW), Quality Attribute-Oriented Software Architecture Design Method (QASAR), AttributeDriven Design (ADD),
En general, la arquitectura del software de la corriente principal todava no se ha expedido en relacin con
los llamados mtodos giles. No hay un solo mtodo, sino una multiplicidad de posturas ms o menos
radicales y combativas: Extreme Programming, SCRUM, Crystal Methods Framework, Feature-Driven
Development, DSDM, Lean Development, Adaptive Software Development, Agile Modeling, Pragmatic
Programming [ASR+02] [CLC03]. De hecho, la comunidad de los metodlogos, que opera a una cierta
distancia de las iniciativas formales de la arquitectura del software, se encuentra dividida tras lo que ha sido
y sigue siendo el gran debate metodolgico entre los mtodos pesados (o rigurosos) de tipo SEI/CMM por
un lado y los mtodos giles por el otro [Hig01].
Los tericos de cada bando han sido, entre otros, Tom De Marco, Ed Yourdon y Tim Lister en la faccin
rigurosa y Ken Orr, Jim Highsmith, Martin Fowler y Michael Jackson del lado gilextremo, con Philippe
Kruchten y RUP buscando establecerse en ambos terrenos. Ambos grupos operan en el contexto de la crisis
del software, que se da por sentada, alegando que es la mentalidad del bando opuesto lo que la ha
Architecture Tradeoff Analysis Method (ATAM), Active Review for Intermediate Design (ARID), CostBenefits Analysis Method (CBAM), Family-Architecture Analysis Method (FAAM), Architecture Level
Modifiability Analysis (ALMA), y Software Architecture Comparison Analysis Method (SACAM). Al lado de
esos mtodos est surgiendo un nutrido conjunto de tcnicas de documentacin; mtodos, tcnicas y
estudios de casos se analizarn en este estudio en documentos separados. Habiendo al menos una docena
de mtodos complejamente engranados entre s, el lector puede perderse con facilidad en un laberinto
bibliogrfico donde no siempre se discierne cules de estos mtodos incluyen a cules otros, cules son sus
relaciones con tcnicas consagradas de ingeniera, cules se encuentran vigentes y cules obsoletos. Un
documento actual que describe a grandes rasgos la mayora de esos mtodos es [KNK03].
22
ocasionado. Los pesados, mirados por los giles como formalistas fracasados, enfatizan el modelado, el
control y la documentacin escrupulosa; los giles, acusados por los pesados de hackers irresponsables que
pretenden imponer sus juguetes en la empresa, no slo desprecian los modelos (formales o informales) sino
que incluso ocasionalmente ponen en tela de juicio hasta a los propios patrones de diseo [Fow01]. Ese
tema tambin ser tratado en un estudio aparte.
En lo que respecta a la estrategia arquitectnica de Microsoft, el marco general de Microsoft Solutions

Framework, versin 3, no se expide sobre metodologas especficas y da cabida a una gran cantidad de
alternativas, desde las densas a las ligeras. Abundan en MSF 3 referencias a mtodos rpidos y giles, a
travs de citas y conceptos de una de las figuras cardinales de Cutter Consortium, Martin Fowler. La
documentacin de MSF ratifica su adecuacin tanto para el CMM de SEI o UPM como para los mtodos
giles en ambientes que requieren un alto grado de adaptabilidad [MS03].
La Abstraccin
El concepto de abstraccin (que a veces se usa en el sentido del proceso de abstraer, otra para designar una
entidad) ha sufrido tambin diversas acepciones, con un ncleo de significados comn. Las diferencias en el
uso del concepto de abstraccin ayudan tambin a identificar las diversas corrientes en el seno de la AS. La
definicin que proporciona Grady Booch, por ejemplo, revela que el autor identifica la abstraccin
arquitectnica con el encapsulamiento propio de la tecnologa de objetos: Una abstraccin escribe
Booch denota las caractersticas esenciales de un objeto que lo distinguen de otras clases de objeto y
provee de este modo delimitaciones conceptuales bien definidas, relativas a la perspectiva del observador
[Boo91].
La idea de abstraccin forma parte de lo que acaso sea la pieza conceptual ms importante de la
arquitectura del software, el concepto de estilo; un estilo se identifica a grandes rasgos o, como se dice
habitualmente, en un estilo menos es ms. La misma idea prevalece en todos los conceptos y
procedimientos que se consideran arquitectnicos. Para Len Bass, Paul Clements y Rick Kazman [BCK98], si
una decisin debe posponerse hasta el momento de tratar las cosas a un bajo nivel, no se trata de una
decisin de arquitectura. Clements y Northrop [CN96] sostienen que el trabajo de Garlan y Shaw sobre los
estilos arquitectnicos nos ensea que aunque los programas pueden combinarse de maneras
prcticamente infinitas, hay mucho que ganar si nos restringimos a un conjunto relativamente pequeo de
elecciones cuando se trata de cooperacin e interaccin. Las ventajas incluyen mejor reutilizacin, mejores
anlisis, menor tiempo se seleccin y mayor interoperabilidad. Menos es ms figura, de hecho, en el ttulo
y en los contenidos de numerosos papers de la profesin [MB02] [CN96]. Conceptos como el de estilo, o
marcos como MSF, revelan su naturaleza arquitectnica en su abstraccin y en su generalidad.
El concepto de abstraccin (que a veces se usa en el sentido del proceso de abstraer, otra para designar una
entidad abstracta) ha sufrido tambin diversas formulaciones sintcticas, con un ncleo de significados
comn. En ltimo anlisis, la abstraccin siempre conlleva una heurstica positiva al lado de una negacin.
Tanto para la IEEE como para Rumbaugh, Shaw y otros autores, la abstraccin consiste en extraer las
propiedades esenciales, o identificar los aspectos importantes, o examinar selectivamente ciertos aspectos
de un problema, posponiendo o ignorando los detalles menos sustanciales, distractivos o irrelevantes.
23
Escenarios
Esta es una nocin arquitectnica importante y se encuentra en la base de muchos de los mtodos de
diseo y desarrollo basados en arquitectura, como ALMA, SAAM y ATAM. Hay que ser precavidos y advertir
desde el comienzo que lo que habitualmente se traduce como escenario no es estrictamente lo que en
lengua castellana se designa como tal; la traduccin correcta debera ser ms bien guin o libreto. La
traduccin literal del trmino no hace ms que aportar confusin. Desde Kruchten en adelante, se reconoce
que los escenarios se dividen en dos categoras: casos de uso (secuencias de responsabilidades) y casos de
cambio (modificaciones propuestas al sistema).
Los escenarios han sido bsicamente tcnicas que se implementan en la elicitacin de los requerimientos,
particularmente en relacin a los operadores de sistemas. Tpicamente, la tcnica comienza instrumentando
sesiones de brainstorming. Tambin se han utilizado escenarios como mtodo para comparar alternativas
de diseo. Los escenarios describen una utilizacin anticipada o deseada del sistema, y tpicamente se
expresan en una frase; Kazman, Abowd, Bass y Clements proponen tambin llamarlos vietas [KAB+96].
Segn algunas definiciones, como la de Clements y Northrop [CN96], los escenarios son algo as como
libretos (en el sentido teatral o cinematogrfico del trmino) correspondientes a las distintas piezas de
funcionalidad de un sistema. Se los considera tiles para analizar una vista determinada [Cle95a] o para
mostrar la forma en que los elementos de mltiples vistas se relacionan entre s [Kru95]. Pueden concebirse
tambin como una abstraccin de los requerimientos ms importantes de un sistema. Los escenarios se
describen mediante texto comn en prosa utilizando lo que se llama un script y a veces se describen
mediante dibujos, como por ejemplo diagramas de interaccin de objeto. Se acostumbra utilizar UML (en el
contexto de 4+1) no tanto como recurso de modelado que despus generar alguna clase de cdigo, sino
como instrumento de dibujo ms o menos informal; pero los propios manuales de UML y los expertos
mundiales en casos de uso (David Anderson, Martin Fowler, Alistair Cockburn) recomiendan desarrollar los
escenarios de requerimiento en texto, no en diagramas.
Algunos autores estiman que se trata de una herramienta importante para relacionar vistas arquitectnicas,
porque recorriendo un escenario puede mostrar las formas en que fragmentos o escenas de esas vistas se
corresponden entre s. Los mtodos propios de la arquitectura basada en escenarios se analizan tambin en
un documento aparte.
La arquitectura del software es hoy en da un conjunto inmenso y heterogneo de reas de investigacin

terica y de formulacin prctica, por lo que conviene aunque ms no sea enumerar algunos de sus campos
y sus focos. Una semblanza semejante (de la que aqu se proporciona slo un rudimento) dudosamente
debera ser esttica. La arquitectura del software comenz siendo una abstraccin descriptiva puntual que
en los primeros aos no investig de manera sistemtica ni las relaciones que la vinculaban con los
requerimientos previos, ni los pasos metodolgicos a dar luego para comenzar a componer el diseo. Pero
esa sincronicidad estructuralista no pudo sostenerse. Por el contrario, dara la impresin que, a medida que
pasa el tiempo, la arquitectura del software tiende a redefinir todos y cada uno de los aspectos de la
disciplina madre, la ingeniera de software, slo que a un mayor nivel de abstraccin y agregando una nueva
dimensin reflexiva en lo que concierne a la fundamentacin formal del proceso.
Campos de la Arquitectura de Software
24
Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en torno de las reas que
componen el territorio. David Garlan y Dewayne Perry, en su introduccin al volumen de abril de 1995 de
IEEE Transactions on Software Engineering dedicado a la arquitectura del software, en el cual se delinean las
reas de investigacin ms promisorias, enumeran las siguientes:
Lenguajes de descripcin de arquitecturas
Fundamentos formales de la arquitectura del software (bases matemticas, caracterizaciones
formales de propiedades extra-funcionales tales como mantenibilidad, teoras de la interconexin,
etctera).
Tcnicas de anlisis arquitectnicas
Mtodos de desarrollo basados en arquitectura
Recuperacin y reutilizacin de arquitectura
Codificacin y gua arquitectnica
Herramientas y ambientes de diseo arquitectnico
Estudios de casos
Fundamental en la concepcin de Clements y Northrop [CN96] es el criterio de reusabilidad como uno de los
aspectos que ms hacen por justificar la disciplina misma. Segn estos autores, el estudio actual de la
arquitectura del software puede ser visto como un esfuerzo ex post facto para proporcionar un almacn
estructurado de este tipo de informacin reutilizable de diseo de alto nivel propio de una familia (en el
sentido de Parnas). De tal manera, las decisiones de alto nivel inherentes a cada miembro de una familia de
programas no necesitan ser re-inventadas, re-validadas y redescriptas. Un razonamiento arquitectnico es
adems un argumento sobre las cuestiones estructurales de un sistema. Se dira tambin que el concepto de
estilo es la encarnacin principal del principio de reusabilidad en el plano arquitectnico.
Paul Clements [Cle96b] define cinco temas fundamentales en torno de los cuales se agrupa la disciplina:
Diseo o seleccin de la arquitectura: Cmo crear o seleccionar una arquitectura en base de
requerimientos funcionales, de rendimiento o de calidad.
Representacin de la arquitectura: Cmo comunicar una arquitectura. Este problema se ha
manifestado como el problema de la representacin de arquitecturas utilizando recursos
lingsticos, pero el problema tambin incluye la seleccin del conjunto de informacin a ser
comunicada.
Evaluacin y anlisis de la arquitectura: Cmo analizar una arquitectura para predecir cualidades
del sistema en que se manifiesta. Un problema semejante es cmo comparar y escoger entre
diversas arquitecturas en competencia.
Recuperacin de la arquitectura: Cmo hacer que un sistema legacy evolucione cuando los
cambios afectan su estructura; para los sistemas de los que se carezca de documentacin confiable,
esto involucra primero una arqueologa arquitectnica que extraiga su arquitectura.
Mary Shaw [Shaw01] considera que en el 2001 los campos ms promisorios de la arquitectura del software
siguen teniendo que ver con el tratamiento sistemtico de los estilos, el desarrollo de lenguajes de
descripcin arquitectnica, la formulacin de metodologas y (ahora) el trabajo con patrones de diseo. Se
requieren todava modelos precisos que permitan razonar sobre las propiedades de una arquitectura y
Desarrollo y evolucin basados en arquitectura: Cmo construir y mantener un sistema dada una
representacin de la cual se cree que es la arquitectura que resolver el problema correspondiente.
25
verificar su consistencia y completitud, as como la automatizacin del proceso de anlisis, diseo y sntesis.
Sugiere que debe aprenderse una leccin a partir de la experiencia de la ingeniera de software, la cual no
obstante haberse desenvuelto durante treinta aos no ha logrado plasmar un conjunto de paradigmas de
investigacin comparable al de otras reas de las ciencias de la computacin donde se estima que la
arquitectura del software se encuentra ya en su fase de desarrollo y extensin, pero que tanto las ideas
como las herramientas distan de estar maduras.
Un campo que no figura en estas listas pero sobre el cual se est trabajando intensamente es en el de la
coordinacin de los ADLs que sobrevivan con UML 2.0 por un lado y con XML por el otro.
Ningn lenguaje de descripcin arquitectnica en el futuro prximo (excepto los que tengan un nicho
tcnico muy particular) ser viable si no satisface esos dos requisitos.
Los ejercicios que pueden hacerse para precisar los campos de la arquitectura del software son incontables.
Ahora que la arquitectura del software se ha abismado en el desarrollo de metodologas, hace falta, por
ejemplo, establecer con ms claridad en qu difieren sus elaboraciones en torno del diseo, del anlisis de
requerimientos o de justificacin econmica de las llevadas a cabo por la ingeniera de software.
Asimismo, se est esperando todava una lista sistemtica y exhaustiva que describa los dominios de
incumbencia de la disciplina, as como un examen del riesgo de duplicacin de esfuerzos entre campos
disciplinarios mal comunicados, una situacin que a primera vista parecera contradictoria con el principio
de reusabilidad.
Modalidades y tendencias
En la dcada de 1990 se establece definitivamente la arquitectura del software como un dominio todava
hoy separado de manera confusa de ese marco global que es la ingeniera y de esa prctica puntual que es el
diseo. Aunque no hay un discurso explcito y autoconsciente sobre escuelas de arquitectura del software,
ni se ha publicado un estudio reconocido y sistemtico que analice las particularidades de cada una, en la
actualidad se pueden distinguir a grandes rasgos unas seis corrientes. Algunas distinciones estn implcitas
por ejemplo en [MT00], pero la bibliografa sobre corrientes y alternativas prcticamente no existe y la que
sigue habr de ser por un tiempo una de las pocas propuestas contemporneas sobre el particular.
Ahora bien, articular una taxonoma de estrategias no admite una solucin simple y determinista. En
distintos momentos de su trayectoria, algunos practicantes de la arquitectura del software se mueven
ocasionalmente de una tctica a otra, o evolucionan de un punto de vista ms genrico a otro ms
particular, o realizan diferentes trabajos operando en marcos distintos. Adems, con la excepcin del gran
debate metodolgico entre mtodos pesados y ligeros [Hig01], las discusiones entre las distintas posturas
rara vez se han manifestado como choques frontales entre ideologas irreconciliables, por lo que a menudo
hay que leer entre lneas para darse cuenta que una afirmacin cualquiera es una crtica a otra manera de
ver las cosas, o trasunta una toma definida de posicin. Fuera de la metodologa, el nico factor reconocible
de discordia ha sido, hasta la fecha, la preminencia de UML y el diseo orientado a objetos. Todo lo dems
parece ser ms o menos negociable. La divisin preliminar de escuelas de arquitectura del software que
proponemos es la siguiente:
Es el modelo de James Rumbaugh, Ivar Jacobson, Grady Booch, Craig Larman y otros, ligado estrechamente
al mundo de UML y Rational. No cabe duda que se trata de una corriente especfica: Rumbaugh, Jacobson y
Booch han sido llamados Los Tres Amigos o la banda de los 3 amigos; de lo que s puede dudarse es que
se trate de una postura arquitectnica. En este postura, la arquitectura se restringe a las fases iniciales y
preliminares del proceso y concierne a los niveles ms elevados de abstraccin, pero no est
sistemticamente ligada al requerimiento que viene antes o a la composicin del diseo que viene despus.
1) ARQUITECTURA COMO ETAPA DE INGENIERA Y DISEO ORIENTADA A OBJETOS.
26
Lo que sigue al momento arquitectnico es business as usual, y a cualquier configuracin, topologa o

morfologa de las piezas del sistema se la llama arquitectura.
En esta escuela, si bien se reconoce el valor primordial de la abstraccin (nadie despus de Dijkstra osara
oponerse a ello) y del ocultamiento de informacin promovido por Parnas, estos conceptos tienen que ver
ms con el encapsulamiento en clases y objetos que con la visin de conjunto arquitectnica. Para este
movimiento, la arquitectura se confunde tambin con el modelado y el diseo, los cuales constituyen los
conceptos dominantes. En esta corriente se manifiesta predileccin por un modelado denso y una profusin
de diagramas, tendiente al modelo metodolgico CMM o a UPM; no hay, empero, una precripcin formal.
Importa ms la abundancia y el detalle de diagramas y tcnicas disponibles que la simplicidad de la visin de
conjunto. Cuando aqu se habla de estilos, se los confunde con patrones arquitectnicos o de diseo [Lar03].
Jams se hace referencia a los lenguajes de descripcin arquitectnica, que representan uno de los assets
reconocidos de la Arquitectura de software; sucede como si la disponibilidad de un lenguaje unificado de
modelado los tornara superfluos. La definicin de arquitectura que se promueve en esta corriente tiene que
ver con aspectos formales a la hora del desarrollo; esta arquitectura es isomorfa a la estructura de las piezas
de cdigo. Una definicin tpica y demostrativa sera la de Grady Booch; para l, la arquitectura del software
es la estructura lgica y fsica de un sistema, forjada por todas las decisiones estratgicas y tcticas que se
aplican durante el desarrollo [Boo91].
Otras definiciones revelan que la arquitectura del software, en esta perspectiva, concierne a decisiones
sobre organizacin, seleccin de elementos estructurales, comportamiento, composicin y estilo
arquitectnico susceptibles de ser descriptas a travs de las cinco vistas clsicas del modelo 4+1 de Kruchten
[Kru95] [BRJ99: 26-28].
2) ARQUITECTURA ESTRUCTURAL, BASADA EN UN MODELO ESTTICO DE ESTILOS, ADLS Y VISTAS.
Todo estructuralismo es esttico; hasta fines del siglo XX, no est muy claro el tema de la posicin del
modelado arquitectnico en el ciclo de vida.
3) ESTRUCTURALISMO ARQUITECTNICO RADICAL.

Se trata de un desprendimiento de la corriente anterior, mayoritariamente europeo, que asume una actitud
ms confrontativa con el mundo UML. En el seno de este movimiento hay al menos dos tendencias, una que
Constituye la corriente fundacional y clsica de la disciplina. Los representantes de esta corriente son todos
acadmicos, mayormente de la Universidad Carnegie Mellon en Pittsburgh: Mary Shaw, Paul Clements,
David Garlan, Robert Allen, Gregory Abowd, John Ockerbloom. Se trata tambin de la visin de la
arquitectura del software dominante en la academia, y aunque es la que ha hecho el esfuerzo ms
importante por el reconocimiento de la arquitectura del software como disciplina, sus categoras y
herramientas son todava mal conocidas en la prctica industrial. En el interior del movimiento se pueden
observar distintas divisiones. Hay una variante informal de boxologa y una vertiente ms formalista,
representada por el grupo de Mark Moriconi en el SRI de Menlo Park. En principio se pueden reconocer tres
modalidades en cuanto a la formalizacin; los ms informales utilizan descripciones verbales o diagramas
de cajas, los de talante intermedio se sirven de ADLs y los ms exigentes usan lenguajes formales de
especificacin como CHAM y Z. En toda la corriente, el diseo arquitectnico no slo es el de ms alto nivel
de abstraccin, sino que adems no tiene por qu coincidir con la configuracin explcita de las aplicaciones;
rara vez se encontrarn referencias a lenguajes de programacin o piezas de cdigo, y en general nadie
habla de clases o de objetos. Mientras algunos participantes excluyen el modelo de datos de las
incumbencias de la arquitectura del software (Shaw, Garlan, etc), otros insisten en su relevancia
(Medvidovic, Taylor).
27
excluye de plano la relevancia del modelado orientado a objetos para la arquitectura del software y otra que
procura definir nuevos metamodelos y estereotipos de UML como correctivos de la situacin. Dado que
pueden existir dudas sobre la materialidad de esta corriente como tal, proporcionamos referencias
bibliogrficas masivas que corroboran su existencia [Abd00] [AW99] [DDT99] [Dou00] [GAD+02] [GarS/f]
[Gli00] [HNS99] [KroS/f] [Sch00] [StS/f] [Tem99] [Tem01]. Pasaremos revista a los argumentos ms fuertes
en contra de UML emanados de este movimiento en el captulo correspondiente del documento sobre
lenguajes de descripcin arquitectnica.
4) ARQUITECTURA BASADA EN PATRONES.

Si bien reconoce la importancia de un modelo emanado histricamente del diseo orientado a objetos, esta
corriente surgida hacia 1996 no se encuentra tan rgidamente vinculada a UML en el modelado, ni a CMM en
la metodologa. El texto sobre patrones que esta variante reconoce como referencia es la serie POSA de
Buschmann y otros [BMR+96] y secundariamente el texto de la Banda de los Cuatro [Gof95]. La diferencia
entre ambos textos sagrados de la comunidad de patrones no es menor; en el primero, la expresin
Software Architecture figura en el mismo ttulo; el segundo se llama Design Patterns: Elements of reusable
Object-Oriented software y su tratamiento de la arquitectura es mnimo. En esta manifestacin de la
arquitectura del software prevalece cierta tolerancia hacia modelos de proceso tcticos, no tan
macroscpicos, y eventualmente se expresa cierta simpata por las ideas de Martin Fowler y las premisas de
la programacin extrema. El diseo consiste en identificar y articular patrones preexistentes, que se definen
en forma parecida a los estilos de arquitectura [Shaw96] [MKM+96] [MKM+97].
5) ARQUITECTURA PROCESUAL.
Desde comienzos del siglo XXI, con centro en el SEI y con participacin de algunos (no todos) los arquitectos
de Carnegie Mellon de la primera generacin y muchos nombres nuevos de la segunda: Rick Kazman, Len
Bass, Paul Clements, Felix Bachmann, Fabio Peruzzi, Jeromy Carrire, Mario Barbacci, Charles Weinstock.
Intenta establecer modelos de ciclo de vida y tcnicas de elicitacin de requerimientos, brainstorming,
diseo, anlisis, seleccin de alternativas, validacin, comparacin, estimacin de calidad y justificacin
econmica especficas para la arquitectura de software. Toda la documentacin puede encontrarse
ordenada en el SEI, pero no se mezcla jams con la de CMM, a la que redefine de punta a punta. Otras
variantes dentro de la corriente procesual caracterizan de otras maneras de etapas del proceso: extraccin
de arquitectura, generalizacin, reutilizacin [WL97].
Es la corriente ms nueva. Se trata de un movimiento predominantemente europeo, con centro en Holanda.

Recupera el nexo de la arquitectura del software con los requerimientos y la funcionalidad del sistema,
ocasionalmente borroso en la arquitectura estructural clsica. Los tericos y practicantes de esta modalidad
de arquitectura se inscriben dentro del canon delineado por la arquitectura procesual, respecto de la cual el
movimiento constituye una especializacin. En esta corriente suele utilizarse diagramas de casos de uso
UML como herramienta informal u ocasional, dado que los casos de uso son uno de los escenarios posibles.
Los casos de uso no estn orientados a objeto. Los autores vinculados con esta modalidad han sido, aparte
de los codificadores de ATAM, CBAM, QASAR y dems mtodos del SEI, los arquitectos holandeses de la
Universidad Tcnica de Eindhoven, de la Universidad Brije, de la Universidad de Groningen y de Philips
Research: Mugurel Ionita, Dieter Hammer, Henk Obbink, Hans de Bruin, Hans van Vliet, Eelke Folmer, Jilles
van Gurp, Jan Bosch.
La profusin de holandeses es significativa; la Universidad de Eindhoven es, incidentalmente, el lugar en el
que surgi lo que P. I. Sharp propopa llamar la escuela arquitectnica de Dijkstra. En todos los simposios
han habido intentos de fundacin de otras variedades de arquitectura del software, tales como una
arquitectura adaptativa inspirada en ideas de la programacin gentica o en teoras de la complejidad, la
6) ARQUITECTURA BASADA EN ESCENARIOS.
28
auto-organizacin, el caos y los fractales, una arquitectura centrada en la accin que recurre a la inteligencia
artificial heideggeriana o al postmodernismo, y una arquitectura epistemolgicamente reflexiva que tiene a
Popper o a Kuhn entre sus referentes; consideramos preferible omitirlas, porque por el momento ni su masa
crtica es notoria ni su mensaje parece sustancial [DD94] [HHr+96] [ZHH+99] [Hock00]. Pero hay al menos un
movimiento cismtico digno de tomarse ms en serio; a esta altura de los acontecimientos es muy posible
que pueda hablarse tambin de una anti-arquitectura, que en nombre de los mtodos heterodoxos se
opone tanto al modelado orientado a objetos y los mtodos sobre documentados impulsados por
consultoras corporativas como a la abstraccin arquitectnica que viene de la academia. El Manifiesto por la
Programacin Agil, en efecto, valoriza:
Los individuos y las interacciones por encima de los procesos y las herramientas
El software que funciona por encima de la documentacin exhaustiva
La colaboracin con el cliente por encima de la negociacin contractual
La respuesta al cambio por encima del seguimiento de un plan
Discernir la naturaleza de cada una puede tener efectos prcticos a la hora de comprender antagonismos,
concordancias, sesgos, disyuntivas, incompatibilidades, fuentes de recursos. Nadie ha analizado mejor los
lmites de una herramienta como UML o de los mtodos ultraformales, por ejemplo, que los que se oponen
a su uso por razones tericas precisas, por ms que stas sean interesadas. Un buen ejercicio sera aplicar
vistas y perspectivas diferentes a las que han regido esta clasificacin informal, y proponer en funcin de
otros criterios o de mtodos ms precisos de composicin y referencias cruzadas, taxonomas alternativas
de las lneas de pensamiento vigentes en la arquitectura del software en la actualidad.
DIFERENCIAS ENTRE ARQUITECTURA Y DISEO

Una vez que se reconoce la diferencia, que nunca debi ser menos que obvia, entre diseo e
implementacin, o entre vistas conceptuales y vistas tecnolgicas Es la arquitectura del software
solamente otra palabra para designar el diseo? Como suele suceder, no hay una sola respuesta, y las que
hay no son taxativas. La comunidad de arquitectura del software, en particular la de extraccin acadmica,
sostiene que sta difiere sustancialmente del mero diseo. Pero Taylor y Medvidovic [TM00], por ejemplo,
sealan que la literatura actual mantiene en un estado ambiguo la relacin entre ambos campos,
albergando diferentes interpretaciones y posturas:
Taylor y Medvidovic estiman que la segunda interpretacin es la que se encuentra ms cerca de la verdad.
En alguna medida, la arquitectura y el diseo sirven al mismo propsito. Sin embargo, el foco de la
arquitectura del software en la estructura del sistema y en las interconexiones la distingue del diseo de
software tradicional, tales como el diseo orientado a objetos, que se concentra ms en el modelado de
abstracciones de ms bajo nivel, tales como algoritmos y tipos de datos. A medida que la arquitectura de
alto nivel se refina, sus conectores pueden perder prominencia, distribuyndose a travs de los elementos
arquitectnicos de ms bajo nivel, resultando en la transformacin de la arquitectura en diseo.
En su reciente libro sobre el arte de la arquitectura del software, Stephen Albin [Alb03] se pregunta en qu
difiere ella de las metodologas de diseo bien conocidas como la orientacin a objetos. La arquitectura del
software, se contesta, es una metfora relativamente nueva en materia de diseo de software y en realidad
1) Una postura afirma que arquitectura y diseo son lo mismo.

2) Otra, en cambio, alega que la arquitectura se encuentra en un nivel de abstraccin por encima del
diseo, o es simplemente otro paso (un artefacto) en el proceso de desarrollo de software.
3) Una tercera establece que la arquitectura es algo nuevo y en alguna medida diferente del diseo
(pero de qu manera y en qu medida se dejan sin especificar).
29
abarca tambin las metodologas de diseo, as como metodologas de anlisis. El arquitecto de software
contemporneo, escribe Albin, ejecuta una combinacin de roles como los de analista de sistemas,
diseador de sistemas e ingeniero de software. Pero la arquitectura es ms que una recolocacin de
funciones. Esas funciones pueden seguir siendo ejecutadas por otros, pero ahora caen comnmente bajo la
orquestacin del chief architect. El concepto de arquitectura intenta subsumir las actividades de anlisis y
diseo en un framework de diseo ms amplio y ms coherente. Las organizaciones se estn dando cuenta
que el alto costo del desarrollo de software requiere ser sometido a algn control y que muchas de las
ventajas prometidas por las metodologas an no se han materializado. Pero la arquitectura es algo ms
integrado que la suma del anlisis por un lado y el diseo por el otro. La integracin de metodologas y
modelos, concluye Albin, es lo que distingue la arquitectura del software de la simple yuxtaposicin de
tcnicas de anlisis y de diseo.
Para Shaw y Garlan [SG96] la arquitectura del software es el primer paso en la produccin de un diseo de
software, en una secuencia que distingue tres pasos:
1) ARQUITECTURA.
Asocia las capacidades del sistema especificadas en el requerimiento con los componentes del sistema que
habrn de implementarla. La descripcin arquitectnica incluye componentes y conectores (en trminos de
estilos) y la definicin de operadores que crean sistemas a partir de subsistemas o, en otros trminos,
componen estilos complejos a partir de estilos simples.
3) DISEO EJECUTABLE.
Remite al diseo de cdigo a un nivel de detalle todava ms bajo y trata cuestiones tales como la asignacin
de memoria, los formatos de datos, etctera. En opinin de Clements [CBK+96] el diseo basado en
arquitectura representa un paradigma de desarrollo que difiere de maneras fundamentales de las
alternativas conocidas actualmente. En muchos sentidos, es diferente del diseo orientado a objetos (OOD)
en la misma medida en que ste difera de sus predecesores. La arquitectura del software deber nutrir una
comunidad de practicantes estableciendo una cultura en la que las ideas arquitectnicas puedan florecer.
Una cuestin tcnica que deber abordarse es la creacin de una articulacin precisa de un paradigma de
diseo basado en arquitectura (o posiblemente ms de uno) y las cuestiones de proceso asociadas. En una
presentacin de 1997, Dewayne Perry, uno de los fundadores de la disciplina, bosquej la diferencia entre
arquitectura y diseo. La arquitectura, una vez ms (todo el mundo insiste en ello) concierne a un nivel de
abstraccin ms elevado; se ocupa de componentes y no de procedimientos; de las interacciones entre esos
componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes y las interacciones
y no de los algoritmos, los procedimientos y los tipos. En cuanto a la composicin, la de la arquitectura es de
grano grueso, la del diseo es de fina composicin procedural; las interacciones entre componentes en
arquitectura tienen que ver con un protocolo de alto nivel (en el sentido no tcnico de la palabra), mientras
que las del diseo conciernen a interacciones de tipo procedural (rpc, mensajes, llamadas a rutinas) [Per97].
En los primeros aos del nuevo siglo, la arquitectura del software precis la naturaleza del proceso de
diseo como metodologa en diversos modelos de diseo basados en arquitectura o ABD [BBC+00]. Esta
metodologa considera que el diseo arquitectnico es el de ms elevado nivel de abstraccin, pero debe
hacer frente al hecho de un requerimiento todava difuso y al hecho de que, en ese plano, las decisiones que
se tomen sern las ms crticas y las ms difciles de modificar.
2) DISEO DEL CDIGO.

Comprende algoritmos y estructuras de datos; los componentes son aqu primitivos del lenguaje de
programacin, tales como nmeros, caracteres, punteros e hilos de control. Tambin hay operadores
primitivos.
30
Fundndose en el concepto de arquitectura conceptual de Hofmeister, Nord y Soni [HNS00] y en un modelos

de vistas similar al 4+1 o a las vistas del modelo arquitectnico de Microsoft, el ABD describe el sistema en
funcin de los principales elementos y las relaciones entre ellos. El proceso se basa en tres fundamentos: (1)
la descomposicin de la funcin (usando tcnicas bien establecidas de acoplamiento y cohesin), (2) la
realizacin de los requerimientos de calidad y negocios a travs de los estilos arquitectnicos, y (3) las
plantillas de software, un concepto nuevo que incluye patrones que describen la forma en que todos los
elementos de un tipo interactan con los servicios compartidos y la infraestructura. El modelo de diseo
especfico de ABD se describe en los documentos correspondientes a metodologas arquitectnicas.
Seguramente el lector encontrar mucho que agregar al planteamiento de las similitudes y diferencias entre
arquitectura y diseo, ms all del hecho obvio de que el diseo arquitectnico se distingue del diseo del
cdigo, que viene determinado desde mucho antes y que es mucho ms crtico para el xito o el fracaso de
una solucin.
PROBLEMAS ABIERTOS EN ARQUITECTURA DE SOFTWARE

Aunque la evaluacin dominante de la trayectoria de la arquitectura del software es abiertamente positiva,
en los primeros aos del siglo comienzan a percibirse desacuerdos y frustraciones en el proyecto de la
disciplina. Por empezar, est muy claro que la definicin original del proyecto, formulada en crculos
acadmicos, guarda poca relacin con la imagen que se tiene de la arquitectura del software en las prcticas
de la industria. An dentro de los confines de aquel crculo, a menudo las presentaciones distan de ser
contribuciones desinteresadas y representan ms bien posturas tericas particulares que se quieren
imponer por va de la argumentacin. Muchas de esas posturas son ms programticas que instrumentales.
Un nmero desmesurado de artculos y ponencias destaca asimismo la frustracin que muchos sienten por
no haber podido consensuar una definicin de la arquitectura del software universalmente aceptada. Por tal
razn vale la pena revisar el inventario de aspectos negativos elaborada por Clements y Northrop [CN96]:
El estudio de la arquitectura del software est siguiendo a la prctica, no liderndola. El estudio de la

arquitectura del software ha evolucionado de la observacin de los principios de diseo y las acciones que
toman los diseadores cuando trabajan en sistemas de la vida real. La arquitectura del software es un
intento de abstraer los rasgos comunes inherentes al diseo de sistemas, y como tal debe dar cuenta de un
amplio rango de actividades, conceptos, mtodos, estrategias y resultados. Lo que en realidad sucede es que
la arquitectura del software se redefine constantemente en funcin de lo que hacen los programadores.
El estudio es sumamente nuevo. Aunque sus races se prolongan en el tiempo, el campo de la arquitectura
del software es realmente muy nuevo, segn puede juzgarse de la reciente avalancha de libros,
conferencias, talleres y literatura consagrado a ella, aun as las fundamentaciones han sido imprecisas. El
campo se ha destacado por la proliferacin de trminos inciertos, verdaderas amenazas para los no
Los abogados de las distintas posturas traen sus sesgos consigo. En efecto, mientras las definiciones
propuestas para la arquitectura del software coinciden en su ncleo, difieren seriamente en los bordes.
Algunos autores requieren que la arquitectura incluya racionalizacin, otros piden ms bien pasos para el
proceso de construccin; otros exigen que se identifique la funcionalidad de los componentes, otros alegan
que una simple topologa es suficiente. En la lectura de los textos de arquitectura del software se torna
esencial entonces conocer la motivacin de sus responsables.
31
precavidos. Por ejemplo, la arquitectura definida como la estructura global de un sistema agrega
confusin en lugar de reducirla, porque implica que un sistema posee una sola estructura.
El trmino se ha usado en exceso. El significado de la palabra arquitectura en su relacin con la
ingeniera de software se ha ido diluyendo simplemente porque parece estar de moda. Es posible encontrar
referencias a las siguientes clases de arquitectura: especfica de dominio, megaprogramacin,
destinatario, sistemas, redes, infraestructura, aplicaciones, operaciones, tcnica, framework, conceptual, de
referencia, empresarial, de factora, C4I, de manufactura, de edificio, de mquina-herramienta, etctera. A
menudo la palabra arquitectura se usa de maneras inapropiadas [CN96].
Hacia el ao 2000, Taylor y Medvidovic celebraban el auge de la arquitectura del software, pero sealaban
que por momentos daba la impresin de haberse convertido en una moda que prometa ms de lo que se
poda realizar. Les preocupaba tambin que la arquitectura del software terminara confundindose con los
ADLs y con el diseo. Si bien el foco en la arquitectura posee un tremendo potencial, argumentan, est
comenzando a percibirse una cierta reaccin. Las razones son numerosas. La arquitectura es an en gran
medida una nocin acadmica, y muy poca de la tecnologa resultante ha sido transferida a la industria y
cuando se lo ha hecho no se lo ha comunicado bien. La concentracin en la investigacin como un valor en s
mismo ha sido tambin mal comprendida. Mientras tales errores ganen terreno, surge el peligro de que los
beneficios concretos y los resultados positivos de la investigacin arquitectnica sufran las consecuencias
[TMA+S/f].
Jason Baragry ha cuestionado la metfora de la arquitectura de edificios como columna vertebral de la

disciplina. Ello ha ocasionado, entre otras cosas, la falta de acuerdo en cuanto a la cantidad y calidad de
vistas arquitectnicas, as como la ostensible carencia de un mecanismo de coordinacin formal entre las
diferentes vistas [BG01], un problema tcnico que tambin surge, incidentalmente, en la integracin de las
vistas y diagramas de UML y en las recomendaciones de los organismos. Un problema que habra que tratar
sistemticamente es la discrepancia en las definiciones de arquitectura del software que prevalecen en la
academia y las que son comunes en la industria, incluyendo en ella tanto a los proveedores de software de
base como a los equipos de desarrollos de las empresas. Jan Bosch [Bos00] ha confeccionado una tabla de
contrastes que seguramente podra enriquecerse con nuevas antinomias.
Tabla 3. Descripcin de las arquitecturas
32
Tampoco conviene sobredimensionar el contraste, imaginando que la academia est desconectada de la

realidad industrial; por el contrario, la mayor parte de las herramientas acadmicas se elaboraron en el
contexto de proyectos industriales y de gobierno, casi todos ellos de misin crtica y de gran envergadura. El
nmero de problemas de consistencia detectados a tiempo (y que se hubiera manifestado sin gua
arquitectnica) es colosal. La cuestin radica ms bien en el desconocimiento que la industria tiene de la
arquitectura acadmica y en su obstinacin por llamar arquitectura a lo que slo es diseo.
Todava se est por elaborar una apreciacin honesta y ordenada de las dificultades enfrentadas por la
disciplina. Algunas de ellas son menos del orden de la calidad conceptual que fruto de los rigores del
mercado: por ejemplo, la escasa penetracin de los ADLs a despecho de las limitaciones expresivas de los
lenguajes de modelado que compiten con ellos, o la escasa atencin que la industria concede prestarle a los
mtodos verdaderamente formales por poco que su utilizacin exija el dominio de una notacin complicada.
Pero a pesar que los ADLs o los mtodos formales no han logrado abrirse camino, la arquitectura del
software en su conjunto s lo ha hecho, aunque la imagen que el pblico tenga de ella pueda en algn
sentido sospecharse espuria, o estar contaminada por ideas difusas referidas a metodologas o herramientas
no necesariamente arquitectnicas. Con toda seguridad, hay muchos elementos para discutir sobre este
punto.
Relevancia de la Arquitectura de Software

Aunque todava no se ha constituido un repositorio uniformizado de estudios de casos en base al cual se
pueda extraer una conclusin responsable, la arquitectura del software ha resultado instrumental en un
nmero respetable de escenarios reduciendo costos, evitando errores, encontrando fallas, implementando
sistemas de misin crtica. Cada uno de los documentos que describen lenguajes de descripcin
arquitectnica, por ejemplo, subraya su utilizacin exitosa en proyectos de gran envergadura requeridos por
organizaciones de gobierno o por grandes empresas. An cuando aqu y all se sealen dificultades
ocasionales, nadie duda de la necesidad de una visin arquitectnica. Escribe Barry Boehm, especialista
mximo en gestin de riesgo y bien conocido creador del COCOMO y del mtodo de desarrollo en espiral:
Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su justificacin, el proyecto no debe
empezar el desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la
puede usar a lo largo de los procesos de desarrollo y mantenimiento [Boe95].
Antes que transcribir listas de ideas que a veces coinciden y otras sealan caractersticas heterogneas,
sintetizaremos las virtudes de la arquitectura del software articulando las opiniones convergentes de los
expertos [CN96] [Gar00]:
2. Decisiones tempranas de diseo. La arquitectura del software representa la encarnacin de las decisiones
de diseo ms tempranas sobre un sistema, y esos vnculos tempranos tienen un peso fuera de toda
proporcin en su gravedad individual con respecto al desarrollo restante del sistema, su servicio en el
despliegue y su vida de mantenimiento. La arquitectura representa lo que el mtodo SAAM una puerta de
peaje: el desarrollo no puede proseguir hasta que los participantes involucrados aprueben su diseo.
3. Restricciones constructivas. Una descripcin arquitectnica proporciona blueprints parciales para el
desarrollo, indicando los componentes y las dependencias entre ellos. Por ejemplo, una vista en capas de
1. Comunicacin mutua. La arquitectura del software representa un alto nivel de abstraccin comn que la
mayora de los participantes, si no todos, pueden usar como base para crear entendimiento mutuo, formar
consenso y comunicarse entre s. En sus mejores expresiones, la descripcin arquitectnica expone las
restricciones de alto nivel sobre el diseo del sistema, as como la justificacin de decisiones arquitectnicas
fundamentales.
33
una arquitectura documenta tpicamente los lmites de abstraccin entre las partes, identificando las
principales interfaces y estableciendo las formas en que unas partes pueden interactuar con otras.
4. Reutilizacin, o abstraccin transferible de un sistema. La arquitectura del software encarna un modelo
relativamente pequeo, intelectualmente tratable, de la forma en que un sistema se estructura y sus
componentes se entienden entre s; este modelo es transferible a travs de sistemas; en particular, se
puede aplicar a otros sistemas que exhiben requerimientos parecidos y puede promover reutilizacin en
gran escala. El diseo arquitectnico soporta reutilizacin de grandes componentes o incluso de frameworks
en el que se pueden integrar componentes.
5. Evolucin. La arquitectura del software puede exponer las dimensiones a lo largo de las cuales puede
esperarse que evolucione un sistema. Haciendo explcitas estas paredes perdurables, quienes mantienen
un sistema pueden comprender mejor las ramificaciones de los cambios y estimar con mayor precisin los
costos de las modificaciones. Esas delimitaciones ayudan tambin a establecer mecanismos de conexin que
permiten manejar requerimientos cambiantes de interoperabilidad, prototipado y reutilizacin.
6. Anlisis. Las descripciones arquitectnicas aportan nuevas oportunidades para el anlisis, incluyendo
verificaciones de consistencia del sistema, conformidad con las restricciones impuestas por un estilo,
conformidad con atributos de calidad, anlisis de dependencias y anlisis especficos de dominio y negocios.
7. Administracin. La experiencia demuestra que los proyectos exitosos consideran una arquitectura viable
como un logro clave del proceso de desarrollo industrial. La evaluacin crtica de una arquitectura conduce
tpicamente a una comprensin ms clara de los requerimientos, las estrategias de implementacin y los
riegos potenciales.
Una de las demostraciones ms elocuentes de la capacidad de la arquitectura del software como

herramienta de decisin de diseo y evaluacin de estilos es el tour de force de Mary Shaw y David Garlan
[SG96] en el que comparan una misma solucin de indexacin de palabras claves en cuatro estilos diferentes
(datos compartidos, tubera y filtro, tipos abstractos de datos e invocacin implcita).
El estudio articula un modelo que permite estimar relaciones de dependencia, modularidad, refinamiento,
reutilizacin, ventajas y desventajas de cada arquitectura antes de escribir una sola lnea de cdigo;
demuestra tambin de qu manera los diferentes estilos definen tcticas especficas de descomposicin
funcional y establecen la pauta que habr de seguirse en el desarrollo.
La arquitectura del software se encuentra, reconocidamente, en una etapa an formativa. Sus tericos no se
encuentran todava en condiciones de asegurar (como lo hacan los Tres Amigos) que con este libro como
gua, usted podr producir, dentro de un plan predecible y un presupuesto ms razonable, el software de la
ms alta calidad posible: una clase de alegacin que llev a Aron Trauring a lamentar que no hubiese algo
as como una FDA que fiscalice los mensajes publicitarios de los metodlogos. Por el contrario, los mejores
entre los arquitectos consideran que su disciplina es tentativa y que se encuentra en estado de flujo. Pero
aunque lo que resta por hacer es formidable, con lo que se lleva hecho ya hay un enorme repertorio de
ideas, experiencias e instrumentos que ayudan a pensar de qu manera, aqu y ahora, se pueden mejorar las
prcticas.
Finalmente, Shaw y Garlan aplican diversas tablas de comparacin de atributos, en un ejercicio de

evaluacin de decisiones estilsticas que se ha convertido en un modelo en su gnero [Pfl02: 279-283]. Si
hubiera que singularizar un trabajo simple y elegante, representativo del estado de arte de la teora y la
prctica de la arquitectura del software, sin duda escogeramos esta demostracin cabal, a treinta aos de
distancia, de que Dijkstra tena razn.
34
MTODOS DE MODELADO
UNIDAD II
35
MTODOS DE MODELADO DE SOFTWARE

El modelo de desarrollo de software se compone de una mezcla de varios elementos, entre los que se
encuentran la filosofa, el modelo de negocio, y el licenciamiento. Ni la calidad ni el desempeo dependen
del modelo.
CONCEPTO DE MODELO
Se ha propuesto, igualmente, que un modelo es una estructura conceptual que sugiere un marco de ideas
para un conjunto de escripciones que de otra manera no podran ser sistematizadas. De esta manera, su
estructura es diferente de la que se supone existe en el conjunto de fenmenos de la naturaleza. El modelo
concebido en esta forma, impulsa la inteligibilidad y ayuda a la comprensin de los fenmenos, ya que
proporciona los canales de interconexin entre hechos que sin la existencia de los lazos inferenciales,
podran permanecer aislados e independientes unos de otros.
Otra versin del concepto de modelo es aquella que lo define como una serie de realizaciones que sirven
durante una poca de ciencia normal para definir problemas y mtodos legtimos en un campo especfico de
investigacin. Es en estas realizaciones en las que se forman generaciones sucesivas de futuros practicantes.
Considero dos puntos importantes para modelar sistemas informticos:
Estructurado
Orientado a objetos
ANLISIS ESTRUCTURADO
Los primeros trabajos entre los 60s y 70s

Como complemento del Diseo Estructurado
Difundido por DeMarco, Gane y Sarson
El mtodo se centraba en aplicaciones de sistemas de informacin
No proporcionaba adecuada notacin para aspectos de control y de comportamiento para
problemas de tiempo real
Describir lo que requiere el cliente

Establecer una base para la creacin del diseo del software
Definir un conjunto de requerimientos que puedan ser validados una vez que se construya el
software
Objetivos:
36
Elementos:
Diccionario de datos: contiene definiciones de todos los objetos de datos consumidos y producidos
por el software
Diagramas entidad-relacin para el modelado de datos
Diagramas de flujo de datos:
o Para indicar cmo se transforman los datos conforme avanzan en el sistema
o Para representar las funciones que transforman el flujo de datos
Diagrama de transicin de estados:
o Indica cmo se comporta el sistema como consecuencia de sucesos externos
o Representa los diferentes modos de comportamiento (estados) del sistema y la
manera en que se realizan las transiciones.
o Es la base del modelado de comportamiento
A qu responde el modelo de datos:
Cules son los objetos de datos primarios que va a procesar el sistema?

Cmo est compuesto cada objeto de datos y qu atributos describe el objeto?
Cul es la relacin entre los objetos y los procesos que los transforman?
Para identificar:
Objetos de datos
Estructura de los objetos
Asociaciones entre los objetos
Ubicacin de los objetos
Especialmente til cuando los datos y las asociaciones que los gobiernan, son complejos y estudia los datos
independientemente de los procesos que los transforman
Se utiliza para:
Examinar los datos en el contexto de una aplicacin de procesamiento de datos

Desarrollar una parte del modelo de anlisis
Adicionalmente, para el diseo de las bases de datos
Representacin de cualquier composicin de informacin compuesta que deba gestionar el

software
Todo aquello que genera informacin
Personas, lugares, eventos, objetos,
Esta composicin se refleja mediante el conjunto de atributos o propiedades diferentes entre s
Pueden ser internos o externos, generando y/o consumiendo informacin para/de el sistema
Estructura del objeto
Encapsula datos, NO operaciones (no es OO)

Puede ser representada de forma matricial encabezado-cuerpo
Cada atributo define una propiedad
Cada atributo puede ser usado para:
Objeto de datos
37
o
o
o
Nombrar una ocurrencia del objeto de datos (Cdigo de llave primaria)

Describir la ocurrencia del objeto (Nombre, Direccin)
Referenciar a una ocurrencia en otro objeto (Cdigo de llave externa)
Atributos
El conjunto adecuado de atributos para un objeto se determina segn el contexto:
Relaciones
o Conexiones entre los objetos de datos.
o Los pares objeto-relacin tambin dependen del contexto
o Son bidireccionales
o Deben ser relevantes para el sistema
Cardinalidad:
o Nmero de ocurrencias de objetos que se dan en una relacin
o Especializacin del nmero de ocurrencias de un objeto que se relaciona con ocurrencias de
otro objeto
o Define el nmero mximo de conexiones de objetos que pueden participar en una asociacin
o Tipos:
1:1
1:n
m:n
Modalidad:
o
o
0: si no hay necesidad explcita de que ocurra una relacin, o que sea opcional
1: si una ocurrencia es obligatoria
38
Diagrama Entidad-Relacin
o Propuesto originalmente por Peter Chen (1977) para el diseo de sistemas de bases de
datos relacionales
o Componentes primarios: objetos de datos, atributos, asociaciones, jerarquas e
indicadores de tipo, asociados mediante una notacin grfica
o Mecanismo que representa la facilidad de asociacin entre objetos
o Es mejor generarlo de manera iterativa
MODELADO FUNCIONAL Y FLUJO DE INFORMACIN
Diagrama de Flujo de Datos (DFD)
No es procedimental
Muestra el flujo de datos
No permite representar secuencias, condiciones ni bucles
No es un diagrama de flujo (flujograma)
Es posible crear un modelo de flujo para cualquier sistema de computador, independientemente del tamao
y de la complejidad donde el anlisis estructurado es una tcnica de modelado del flujo y del contenido de la
informacin
39
Puede representar un sistema o software a cualquier nivel de abstraccin

A menor nivel de abstraccin, mayor detalle funcional
Diagrama de Flujo de Datos (DFD)
El DFD de nivel 0 es el Diagrama de Contexto

En el Nivel 0 no se diagraman los almacenamientos
Un modelo consistente presentar continuidad en el flujo de informacin:
o Entre los niveles i e i+1 debe haber punto de conexin tanto para entradas cuanto para
salidas
La notacin bsica del DFD no es suficiente para describir los requerimientos del software
AMPLIACIONES
Para describir el contenido de los objetos de datos que viajan en el flujo, se recurre al Diccionario de Datos
La notacin del DFD puede ser ampliada con texto descriptivo, mediante una Especificacin de proceso (EP)
Describe la entrada de la funcin, el algoritmo que aplica, y la salida que produce.

Indica las restricciones y limitaciones impuestas al proceso, las caractersticas de rendimiento y las
restricciones de diseo que pudieran influir en la forma de implementar el proceso.
Para sistemas de tiempo real:

El flujo de informacin es recogido o producido de forma continua en el tiempo
La informacin de control que pasa por el sistema y el procesamiento de control asociado
Mltiples ocurrencias de la misma transformacin que se encuentran en situaciones de multitarea
Estados del sistema y mecanismos que producen transiciones de estado
Procesar eventos
Entrada / Salida continua de datos
Flujos y procesos de control
Almacenamientos de control
Otro ejemplo respecto del flujo de datos:
40
MODELADO DEL COMPORTAMIENTO

Slo ciertas versiones del Anlisis Estructurado proporcionan notacin para modelar el comportamiento
Diagrama de transicin de estados:
Estados posibles en el sistema

Eventos que generan un cambio de estado
Acciones (procesos) realizadas como consecuencia de un evento
Estado:
Modo observable de comportamiento
Los rectngulos representan los estados del sistema, Las flechas representan transiciones entre estados y
cada flecha est etiquetada con dos textos dispuestos como fraccin:
Superior: suceso(s) que originan la transicin

Inferior: accin(es) que se producen en consecuencia
DICCIONARIO DE DATOS
Es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con
definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una
misma comprensin de las entradas, salidas, componentes de los almacenes y de los clculos
intermedios
Usualmente se crean y mantienen mediante herramientas CASE.
Contenido bsico:
Proporciona una manera organizada de representar las caractersticas de cada objeto de datos y elemento
de control, tambin maneja una gramtica casi formal para describir el contenido de los objetos
41
Nombre: del elemento de datos o control, almacn de datos o entidad externa

Alias: otros nombres (ms descriptivos)
Dnde/cmo se usa: listado de procesos que llaman al elemento, y cmo lo usan (como entrada, salida,
almacenamiento, etc.)
Descripcin del contenido: con una notacin
Informacin adicional: valores por omisin, restricciones, rangos, etc.
Notacin para describir el contenido:
La notacin permite representar una composicin de datos en una de tres formas:
Como una secuencia de elementos de datos

Como una seleccin de entre un conjunto de elementos de datos
Como una agrupacin repetitiva de elementos de datos
Ejemplo:
Nm. telefnico = prefijo pas + cdigo rea + nmero + extensin
Caractersticas a cumplir:
Consistencia de las denominaciones (controlada por el CASE)
Dnde / cmo se usa: registro automtico a partir de los modelos de flujo. La referencia cruzada
permite conocer
o
o
o
Los objetos que llaman al elemento

Los objetos llamados por el elemento
El impacto de un posible cambio
42
CASO DE ESTUDIO MODELADO ESTRUCTURADO

SISTEMA DE VOTACIN ELECTRNICO
La tecnologa se ha convertido en la actualidad en un elemento clave para llevar adelante tanto la
administracin, la organizacin como la realizacin del proceso electoral. Es esencial para la logstica de las
elecciones modernas a gran escala.
Ms an, su apropiada aplicacin, permite aumentar la eficiencia administrativa, reducir los costos a largo
plazo y fortalecer la transparencia poltica.
Todo ello sin perder de vista tres objetivos fundamentales:
-
Respetar el voto, libre, igual, secreto y directo
Lograr una mayor participacin de los estudiantes.
Garantizar la transparencia de los actos comiciales.
En su gran mayora, las universidades han incorporado tecnologa en las distintas etapas de este proceso
(por ejemplo, hace tiempo que los padrones electorales, o registros electorales, se confeccionan a partir de
una base de datos computarizada) y continan hacindolo, particularmente, en lo que se refiere a la
transmisin y el procesamiento de los resultados.
Descripcin de la institucin
La Universidad Nacional de Loja, es una Institucin de Educacin Superior, laica, autnoma, de derecho
pblico, con personera jurdica y sin fines de lucro, de alta calidad acadmica y humanstica, que ofrece
formacin en los niveles: tcnico y tecnolgico superior; profesional o de tercer nivel; y, de postgrado o
cuarto nivel; que realiza investigacin cientfico-tcnica sobre los problemas del entorno, con calidad,
pertinencia y equidad, a fin de coadyuvar al desarrollo sustentable de la regin y del pas, interactuando con
la comunidad, generando propuestas alternativas a los problemas nacionales, con responsabilidad social;
reconociendo y promoviendo la diversidad cultural y tnica y la sabidura popular, apoyndose en el avance
Planteamiento del Problema

Actualmente, en la gran mayora de los departamentos de la Universidad de Loja se administra el proceso de
eleccin de dignidades de forma manual.
cientfico y tecnolgico, en procura de mejorar la calidad de vida del pueblo ecuatoriano.
43
Los votantes acuden a la institucin en la convocatoria de elecciones y se registran en un listado impreso a

cargo de uno o varios colaboradores del proceso. Al ser validados en los listados de afiliados autorizados
para ejecutar su derecho al voto, reciben una papeleta impresa que comprende las listas, dignidades y
candidatos a ser elegidos por los concurrentes.
Una vez que el sufragante realiza su votacin, deposita la papeleta en las urnas elaboradas para el proceso.
Todos los votos de los concurrentes son recolectados por los colaboradores del proceso, y posteriormente
son contados de manera manual con el fin de obtener los ganadores.
El conteo de concurrentes tambin se elabora de forma manual mediante le conteo de asistentes en los
listados de afiliados.
Los antecedentes mencionados anteriormente, denotan la naturaleza manual de los controles que se
aplican sobre el proceso de elecciones, el cual con el fin de garantizar de forma adecuada los principios
fundamentales del voto, deben ser automatizados con el fin de disminuir la incidencia de controles
manuales sobre el proceso y optimizar los procedimientos de conteo de votos y de verificacin de los ndices
de sufragantes. Adems, al ser un proceso manual, existen demoras en el tiempo de ejecucin del proceso y
por ende en la calidad en la atencin a los sufragantes que se acercan a ejercer su derecho al voto.
Adems las universidades de la ciudad de Loja administran el proceso de eleccin de dignidades de forma
manual.
Los votantes acuden a la institucin en la convocatoria de elecciones y se registran en un listado impreso a
cargo de uno o varios colaboradores del proceso. Al ser validados en los listados de afiliados autorizados
para ejecutar su derecho al voto, reciben una papeleta impresa que comprende las listas, dignidades y
candidatos a ser elegidos por los concurrentes.
Solucin Propuesta
En base a la urgente necesidad de automatizar los diferentes procesos de electorales, se propone la
construccin del Sistema de Votacin Electrnico.
implementacin de una administracin automtica de los sufragantes, listas, dignidades, candidatos y de la

recopilacin de los votos en si. Adems, al realizar el proceso de forma automtica se realizara un conteo
automtico de los votos lo cual podr ser corroborado por un proceso de conteo manual de las papeletas
impresas del sistema que reflejan los resultados almacenados en el mismo.
Mediante el sistema propuesto, el proceso electoral se efectuar de una forma ms eficiente, mediante la
44
DICCIONARIO DE DATOS
Sistemas de votacin electrnica que haga uso de la huella digital para los procesos de elecciones
estudiantiles dentro de la universidad, posteriormente reporte los resultados del sufragio.
ESTUDIANTE =
Cdula + Apellidos + Nombres+ Direccin + Telfono + Email + sexo, password,

fecha_nacimiento, fecha_ingreso, fecha_actualizacion, huella_biometrica
{ROLES, codigo_rol}
CONFIGURAR_ELECCIONES =
cdigo_configuracion_elecciones, periodo, tipo_eleccion,

nombre _eleccin, descripcin_eleccion, periodo_votacion,
ROLES
= cdigo_rol, nombre, descripcin
PARTIDO
= cdigo_partido, sigla, nombre_partido, logo_partido,
TIPO_VOTO
= codigo_voto, voto_nombre
DIGNIDAD
=codigo_dignidad, nombre_dignidad
CANDIDATO
= cdigo_candidato, dignidad, fecha_registro, foto,

huella_biometrica, {PARTIDO, cdigo_partido}, {DIGNIDAD, cdigo_dignidad}
PADRN_ELECTORAL = cdigo, nombre,{PARTIDO, cdigo_partido}

VOTACIN
= fecha, hora, {ESTUDIANTE, cedula},{PARTIDO, cdigo_partido},

{TIPO_VOTO, codigo_voto}
ACCESO_SISTEMA
= {ROLES, codigo_rol}, {ESTUDIANTE, cedula}, fecha, hora
DESCRIPCIN DE ENTIDADES:
ESTUDIANTE, informacin con respecto del estudiante

CONFIGURAR, permite registrar los aspectos de los sufragios
ROLES, el papel de quienes intervienen en el proceso de votacin
PARTIDO, las listas pos las cuales el estudiante puede votar
TIPO_VOTO, registra si son votos blancos, nulos y validos
CANDIDATO, los estudiantes que postulan por una dignidad de una lista como presidente, vicepresidente.
DIGNIDAD, son los representaciones que asumira el estudiantiles cuando que se eligen para los estudiantes
PADRN_ELECTORAL, se refiere a todos los estudiantes que son aptos para votar y las listas calificadas para
el proceso de sufragio
VOTACIN = registro de los votos por partido, estudiante, fecha y hora en que realiza el sufragio
ACCESO_SISTEMA, registro de quienes accede al sistema y que rol lo ingresan
45
DICCIONARIO DE DATOS DETALLADO

Entidad: votacin
Campo
id_votacion
id_usuario
id_configura_eleccion
fecha_hora
id_gd_tipovoto
Descripcin
Almacena el cdigo de la votacin
Cdigo del usuario
Cdigo de la configuracin de la eleccin
Almacena la fecha y la hora de la votacin
Indica el tipo de voto que sea a realizado en la
votacin
Entidad: configura_eleccin
Campo
id_periodo
id_g_entidad
id_gd_entidad
nombre_eleccin
descripcion_eleccion
fecha_eleccion
hora_inico
hora_fin
estado
Descripcin
Almacena el cdigo de la configuracin de la eleccin
Cdigo del periodo
Almacena el cdigo de la entidad
Almacena el grupo de detalle de la entidad
Indica un nombre corto de la eleccin
Descripcin larga de la eleccin
Indica la fecha q se efecta la eleccin
Indica la hora que inicia la eleccin
Indica la hora que finaliza la eleccin
Indica el estado de la configuracin de la eleccin
Entidad: padrn_electoral
Campo
id_usuario
id_padron_electoral
fecha_registro
disponible
estado
Descripcin
Cdigo de la configuracin de la eleccin
Cdigo de el usuario
Almacena el cdigo del padrn electoral
Almacena la fecha de registro en el padrn electoral
Indica si el padrn esta disponible
Indica el estado del registro del padrn electoral
Entidad: candidato
46
Campo
id_candidato
id_dignidad_candidato
id_usuario_postulante
Fecha
Foto
mostrar_papeleta
id_partido
id_usuario
Descripcin
almacena el cdigo del candidato
Almacena la dignidad que el candidato postula
Indica el la postulacin del usuario
Fecha en el que el candidato se inscribe
Almacena la ruta donde se encuentra guardada la foto
del candidato
Indica si el candidato debe mostrarse en la papeleta
de votacin
Almacena el cdigo del partido poltico
Almacena el cdigo del usuario
Almacena el cdigo de la configuracin de la eleccin
Entidad: usuario
Campo
id_usuario
id_grupo_detalle
Identificacin
id_gd_rol
id_g_entidad
id_gd_entidad
id_gd_tipoidentificacion
Apellido
Nombre
Password
fecha_ingreso
fecha_actualizacion
Estado
Descripcin
Cdigo del usuario.
Almacena la identificacin del usuario
Almacena el rol del usuario
Almacena descripcin de entidades
Almacena la el detalle de las entidades descritas
Almacena el tipo de identificacin del usuario
Almacena el nombre del usuario
Almacena el nombre del usuario
Almacena la password del usuario
Almacena la fecha del ingreso del usuario
Almacena la fecha de actualizacin de datos del
usuario
Estado del registro del usuario
NOTA:
Cada entidad descrita en la solucin del problema debe ser descrita a detalle y para li cual se debe hacer uso
de una herramienta CASE
47
MODELO ENTIDAD RELACIN

Modelado de Entidades Relacin - ER
Se considera las entidades con nomenclatura para especificar la pertenencia lgica de estas a un
paquete.
1.
48
Modelado fsico de Base de Datos Relacional
2.
49
DIAGRAMA DE FLUJO DE DATOS - DFD

Nivel 0
Sistemas de votacin electrnica que haga uso de la huella digital para los procesos de elecciones
estudiantiles dentro de la universidad, posteriormente reporte los resultados del sufragio.
DIAGRAMA DE CONTEXTO (NIVEL 0)
Administrador
Alumno
Indentificacion biometrica
Indentificacion biometrica
sufraga
Consulta sus datos
empadronamieno
Administracion de elecciones
Votacion
bioelectronica
Resultados de las elecciones
Entrega comprobantede votacion
Postula a una dignidad

Inscribe en un partido politico
Candidato
Nomenclatura:
50
Nivel 1
Alumno
Registro de HUELLAS
1
Ingresa
Registro de HUELLA DIITAL
Ingreso
pantalla de
ininco del
sistema
Ingresa
HUELLA DIITAL
Autenticacion
Dactilar
[ADMINISTRADOR]
Administrador
[ALUMNO]
Registra
ALUMNO
ADMINISTRADOR
10
Datos de alumno
Administration
de
Usuarios
Datos alumno a postulado

Configuro proceso de votacion
4
7
Datos registrados
Empadronamient
o y papeletas
electorales
Administracion
de Candidaturas
Administracion
de periodos de
votacion
Genero
Datos del alumno
ALUMNO
Habilito
Configuracion
de Elecciones
establecio
Validacion de datos habilitados
CANDIDATO
Datos del cadidato
8
Certificado de votacion
Datos de candidato
[ CANDIDATO ]
Sufragio
6
Datos sufragados
Adminsitracion
de partidos
politicos
Datos de los comicios
VOTOS
Presenta resultados de ganadores
Datos del alumno
Datos de alumno
ALUMNO
9
Resultado de los
comicios
electorales
Resultados de ganadores
ALUMNO
Datos de Partido Politico
PARTIDO POLITICO
CANDIDATO
Sufraga
51
ARQUITECTURA DE SOFTWARE FINAL
Tcnica de conversin de requerimientos en diseo se debe considerar conceptos de diseo

basados en:
Modularidad
Diseo descendente
Programacin estructurada (secuencia-condicin-bucles)
La transformacin del DFD a la arquitectura de software se considera:
Descomposicin por refinamientos sucesivos
Creacin de una jerarqua modular
Elaboracin de mdulos independientes
Pasos:
1. Establecer el tipo de flujo de informacin
2. Indicar los lmites del flujo
3. Convertir el DFD en la estructura del programa
4. Definir la jerarqua de control
5. Refinar la estructura usando medidas y heursticas de diseo
6. Refinar y elaborar la descripcin arquitectnica
FLUJO DE TRANSFORMACION
Este esquema nos permite buscar el flujo de entrada y el centro de transformacin que puedes varios y
finalmente los flujos de salida.
52
Es un conjunto de pasos de diseo que permiten convertir un DFD tipo transformacin en un estilo
arquitectnico especfico en funcin de nuestro DFD nivel 1 y los requisitos del software
1.
2.
3.
4.
Revisar y refinar los DFD del software

Refinar a n niveles de detalle, hasta que la cohesin en las transformaciones es alta: el
proceso realiza slo una funcin y puede ser especificado como mdulo
Determinar si el DFD es de transformacin o de transaccin
Aislar el centro de transformacin especificando los lmites de los flujos de entrada y salida
Realizar la descomposicin de segundo nivel (convierte las transformaciones individuales del DFD
en mdulos, subordinados a la estructura del software)
Se pueden combinar varias burbujas para representarlas como un solo mdulo
(considerando problemas potenciales de cohesin), o una sola burbuja puede dividirse en
2 o ms mdulos
A ms del nombre, el mdulo debe tener un texto que describa:
La informacin de entrada y de salida (descripcin de la interfaz)
La informacin retenida en el mdulo (datos almacenados)
Una descripcin procedimental que indique los principales puntos de decisin y
las tareas
Pequeo estudio de las restricciones y caractersticas especiales
Se refinar la estructura inicial de la arquitectura utilizando heursticas para mejorar la calidad del software
53
1
Ingresa
Ingreso
pantalla de
ininco del
sistema
Ingresa
Autenticacion
Dactilar
[ADMINISTRADOR]
[ALUMNO]
Registra
10
Datos alumno a postulado
Administration
de
Usuarios
Datos de alumno
Configuro proceso de votacion
4
7
Datos registrados
Empadronamient
o y papeletas
electorales
Administracion
de Candidaturas
Habilito
Configuracion
de Elecciones
establecio
Administracion
de periodos de
votacion
Genero
Datos del alumno

Sufraga
Datos del cadidato
8
Datos de candidato
[ CANDIDATO ]
Resultado de los
comicios
electorales
Sufragio
6
Datos sufragados
Adminsitracion
de partidos
politicos
Presenta resultados de ganadores
Datos del alumno
Datos de alumno
Datos de Partido Politico
Los procesos en rojo son identificados como puntos de transformacin

Transformar el DFD en una estructura de programa adecuada al procesamiento de la transaccin
El flujo de transaccin se convierte en una arquitectura con una rama de entrada y una
rama de distribucin
Iniciando con el centro de transaccin, las burbujas en el camino de entrada pasan a ser
mdulos
El centro de transaccin se convierte en un mdulo distribuidor
5.
54
As tendramos:
1
Ingreso
pantalla de
ininco del
sistema
Ingresa
2
Autenticacion
Dactilar
Registra
10
[ADMINISTRADOR]
Administration
de
Usuarios
Datos de alumno
4
7
Ingresa
Empadronamient
o y papeletas
electorales
3
establecio
Administracion
de Candidaturas
Configuracion
de Elecciones
Habilito
Administracion
de periodos de
votacion
[ CANDIDATO ]
6
Datos del cadidato
Adminsitracion
de partidos
politicos
Sufragio
Datos del cadidato
9
Resultado de los
comicios
electorales
7.
Aislando los a nivel modular: Descomponer y refinar la estructura de transaccin y la estructura de

todos los caminos de accin, aplicando el anlisis de transformacin o de transaccin
Refinar la primera arquitectura del programa utilizando heursticas de diseo para mejorar la
calidad del software. Considerar:
Independencia
Conveniencia (eficacia de implementacin y prueba)
Facilidad de mantenimiento
Bajo acoplamiento
Alta cohesin
Absorcin (Fan-In): nmero de superordinados inmediatos del mdulo. Conviene
maximizarlo durante el diseo, pues indica que no se duplica cdigo
Diseminacin del control (Fan-Out): nmero de subordinados inmediatos del mdulo.
Preferible de moderado a bajo.
6.
55
ARQUITECTURA DE SOFTWARE FINAL
Sistema de
Votacion
electronica
10
Administration
de
Usuarios
Configuracion
de Elecciones
Ingreso
pantalla de
ininco del
sistema
Sufragio
7
5
Autenticacion
Dactilar
Empadronamient
o y papeletas
electorales
Administracion
de Candidaturas
Administracion
de periodos de
votacion
Adminsitracion
de partidos
politicos
9
Resultado de los
comicios
electorales
56
OBTENCIN DE REQUISITOS
Enfoque basado en el anlisis de porte y modelos i*
El presente temario se centra en la experiencia prctica en sistemas de software que involucran complejidad
internacional por la naturaleza comercial distinta centrada en componentes y como resultado se obtiene
arquitecturas hbridas en los sistemas de informacin.
Para este punto considero un caso de estudio donde se aprecia la construccin de este tipo de sistemas que
se caracteriza por la participacin de sistemas legados que fueron desarrollados por la empresa en forma
separada y en lenguajes licenciados y no licenciados que se integran con algn software a la medida que
toma en cuenta aspectos tecnolgicos. La correcta aplicacin de este enfoque requiere la identificacin de
los servicios que el sistema deber brindar y su agrupacin en dominios atmicos que son los actores del
sistema, que posteriormente sern remplazados por componentes apropiados e independientes de su
naturaleza y origen.
El presente trabajo se considera como punto de partida las 5 fuerzas de Michael Porter y luego se
caracterizan los aspectos metdicos con la utilizacin de modelos i*, que permite identificar los actores del
sistema y su estructuracin arquitectnica para aplicaciones de negocios.
Introduccin
En la presente realizo un caso prctico de la empresa TECNEGIN
S.A., se le aplicar las cinco fuerzas de Porter y la cadena de valor
para la identificacin de los actores, se considera tambin
aspectos que se analicen los objetivos del modelo i*.
Los criterios de Michael Porter se pueden usar en el anlisis de los modelos de negocios donde a travs de 2
artefactos tiles como las Cinco Fuerzas de Porter, que nos servirn para la identificacin del actores del
entorno empresarial y cmo afecta al desempeo de la misma segn las dependencias existentes con la
empresa, y finalmente la Cadena de Valor que ser la base para la identificacin de los objetivos
estratgicos de las empresas al permitir seleccionar estos objetivos como pasos a realizar por cada una de
las actividades pertenecientes a la cadena de valor de una empresa.
TECNEGIN S.A.
Tecnologa en negocin innovadores enfocado en tecnologa web para la publicidad de bienes inmuebles,
vehculos, anuncios en general, ventas de computadores y la colocacin de personal. Los objetivos
fundamentales de la empresa es la masificacin de los servicios de publicidad y venta de productos a las
clases sociales medias y bajas mediante uso de las formas de pago a crdito y que no se prescindible el uso
de tarjetas de crdito para los pagos en lnea.
57
Modelado i*
Para el modelado del caso de estudio se considera aspectos del mtodo DHARMA, haciendo uso de
diagramas i*, que permite identificar la arquitectura de un sistema basado en componentes de la empresa
TECNEGIN S.A. Pues en la actualidad las nuevas formas de hacer negocio se centran en la gama de servicios
que cruzan informacin a travs de sistemas de software que integran componentes de software de
diferente naturaleza y orgenes (Arquitecturas Hbridas).
Los componentes de software utilizados en este enfoque arquitectnico incluyen componentes
desarrollados por la empresa, generalmente conocidos como componentes comerciales (Off-The-Shelf
OTS), uno que otro componente gratuito o de cdigo abierto (FOSS) y finalmente servicios Web en .Net
para la integracin de todos estos componentes de software desarrollado por la empresa y pequeos
sistemas legados. Los sistemas fueron construidos de manera oportunista e independientes con bajo
grado de acople, considerando el entorno y la estrategia organizacional, de tal forma que los componentes
desarrollados a la medida y por separado con la idea es realizar posteriormente un integrador de los
OTS/FOSS e interactuar de manera transparente con los usuarios y los recursos.
La especificacin de requisitos, la seleccin de los componentes requeridos, y su adaptacin e integracin en

una arquitectura comn, son algunos de los problemas que son motivo del presente caso de estudio, para
descubrir e identificar las necesidades estratgicas que el sistema requerir en primer lugar, se toma en
cuenta el descubrimiento de los servicios especficos (asociados a dichas necesidades) y que el sistema
deber brindar; as como la agrupacin de los servicios relacionados en dominios atmicos que estructuran
la arquitectura genrica del sistema, finalmente describir la funcionalidad mnima que debe ser cubierta por
cada uno de los componentes que lo integraran.
El objetivo del modelado en i* propone es el uso de dos tipos de modelos SD y SR los cuales hacen uso de la
notacin que se muestran en la figura 6.
Al modelado i* le corresponden dos niveles de abstraccin:
Modelos de Dependencias Estratgicas (SD)- nivel intencional

Consiste en nodos (actores), dependencias (relaciones) indicando si un elemento intencional puede
ser un recurso, una tarea (considerada una actividad), un objetivo (requisito funcional) o un
objetivo blando (requisito no funcional). Tambin es posible definir la importancia de la
dependencia para cada uno de los actores involucrados utilizando tres categoras: abierta,
comprometida o crtica.
Modelos de Racional Estratgico (SR) - nivel racional.
Permite visualizar los elementos intencionales en la frontera de un actor a fin de refinar el modelo
SD con capacidades de razonamiento. Las dependencias del modelo SD estn vinculadas a
elementos intencionales dentro de la frontera del actor.
En el caso de estudio se considera el modelado i*, considerando nicamente el modelo de dependencias

estratgicas (SD).
58
FIGURA 2. NOTACIN PARA I*
Identificacin de actores del entorno organizacional basada en el modelo de porter

El modelo de las Cinco Fuerzas de Porter permite determinar las consecuencias de la rentabilidad a largo
plazo, por medio de la evaluacin de sus objetivos y recursos con las cinco fuerzas que rigen la
competitividad de manera que el objetivo de este mtodo no es el de identificar la arquitectura final del
sistema, en la que los actores representan subsistemas directamente mapeables a componentes OTS que
cubre los servicios y otros que no pueden ser cubiertos por componentes existentes, requiriendo de algn
desarrollo a la medida. Para esto es necesario un mtodo concebido en cuatro actividades de las cuales se
realizaran tres y que pueden ser iteradas o intercaladas:
Modelado del entorno del sistema. Determinar el sistema de la organizacin sea puro o un hbrido que
incluye componentes de software, hardware con software embebido y el impacto que ste tendra en
relacin a los elementos en el entorno de la misma con el objeto de terminar cules pueden ser satisfechas
directamente por el sistema, y cules son necesarias para que este mantenga su operacin.
Descomposicin de los objetivos del sistema. El sistema es detallado y descompuesto en una jerarqua de
objetivos necesarios para satisfacer las dependencias estratgicas con su entorno para interactuar con los
actores.
Modelado del entorno de la organizacin. La organizacin y su modelo de negocio son estudiados en

detalle mediante el modelo de Michael Porter a fin de identificar el rol de los actores en relacin a su
entorno y luego representarlos con modelos i* de dependencias estratgicas (SD).
59
Identificacin de actores del sistema. Los objetivos incluidos en el modelo SR de sistema son analizados y
agrupados en actores que representan dominios atmicos bien definidos en base a la direccin de las
asociaciones medio-fin existente entre los objetivos incluidos en cada uno de ellos usando taxonomas de
dominios.
Conforme se detallan las distintas dependencias genricas identificadas en relacin a cada uno de los actores
genricos de entorno se usar una nomenclatura especial para indicar a qu tipo de dependencia pertenece
cada una de las identificadas, la G corresponde a un objetivo, SG representa un objetivo blando, R para los
recursos y finalmente T para tareas (ver Tabla 1).
Primera fuerza: COMPETIDORES

La determinacin de las empresas competidoras es un factor que depende de una serie de barreras que
determinan si el mercado es o no atractivo. Como primer punto es importante conocer los competidores
entre los cuales figuran:
Por fin empleo

Bumeran
Multitrabajo, y
Pequeas pymes orientadas a la venta de espacios publicitarios en la web
En funcin de los competidores, el enfoque lo realiza bajo los siguientes aspectos reales que realizamos para
poner en marcha las ideas de negocios dentro de la empresa:
Economas de escala.- la empresa tienen sus inicios en el centro de incubacin del Valle de Tecnologa
perteneciente a la Universidad Tcnica de Loja - UTPL y la Agencia de Desarrollo Empresarial ADE -LOJA,
este escenario empodera el concepto de economas de escalas en los procesos que se realizan y esas
normativas son manejas dentro de la empresa.
Requisitos de capital. Corresponde a los requerimientos en recursos financieros para competir en el

mercado, para competir en y poner en marcha el negocio fue vital asociar a la empresa una persona con
capital y experiencia en negocios que coloco capital financiero para poner en marcha en los primeros meses
las estrategias tecnolgicas.
Costos cambiantes.- Esta barrera es la creada por la presencia de costos ligados a los proveedores, nuestro
proveedor en los primeros meses fueron en funcin de Domino y Hosting por parte de la empresa
Diferenciacin del producto.- Esta caracterstica crea una barrera para el ingreso al mercado enfocada en
los aspectos de masificacin y segmentacin del mercado, esto implico a que dentro de la empresa
consideremos extractos sociales medianos y bajos que no son considerados por nuestros competidores y
permiti identificar alternativas de comercializacin al momento de establecer la venta de los servicios con
nuevas formas de adquirir los servicios y productos en la web orientada al comn de los usuario
permitindoles adquirir servicios y productos sin que sea indispensable el uso de tarjetas de crdito y
haciendo uso de pagos a crdito.
60
ECUAHOSTING y en la cual se comparta el hospedaje de nuestros servicios con otras empresas, sin embargo
se migro la informacin a nuevos servidores dedicados esto permite confiabilidad y administracin exclusiva
as como dentro de la empresa contar con personal para la contingencia frente a fallos.
Acceso a los canales de distribucin.- Manejamos nuestras propias formas de distribucin de los servicios
estableciendo jerarquas de comercializacin reconociendo comisiones de pago segn las ventas realizadas
por nuestros agentes, distribuidores y vendedores. Este esquema es manejado por un sistema de
informacin integrada a los servicios que ofrece la empresa.
Desventajas de costos, este un actor que juega a nuestro favor y se manifiesta por valores bajos por los
servicios. Sin embargo la empresa tiene como estrategia la masificacin de servicios lo enfrenta otro
problema las formas de pagos de nuestros cliente del clase media y baja pues la mayora no posee tarjetas
de crdito y segundo hacer colas en los bancos por valores pequeos no es una alternativa viables y
funcional; por esta razn nuestros canal de distribucin a travs de nuestros agentes, distribuidores y
vendedores son tambin quienes recaudan y activan los servicios a nuestros clientes convirtiendo as en una
forma fcil para el cliente y que con ayuda de nuestra red integrada administramos esta logstica.
Poltica gubernamental. Las regulaciones del gobierno y sus nuevas formas de limitar las empresas de razn
comercial privadas han limitados en algunos casos nuestro crecimiento y cuya razn no est en exigir
licencias, permisos, sino en limitaciones en cuanto a las nuevas polticas de orden laboral, la eliminacin de
la tercializacion y algunas restricciones comerciales internacionales para los productos que a futuro
buscbamos importar.
Caracterizacin del entorno:
Para satisfacer las necesidades de capital se identifican un actores que es un capitalista y Accionistas, que
ayuda a la empresa a obtener el dinero requerido para sus inversiones, que incluyen entre otras cosas el
acceso a tecnologa ms moderna para poner en marcha cada una de las actividades planificadas.
Finalmente en relacin a las polticas gubernamentales, se identificaron dos actores del entorno:
Organismos de Control y Organismos de Concesin. Estos actores son los encargados de emitir permisos y
licencias de concesin, dictar las normas, regulaciones tributarias y de calidad (entre otras), que rigen a uno
o ms sectores de la economa y verificar el cumplimiento de las mismas mediante la solicitud de los
informes apropiados.
Para contrarrestar las economas de escala, las desventajas de costos, o la falta de identidad de marca, la
empresa genera un cruce de negocios entre cada uno de las actividades econmicas en la web, uso de un
aliado estratgico para salir al mercado haciendo uso de un Aliado Estratgico (UTPL ADE - LOJA) para
ampliar su cobertura o disminuir costos de los servicios y distribucin, logrando una diferenciacin del
producto o servicio. Para hacer uso de los canales de distribucin la empresa crea su red de Distribuidores,
que son actores de entorno encargados de la entrega del producto y activacin de servicios al cliente final.
61
Segunda fuerza: RIVALIDAD ENTRE COMPETIDORES

Esta fuerza consiste en alcanzar una posicin de privilegio y la preferencia del cliente entre las empresas
rivales, considerando que la empresa posee varios servicios como colacin de personal, venta de
computadores y venta de espacios publicitarios orientados a adquisicin o alquiles de vivienda, vehculos y
anuncios en general, esta gama de servicios presenta un reto al conocer la rivalidad frente a varios
competidores con varias tipos de comportamientos en el mercado as que nos caracterizamos en gran parte
por observar las estrategias de los principales competidores y por la intensidad en como la empresa
emplean toda su imaginacin y recurso para tratar de superar las acciones de las dems; de igual manera la
empresa emplea una estrategia enfocada a generar ventaja competitiva que intensifica la presin por parte
de nuestros rivales.
En relacin a esta fuerza se ha identificado un nuevo actor del entorno, la Competencia, que influye en la
estrategia de la empresa y en las decisiones a tomar debido a que cualquier cambio que realice la
competencia tendr un impacto en las preferencias de los clientes y la empresa debe estar informada para
no perder espacios en el mercado, por este motivo es importante el anlisis de este actor y sus
dependencias con la empresa.
Tercera fuerza: SUSTITUTOS

Por definicin es reemplazar un servicio por otro debido a un cambio de circunstancias implica que nuestros
productos o servicios permiten que el cliente este continuamente comparando calidad, precio y desempeo
esperado frente a los costos cambiantes que son por naturaleza cambiantes.
TECNEGIN S.A. tiene como objetivos fundamental la masificacin de los servicios de publicidad y venta de
productos a las clases sociales medias y bajas mediante uso de las formas de pago a crdito y que no se
prescindible el uso de tarjetas de crdito para los pagos en lnea.
Ofrecer una diversidad de servicios para nuestros usuarios y empresas considerando variedad y formas de
pago, precio de venta as como la categorizacin de servicios. Otro factor ponderarte es clientes y las
empresas afiliadas a las franquicias y la mayora de las estrategias centran su atencin en la confianza que la
empresa ofrece en su canal de comercializacin y que frente a nuestros competidores no presentan
diversidad en sus servicios integrados en varios tipos de negocio de base tecnolgica considerando la
masificacin de los segmentos ms pequeos del mercado.
Cuarta Fuerza: PROVEEDORES

El determinar una barrera de negocio a este nivel no presenta obstculos pues la empresa mantiene su
razn de ser en servicios ms que en productos lo que implica en mantener una buena asistencia tcnica o al
no depender haciendo uso de un servidor dedicado con el soporte correspondiente por parte de la empresa.
En este estudio no consideraremos como actores del entorno, puesto que al ser una alternativa los servicios
y productos ofrecido por la empresa tambin sern considerados dentro de la competencia.
62
Actualmente la empresa, depende de un tercero que le ofrecen por ahora servicio de dominio y hosting para
cada uno se los sitios web con razones de negocio diferentes y que administrativamente no afectan a la
organizacin de los servicios que se ofreces a los clientes al no inferir en variaciones de precios, cantidad de
cupos en los paquetes y catlogos de servicios.
La empresa depende de la infraestructura de Dominio y Hosting necesaria para ofrecer la distribucin de los
productos y provisin de servicios.
Quinta Fuerza: CLIENTES

Los clientes que componen el mercado de oferta y demanda pueden observar productos y servicios
sustitutos, buscando calidad, un servicio superior y precios bajos, lo que conduce a que los proveedores
compitan entre ellos por esas exigencias. Esto permite a la empresa a centrar sus estrategias a las
respuestas de los clientes que perteneces a los segmentos ms grandes del mercado que presentan otras
caractersticas de consumo y formas de adquisicin prestando facilidades para acceder a la comprar de
nuestros servicios.
Finalmente hay la presencia en el modelo con una sexta fuerza, el gobierno. La empresa tiene en cuenta las
acciones y potenciales acciones del gobierno actual no slo por su capacidad reguladora, sino porque puede
convertirse en una competencia directa como lo es actualmente con la red de empleo montada a nivel
nacional y que est orientada al mismo nicho de mercado.
Los Clientes que son actores indispensables para la sostenibilidad de una empresa lo que puede traducirse
en un incremento de costos y reduccin de margen de beneficio de la empresa
CADENA DE VALOR
Se consideran, la LOGSTICA, a nivel de productos est presente en la venta de equipos de computadores

que por lo general son porttiles o computadores de escritorio que se despachan bajo pedido, esto implica
la actualizacin de catlogo mensualmente y promociones publicitarias, sin embargo en pocas de compras
masivas como el ingreso a clases, navidad y otras fechas donde dichas adquisiciones hacen uso de bodega y
de un vehculo para la distribucin.
A nivel de servicios se considera la organizacin de categoras organizadas por paquetes Golden, Platinum y
premiun de las ofertas de ventas publicitarias y los servicios anexos a las mismas. La tarea de la empresa es
valorar los costos y rendimientos en cada actividad creadora de valor para el cliente o usuario, as como los
medir costos y rendimientos de los competidores buscando puntos de referencia para mejoras. En la medida
Michael Porter propuso la cadena de valor como la principal herramienta para identificar fuentes de
generacin de valor para el cliente: Cada empresa realiza una serie de actividades para disear, producir,
comercializar, entregar y apoyar a su producto o servicio; la cadena de valor identifica 9 actividades
estratgicas de la empresa, cada una con un costo, a travs de las que se puede crear valor para los clientes,
estas 9 actividades se dividen en 5 actividades primarias y 4 de apoyo.
63
en que la empresa desarrolle una actividad mejor que la de los competidores, podremos alcanzar una
ventaja competitiva.
El xito de la empresa depende no solo de cmo realiza cada departamento sus tareas, sino tambin de
cmo se coordinan las actividades entre ellos pues la ser una Pyme son 3 departamentos definidos y por lo
cual es fcil de sincronizar la bsqueda delos inters de la empresa. Es as que hay que poner ms nfasis en
facilitar la labor de gestin de los procesos bsicos de la empresa, la mayora de los cuales suponen tareas
compartidas y de cooperacin.
PROCESOS.- Algunos de los procesos bsicos de la empresa son: Proceso de diseo de nuevos servicios de
publicidad web y acceso a esta mediante el Proceso de gestin de inventarios que no representa un
problema, pues el 75% de la razn de negocio de la empresa son los servicios de publicidad y solo el 25% son
productos bajo pedido y para lo cual se dispone de vehculos para la entrega de estos. Proceso de gestin
de pedidos se los realiza mediante el sistema de informacin integrado. Proceso de servicio a clientes todo
es mediante los sitios web representadas segn la necesidad del cliente entre los cuales tenemos:
www.ecuacompu.com
www.encontretrabajo.com
www.negociocasas.com
www.begociotodo.com
INFRAESTRUCTURA, Se refiere a la capacidad que tiene la empresa de responder a compromisos que se

hacen con los clientes, estos compromisos se traducen en una promesa bsica que debe ser cumplida
(requerimiento funcional objetivo blando), pero no de cualquier forma, hay que hacerlo con las
expectativas de los clientes, y por supuesto superando la competencia. Considero que cada sitio web posee
un dominio y hosting en servidores por separado con la finalidad de mejorar la confianza y disposicin de los
servicios que acceden el cliente pues si un servidor deja de funcionar el resto de servicios continua
realizando prestaciones, tambin al no compartir ancho de banda el acceso permite mejor disponibilidad,
finalmente el riesgo por mantenimiento es menor cuando se actualizacin los servicios y a las aplicaciones.
INFORMACIN Y LA TECNOLOGA, La tendencia del mercadeo moderno es hacia las relaciones, o sea el
mercadeo uno a uno o mercadeo relacional, y para poder realizar esta forma de mercadeo es fundamental
contar con una buena informacin como arma competitiva. TECNEGIN S.A. implemento un sistema de
informacin que integra y monitora las actividades econmicas de los sitios web de comercializacin basada
en almacenamientos transacciones. Generalmente se considera tres niveles de informacin: el nivel bsico,
que se refiere a los datos elementales de los clientes para tener un contacto y presentarle ofertas
permanente; un segundo nivel, que es la informacin histrica, a travs de la cual sabemos como han sido
las compras de los clientes, que referencias son las mas compradas, como es el ciclo de negocios del cliente,
cual es la estacionalidad de las compras, etc., esta informacin es clave, por que a travs de ella podemos
asesorar a nuestros clientes basados en el conocimiento y experiencia que hemos tenido con el; el tercer
La infraestructura fsica est conformada por oficinas ubicadas en el centro del puerto principal, Guayaquil
Ecuador, buscando un agradable sitio de trabajo para los clientes y empleados, tambin se puede hacer uso
de las lneas telefnicas 1-700- para el soporte garantizando comodidad, confianza, seguridad. Los puntos
de venta por lo general son los cibercaf donde el cliente accede a nuestros servicios y pagar por estos.
64
nivel es la informacin estratgica, que consiste en saber hacia donde va el cliente para poder convertirnos
en una fuente de su ventaja competitiva o de su total satisfaccin, solo a travs de esta informacin
podemos garantizar la relacin en el largo plazo.
CULTURA ORGANIZACIONAL, basada en la confianza como las personas al interior de la empresa, un sostn
importante es compartir actividades definir responsables y terminar las tareas a tiempo as la comunicacin
es un vehculo de xito real para acercarse al mercado.
En resumen, es importante echarle un vistazo detallado a la organizacin en su interior, para poder

garantizar lo que se llama alineamiento estratgico de la compaa con el mercado y de esta manera
determinar los objetivos, tareas y actores y poder modelar oportunidades organizaciones y al mismo tiempo
podemos ver las amenazas que se presentan.
MODELADO DHARMA
El modelado del entorno de una organizacin requiere realizar algunas actividades como: la identificacin de
los actores de entorno y la identificacin de sus dependencias con la organizacin. En esta se considera los
aspectos identificados mediante el anlisis de las fuerzas de Porter y la cadena de valor.
Identificacin de actores del entorno

En el entorno de una organizacin hay varios actores de diversa naturaleza pueden ser identificados como:
Personas:
Clientes, Administrador, Distribuidores, Vendedores.
Organizaciones: Ecuahosting, SRI, Super Compaas.
Hardware:
Servidores Web y de Correo, Datafax, Impresoras, Modem para mensajes de
celular.
Software:
Servidor Apache, ISS, servidor de correo, servidor de mensajes.
Identificacin de dependencias
Una vez identificados los actores en el entorno TECNEGIN S.A., las dependencias entre ellos se grafican
utilizando modelos SD con la notacin grafica utilizada en los modelos i*. La obtencin de las dependencias
sobre la organizacin guarda relacin a los catlogos de requisitos no funcionales de acuerdo al estndar
ISO/IEC 9126, en el caso de identificar dependencias de tipo objetivo-blando y se denota en la tabla 1.
ACTOR
Proveedor
Dominio
de
hosting
TIPO
DEPENDENCIA
DESCRIPCIN
SENTIDO
GRADO
DE
DEPENDENCIA
objetivo
Calidad de servicios
<----
Crtica
Objetivo
Conexin dedicada
<----
Crtica
Objetivo
Conexin a internet
<----
Crtica
TABLA 1. ACTORES DEL ENTORNO DE LA ORGANIZACIN Y SUS DEPENDENCIAS
65
Recursos
Infraestructura de Servicios en HW SW
<----
Crtica
Recursos
Informacin de trafico
<----
Crtica
objetivo blando
Tarifas bajas
<----
Comprometida
SRI
Objetivo
Declaracin de impuestos
<----
Comprometida
Organismo de control y
regulacin
Objetivo
Permisos de operacin
<----
Crtica
Postulante
Objetivo
Anuncios de empleo adquiridos
<----
Crtica
Clientes
objetivo blando
Soluciones oportunas a problemas
---->
Crtica
Objetivo
Paquetes de Servicios adquiridos
---->
Crtica
Objetivo
Calidad de servicios
<----
Comprometida
Objetivo
Soporte promocional y atencin
---->
Crtica
Objetivo
Anuncios de Inmuebles adquiridos
<----
Crtica
Objetivo
Anuncios de vehculos adquiridos
<----
Crtica
Objetivo
Reporte de anuncio
<----
Comprometida
Objetivo
Cobros realizados
<----
Crtica
Objetivo
Catlogo de Servicios, Productos tarifas

y planes
---->
Crtica
Objetivo
Parmetros de comercializacin
---->
Crtica
Objetivo
Paquetes de Servicios adquiridos
<----
Crtica
Objetivo
Empleos anunciados
---->
Crtica
Objetivo
Persona seleccionado
---->
Crtica
Objetivo
Paquetes de
adquiridos
anuncio
de
empleo
---->
Crtica
Patios de carro
Objetivo
Paquetes de
adquiridos
Anuncio
de
empleo
---->
Crtica
Inmobiliarias
Objetivo
Paquetes de
adquiridos
Anuncio
de
empleo
---->
Crtica
Clientes
objetivo blando
Cobros de servicios
<----
Crtica
Distribuidor
Empresas
Diagrama i*
Se representa grficamente cada uno de los actores y sus dependencias con la organizacin TECNEGIN S.A.
se muestran en la figura 2.
66
Parametros de
comercializacion
Catalogo de
Servicios,Productos
tarifas y planes
D
D
Reportes de anuncios
publicitados
Anuncios de
empleo
adquiridos
Conexin
dedicada
D
D
Conexin
a internet
Calidad de
servicios
Anuncios de
vehculos
adquiridos
Is a
TECNEGIN S.A.
Soporte
promocional
de servicios
D
Declaracin
de impuestos
D
D
Personal
seleccionado
Empresas
Is a
Empleos
anunciados
Paquetes de
Anuncio de empleo
adquiridos
Is a
D
Paquetes de
Anuncio de empleo
adquiridos
Patio de carros
Is a
Paquetes de
Anuncio de empleo
adquiridos
Clientes
Anuncios de
Inmuebles
adquiridos
Permisos
de
operacin
D
Infraestructura de
Servicios en HW SW
Informacin de
trafico
Organismo de
control y
regulacin
Postulante
Proveedor de
hosting y
Dominio
SRI
Calidad de
servicios
Distribuidor
Inmoviliarias
FIGURA 3. ACTORES Y SUS DEPENDENCIAS CON TECNEGIN S.A.
Modelado del entorno del sistema
Las dependencias relacionadas con el sistema que deben satisfacer el sistema para el caso de dependencias
entrantes en las que el sistema acta como depende y que son necesarias para su operacin y para las
dependencias salientes el sistema acta como depender, con estas observaciones se realiza las siguientes
actividades:
Identificacin de dependencias relevantes para el sistema
Una vez modelado el entorno TECNEGIN S.A., se analiza el impacto que la introduccin de un sistema
integrador tiene sobre los elementos incluidos en el mismo. Una pequea observacin respecto a la
empresa es que esta ya posee sistemas legados construidos exclusivamente en componentes de software,
por lo que tenemos tambin un sistema mixto - hibrido con elementos de hardware.
67
La identificacin de nuevos actores en el entorno del sistema se ligan al modelo de entrono de la

organizacin y deben ser analiza de manera sistemtica de manera que el sistema de informacin acte
como depender o dependee en la misma redireccionando la dependencia al sistema de informacin y la
organizacin es relevada de su rol. Ejemplarizando tendramos: informacin de ventas, informacin
contable, emisin de facturas soporte de monitoreo de negocios, fcil definicin de planes, monitorear
consumo de servicios, fcil administracin y valores de parmetros (ver Fig. 3).
En caso de existir dependencia esta debe ser removida del modelo. En cualquier aspecto de anlisis tener en
cuenta el sentido de las dependencias y sus actores.
Identificacin de actores adicionales en el entorno del sistema

El modelo anterior deja observar que el sistema incluye un subconjunto de los actores y dependencias del
modelo de entorno de la organizacin. Al incorporarse el sistema de informacin, la organizacin pasa a ser
un actor en su entorno, con un conjunto de dependencias. Utilizando la misma metodolgica se puede
identificar otros actores en el entorno del sistema cuya intencionalidad debe mantenerse como una
dependencia respecto al sistema y describir los objetivos, objetivos blandos y tareas.
Ver fig. 4
68
Calidad de
servicios
Parametros de
comercializacion
Catalogo de
Servicios,Productos
tarifas y planes
D
D
D
D
Soporte
promocional
de servicios
Empresas
Anuncios de
Inmuebles
adquiridos
Personal
seleccionado
Paquetes de
Anuncio de empleo
adquiridos
Fcil
administracin
Paquetes de
Anuncio de empleo
adquiridos
Paquetes de
Anuncio de empleo
adquiridos
Declaracin
de impuestos
D
SRI
Patio de carros
Is a
Valores de
parametros
Is a
Is a
Inmoviliarias
Permisos de
operacin
Organismo de
control y
regulacin
FIGURA 4. ACTORES Y SUS DEPENDENCIAS CON SISTEMA DE INFORMACIN
Monitorear
consumo de
servicios
Empleos
anunciados
Fcil definicin
de planes
Clientes
Soporte de
monitoreo de
negocios
Emisin de
facturas
D
D
Anuncios de
vehculos
adquiridos
Sistema de
informacin
Calidad de
servicios
Is a
Informacion
contable
Tecnegin
S.A.
Postulante
Anuncios de
empleo
adquiridos
Informacion
de ventas
D
D
publicitados
Infraestructura de
Servicios en HW SW
Informacin de
trafico
Distribuidor
Conexin
a internet
Proveedor de
hosting y
Dominio
Conexin
dedicada
69
Descomposicin del sistema

Un modelado del entorno del sistema permite comprender lo que esperan los actores de este lo requiere un
la identificacin de los servicios en detalle e interviene los modelos i* SR que permiten al sistema por medio
de estructuras jerrquicas definir el medio-fin, descomposicin de tareas y relaciones de contribuciones de
objetivos blandos.
En este caso de estudio de TECNEGIN S.A., mantiene sistemas legados actuando como componentes y que
ya cumplen requerimientos especficos, pero estos no funcionan de manera integrada entre ellos. Se debe
recordar que en este el propsito primario es identificar los objetivos internos que deben ser alcanzados, a
fin de que el sistema satisfaga las dependencias de los actores en su entorno de sistema y retirar los
elementos que no dependen directamente de sistema como es caso de los aspectos legales y organismos de
control. Por tanto, se realiz un enfoque en la descomposicin del sistema teniendo presente la
intervencin de los sistemas legados internos, de tipo objetivo-objetivo, ya que stas describen la
funcionalidad (servicios) que este sistema debe proveer a los actores en su entorno. Para ello se debe seguir
a detalle los pasos de la metodologa de modelado SR. En este caso no profundizamos a este detalle pero si
denoto el uso de los sistemas legados que actan como subsistemas (Actores) del sistema de informacin.
Ver la fig. 5
Parametros de
comercializacion
Catalogo de
Servicios,Productos
tarifas y planes
D
D
D
D
Ofertas laborales
aplicadas
D
D
Ofertas de
vehculos
aplicadas
Ofertas aplicadas
Calidad de
servicios
Is a
Especificacion
salarial
Anuncios de
vehculos
adquiridos
Postulante
Servicios de mais
enviados
Informacin de
trafico
Servicios de
paginas web
procesadas
Anuncios de
empleo
adquiridos
D
Hoja de vida
registrdas
Conexin
a internet
Infraestructura de
Servicios en HW SW
Mails de ofertas
laborales
Web de Bolsas de
empleo
Gestionadas
Mensajes de
anuncios enviados al
celular
Servicios
integrados
D
Proveedor de
hosting y
Dominio
publicitados
Conexin
dedicada
Sistema de
informacin
Calidad de
servicios
Distribuidor
D
D
D
D
D
Planes laborales
definidos
Planes de casas
definidos
D
D
Fcil
administracin
Paquetes de
Anuncio de empleo
adquiridos
Paquetes de
Anuncio de empleo
adquiridos
Valores de
parametros
Personal
seleccionado
Paquetes de
Anuncio de empleo
adquiridos
Empresas
Is a
Planes vehivulares
definidos
Monitorear
consumo de
servicios
Is a
Empleos
anunciados
Inmoviliarias
FIGURA 5. DESCOMPOSICION DEL SISTEMA DE INFORMACIN
Is a
Patio de carros
Postulante
notificado por
celular
Soporte de
monitoreo de
negocios
Fcil definicin
de planes
Anuncios de
Inmuebles
adquiridos
Califica perfil de
postulante
Planes definidos
Emisin de
facturas
D
D
Ofertas Mobiliaria
aplicadas
Tecnegin
S.A.
Web de anuncios
vehivulares
Gestionadas
Informacion
contable
Clientes
Informacion
de ventas
Mails de ofertas
vehiculares
Mails de ofertas
inmobiliaria
Soporte
promocional
de servicios
Web de anuncios
inmobiliarias
Gestionadas
70
Finalmente tenemos una definicin ms clara de las necesidades a satisfacer con el sistema, tambin las
funcionalidades que deben cumplir nuestros componentes desarrollados y en produccin, el punto principal
que este modelamiento es resolver es hasta qu punto los componentes diseados por TECNEGIN S.A.,
deben integrarse. Esta interrogante es fcil de responder si observamos la figura 4, y nos centramos en el
sistema de informacin agrupando elementos del modelado de acuerdo al color. Ver figura 6
Servicios
integrados
Mensajes de
anuncios enviados al
celular
Mails de ofertas
laborales
Servicios de mais
enviados
Hoja de vida
registrdas
Web de Bolsas de
empleo
Gestionadas
Servicios de
paginas web
procesadas
Ofertas laborales
aplicadas
Ofertas aplicadas
Especificacion
salarial
Planes laborales
definidos
Planes definidos
Postulante
notificado por
celular
Web de anuncios
inmobiliarias
Gestionadas
Califica perfil de
postulante
Ofertas de
vehculos
aplicadas
Sistema de
informacin
Mails de ofertas
vehiculares
Web de anuncios
vehivulares
Gestionadas
Ofertas Mobiliaria
aplicadas
Planes vehivulares
definidos
Mails de ofertas
inmobiliaria
Planes de casas
definidos
www.negociocarros.com
FIGURA 7. DESCOMPOSICIN DEL SISTEMA DE INFORMACIN
www.encontretrabajo.com
Sistema Integrador
71
Conclusiones
El uso de un modelado i* ayuda a resolver un problema real con el mtodo DHARMA para la determinacin
de arquitecturas software donde existe variedad de sistemas hbridos permite no centrarse en que
tecnologa estn realizados sino que el punto es resolver o cubrir una necesidad empresarial es as la
empresa mantiene componentes desarrollados en varias plataformas como ruby onrails
(www.negociocarros.com,
,
www.negociotodo.com),
con
asp.net
(www.encontretrabajo.com), adems se mantiene componente de software libre basados en PHP,
finalmente el componente de integracin se lo realizo en .net basado en SOA (Arquitectura orientada a
servicios) mediante el uso de Web Services.
DHARMA permite resolver problemas complejos con mtodos fciles de entender bajo en el marco i* para
descomponer un sistema en actores que representan los diferentes dominios de software mejorando la
calidad en los sistemas compuestos, y definir aspectos de elicitacin de requisitos en sistemas
(componentes) que abarcan diversos dominios.
72
REQUERIMIENTOS
Los encontramos en formas variadas como lista de pedido, casos de uso, historias, escenarios de negocio,
reglas de negocio, condiciones de sistema entre otras. Pero lo que es muy cierto es que los requerimientos
debern de ser claros, descritos o bosquejados de manera atmica adems de saber cmo sern probados,
por dichas razones hay que documentarlos y colocarles un identificador nico (el documentado del
requerimiento puede ser: escritos, dibujados o modelados) tal que podamos transmitirlos, implementarlos,
verificarlos y obtener la aprobaciones correspondiente.
Divisin bsica de los requerimientos

Los requerimientos se dividen en Funcionales.- Que servicios necesita que haga el sistema, que operaciones
o funcionalidades son esperadas por los stakeholders.
Para los Requerimientos No funcionales.- Cuales son las cualidades del servicio (usabilidad, tiempos de
respuesta, flexibilidad, confiabilidad, estabilidad, recuperacin de fallas entre otros). Estos habitualmente no
son considerados por los lderes o bien por que ya existe el sistema y se estn haciendo mejoras o porque
definitivamente no saben que existen.
Como programadores nos corresponde detectar ciertos requerimientos que no son solicitados de manera
explcita, pero sin embargo deben de estar en el sistema, estos son establecidos a travs de los
requerimientos no funcionales, donde vamos creando requerimientos complementarios con el fin de cubrir la
necesidad del cliente o stakeholdres. Esto lo encontramos en las pruebas de concepto, propuesta de
usabilidad, desarrollo de componentes de infraestructura, utilizacin de un u otro framework entre otras
actividades, normalmente estos ltimos no se documentan de manera formal, pero es muy conveniente que
se documente en el cdigo (best practice) y difundirlo al equipo, esto puede ayudar a que se evite la
programacin redundante.
Lo importante de los requerimientos al transmitirlos es que sean claros, nicos (no redundante o que se
tengan conflictos con otros), que sean concretos y que ante todo se alineen al objetivo o visin inicial.
Cada metodologa tiene formas diferentes para expresarlos, lo comn de todas ellas es que coinciden en la
importancia del requerimiento, siendo fundamental para las dems actividades del equipo de trabajo, los
requerimientos deben de ayudar a establecer el plan de trabajo (esfuerzos, tiempos y costo) incluyendo la
manera en que se va a probar y validar
73
Delimitan el qu
Deben ser:
o Obtenidos
o Depurados y validados
o Especificados
o Administrados
o Enlazados al proceso de desarrollo
o Mantenidos
Un requerimiento es una condicin o capacidad que necesita un usuario para resolver un problema
(necesidad) o lograr un objetivo.
Condicin o capacidad que debe ser cumplida o poseda por un sistema o componente de un sistema
para satisfacer un contrato, estndar, especificacin o cualquier otro documento formal impuesto
Los requerimientos son: una especificacin de lo que debe ser implementado. Son descripciones de cmo
el sistema debe comportarse, o de una propiedad o un atributo del sistema. Pueden ser una restriccin
sobre el proceso de desarrollo del sistema
REQUERIMIENTOS FUNCIONALES
Especificacin de la funcionalidad del producto

Acciones que el producto debe hacer, comprobar, calcular, registrar o actualizar
Descripciones de comportamientos en situaciones particulares
Tambin puede declararse lo que el sistema NO debe hacer
Sommerville, Sawyer, 1997
74
REQUERIMIENTOS NO-FUNCIONALES
Definen los atributos que califican cmo realizar su trabajo:

Son el cmo, cundo y cunto del qu.
Con ellos, se limita y se ponen restricciones al sistema o sobre el proceso de desarrollo
Tambin llamados Atributos de Calidad:
o No tienen que ver con la funcionalidad del sistema (directamente)
o Establecen restricciones al producto por desarrollar
o Establecen restricciones al proceso de desarrollo
o Pueden comprender o plantear restricciones externas al producto
Los requerimientos no-funcionales pueden ser ms crticos que los requerimientos funcionales. Si estos
no se cumplen, el sistema no es til.
En ocasiones, algunos requerimientos no funcionales deben ser sacrificados para cumplir con los
requerimientos funcionales.
Niveles y tipos de requerimientos Segn Westfall:
Niveles de requerimientos Segn Wiegers:
75
CONCLUSIN:
76
REQUERIMIENTOS DEL NEGOCIO

Los requerimientos del negocio representan los objetivos de alto nivel de la organizacin o cliente que
solicita el sistema.
Usualmente provienen de:
Quien financia el proyecto

El cliente que compra
El administrador de los usuarios reales
El departamento de mercadeo o un visionario del producto.
Los requerimientos del negocio describen por qu la organizacin est interesada en implementar el sistema
los objetivos que sta desea alcanzar. Es til describir los requerimientos del negocio en un documento de
visin y alcance
REQUERIMIENTOS DEL USUARIO
Proveen informacin relativa al qu.

Describen lo que el usuario ser capaz de hacer con el producto: tareas que ser capaz de realizar y
metas que ser capaz de cumplir.
Esta informacin puede ser representada mediante casos de uso, escenarios, historias de usuarios,
tablas estmulo-respuesta.
Nota: los casos de uso pueden ser incorporados en la Especificacin de requerimientos de software
Ejemplos:
Hacer una compra en un sistema Web para herramientas, accesorios y repuestos automotrices.
Es conveniente adoptar un enfoque centrado en el usuario para indagarlos, analizarlos y
especificarlos. Por eso son tan tiles los casos de uso y las historias de usuarios
Este trmino comprende los requerimientos de alto nivel de un producto constituido por mltiples subsistemas.
El sistema podra incluir sub-sistemas de hardware, software y gente.
Algunas funciones del sistema podran ser asignadas a la personas
REGLAS DEL NEGOCIO
Incorporan:
Polticas empresariales
Regulaciones gubernamentales
o Estndares industriales
77
o
o
Prcticas contables
Algoritmos computacionales
No son requerimientos en s, porque existen fuera de los sistemas de software, sin embargo restringen
quin puede realizar un caso de uso o pueden dictar que el sistema contenga cierta funcionalidad para
cumplir con ellas
Restricciones
Limitan las decisiones que los desarrolladores pueden hacer en cuanto a diseo y construccin; por ejemplo:
Plataforma operativa
Lenguaje de programacin
Sistema de bases de datos
Formatos para intercambio de datos
Etc.
INGENIERA DE REQUERIMIENTOS
Proporciona el mecanismo adecuado para comprender lo que quiere el cliente:
Analizando necesidades
Confirmando su viabilidad
Negociando una solucin razonable
Especificando la solucin sin ambigedad
Validando la especificacin
Gestionando los requerimientos
para producir un sistema operacional
El proceso de Ingeniera de requerimientos comprende 5 pasos:

Identificacin
Anlisis y negociacin
Especificacin
Modelado
Validacin
Gestin
IDENTIFICACIN:
Por qu su alto costo? Problemas de:
Alcance: mal definido el lmite, o detalles tcnicos innecesarios

Comprensin: en clientes o usuarios, en comunicacin, por omisiones obvias, en
conflicto con otros usuarios, ambigedad, baja estabilidad
Volatilidad: requerimientos que cambian con el tiempo
Cmo obtenerlos?
Valorar impacto y factibilidad tcnica
1.
78
Varios puntos de vista

Ambiguos prototipado
Qu debe contener el resultado?
2.
Identificar las restricciones de dominio
Mapeo necesidad caracterstica

Alcance
Lisado de clientes, usuarios y otros participantes
Descripcin del entorno tcnico
Conjunto de escenarios
Prototipo(s) desarrollado(s) para comprensin de un requerimiento
ANLISIS Y NEGOCIACIN:
Cada requerimiento es consistente con los objetivos del sistema?
Todos tienen el nivel de abstraccin adecuado?
Son necesarios o no esenciales para la finalidad del sistema?
Delimitados y no ambiguos?
Tienen origen conocido?
Son posibles de alcanzar en el entorno tcnico donde operarn?
Pueden ser probados una vez implementados?
Si entran en conflicto entre s: negociarlos
Identificar y analizar los riesgos de cada uno

Estimar el esfuerzo de desarrollo y el impacto de cada uno en el costo y plazo de
entrega
Quines ayudarn en la especificacin
79
Ingeniera de requerimientos
En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos o Ingeniera de
requerimientos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las
condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de
los inversores, que pueden entrar en conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traduccin del
ingls. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al
ingls como request. Personalmente considero que primero los requisitos y luego los requerimientos.
El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de
alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin
ambigedades o contradicciones, etc.
IMPLICACIONES
La elicitacin (sonsacado) de los requisitos de usuario

Al anlisis y negociacin de requisitos para derivar requisitos adicionales
A la documentacin de los requisitos como especificacin
A la validacin de los requisitos documentados contra las necesidades de usuario
As como los procesos que apoyan estas actividades.
La ingeniera de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
80
FASES DE IMPLEMENTACIN
Desde un punto de vista conceptual, las actividades son de cinco clases.
ESPECIFICACIN:
Producto final sobre los requerimientos del sistema
Describe la funcin y caractersticas de un sistema y las restricciones que gobiernan su desarrollo
Delimita cada elemento del sistema
Describe la informacin (datos y control) que entra y sale del sistema
3.
LA ESPECIFICACIN DEBE SER:

Correcta.
Sin ambigedades.
Completa.
Consistente.
Con prioridades: importancia o estabilidad.
Verificable.
Modificable.
Rastreable (trazable).
Correcta.
o Todo requerimiento enunciado es algo que el sistema satisfar.
o Comparar con otras especificaciones, documentos, estndares, sistemas existentes.
o Validar con los usuarios.
o Conciliar perspectivas.
Sin ambigedades
o Todo requerimiento enunciado tiene una sola interpretacin.
o Cada caracterstica debe ser descrita con un solo trmino.
o Usar glosarios.
o Balancear representaciones: usuarios, tcnicos.
o Revisar lenguaje natural.
Usar lenguajes y herramientas pertinentes
Completa:
o
Slo si incluye los siguientes elementos:
Todos los requerimientos significativos: funcionalidad, rendimiento, restricciones

de diseo, interfaces externas, atributos.
Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber
cules son sus deseos.
Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos
obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente
documentados.
Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la
aplicacin.
Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que
inicialmente se pretenda.
81
Etiquetas y referencias completas para todas las figuras, tablas y diagramas en la

especificacin, y definicin de todos los trminos y unidades de medida.
Consistente (internamente)
o Ningn subconjunto de requerimientos individuales descrito est en conflicto.
Las caractersticas de objetos del mundo real pueden estar en conflicto.

Conflicto lgico o temporal entre acciones especificadas.
Uso de mltiples trminos para referirse al mismo objeto del mundo real.
Con prioridades
o Todo requerimiento posee un indicador de su importancia y/o estabilidad.
o Algunos requerimientos son esenciales, otros son deseables.
o Hacer claras y explcitas las diferencias.
Grado de estabilidad
o Nmero de cambios esperados para cualquier requerimiento.
o Sobre la base de la experiencia o conocimiento de eventos por presentarse en el futuro
(incluir modificaciones de procesos).
o Considerar gente, funciones y organizacin apoyada por el sistema.
Grado de necesidad
o Esencial: el sistema no es aceptable a no ser que se provean estos requerimientos de una
manera (mutuamente) acordada.
o Condicional: estos requerimientos mejoraran el sistema, pero no lo hacen inaceptable si
estn ausentes.
o Opcional: una clase de funciones que puede o no valer la pena incluir.
Verificable
o
o
o
o
Todo requerimiento es verificable: si existe un proceso finito y econmico para que una
persona o mquina pueda comprobar que el sistema satisface el requerimiento.
No verificables: trabaja bien, buena interfaz humana, usualmente pasar...
No encontrar mtodo => revisar o quitar requerimiento.
La salida del programa deber producirse a lo sumo 20 s despus del evento X un 60% del
tiempo, y deber producirse a lo sumo 30 s despus del evento X un 100% del tiempo.
Modificable
o La estructura y estilo son tales que los cambios en los requerimientos pueden hacerse
-
Fcilmente
Completamente
Consistentemente
Definicin de las respuestas del sistema a todas las clases realizables de datos de
entrada en todas las clases de situacin realizables.
82
Manteniendo la estructura y el estilo.
Ayudas a la facilidad de modificacin:

o Organizacin coherente y fcil de usar, con tabla de contenidos, ndices y/o referencias
cruzadas.
o Carecer de redundancia.
o Expresar cada requerimiento separada-mente, y no entremezclado con otros
requerimientos. Buscar atomicidad.
Rastreable
o
o
o
o
El origen de cada requerimiento es claro.

Da facilidades para referenciar cada requerimiento.
Rastreabilidad retrospectiva: cada requerimiento referencia explcitamente sus fuentes en
documentos anteriores.
Rastreabilidad prospectiva: cada requerimiento posee un identificador nico.
4.
MODELADO:
Evaluar los componentes del sistema y sus relaciones entre s

Determinar cmo estn reflejados los requisitos
5.
VALIDACIN
Se evala la calidad de la especificacin:
Sin ambigedades
Sin inconsistencias
Sin omisiones
Errores corregidos
Apego a estndares para el
Proceso
Proyecto
Producto
83
6.
GESTIN
Conjunto de actividades que ayudan a identificar, controlar y seguir los requisitos y los cambios en
cualquier momento
Matrices de seguimiento:
De caractersticas (requerimiento-caracterstica)
De orgenes (requerimiento-origen)
De dependencias (requerimiento-requerimiento)
De subsistemas (requerimiento-subsistema)
De interfaces (requerimiento-interfaz interna o externa del sistema)
EL PROBLEMA DE LOS REQUERIMIENTOS
El objetivo del desarrollo de software es desarrollar software de calidad oportuno y dentro del
presupuesto que cumpla las necesidades reales del cliente
El xito del proyecto depende de una buena administracin de requerimientos.
Los errores en requerimientos son el tipo ms comn de error de desarrollo, y el ms costoso de
determinar
Pocas caractersticas clave pueden significar la reduccin de errores y mejorar la calidad
Elicitacin de requerimientos
3 problemas endmicos:
Sndrome del si, pero

Sndrome de las ruinas no descubiertas
Sndrome del usuario y desarrollador
Entrevistas y cuestionarios
Talleres de requerimientos
Lluvia de ideas, reduccin
Historias
Casos de uso
Juegos de roles
Prototipado
Tcnicas utilizadas:
84
ANLISIS ORIENTADO A OBJETOS
UNIDAD III
85
ANLISIS ORIENTADO A OBJETOS
INTRODUCCIN
Actualmente, el software tiene la tendencia de ser grande y complejo. Los usuarios demandan interfaces
cada vez ms completas y funcionalidades ms elaboradas, todo ello influyendo en el tamao y la
complejidad del producto final. Por ello, los programas deben ser estructurados de manera que puedan ser
revisados, corregidos y mantenidos, rpida y eficazmente, por gente que no necesariamente ha colaborado
en su diseo y construccin, permitiendo acomodar nueva funcionalidad, mayor seguridad y robustez,
funcionando en todas las situaciones que puedan surgir, de manera previsible y reproducible.
Ante problemas de gran complejidad, la mejor forma de abordar la solucin es modelar. Modelar es disear
y estructurar el software antes de lanzarse a programar y es la nica forma de visualizar un diseo y
comprobar que cumple todos los requisitos para l estipulados, antes de que la flotilla de programadores
comience a generar cdigo. Modelando, los responsables del xito del producto pueden estar seguros de
que su funcionalidad es completa y correcta, que todas las expectativas de los usuarios finales se cumplen,
que las posibles futuras ampliaciones pueden ser acomodadas, todo ello mucho antes de que la
implementacin haga que los cambios sean difciles o imposibles de acomodar. Modelando, se abstraen los
detalles esenciales de un problema complejo y se obtiene diseos estructurados que, adems, permiten la
reutilizacin de cdigo, reduciendo los tiempos de produccin y minimizando las posibilidades de introducir
errores.
UML es un lenguaje grfico que sirve para modelar, disear, estructurar, visualizar, especificar, construir y
documentar software. UML proporciona un vocabulario comn para toda la cadena de produccin, desde
quien recaba los requisitos de los usuarios, hasta el ltimo programador responsable del mantenimiento. Es
un lenguaje estndar para crear los planos de un sistema de forma completa y no ambigua. Fue creado por
el Object Management Group, OMG, un consorcio internacional sin nimo de lucro, que asienta estndares
en el rea de computacin distribuida orientada a objetos, y actualmente revisa y actualiza peridicamente
las especificaciones del lenguaje, para adaptarlo a las necesidades que surgen. El prestigio de este consorcio
es un aval ms para UML, considerando que cuenta con socios tan conocidos como la NASA, la Agencia
Europea del Espacio ESA, el Instituto Europeo de Bioinformtica EBI, Boeing, Borland, Motorla y el W3C, por
mencionar algunos.
Aunque UML puede emplearse en cualquier paradigma, como la programacin estructurada o la lgica, est
especialmente cerca del paradigma de la orientacin a objetos. Por tanto, es precisa una familiarizacin con
algunos detalles de este paradigma antes de continuar con UML.
La Orientacin a Objetos, OO
86
Qu es un Objeto
De manera intuitiva, la tendencia general es asociar el trmino objeto con todo aquello a lo que se puede
atribuir la propiedad fsica de masa, como una tostadora de pan, aunque es posible encontrar objetos de
ndole no tangible, como por ejemplo una direccin postal. En el mbito de la informtica, un objeto define
una representacin abstracta de las entidades del mundo, tangibles o no, con la intencin de emularlas.
Existe pues, una relacin directa entre los objetos del mundo y los objetos informticos, de modo que puede
emplearse el trmino objeto de manera indistinta.
Los objetos tienen dos caractersticas, que son su estado y su comportamiento. El estado es una situacin en
la que se encuentra el objeto, tal que cumple con alguna condicin o condiciones particulares, realiza alguna
actividad o espera que suceda un acontecimiento. Una tostadora puede estar encendida y cargada de pan y,
en cuanto a su comportamiento, lo normal en este estado es tostar pan.
Los objetos mantienen su estado en uno o ms atributos, que son simplemente datos identificados por un
nombre, y exhiben su comportamiento a travs de mtodos, que son trozos de funcionalidad asociados al
objeto. En este sentido, un objeto es realmente un conjunto de atributos y mtodos. Pero un objeto slo
revela su verdadera utilidad cuando es integrado en un contexto de comunicacin con otros objetos, a
travs del envo de mensajes, para componer un sistema mucho mayor y demostrar un comportamiento
ms complejo. Una tostadora en un armario resulta de poca utilidad, pero cuando interacta con otro
objeto, como un ser humano, se convierte en una herramienta til para tostar pan. El humano
intercambiara con la tostadora el mensaje tuesta el pan que tienes en la bandeja a travs de la pulsacin
del botn de tostar.
Figura 1: Objetos comunicndose
A partir del ejemplo anterior, es fcil deducir que el envo de mensajes es la forma en que se invocan los
mtodos de un objeto y que la invocacin de mtodos es el mecanismo a travs del cual un objeto puede
cambiar su estado o el de otro objeto. Los atributos y los mtodos de un objeto pueden tener un menor o
mayor grado de visibilidad, desde privado hasta pblico, lo que hace que aparezca un concepto nuevo,
la encapsulacin. La encapsulacin oculta los detalles del funcionamiento interno del objeto, exponiendo
slo aquello que pueda ser de inters.
87
Qu es una Clase
Los objetos no son entidades que existan de modo nico. Hay muchos tipos de tostadoras e, igualmente,
muchas tostadoras del mismo tipo. Se puede entender fcilmente el concepto de clase si nos permitimos
emplear el trmino tipo como equivalente. As, todos los objetos que son del mismo tipo, comparten el
mismo juego de atributos y mtodos (aunque cada objeto pueda tener un valor distinto asociado a cada
atributo) y por tanto pertenecen a una misma clase. Las clases son como patrones que definen qu atributos
y qu mtodos son comunes a todos los objetos de un mismo tipo.
Cada objeto tiene sus atributos y su comportamiento, creados empleando una clase a modo de patrn. Una
vez creado el objeto, pasa a ser una instancia particular de la clase a la que pertenece y sus atributos tienen
unos valores concretos, que podrn variar de un objeto a otro (dos objetos distintos pertenecientes a la
misma clase, pueden tener exactamente los mismos valores en todos sus atributos). A estos atributos, que
pueden variar de un objeto a otro, se les conoce tambin como variables de instancia.
Hay atributos que, sin embargo, no varan de un objeto a otro, es decir todas las instancias de la clase a la
que pertenecen, tienen el mismo valor para ese atributo. Todas las tostadoras del mismo tipo consumen los
mismos Watios y sus resistencias son de los mismos Ohmios. A estos atributos se les conoce como variables
de clase y son compartidos por todas y cada una de las instancias de la clase. De manera anloga al caso de
los atributos, encontramos mtodos de instancia y mtodos de clase.
Herencia
Los objetos se definen en funcin de clases, es decir, tomando una clase como patrn. Se puede saber
mucho acerca de un objeto sabiendo la clase a la que pertenece. Por ejemplo, con decir que la Russell
Hobbs 10243 Kudos es un tipo de tostadora, inmediatamente se sabe que se trata de una mquina para
tostar pan, probablemente elctrica y con por lo menos una ranura en la que insertar una rebanada de pan y
un botn para activar su funcionamiento.
En la siguiente figura se puede ver una jerarqua de especializacin de dos niveles. La clase Animal es la
raz , la clase padre en la jerarqua. Especifica que los animales comen, como caracterstica ms significativa
de stos. En el primer nivel de especializacin encontramos las clases Carnvoro y Herbvoro, ambas son
sendos tipos de animal y por tanto comen, slo que en el caso de los carnvoros se ha especializado el tipo
de comida que comen para indicar que se trata de carne. Aparece una nueva caracterstica de este tipo de
animal, que es el hecho de que los carnvoros cazan. En el caso de los herbvoros, encontramos que comen
plantas y pacen. En el segundo nivel de especializacin, encontramos un animal que es a la vez Herbvoro
y Carnvoro y, como cabe esperar, este nuevo tipo de animal puede hacer todo lo que pueden hacer sus
Las clases llegan un paso ms lejos, permitiendo su definicin en funcin de otras clases, de modo que es
posible establecer una jerarqua de especializacin. Una clase que se define en funcin de otra, hereda
todos los atributos y mtodos de aquella y permite el aadido de nuevos o la sobre escritura de los
heredados. La clase patrn se conoce con el nombre de superclase o clase padre, mientas que la que hereda
se conoce como clase hija. La herencia no est limitada simplemente a padre-hija(s), la jerarqua puede ser
todo lo profunda que sea necesario, hablando en trminos de nietas, biznietas, etc. De la misma manera,
una clase puede heredar de varias clases a la vez.
88
ancestros, comer carne, comer plantas, cazar y pacer, no encontrando ninguna caracterstica adicional en los
Omnvoros.
Figura 2: La Herencia
Interfaz
Una interfaz es un mecanismo que emplean dos objetos para interactuar. En nuestro ejemplo de la
tostadora, el humano emplea el botn de tostar a modo de interfaz para pasar el mensaje tuesta el pan
que tienes en la bandeja.
Las interfaces definen un conjunto de mtodos para establecer el protocolo en base al cual interactan dos
objetos. En este sentido, existe una analoga entre interfaces y protocolos. Para que el humano pueda
tostar, debe seguir el protocolo establecido por la interfaz botn de tostar, consistente en pulsar dicho
botn.
Las interfaces capturan las similitudes entre clases no relacionaras, sin necesidad de forzar una interrelacin
y son a su vez clases.
89
El Lenguaje Unificado de Modelado, UML

El UML es un lenguaje de modelado cuyo vocabulario y sintaxis estn ideados para la representacin
conceptual y fsica de un sistema. Sus modelos son precisos, no ambiguos, completos y pueden ser
trasladados directamente a una gran variedad de lenguajes de programacin, como Java, C#, C++ o Visual
Basic, pero tambin a tablas de bases de datos relacionales y orientadas a objetos. Es posible generar cdigo
a partir de un modelo UML (ingeniera directa) y tambin puede construirse un modelo a partir de la
implementacin (ingeniera inversa), aunque en las dos situaciones debe intervenir un mayor o menor grado
de supervisin por parte del programador, en funcin de lo buenas que sean las herramientas empleadas.
Bloques bsicos de construccin de UML
Los elementos son abstracciones que actan como unidades bsicas de construccin. Hay cuatro
tipos, los estructurales, los de comportamiento, los de agrupacin y los de notacin. En cuanto a los
elementos estructurales son las partes estticas de los modelos y representan aspectos
conceptuales o materiales. Los elementos de comportamiento son las partes dinmicas de los
modelos y representan comportamientos en el tiempo y en el espacio. Los elementos de
agrupacin son las partes organizativas de UML, establecen las divisiones en que se puede
fraccionar un modelo. Slo hay un elemento de agrupacin, el paquete, que se emplea para
organizar otros elementos en grupos. Los elementos de notacin son las partes explicativas de
UML, comentarios que pueden describir textualmente cualquier aspecto de un modelo. Slo hay un
elemento de notacin principal, la nota.
Las relaciones son abstracciones que actan como unin entre los distintos elementos. Hay cuatro
tipos, la dependencia, la asociacin, la generalizacin y la realizacin.
Los diagramas son la disposicin de un conjunto de elementos, que representan el sistema

modelado desde diferentes perspectivas. UML tiene nueve diagramas fundamentales, agrupados
en dos grandes grupos, uno para modelar la estructura esttica del sistema y otro para modelar el
comportamiento dinmico. Los diagramas estticos son: el de clases, de objetos, de componentes y
de despliegue. Los diagramas de comportamiento son: el de Casos de Uso, de secuencia, de
colaboracin, de estados y de actividades.
Los bloques bsicos de construccin de UML son tres, los elementos, las relaciones y los diagramas.
90
ELEMENTOS
Clase activa
E
L
E
Interfaz
M
E
N
T
Colaboracin
O
S
E
S
T
Caso de uso
R
U
C
T
U
Componente
Agrupacin de mtodos u
operaciones que especifican un
servicio de una clase o
componente, describiendo su
comportamiento, completo o
parcial, externamente visible.
UML permite emplear un crculo
para representar las interfaces,
aunque lo ms normal es
emplear la clase con el nombre
en cursiva.
Define una interaccin entre
elementos que cooperan para
proporcionar
un
comportamiento mayor que la
suma de los comportamientos
de sus elementos.
Describe un conjunto de
secuencias de acciones que un
sistema ejecuta, para producir
un resultado observable de
inters.
Se emplea
para
estructurar los aspectos de
comportamiento de un modelo.
Parte fsica y por tanto
reemplazable de un modelo,
que agrupa un conjunto de
interfaces, archivos de cdigo
fuente, clases, colaboraciones y
proporciona la implementacin
de dichos elementos.
Clase
Describe un conjunto de objetos

que comparten los mismos
atributos, mtodos, relaciones y
semntica. Las clases
implementan una o ms
interfaces.
Se trata de una clase, en la que
existe procesos o hilos de
ejecucin concurrentes con
otros elementos. Las lneas del
contorno son ms gruesas que
en la clase normal
91
R
A
Nodo
L
E
Elemento fsico que existe en

tiempo
de
ejecucin
y
representa
un
recurso
computacional con capacidad de
procesar.
Interaccin
Elementos
de
comportamiento
Mquinas
de
Comprende un conjunto de
mensajes que se intercambian
entre un conjunto de objetos,
para cumplir un objetivo
especifico.
Especifica la secuencia de
estados por los que pasa un
objeto o una interaccin, en
respuesta a eventos.
estados
Se emplea para organizar otros
elementos en grupos.
Elementos
de
Paquete
agrupacin
Partes explicativa de UML, que
puede describir textualmente
cualquier aspecto del modelo
Elementos
de
Nota
notacin
Tabla 1: Elementos de construccin en UML
RELACIONES
Asociacin
Es una relacin estructural que resume un conjunto

de enlaces que son conexiones entre objetos.
Dependencia
Es una relacin entre dos elementos, tal que un

cambio en uno puede afectar al otro.
92
Es una relacin en la que el elemento generalizado

puede ser substituido por cualquiera de los
elementos hijos, ya que comparten su estructura y
comportamiento.
Generalizacin
Es una relacin que implica que la parte realizante

cumple con una serie de especificaciones
propuestas por la clase realizada (interfaces).
Realizacin
Tabla 2: Elementos de relacin en UML
DIAGRAMAS
Clases
Muestra un conjunto de clases,

interfaces y colaboraciones, as como
sus relaciones, cubriendo la vista de
diseo esttica del sistema.
M
O
D
E
L
Objetos
A
N
Componentes
E
S
T
R
U
C
Despliegue
Anlogo al diagrama de clases,

muestra un conjunto de objetos y sus
relaciones, pero a modo de vista
instantnea de instancias de una clase
en el tiempo.
Muestra
la
organizacin
dependencias de un conjunto
componentes. Cubren la vista
implementacin esttica de
sistema. Un componente es
mdulo de cdigo, de modo que
diagramas de componentes son
anlogos fsicos a los diagramas
clases.
y
de
de
un
un
los
los
de
Muestra la configuracin del hardware

del sistema, los nodos de proceso y los
componentes empleados por stos.
Cubren la vista de despliegue esttica
de una arquitectura.
U
R
A
93
Casos de Uso
M
O
Secuencia
D
E
L
A
N
Colaboracin
C
O
M
P
O
R
T
A
Estados
Muestra un conjunto de casos de uso,

los actores implicados y sus
relaciones.
Son
diagramas
fundamentales en el modelado y
organizacin del sistema.
Son diagramas de interaccin,
muestran un conjunto de objetos y sus
relaciones, as como los mensajes que
se intercambian entre ellos. Cubren la
vista dinmica del sistema. El
diagrama de secuencia resalta la
ordenacin temporal de los mensajes,
mientras que el de colaboracin
resalta la organizacin estructural de
los
objetos,
ambos
siendo
equivalentes o isomorfos. En el
diagrama de colaboracin de la figura
de la izquierda, se puede ver que los
elementos grficos no son cajas
rectangulares, como cabra esperar, y
en su lugar encontramos sus versiones
adornadas. Estas versiones tienen
como finalidad evidenciar un rol
especfico
del
objeto
siendo
modelado. En la figura encontramos
de izquierda a derecha y de arriba
abajo un Actor, una Interfaz, un
Control (modela un comportamiento)
y una Instancia (modela un objeto de
dato).
Muestra una mquina de estados, con
sus estados, transiciones, eventos y
actividades. Cubren la vista dinmica
de
un
sistema.
Modelan
comportamientos reactivos en base a
eventos.
Tipo especial de diagrama de estados
que muestra el flujo de actividades
dentro de un sistema.
I
E
N
Actividades
Tabla 3: Diagramas de UML
94
Diagrama de Clases y Diagrama de Objetos
Los diagramas de clases muestran un resumen del sistema en trminos de sus clases y las relaciones entre
ellas. Son diagramas estticos que muestran qu es lo que interacta, pero no cmo interacta o qu pasa
cuando ocurre la interaccin.
El siguiente diagrama modela los pedidos de un cliente a una tienda de venta por catlogo. La clase principal
es Pedido, asociada a un cliente, una forma de pago y un conjunto de artculos.
La clase Pago es abstracta, en UML los nombres de clases abstractas se representan en Itlica. Las clases
abstractas actan a modo de interfaz, proporcionando nicamente un listado de mtodos a ser realizados
por las clases que las implementan o realizan. Pago es una superclase especializada, y a la vez realizada,
por sus formas ms comunes Credito y Efectivo. Un Pedido tiene una nica forma de pago, expresada
por su multiplicidad, 1, mientras que una forma de pago puede estar presente en uno o ms pedidos, como
sugiere su multiplicidad, 1..*.
Figura 3: Diagrama de Clases
En cuanto a las asociaciones, observamos que algunas vienen representadas como una flecha navegable,
cuya orientacin expresa el sentido en que se consultan los datos. Las asociaciones sin flecha son bidireccionales. Las agregaciones expresan conjunto de; la relacin entre Pedido y Articulo es de
conjunto. Un pedido es una agregacin de una o ms lneas de pedido, donde cada una hace alusin a un
artculo concreto, as mismo una lnea de pedido puede estar presente en varios pedidos y un artculo puede
no haber sido solicitado nunca.
95
En cuanto a la multiplicidad, la siguiente tabla resume las ms comunes. Hay que tener en cuenta que la
multiplicidad se expresa en el lado opuesto de la relacin y es el nmero de posibles instancias de una
clase asociadas con una nica instancia de la clase en el otro extremo.
Multiplicidad
1
N/*
0..N / 0..*
1..N / 1..*
0..1
N..M
Significado
Una nica instancia
N instancias
Entre ninguna y N instancias
Entre una y N instancias
Ninguna o una instancia
Entre N y M instancias
Tabla 4: Multiplicidad en Diagramas de Clases
El siguiente diagrama muestra una dependencia existente entre las clases Pedido y Fecha. Cualquier
cambio en la clase dependida, Fecha, afectar la clase dependiente, Pedida.
As mismo se puede observar que las clases vienen representadas por cajas en las que hay tres separaciones,
o compartimentos. El primero se emplea siempre para indicar el nombre de la clase, el segundo para
mostrar los atributos y el tercero para los mtodos. Tanto los atributos como los mtodos vienen precedidos
por un smbolo de acceso, que normalmente suele ser un + para el acceso pblico, un - para el acceso
privado, (slo por otros mtodos de la clase) y un # para el acceso protegido (slo por clases hija), aunque
la herramienta empleada en la elaboracin del tutorial traduce estos elementos en iconos.
Los atributos tienen un tipo que puede mostrarse a continuacin de su nombre separado por :. De igual
manera, los mtodos pueden devolver un elemento de un tipo determinado y recibir parmetros,
expresados entre parntesis mediante el nombre del parmetro y el tipo, separados por :. Para el caso de
mltiples parmetros, se separan por comas (p1:t1, p2:t2 ... pn:tn). Los parmetros que tienen un valor por
defecto se expresan mediante un = y el valor, a continuacin del tipo (p1:t1=v1) y si un parmetro en la
posicin i de la lista de parmetros tiene valor por defecto, todos los parmetros que le sigan, es decir que
ocupen posiciones sucesivas a i en la lista, debern tener tambin un valor por defecto.
Figura 4: Relacin de dependencia en Diagramas de Clase
El siguiente diagrama muestra una auto-relacin de agregacin. Un Departamento puede estar compuesto
a su vez por ms sub-departamentos, o ninguno, con la restriccin de que el mnimo nmero de personas en
los sub-departamentos debe ser dos. Las restricciones son condiciones que deben ser cumplidas siempre, se
expresan entre llaves {condicin }.
Los atributos y mtodos estticos (de clase) se representan mediante un subrayado (en el caso de los
mtodos se puede emplear el estereotipo <<static>>, los estereotipos se ven ms adelante).
96
Figura 5: Auto-agregacin
Los diagramas de objetos son anlogos a los de clases, con la particularidad de que en lugar de encontrar
clases, encontramos instancias de stas. Son tiles para explicar partes pequeas del modelo en las que hay
relaciones complejas.
Diagrama de Componentes y Diagrama de Despliegue
Figura 6: Diagrama de Componentes
Los componentes son mdulos de cdigo, as que los diagramas de componentes vienen a ser los anlogos
fsicos a los diagramas de clases. Muestran como est organizado un conjunto de componentes y las
dependencias que existen entre ellos.
97
Los diagramas de despliegue sirven para modelar la configuracin hardware del sistema, mostrando qu
nodos lo componen.
Figura 7: Diagrama de Despliegue
Diagrama de Casos de Uso

Los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de vista de un observador
externo, enfatizando el qu ms que el cmo. Plantean escenarios, es decir, lo que pasa cuando alguien
interacta con el sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso
describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su
caf y el pan tostado
Figura 8: Diagrama de Casos de Uso nivel 1
En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempean. Se
representan mediante un hombre de palitos, de modo que en el ejemplo, Carlos es un Actor. Los Casos de
98
Uso se representan por medio de valos y las lneas que unen Actores con Casos de Uso representan una
asociacin de comunicacin.
Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo si tomamos por
separado Preparar pan y Preparar cafe, podemos bajar un nivel de descripcin y llegar a los siguientes
Casos de Uso.
Figura 9: Diagrama Casos de Uso nivel 2 A

Carlos tuesta el pan en la tostadora, despus lo unta con mantequilla y mermelada de fresa y se lo come,
posiblemente mojndolo en un caf.
Figura 10: Diagrama Casos de Uso nivel 2 B

Carlos calienta leche, aade caf y azcar al gusto y se lo bebe.
Los Casos de Uso suelen venir delimitados por fronteras o lmites, que definen una separacin entre lo que
es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeo. En las
figuras, esta separacin viene representada por medio de la caja que encapsula los valos.
El siguiente Caso de Uso es equivalente al primero, Desayuno, slo que en l se ha condensado la mxima
cantidad posible de informacin. En l se muestra un nuevo elemento que hasta ahora no se haba
mostrado, el estereotipo, que viene entre sendos smbolos angulados << y >> y concreta un paso ms
all el tipo de relacin existente entre dos Casos de Uso. Encontramos dos estereotipos <<include>> y
<<extend>>. El primero indica que el Caso de Uso Tostar pan requiere de Usar tostadora para poder ser
llevado a cabo. Esta es una forma muy adecuada de sacar factor comn entre Casos de Uso, o incluso de
Los Casos de Uso son acompaados por una explicacin textual que clarifica las posibles cadencias del
lenguaje meramente grfico. De esta manera, combinando Casos de Uso y explicacin textual, se puede
obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su
sencillez de comprensin incluso por quien no est familiarizado con UML. Los Casos de Uso se emplean
tambin en la preparacin de escenarios de pruebas con que verificar el software una vez ha sido
construido.
99
fraccionar Casos de Uso muy grandes. El segundo indica que el Caso de Uso Untar pan es una variacin de
Untar. Observamos tambin que Comer pan y Beber cafe son una generalizacin de Alimentarse.
Figura 11: Diagrama Casos de Uso nivel 1 detallado

Carlos va a desayunar. Para ello debe hacer dos actividades distintas, pero relacionadas. La primera
consisten en tostar pan, para lo cual necesita emplear una tostadora. Una vez tostado el pan, lo unta de
mantequilla y mermelada de fresa (untar pan no es muy distinto de untar otro tipo de alimentos). La
segunda consiste en preparar el caf, par lo cual necesita calentar leche y aadir caf y azuzar. Terminadas
ambas actividades, Carlos puede proceder a alimentarse, comiendo el pan tostado y bebiendo el caf. El
orden en que realice las actividades da igual y tambin da igual si se realizan a la vez.
Diagrama de Secuencia y Diagrama de Colaboracin
Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de
interaccin que detalla como las operaciones se llevan a cabo, qu mensajes son enviados y cuando,
organizado todo en torno al tiempo. El tiempo avanza hacia abajo en el diagrama. Los objetos
involucrados en la operacin se listan de izquierda a derecha de acuerdo a su orden de participacin dentro
de la secuencia de mensajes.
100
Figura 12: Diagrama de Secuencia

Las lneas verticales o lneas de la vida representan el tiempo de vida del objeto. La vida del objeto carlos
no termina en este diagrama, sin embargo la del objeto tosty s y esto viene representado mediante el
aspa al final de su lnea de la vida.
Los rectngulos verticales son barras de activacin y representan la duracin de la ejecucin del mensaje. El
mensaje Encender, posiblemente implementado mediante la introduccin del enchufe en una toma de
pared, tiene una duracin escasa y similar a la de Apagar. No ocurre lo mismo con la llamada al mtodo
tostar(), que dura desde la pulsacin del botn de tostar hasta que el pan es retirado de la bandeja y
adems interviene la emisin de un aviso cuando el pan est lo suficientemente caliente, a fin de evitar que
se queme.
Como se puede observar, la accin tostar viene condicionada por la presencia de pan en la bandeja de la
tostadora. En UML los corchetes [] expresan condicin y si estn precedidos de un asterisco indican
interaccin mientras se cumpla la condicin.
Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser sncronos o
asncronos. Los mensajes asncronos son aquellos tal que el emisor puede enviar nuevos mensajes mientras
el original est siendo procesado. El mensaje asncrono ocurre en el tiempo de manera independiente a
otros mensajes. Los mensajes sncronos son todo lo contrario, el emisor debe esperar a que termine el
tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML emplea los siguientes
convenios para representar el tipo de mensaje.
Significado
Mensaje simple que puede
ser sncrono o asncrono.
Mensaje simple de vuelta
(opcional).
Smbolo
101
Mensaje sncrono.
Mensaje asncrono.
Tabla 5: Tipos de mensaje en diagramas de interaccin
Los diagramas de colaboracin son otro tipo de diagramas de interaccin, que contiene la misma
informacin que los de secuencia, slo que se centran en las responsabilidades de cada objeto, en lugar de
en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboracin tiene un
nmero de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la
misma llamada a un mtodo se numeran 1.1, 1.2 y as sucesivamente para tantos niveles como sea
necesario.
Figura 13: Diagrama de Colaboracin
Diagrama de Estados y Diagrama de Actividades
Las transiciones son las lneas que unen los diferentes estados. En ellas se representa la condicin que
provoca el cambio, seguida de la accin oportuna separada por /. En un estado en que el objeto esta
pendiente de algn tipo de validacin que dependa de un proceso en curso, no es necesario evento externo
alguno para que se produzca la transicin, ya que sta ocurrir cuando termine el proceso, en funcin del
resultado de ste. En estos casos es conveniente, por claridad, incluir la condicin que de la que depende la
transicin (entre corchetes).
Los estados inicial, a partir del que se entra en la mquina de estados, y final, que indica que la mquina
de estados termina, no tienen otro significado adicional, son elementos ornamentales y se representan
mediante un circulo negro y un circulo negro resaltado respectivamente.
Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las
transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que
est llevando a cabo o de alguna condicin.
102
Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser
agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra subactividades asncronas o concurrentes.
Figura 15: Mquina de Estados, estados compuestos
Los diagramas de actividades son bsicamente diagramas de flujo adornados, que guardan mucha similitud
con los diagramas de estados. Mientras que los diagramas de estados centran su atencin en el proceso que
est llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las
dependencias entre ellas.
Figura 14: Mquina de Estados, estados simples
103
Los diagramas de actividades pueden dividirse en calles que determinan qu objeto es responsable de qu
actividad. Las actividades vienen unidas por transiciones, que pueden separarse en ramas en funcin del
resultado de una condicin expresada entre corchetes. Cada rama muestra la condicin que debe ser
satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o
ms actividades paralelas.
Figura 16: Diagrama de Actividades
104
Cmo utilizar UML

UML es simplemente un lenguaje de modelado. Define un conjunto de elementos y relaciones entre ellos,
que se emplean en la definicin de modelos. UML es tpicamente usado como parte de un proceso de
desarrollo, con la ayuda de una herramienta CASE (Computer Aided Software Engineering), para definir
requerimientos, interacciones y elementos del software que se est desarrollando. UML es independiente
de cualquier proceso particular, no est ligado a ningn ciclo de vida de desarrollo del software concreto, no
obstante se obtienen mayores beneficios si se selecciona un proceso que est dirigido por Casos de Uso, se
centre en la arquitectura y sea incremental.
La arquitectura de un sistema es el conjunto de decisiones significativas que se toma en torno a su

organizacin, la seleccin de elementos estructurales, la definicin de las interfaces entre estos elementos,
su comportamiento, su divisin en subsistemas, qu elementos son estticos y cuales dinmicos. La
arquitectura tambin incluye el uso que se le va a dar al sistema, la funcionalidad, el rendimiento, la
capacidad de adaptacin, la reutilizacin, la capacidad de ser comprendido, las restricciones econmicas, las
temporales, los compromisos entre alternativas y los aspectos estticos.
Un proceso incremental es aqul que consiste en sucesivas ampliaciones y mejoras de la arquitectura, a

partir de una lnea bsica. Cada incremento resuelve los problemas encontrados en la versin anterior
minimizando incrementalmente los riesgos ms significativos para el xito del proyecto.
Vista de Casos de Uso: Engloba los Casos de Uso que describen el comportamiento del sistema
como lo veran los usuarios finales, los analistas y dems componentes del equipo de desarrollo. No
especifica la organizacin del sistema. Con UML los aspectos estticos de esta vista se pueden
concretar con los diagramas de Casos de Uso; los aspectos dinmicos con los diagramas de
iteracin (secuencia y colaboracin), diagramas de estados y de actividades.
Vista de Diseo: Engloba las clases e interfaces que conforman el vocabulario del problema y su
solucin. Da soporte a los requisitos funcionales del sistema, es decir los servicios que proporciona
a los usuarios finales. Con UML los aspectos estticos de esta vista se pueden concretar con los
diagramas de clases y de objetos; los aspectos dinmicos con los diagramas de iteracin (secuencia
y colaboracin), diagramas de estados y de actividades.
Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos de sincronizacin y
concurrencia del sistema. Da soporte al funcionamiento, capacidad de crecimiento y rendimiento
del sistema. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de
clases, de clases activas y de objetos; los aspectos dinmicos con los diagramas de iteracin
(secuencia y colaboracin), diagramas de estados y de actividades.
Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una
metodologa de desarrollo que defina la naturaleza concreta del proceso a seguir. El modelo a definir en
base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un
aspecto o punto de vista del sistema. En general, independientemente del proceso que se emplee, se puede
encontrar las siguientes vistas:
105
Vista de Despliegue: Engloba los nodos que forman la topologa hardware sobre el que se ejecuta
el sistema. Da soporte a la distribucin, entrega e instalacin de las partes que conforman el
sistema fsico. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas
despliegue; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin),
diagramas de estados y de actividades.
Vista de Implementacin: Engloba los componentes y archivos empleados para hacer posible el
sistema fsico. Da soporte a la gestin de configuraciones de las distintas versiones del sistema, a
partir de componentes y archivos. Con UML los aspectos estticos de esta vista se pueden
concretar con los diagramas de componentes; los aspectos dinmicos con los diagramas de
iteracin (secuencia y colaboracin), diagramas de estados y de actividades.
1.
Iniciar y mantener reuniones con los usuarios finales del programa, para comprender sus
necesidades, el contexto en que lo usarn y todos los detalles necesarios para comprender el
mbito del problema a resolver. Esta informacin ser empleada para capturar las actividades y
procesos involucrados y susceptibles de ser incorporados en el programa, a un nivel alto, y
proporcionar la base para construir la vista de Casos de Uso.
2.
Construir la vista de Casos de Uso definiendo exactamente la funcionalidad que se va a incorporar

en el programa, desde el punto de vista de sus usuarios. El modelo resultante es realmente un
mapeo de la informacin obtenida en el paso anterior, en el que cada nuevo Caso de Uso realiza un
aspecto de la funcionalidad planteada. Refinar, en conjunto con los usuarios finales, todos los
diagramas de Casos de Uso, incluyendo requisitos y restricciones, para llegar a un acuerdo comn
en lo que el programa har y no har. En este punto puede ser conveniente disear escenarios de
prueba que ayuden a verificar si el programa finalizado cumple con las expectativas del contrato.
3.
Partiendo del modelo de Casos de Uso se comienza a estructurar los requisitos en una arquitectura
llamada lnea base. Se definen clases y relaciones entre ellas, los primeros diagramas de
secuencia y colaboracin, definiendo los comportamientos de cada clase, tambin las interfaces
entre los diferentes elementos de la arquitectura. Se construye aqu la vista de diseo y la vista de
procesos. Construir diagramas de clases ms elaborados y refinar los comportamientos del sistema.
4.
A medida que crece el modelo se puede fraccionar en componentes software y paquetes. Aparecen
nuevos requisitos que deben ser integrados. Se define la vista de despliegue, que define la
arquitectura fsica del sistema, y la vista de implementacin.
5.
Construir el sistema, repartiendo las tareas entre el equipo de programacin.
Un ejemplo de proceso para la construccin de un programa, podra ser similar al siguiente, teniendo en
cuenta que el proceso descrito deja muchas cosas por ampliar y puede no adaptarse a las necesidades
particulares de un grupo de trabajo determinado. Se proporciona meramente como un ejemplo de cmo se
puede encajar UML como soporte para el desarrollo de un proyecto:
106
Buscar errores de programacin, o incluso de diseo, corregirlos e ir sacando sucesivas versiones

del programa hasta llegar a una versin que cumpla con todos los requisitos especificados en el
contrato con los usuarios.
7.
Documentar y entregar el programa a los usuarios finales.
6.
107
CASO DE ESTUDIO ANLISIS Y DISEO ORIENTADO A OBJETOS

SISTEMA DE VOTACIN BIOELECTRNICA
La presente documento es el modelado de un sistema de votacin bioelectrnico que usa un dispositivo
elctrico para la lectura de la huella y automatiza el proceso de votacin en la universidad pblica
ecuatoriana y poner en la prctica modelado de sistemas de software que involucran complejidad y uso de
tecnologa web service - ws.
Se consideran los siguientes aspectos:

I.
II.
III.
IV.
V.
INTRODUCCIN
ESPECIFICACION DE REQUERIMIENTOS
DESCRIPCIN DE REQUERIMIENTOS
ANLISIS Y DISEO
CODIFICACIN
El presente trabajo consta del modelado y anlisis completo de un sistema de votacin bioelectrnica. He
diseado un WEB SERVICE para dar el ambiente cliente servidor, cabe considerar que el ambiente del cliente
es Windows por la necesidad de hacer uso del dispositivo para la lectura de huellas dactilares y se hace
indispensable que los controladores se instalen en las terminales.
EL modelado contempla un esquema completo a detalle de todo el sistema considerando la tecnologa de
web service, que en Microsoft es el uso de Windows Communication Foundation, servidores SQL SERVER
2008.
Finalmente la aplicacin es 100% funcional y probada, lista para ponerla en produccin para lo cual se
puede usar lectores biomtricos HAMSTER-Conexin USB, Modelo de ltima generacin en scanner de
huella dactilar con diseo ergonomtrico y moderno. Este sensor ptico utiliza la tecnologa patentada SEIR
(Surface Enhanced Irregular Reflection) de lectura biomtrica y es la solucin ideal para la autenticacin,
identificacin y verificacin biomtrica de personas, que garantizan el voto de los sobrantes reemplazando
todo tipo de credenciales como cedula y carnet.
108
Antecedentes
La Universidad estatal necesita un proceso que le garantice transparencia y rapidez en las elecciones
estudiantiles que se realizan cada ao.
Las caractersticas del sistema de votacin es hacer uso de un lector biomtrico que garantiza el ingreso del
estudiante y no un suplantador garantizando la seguridad del sufragio; al autenticarse biomtricamente el
votante tendr acceso a seleccionar la papeleta electrnica para realizar el voto correspondiente lo que
substituye al proceso de votacin tradicional.
La Universidad tienen reas que su ves estn formadas por carreras, cada carrera contiene de 8 a 10
Mdulos y las elecciones se realizan en una fecha especfica de cada ao donde se eligen presidentes,
vicepresidentes y tesorero a nivel de universidad y carrera.
Se consideran como estudiantes con participacin a sufragar s estn matriculados en el periodo los cuales
deben registrar sus datos personales y sus huellas digitales para el empadronamiento de acuerdo a un
periodo de votacin vigente.
Los partidos polticos se crean considerando el nmero de lista, nombre, descripcin y logotipo de campaa
y a estos se agregan los candidatos que se suscriben en la cual postulan por una dignidad considerando sus
datos personales, fotografa y descripcin de la misma. En funcin de los partidos polticos y sus candidatos
se estructuran las papeletas de votacin.
En el proceso de votacin los estudiantes deben acercarse al computador donde se identifica con su huella
dactilar a travs de un lector biomtrico la cual busca y validad su huella en el padrn electoral; luego, este
puede ejercer el voto donde se debe registrarse fecha y hora del sufragio, considerando el padrn electoral
activo, candidato(s) elegido(s) lo que determina el tipo de voto (valido, nulo o blanco).
La tecnologa se ha convertido en la actualidad en un elemento clave para llevar adelante tanto la
administracin, la organizacin como la realizacin del proceso electoral. Es esencial para la logstica de las
elecciones modernas a gran escala. Ms an, su apropiada aplicacin, permite aumentar la eficiencia
administrativa, reducir los costos a largo plazo y fortalecer la transparencia poltica.
Todo ello sin perder de vista tres objetivos fundamentales:
Respetar el voto, libre, igual, secreto y directo
Lograr una mayor participacin de los estudiantes.
Garantizar la transparencia de los actos comiciales.
En base a la urgente necesidad de automatizar los diferentes procesos de electorales, se propone la

construccin del Sistema de Votacin Electrnico mediante el sistema propuesto, el proceso electoral se
efectuar de una forma ms eficiente, mediante la implementacin de una administracin automtica de los
sufragantes, listas, dignidades, candidatos y de la recopilacin de los votos en si. Adems, al realizar el
proceso de forma automtica se realizara un conteo automtico de los votos lo cual podr ser corroborado
por un proceso de conteo manual de las papeletas impresas del sistema que reflejan los resultados
almacenados en el mismo.
En su gran mayora, las universidades han incorporado tecnologa en las distintas etapas de este proceso
(por ejemplo, hace tiempo que los padrones electorales, o registros electorales, se confeccionan a partir de
una base de datos computarizada) y continan hacindolo, particularmente, en lo que se refiere a la
transmisin y el procesamiento de los resultados.
109
Finalmente una vez concluido el proceso de votacin, se presentar las estadsticas grafica de resultados
donde se indicara cantidad de votos, candidatos votados y tipos de votos; esta informacin permite al
sistema presentar los reportes correspondiente de ganadores por cada una de las dignidades a elegidas.
ESPECIFICACION DE REQUERIMIENTOS
La especificacin de requerimientos se hizo bajo el estndar de la IEEE-830
En esta seccin se detallar el Modelo de Especificacin de Requisitos de Software (ERS) para el Sistema de
Votacin Electrnica para la Universidad e Instituciones acadmicas pblicas o privadas donde se emplea
acceso biomtrico al proceso de sufragio, para lo cual considero el estndar IEEE Recommended Practices
for Requirements Specification ANSI/IEEE st. 830, 1998. el cual se basa en las entrevistas realizadas a los
usuarios participantes y el estudio de la documentacin existente. El desarrollo del documento enmarca los
siguientes en algunos puntos que son abordados a continuacin.
Propsito
El objetivo primordial es analizar y documentar las necesidades funcionales que debern ser soportadas por
el sistema a desarrollar. Para ello, se identificarn los requisitos que ha de satisfacer el nuevo sistema
mediante entrevistas, el estudio de los problemas de las unidades afectadas y sus necesidades actuales.
Adems de identificar los requisitos se debern establecer prioridades, lo cual proporciona un punto de
referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario.
Esta especificacin de requisitos se encuentra dirigido a los principales usuarios del sistema como son: el
sector docente, al alumnado legalmente inscrito en la Universidad y apto para realizar el sufragio
correspondiente, al sector administrativo, y al grupo de administradores del sistema.
As mismo esta documentacin est sujeta a revisiones por el grupo de usuarios que se recogern por medio
de sucesivas versiones del documento, hasta alcanzar su aprobacin por parte de la direccin de (CLIENTE) y
del grupo de usuarios. Una vez aprobado, servir de base al equipo para la construccin del nuevo sistema.
El proyecto tiene la finalidad de desarrollar un sistema que permita el registro, control y administracin de
los datos generados durante los procesos de sufragio que realiza la Universidad Nacional de Loja, los mismos
que se cumplen por parte de los docentes, alumnos y los funcionarios administrativos de la Institucin. De
igual manera el sistema deber permitir obtener reportes de los resultados finales obtenidos y proceder a
archivarlos para posteriores consultas que los usuarios deseen realizar.
IEEE Recommended Practices for Requirements Specification ANSI/IEEE st. 830, 1998.
mbito y Alcance
110
Para ello se definirn los procesos y entes que intervienen en el desarrollo del sistema, esperando mantener
en todo momento un control eficaz del mismo as como de su correcto funcionamiento.
El futuro sistema se identificar como E-VOTE Sistema de Votacin bioelectrnico
Definiciones, acrnimos y abreviaturas

Definiciones:
Institucin: Organismo pblico o privado que se encuentra legalmente constituido.
Funcionario administrativo: Persona que trabaja en una Institucin y que cumple el rol de usuario
final en el proceso de sufragio para las elecciones de Rector de la Institucin Educativa.
Administrador: Usuario con privilegios de establecer las configuraciones necesarias en el sistema y
que le permiten registrar los resultados de un proceso de votacin.
Alumno: Usuario que cumple el rol de usuario final en el proceso de sufragio para todas las
elecciones estudiantiles.
Universidad: Institucin educativa que es la beneficiada directa con la implementacin del sistema
de votacin.
Biolectronica.- conjugacin de aspectos de datos biolgicos y la parte electrnica o circuitos que
interactan con el computador.
Abreviaturas y Acrnimos:
ERS: Especificacin de Requisitos del Software
E-VOTE: Sistema de Votacin Bioelectrnico
Visin General del Documento

Este apartado del documento consta de tres secciones, la primera contiene una visin general del sistema a
desarrollar. En la segunda seccin se describe el sistema, sus principales funciones, gestin de los datos y
factores que inciden en el sistema a nivel general. Y, en la ltima seccin se definen detalladamente los
requisitos que debe satisfacer el sistema.
Descripcin Global
Perspectiva del Producto

El Sistema es totalmente independiente de otros productos de software, es decir para su implementacin no
depende de otras aplicaciones de la Institucin para su funcionamiento.
La arquitectura de E-VOTE permite la integracin de este con otras instancias las instituciones, para lo cual
es necesario se incluya dentro del core del sistema un canal o interfaz de orientada a servicios.
En esta seccin se describe de manera general las principales funciones y restricciones que debe soportar el
sistema, as como cualquier otro factor que incida en la construccin del mismo.
111
Un esquema a nivel de base de datos que garantice procesos concurrentes y permita futuros acoples de
disponibilidad como mirror o backup a nivel de servicios, esto con la finalidad generar fiabilidad en los
proceso de sufragio.
Se considera obtener como un producto final un esquema como el que se muestra en la figura a
continuacin:
Se utilizara un aplicacin desktop para interactuar con el dispositivo la cual se conectara a una aplicacin
web service para acceder a la lgicas de negocio y finalmente este a la base de datos sql server 2008.
La parte tecnolgica se considera el uso de un lector de huellas que ofrezca seguridad y facilidad de uso para
lo cual se considera el siguiente dispositivo:
112
Funciones del Sistema

El objeto del sistema es convertirse en una herramienta de apoyo para efectuar de una manera ms ptima
los procesos de sufragio que la institucin lleva a cabo, para ello se deber cumplir con las siguientes
caractersticas funcionales:
BITCORA DE REQUERIMIENTOS
Responsable :
Versin del documento:

Patricio Michael Paccha Angamarca
Fecha de elaboracin:
REQ 01
ADMINISTRACIN DE LOGUEOS
Observaciones Requerimientos funcionales de las historias:
Formulario que permite el ingreso al administrador del sistema
Usuario
Administrador del Sistema
REQ 02
ADMINISTRACIN DE CANDIDATURAS
Observaciones
Requerimientos funcionales de las historias:
Formulario que permite ingresar o registrar los postulantes de cada uno de los
movimientos polticos que existen en la Universidad Nacional de Loja.
Usuario
REQ 03
ADMINISTRACIN DE ELECCIONES
Formulario que permite definir el periodo y tipo de eleccin, delimitar el grupo de
usuarios finales que podrn sufragar y determinar la fecha correspondiente en la cual se
desarrollar.
Usuario
REQ 04
ADMINISTRACIN DE ENTIDADES
Permite la administracin de las entidades o ventanas del sistema E-VOTE.
Usuario
REQ 05
ADMINISTRACIN DE PADRONES.
Formulario que permite registrar todos los usuarios autorizados y habilitados para sufragar
en un periodo especfico de elecciones, tanto de Alumnos, Docentes, Empleados y
Administrativos.
REQ 05
CONFIGURACION DE LOS PROCESOS PRINCIPALES DEL SISTEMA
Formulario principal desde el cual el administrador del sistema puede ir configurando los
parmetros de cada uno de los procesos del sistema.
Usuario
113
Usuario
REQ 06
ADMINISTRACIN DE PADRONES.
Formulario que permite registrar los datos para generar la papeleta electrnica
determinando el tipo y mbito de cada eleccin.
Usuario
REQ 07
ADMINISTRACIN DE PARTIDO.
Formulario que permite el registro de los partidos o movimientos polticos existentes en la
UNL, cada uno de estos tendr un nombre, sigla y logotipo y se asignar un cdigo nico
por partido.
Usuario
REQ 08
ADMINISTRACIN DE PERIODOS.
Formulario que le permite al administrador crear nuevos periodos de votacin los cuales
se desarrollaran en fechas y horarios especficos, as como tambin
Usuario
REQ 09
ADMINISTRACIN DE RESULTADOS
Formulario que permite tener una proyeccin grfica de los resultados obtenidos en un
periodo de elecciones de acuerdo a la dignidad elegida.
Usuario
REQ 10
ADMINISTRACIN DE USUARIOS
Formulario que permite registrar la informacin personal de los usuarios habilitados para
realizar el sufragio como son: estudiantes, docentes, administrativos y empleados de la
Institucin.
Usuario
REQ 12
Eleccin de dignidades
Formulario del proceso de votacin que permite seleccionar la dignidad eligiendo las
respectivas papeletas para ello.
Usuario
Sufragante
REQ 11
REGISTRO DE HUELLA DIGITAL
Formulario que permite adquirir la imagen de la huella digital de cada una de las personas
empadronadas para sufragar.
Usuario
Sufragante
114
DESCRIPCIN DE REQUERIMIENTOS
En esta seccin se realiza la descripcin de la Especificacin de Requisitos de Software (ERS) para
el Sistema de Votacin Electrnica para la Universidad e Instituciones acadmicas pblicas o
privadas donde se emplea acceso biomtrico al proceso de sufragio, bajo el estndar IEEE
Recommended Practices for Requirements Specification ANSI/IEEE st. 830, 1998.
REQ - 01
ALCANCE FUNCIONAL
Permite el acceso al sistema del administrador del mismo, as como de alumnos, docentes y personal
administrativo debidamente registrado en el sistema.
Cdigo:
Ttulo:
Descripcin:
Criterio de aceptacin:
Riesgo:
Estado:
EVOTE 001
Administracin de logueos
El administrador y usuarios finales pueden ingresar al sistema
digitando su nombre de usuario y contrasea y de acuerdo a ello se
autoriza los permisos respectivos para cada rol.
Referirse a los requerimientos no funcionales, requerimientos de
interfaz grfica de usuario, especificaciones y los test cases definidos
para el presente caso de uso sean cumplidos.
alto
validado
REQUERIMIENTOS FUNCIONALES.
Los usuarios que se encuentren registrados y hayan sido empadronados podrn ingresar al sistema, para lo
cual se autenticarn mediante su huella digital y podrn ser validados por el Sistema de acuerdo al rol de
cada usuario, y utilizar las funciones que le correspondan.
115
REQ - 02
ALCANCE FUNCIONAL
Permite registrar y configurar los partidos polticos, candidatos y el tipo de eleccin al que se postular un
candidato.
Cdigo:
EVOTE 002
Ttulo:
Administracin de candidaturas
Descripcin:
Riesgo:
El administrador del sistema puede registrar, crear, modificar a las

personas que sern autorizadas para ser candidatos polticos, junto con el
partido poltico al que pertenecen, y a que candidatura postulan.
Referirse a los requerimientos no funcionales, requerimientos de interfaz
grfica de usuario, especificaciones y los test cases definidos para el
presente caso de uso sean cumplidos.
alto
Estado:
Activo
El administrador del sistema puede registrar y habilitar el tipo de eleccin que se realiza en determinado
periodo, as como tambin la dignidad a elegir, partido poltico, postulante, cuyos datos se mostraran en la
papeleta virtual para el usuario final.
REQ - 03
ALCANCE FUNCIONAL
Permite registrar y configurar el tipo de eleccin que se realizar en determinado periodo.
116
Cdigo:
Ttulo:
Descripcin:
Riesgo:
EVOTE 003
Administracin de elecciones
El administrador del sistema puede configurar y habilitar una eleccin
para un periodo determinado, registrando el mbito, seccin a la que va
dirigida, as como la fecha en la cual se realizar.
alto
Estado:
validado
El administrador del sistema puede configurar una eleccin electoral, asignando los datos correspondientes
como nombre, descripcin, tipo, mbito y fecha en la que se llevar a cabo.
REQ - 04
ALCANCE FUNCIONAL
Permite registrar y configurar las entidades o pantallas del sistema para tener acceso de los usuarios que se
encuentran registrados.
Cdigo:
EVOTE 004
Ttulo:
Administracin de Entidades
El administrador del sistema puede configurar y manipular la informacin

en todos los procesos que contiene el sistema.
Riesgo:
alto
Estado:
validado
Descripcin:
117
El administrador del sistema puede habilitar las opciones que se visualizarn en cada pantalla en base a las
elecciones que se desarrollen.
118
REQ 05
ADMINISTRACIN DE PROCESOS DEL SISTEMA
ALCANCE FUNCIONAL
Permite habilitar una eleccin electoral configurando cada proceso del sistema, a fin de habilitar aquellas
entidades que el usuario final visualizar y tendr acceso.
Cdigo:
EVOTE 05
Ttulo:
Administracin de Procesos del Sistema
Descripcin:
El administrador del sistema puede configurar y manipular la informacin en

cada uno de los procesos que posee el sistema.
grfica de usuario, especificaciones y los test cases definidos para el presente
caso de uso sean cumplidos.
Riesgo:
alto
Estado:
validado
El administrador puede configurar todos los procesos del sistema como son: periodos, partidos, padrn
electoral, candidatos, usuarios, administrar una eleccin, las entidades y la proyeccin de resultados finales,
los cuales contendrn la informacin de acuerdo a las elecciones que se realicen.
REQ 06
ALCANCE FUNCIONAL
Permite que el administrador del sistema configure los procesos de eleccin y toda la informacin
concerniente a los mismos.
Cdigo:
EVOTE 06
ADMINISTRACIN DE PADRON ELECTORAL
119
Ttulo:
Descripcin:
Administracin de Padrn Electoral

El administrador del sistema puede configurar el padrn electoral de
acuerdo a la eleccin que se vaya a realizar.
grfica de usuario, especificaciones y los test cases definidos para el presente
caso de uso sean cumplidos.
Riesgo:
Alto
Estado:
validado
REQUERIMIENTOS FUNCIONALES
El administrador del sistema podr habilitar un padrn electoral teniendo registrado a todos los usuarios
autorizados para el sufragio.
REQ 07
ADMINISTRACIN DE PAPELETA ELECTORAL
ALCANCE FUNCIONAL
Permite que el administrador del sistema habilite una papeleta electoral de acuerdo al tipo de eleccin que
Cdigo:
EVOTE 07
Ttulo:
Administracin de Papeleta Electoral
Descripcin:
Pre-condiciones:
Pos-condiciones:
Riesgo:
Estado:
El administrador del sistema puede configurar la informacin que ser

visualizada por el usuario final del sistema.
Tener definido el tipo de eleccin que se vaya a realizar, el mbito de
eleccin y la seccin de usuarios que van a efectuar el voto.
Se visualiza la papeleta virtual de acuerdo tipo de usuario y eleccin.
alto
Validado
se realizar y al tipo de usuario que vaya a cumplir con el voto.
120
El administrador del sistema puede configurar la informacin que el usuario final visualizar en la papeleta
virtual, definiendo el mbito de la eleccin, tipo de eleccin y usuarios a la cual ser dirigida la eleccin.
REQ 08
ADMINISTRACIN DE PARTIDOS
ALCANCE FUNCIONAL
Permite que el administrador del sistema inscriba un partido poltico para que se visualicen en la papeleta
virtual de acuerdo al tipo de eleccin que se vaya a desarrollar.
Cdigo:
EVOTE 08
Ttulo:
Administracin de Partidos
Descripcin:
Pre-condiciones:
El administrador del sistema puede agregar la informacin de cualquier

partido poltico que se inscriba legalmente.
Tener definido los partidos polticos autorizados y su informacin
relevante.
Pos-condiciones:
Se visualizan los partidos polticos en las papeletas virtuales.
Riesgo:
Alto
Estado:
validado
El administrador del sistema puede configurar la informacin de los partidos polticos que han sido
autorizados por la Institucin, asignando el nombre del partido, la sigla y la insignia correspondiente.
121
REQ 09
ADMINISTRACIN DE PERIODOS
ALCANCE FUNCIONAL
Permite que el administrador del sistema habilite un periodo electoral.
Cdigo:
EVOTE 009
Ttulo:
Administracin de Periodos
Descripcin:
El administrador del sistema puede agregar el periodo de eleccin que

corresponda.
Riesgo:
alto
Estado:
validado
El administrador del sistema puede configurar el periodo asignndole el nombre respectivo, as como
tambin la fecha en la que se llevar a cabo el periodo de elecciones.
REQ 10
ADMINISTRACIN GRFICA DE RESULTADOS
ALCANCE FUNCIONAL
Cdigo:
EVOTE 10
Ttulo:
Administracin Grfica de Resultados
Descripcin:
El administrador del sistema puede proyectar los datos obtenidos luego de

sufragio en forma grfica.

122
Riesgo:
alto
Estado:
validado
El administrador del sistema puede proyectar los resultados finales en una grfica estadstica considerando
los reportes de cada sufragio que se realice.
REQ 11
ALCANCE FUNCIONAL
Permite que el administrador del sistema registre la informacin de cada uno de los usuarios que estn
autorizados para realizar el voto.
Cdigo:
EVOTE 11
Ttulo:
Administracin de Usuarios
Descripcin:
El administrador del sistema puede registrar todos los usuarios que tendrn
acceso a las entidades de votacin respectivamente, para lo cual tiene que
asignar la informacin que corresponde a cada uno de ellos.
Riesgo:
alto
Estado:
validado
El administrador del sistema registra la informacin que identificar a cada usuario, como es el nombre,
carrera, rea, imagen y registrar la huella digital para que pueda acceder de manera segura al sistema en el
momento que efecte el sufragio.
123
REQUERIMIENTOS NO FUNCIONALES
Transporte:
En un sistema informtico se debe cuidar la veracidad de los datos, para asegurar la confiabilidad l
transmitir informacin por la red, haciendo uso del web service implementado con Windows
communication foundation.
La transferencia de informacin, debe de ser uno de los requisitos fundamentales, ya que de este
depende el funcionamiento del sistema, esto lo logramos a travs de la tecnologa electrnica, la
informacin viaja a grandes distancias y a una velocidad muy alta.
Persistencia:
La persistencia es una propiedad muy importante en un sistema informtico moderno al eliminar la
dualidad de tratamiento del almacenamiento a corto y a largo plazo.
Toda la informacin puede ser persistente y debe ser manipulada de la misma manera,
independientemente del tiempo que deba persistir.
Seguridad:
Requerimientos relacionados con la confidencialidad de los datos en la transmisin y en el
almacenamiento, junto con las necesidades del sistema para evitar intrusiones no autorizadas al
mismo y la capacidad para seguir eventos que comprometan esta seguridad a travs del tiempo.
Presentar procesos de autenticacin al sistema
Empleo de canales seguros
Almacenamiento cifrado para informacin de acceso al sistema
Uso de sesiones de usuario
Capacidad para realizar auditoria al sistema
Los tems que se consideran para esta categora son los siguientes:
124
Escalabilidad:
Estos requisitos hacen referencia a la capacidad del sistema para acoplar mdulos componentes y
extensiones, presentan directrices en el diseo y la arquitectura, sugiere el empleo de tendencias
en tecnologas que puedan permitir al sistema tener vigencia en su diseo por lo menos en un
periodo de tiempo considerable, de tal manera que los componentes de extensin que se
propongan puedan ser desarrollados basados en tecnologas conocidas.
Los criterios que se tienen en cuenta en esta categora son los siguientes:
Diseo de la arquitectura empleando mdulos independientes acoplables.
Empleo de tendencias en tecnologa (XML, WEB SERVICE) para hacer el sistema

compatible con otros sistemas.
Mdulos funcionales a los que se pueda agregar, posteriormente, nuevos componentes

funcionales
Rendimiento:
Los requerimientos clasificados en esta categora estn relacionados con tiempos de respuesta
estimados, requeridos y esperados para la ejecucin en lnea de procesos del sistema, teniendo
como base la plataforma tecnolgica y escenarios especficos a los que en teora el sistema estar
expuesto y frente a los que deber responder.
Los tems de calidad que se consideran para esta categora son los siguientes:
Tiempos de respuesta esperados para ejecucin de procesos generales.
Planeacin de secuencias de procesos del sistema (procesos ETL) para mantener calidad
de servicio en trminos de tiempos de respuesta.
Tasa esperada de velocidad de respuesta dada la tasa de clientes conectados.
125
ANLISIS Y DISEO
Se considera el conjunto o disposicin de procedimientos o programas relacionados de manera
que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y
dispuestas de manera ordenada mostrando un plan lgico en la unin de las partes.
El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito
de definir un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y
realizacin fsica.
La etapa del Diseo del Sistema encierra cuatro etapas:
El diseo de los datos, Trasforma el modelo de dominio de la informacin, creado durante el
anlisis, en las estructuras de datos necesarios para implementar el Software.
El Diseo Arquitectnico, Define la relacin entre cada uno de los elementos estructurales del
programa.
El Diseo de la Interfaz, Describe como se comunica el Software consigo mismo, con los
componentes que operan con los operadores y usuarios que lo emplean.
El Diseo de procedimientos, Transforma elementos estructurales de la arquitectura del
programa. La importancia del Diseo del Software se puede definir en una sola palabra Calidad,
dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de
materializar con precisin los requerimientos del cliente.
ROADMAP
El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto
de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a
construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de
revisiones tcnicas lo cual debe ser estructurado y organizado.
El presente proyecto se esquematiza todos los elementos que sern parte del anlisis y del diseo:
126
analysis Readme
Business Rules
E- VOTE RoadMap
Functional
Requirements
Features
User Interface
Requirements
Performance
Scalability
Non-Functional
Requirements
Security
Persistence
Actors
Transport
Use Case
Ecenarios
01 GUI
Frameworks
Domain Model
Logical Model
Sistema de votacion
bioelectronica
02 Domain
Class
Design Model
Data Model
03 Data Class
Model
04 Data Base
Schema
Sequence
Dynamic View
Collaboration
State
Component
Model
Activity
Deployment
Model
En la ingeniera de sistemas, un requerimiento es una necesidad documentada sobre el contenido,

forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniera de
sistemas o la ingeniera de software.
Se realiz tres tipos de requisitos:
REQUIREMENTS
127
Un requisito funcional: es una descripcin de lo que un sistema debe hacer. Este tipo de
requisito especifica algo que el sistema entregado debe ser capaz de realizarse.
Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio
sistema, y cmo debe realizar sus funciones.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto.
Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuacin a
leyes o regulaciones aplicables al producto
Se consideraron los siguientes aspectos a modelar:

analysis Readme
Business Rules
Functional
Requirements
Features
User Interface
Requirements
Performance
Scalability
Non-Functional
Requirements
Security
Persistence
T ransport
Los requerimientos funcionales:
Se consideran reglas de negocios

Caractersticas
Requerimientos de interfaz de usuario
Cada uno de estos requerimientos mantiene cdigo de secuencia segn la captura de los
requerimientos con el prefijo REQ.
Modelado de requerimientos usando Enterprise Architect
128
129
FEATURES
FUNCTIONAL REQUIREMENTS
130
custom Features
Features typically describe discrete pieces of functional behavior that yield a

specific result.
REQ 01.1 Iniciar la apliacion con

SplashScreen
REQ 01 Ingresar al
sistema
REQ 01.2 Autenticarse al ingresar

al sistema
REQ 01.3 Presentar un formulario

principal
REQ 01.4 Autenticar

biometricamente al
sufragante
REQ 11.1 Cerrar sesion de base

de datos
REQ 11.2 Cerrar sesion de

aplicacion
REQ 11.3 Apargar Dispositivo

lector de huella
BUSINESS RULES
REQ 11 Salir del sistema
131
02 Administrar Entidades
132
custom Administar Entidades

REQ 02.1
Agregar entidad
REQ 02.2
Actualizar entidad
REQ 02 Administar
Entidades
REQ 02.3
Eliminar entidad
REQ 02.4
Consultar entidad
03 Administrar configuracin de Elecciones
133
custom Administrar configuracin de Elecciones

REQ 03.1 Agregar
configuracin de
Elecciones
REQ 03 Administrar
configuracin de
Elecciones
REQ 03.2 Actualizar

configuracin de
Elecciones
REQ 03.3 Eliminar
configuracin de
Elecciones
REQ 03.4 Consultar
configuracin de
Elecciones
04 Administrar Estudiante
custom Administracion de Estudiante

REQ 04.1 Agregar
Estudiante
REQ 04.2 Actualizar

Estudiante
REQ 04.3 Eliminar

Estudiante
REQ 04.4 Consultar

Estudiante
REQ 04 Administrar
Estudiante
134
06 Administrar partido poltico
custom Administrar partido poltico

REQ 06.1 Agregar partido
poltico
REQ 06 Administrar
partido poltico
REQ 06.2 Actualizar partido

poltico
REQ 06.3 Eliminar partido
poltico
REQ 06.4 Consultar partido

poltico
07 Administracin de administradores del sistema
135
custom Administracion de administradores del sistema

REQ 07.1 Agregar
administrador
REQ 07 Administracion de
administradores del
sistema
REQ 07.2 Actualizar

administrador
REQ 07.3 Eliminar

administrador
REQ 07.4 Consultar
administrador
08 Administrar Candidatura
custom Administrar Candidatura

REQ 08.1 Agregar
Candidatura
REQ 08.3 Eliminar

Candidatura
REQ 08.4 Consultar
Candidatura
REQ 08 Administrar
Candidatura
REQ 08.2 Actualizar

Candidatura
136
09 Sufragio de Estudiante
custom Sufragio de Estudiante

REQ 09.1 Registrar huella
del estudiante
REQ 09.2 Validar Huella

del Estudiante
REQ 09.3 Organizar Papeleta

electronica con candidatos
postulados
REQ 09.4 Sufregar seleccionando un

candidato de la papeleta
electronica
REQ 09.5 Validar votacion

del estudiante
REQ 09.6 Imprimir

comprobante de
votacion
REQ 09 Sufragio de
Estudiante
137
10 Resultado de los comicios electorales
custom Resultado de los comicios electorales

REQ 10.1 Reporte con graficas de
Ganadores
REQ 10 Resultado de los

comicios
electorales
REQ 10.2 Reporte de

sufragantes
REQ 10.3 Reporte con graficas de Votos

validos, nulos y blancos
Esquema de Navegacin
USER INTERFACE
138
custom User Interface

frmSplashScreen
The User Interface package contains high level
descriptions of end-user visible screens and forms
which are required to support the proposed system.
frmVotacin
navigate
frmMostrarPapeleta
frmAdminLog
Screen elements model
proposed user interface
components.
navigate
frmFingerLogin
navigate
frmMain
UI Controls model
various common user
interface control types
navega
navega
navega
frmPartidoPolitico
frmPadron
frmConfigurarEleccin
frmEntidad
navega
navega
frmCandidato
frmEstudiante
frmResultados
navega
frmAdministrador
navega
139
NON-FUNCTIONAL REQUIREMENTS
Para este sistema se consideran aspectos de:
Rendimiento,
Escalabilidad,
Seguridad
Persistencia
Transporte
Estos aspectos se modelan a continuacin:
140
custom Non-Functional Requirements
These packages contain non-functional requirements specified for the new system. These
typically describe performance criteria, reliability, security and other operational parameters.
T ransport
El paquete de transporte define las limitaciones y

los requerimentos que afectan la transmisin de
informacin entre los puntos o nodos. Las redes,
rels, protocolos de transmisin de la calidad de
servicio e incluso de los medios fsicos se incluyen
aqui.
WCF - SOAP
Persistence
Back-Up
El paquete de persistencia detalla el criterio de

funcionamiento y de comportamiento
relacionados con el almacenaje de la
informacin, incluyendo casos de redundancia
pertinentes, copias de seguridad, sistemas de
base de datos, archivos y otros mecanismos de
alamacenaje persistentes.
Imagenes
Huellas
Digitales
Security
Encriptacin
Huellas Digitales
Logueo
El paquete de seguridad detalla los

requerimientos con respecto al acceso de datos
(seguridad de la informacin) y a la seguridad
fsica ( acceso a servidores y a otro hardware
crtico)
Scalability
WCF
Arquitectura
Base de Datos
Los requerimientos de escalabilidad definen los

parmetros de funcionalidad con respecto al
tamao del sistema, numero de transacciones,
capacidad, numero de usuarios y distribucin de
nodos.
FrontEnd
Lector de Huella
Ingreso al
Sistema
Pantallas
Los requerimientos de comportamiento definen

parmetros tales como transacciones por segundo,
red de trabajo, condicin de tiempos de carga de
forma y otros aspectos cuantificables del sistema que
rigen la velocidad y la capacidad de respuesta.
Perform ance
141
USE CASE
Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo
algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores.
Los diagramas de casos de uso sirven para especificar la comunicacin y el comportamiento de un sistema
mediante su interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la
relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin entre los
elementos del modelo, por ejemplo la especializacin y la generalizacin son relaciones. Los diagramas de
casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona a eventos
que se producen en su mbito o en l mismo.
analysis Readme
Actors
Use Case
Ecenarios
Sistema de votacion
bioelectronica
ACTORES:
uc Actores
Administrador
Actor que se encarga

de la administracion
del sistema
actor que realiza la

votacion
Candidato
estudiantes que se
participa como
candidatos en un
partido politico
Estudiante
142
FUNCTION USE CASE
143
DIAGRAMA - GENERAL USE CASE
144
uc 01 VOTACIN BIOELECTRNICA
F1 Ingresar al
sistema
F2 Administrar
entidades
Se realiza a travez de un dispositivo

electronico conectado al pc donde se
lee cada una de las huellas de los
dedos uno a uno
F3 Administrar
configuracin de
Elecciones
Permite el acceso al sistema al

administrador y estudiantes
debidamente registrado en el
sistema.
Permite registrar y configurar las

entidades como:
Universidad, areas, carreras y
modulos
Permite configurar la eleccin

electoral vigente
F4.1.1 Validacion de
Huella dactilar
Permite que el
administrador y usuario
actualize, ingrese, vea y
borre sus datos y huellas
dactilares
include
F4 Administrar
estudiante
sufragante
Administrador
F9 Sufragio de
Estudiante
Estudiante
F5 Empadronamiento
A
Permite el sufragio electronico de un

representante estudiantil y luego se
debe entregar un COMPROBANTE
DE VOTACION
F6 Administrar partido
poltico
F7 Administrar
administradores del
sistema
Permite que el administrador

del sistema valide y verifique
los datos de los estudiantes
que van a sufragar

del sistema inscriba un partido
poltico para que se visualicen
en la papeleta virtual de
acuerdo al tipo de eleccin
que se vaya a desarrollar.

actualize, ingrese, vea y borre
sus datos
F8 Administrar
Candidatura
Permite que el administrador y

candidato inscriba un partido poltico
para que se visualicen en la papeleta
virtual de acuerdo al tipo de eleccin
que se vaya a desarrollar.
F11 Sallir de Sistema

del sistema habilite un periodo
electoral.
Cerrar y apagar o suspender

dispositivos ligados al
sistema
F10 Resultado de los

comicios electorales
Candidato
145
ECENARIO - USE CASE
146
DESCRIPTION ECENARIO - USE CASE
Escenario I
sd Interaction - Administrador
frmSplashScreen
frmAdminLog
frmMain
(from User Interface)
Candidato
Administrador
Hace click para iniciar el

sistema()
Carga el splah del
sistema()
presenta pantalla de
legeo()
Ingresa su login y password()
Valida los datos ingresados()

[si datos validos]:carga datos de adminsitrador()
[si datos del administrador ]:personalizar

menus()
cierra la
apliacacion()
cerrar seciones levantadas()
147
Escenario II
sd Interaction - Estudiante
frmFingerLogin
frmVotacin
Estudiante
registra su Huella dactilar()
validar
huella()
[si huella valida]:presenta la pantalla de
sufragio()
[huella NO valida]:mensaje(datos no
validos)
148
sd Interaction
frmMain
frmEntidad
Administrador
selecciona abrir administracion de

entidad()
presenta el
formulario()
selecciona insertar nueva entidad del

sistema()
Valida y guardar datos()
selecciona modificar entidad del

sistema()
selecciona eliminar entidad del

sistema()
consultar datos de las entidades del sistema()
149
sd Interaction
frmMain
frmConfigurarEleccin
Administrador
selecciona abrir administracion de configuracion de elecciones()
presenta el formulario()
selecciona insertar nueva configuracion de elecciones()
selecciona modificar configuracion de elecciones()
selecciona eliminar configuracion de elecciones()
selecciona consultas la configuracion de elecciones()
150
sd Interaction
frmEstudiante
frmFingerLogin
Administrador
selecciona abrir administracion de Estudiantes()

presenta formulario()
ingresa datos del estudiante()

presenta formularios()
ingresa la huella digital()

valida huella()
valida los datos y guarda()
ingresa datos a modificar de estudiante()

valida los datos y guarda()
elimina datos del estudiante()
consulta sus datos()
consulta datos del estudiante()
Estudiante
frmMain
151
sd Interaction
frmMain
frmEstudiante
Administrador
selecciona llamar al formulario estudiante()
valida requisitos para el empadronamiento()

empadronamiento()
guarda datos()
152
sd Interaction
frmMain
frmPartidoPolitico
Administrador
selecciona abrir administracion de partido politico()
presentar formulario()
ingresar datos del partido politico()

validar datos y guardar()
ingresar datos a modificar de partido politico()
validar datos y guardar()
eliminar datos del partido politico()
consultar datos del partido politico()
153
sd Interaction
frmMain
frmAdministrador
Administrador
Selecciona administrar datos del administrador()
ingresa datos del administrador()
validad y guarda los datos()
modifica los datos del administrador()
validad y guarda los datos()
eliminar datos del administrador()
consultar datos del administrador()
154
sd Interaction
Candidato
frmMain
frmCandidato
Certificacion
Administrador
Solicita postulacion()
validad datos de postulacion()
selecciona Administracion de candidato()
ingresa datos del candidato()
validad y guarda datos()

modificar datos del candidato()
validad y guarda datos()
[si no cumple requerimientos]:eliminar cadidatura()
selecciona consulta o reportes()
imprime certificacion()
[datos correctos de postulacion]:valida()
entrega y Firma certificacion()
155
sd Interaction
Administrador
frmAdminLog
frmVotacin
frmFingerLogin
Certificado de
votacion
Estudiante
selecciona opcion sufragar()
el actor de autentica ()
presenta formulario de registro de huella()
registra la huella()
valida la huella()
[huella valida]:seleccionar papeleta electoral ()
valida voto y guarda()

imprime certificado de votacion()
entregar certificado de votacion()
156
sd Interaction
Candidato
frmMain
frmResultados
Reporte
Administrador
Seleciona presentar resultados()
selecciona resultados de votacion()
presenta el reporte()
imprime el reporte()
se entrega el reporte()
firma y entrega el reporte()
sd Interaction
frmMain
Administrador
Selecionar Cerrar aplicacion()
cerrar sesion de aplicacion()
cerrar seccion de base de datos()
cerrar aplicacion()
cerrar session de webservice()
157
DIAGRAMA SPECIFIC USE CASE
CU: F4.1 CREAR ESTUDIANTE

uc 02 Administrar Estudiante
F4 Administrar
estudiante
sufragante
Estudiante
Administrador
F4.2 Modificar
Estudiante
F4.1 Crear
Estudiante
include
F4.4 Consultar
Estudiante
F4.3 Borrar
Estudiante
include
F4.1.1 Validacion de
Huella dactilar
F4.4.1 Consulta
parametrizada
F4.4.2 Consulta
General o totalizada
include
Flujo Principal
1. El actor selecciona administrar estudiante
2. El sistema presenta pantalla administrar estudiante
3. El actor ingresa sus datos personales del estudiante
4. El sistema valida los datos ingresados
5. El actor ingresa la huella digital.
6. El actor presiona grabar
7. El sistema almacena los datos
8. El sistema presenta un mensaje de datos almacenados con xito
Flujo Alterno
9. Ir al caso de uso F4.1.1, se validan la huella digitada
Excepciones
5) Error de la lectura de la huella digital del lector de huellas.
7) Error de conexin en base de datos
F4.1.1.1 Leer Huella

dactilar
158
Lo mismo se repite para F4.2
159
CU: F6 CREAR PARTIDO POLTICO

uc 03 Administrar Partido Politico
F6 Administrar partido
poltico
Administrador
F6.1 Crear Partido

Politico
F6.2 Modificar
Partido Politico
F6.3 Borrar Partido

Politico
F6.4 Consultar
Partido Politico
F6.4.1 Consulta
parametrizada de
Partido Politico
F6.4.2 Consulta
general o totalizada
de Partido Politico
Flujo Principal
1. El actor selecciona administrar partido poltico
2. El sistema presenta pantalla administrar partido poltico
3. El actor ingresa sus datos del partido poltico
4. El sistema valida los datos ingresados
5. El actor presiona grabar
7. El sistema presenta un mensaje de datos almacenados con xito
Flujo Alterno
8. Se debe primero ir a F3. Administracin de configuracin de elecciones
Excepciones
Lo mismo se repite para F2, F3, F7, F8, F10
160
Flujo Principal
1. El actor selecciona administrar papeleta electoral
2. El sistema presenta pantalla papeleta electoral
3. El sistema presenta las papeletas electorales que se puede seleccionar el candidato
4. El actor selecciona papeleta electoral
5. El sistema valida los datos seleccionados
7. El sistema presenta un mensaje de votacin exitosa
Flujo Alterno
8. Ir al caso de uso F4.1.1, se validan la huella digitada
Excepciones
2) Error al organizar la papeleta electoral
CU: F9.1. COMPONENTE DE PAPELETA ELECTORAL
161
DOMAIN MODEL
analysis Readme
Domain Model
Sistema de votacion
bioelectronica
Su relevancia radica en que si no comprendemos el dominio del problema y las reglas de negocio y
los elementos principales a mostrar en el modelo conceptual son:
Conceptos. Elemento lgico o fsico que ayuda a entender el problema, es parte del
lenguaje utilizado por el cliente y generalmente se nombra como sustantivo. Se
representan con el smbolo de una clase. Ejemplo: Estudiante, voto, etc.
Atributos. Informacin que caracteriza al concepto en el mundo real. Se muestra en el

segundo compartimiento de las clases. Ejemplo: Nombre, apellidos y edad del cliente.
Asociaciones. Relaciones lgicas o fsicas que existen en el mundo real entre dos
conceptos. Si puedes armar una frase con dos conceptos significa que la puedes
representar mediante una relacin de asociacin entre esos dos conceptos.
Rol. El rol tambin puede aclarar la relacin entre dos conceptos, indica el rol que juega un
concepto con respecto a otro en una relacin de asociacin.
Multiplicidad. El nmero de instancias de un concepto relacionados con el otro concepto.
Generalizacin. En lugar de poner una asociacin para armar la frase es-un-tipo-de

podemos poner una generalizacin
Agregacin y composicin. Indican una relacin donde uno de los conceptos es el

contenedor del otro.
Considerado todas estas caractersticas del modelado se tiene el siguiente modelado:
162
obj ect Domain Problem Model Obj ect
The Domain Model is a view of all the objects

that make up an area of interest, and their
relationships. It is used to capture the significant
objects within a system, organization or any target
domain.
Hereda de estudiante,
pues para ser
candidato debe ser
estudiante
:Estudiante
Domain Model
el voto es el resultado
de la asociacion entre
un estudiante y la
papeleta electoral
para adminsitrar informacion jerarquica

+Universidad
+ Area
+ Carrera
+ Semestre
Univ ersidad :Entidad
:Voto
sufraga
1
la relacion entre un candidato

y un partido politico es
mediante una postulacion que
se representa como una
dignidad (presidente,
vicepresidente, tesorero)
tiene
1..*
TipoVoto
es
Area :Entidad
1
:Candidato
1
tiene
tiene
1..*
Entidad que permite

configurar el proceso
de votacion
Carrera :Entidad
Dignidad
postula
1
define
1..*
:PartidoPolitico
:PapeletaElectoral
Compone
1..*
:ConfigurarEleccion
implica
1..*
pat_mic :Administrador
1..*
163
DESIGN MODEL
analysis Readme
01 GUI
Frameworks
Logical Model
Sistema de votacion
bioelectronica
02 Domain
Class
Design Model
Data Model
03 Data Class
Model
04 Data Base
Schema
Se modelo aspectos de la arquitectura por capas:

Logical model
01 GUI Interfaz grfica de usuario, donde con templa cada una de las formularios que el usuario
utilizara.
02 Domain Class Clases correspondientes a las clases de negocio o dominio del problema
Data model
03 Data Class Model Clases que se encarga de enviar la informacin a la base de datos
04 Data Base Shema Esquema de la base de datos a implementar sobre motor de SQL Server
2008
Esquema de modelado:
164
165
166
DESIGN MODEL Logical Model
01 GUI
Diagrama de clase de los formularios que representan la interfaz grfica de usuario y se considera
un <<interface>> para obligar a las clases a implementar mtodos generales
167
class GUI Framew orks
01 GUI - SISTEMA DE VOTACION BIOELECTRONICA

El formulario debe
aparecer cuando el
sistema se inicia
FrmSplashScreen
-
imagenBackground: image
imagenLogoAplicaion: image
Descripcion: string
version: string
credito: string
+
+
+
FrmSplashScreen() : void
showSplashScreen() : void
close() : void
Formulario central del

sistema que permite el
llamado a los demas
formularios
property get
+ getimagenBackground() : image
+ getimagenLogoAplicaion() : image
property set
+ setimagenBackground(image) : void
+ setimagenLogoAplicaion(image) : void
FrmLogin
El formulario permite
el ingreso de
identificacion y clave
al adminitrador usuario del sistema
Formulario que
permite el sufragio del
estudiante
nroIntentos: int
+
+
+
+
FrmLogin() : void
bntIngresar(object, EventArgs) : void
btnCancelar_Click(object, EventArgs) : void
close() : void
FrmPrincipal
+
+
+
+
+
+
+
+
+
+
+
+
+
+
FrmPrincipal() : void
showMenu() : void
showFrmSplashScreen() : void
showFrmLogin() : boolean
mnShowFrmEstudiante() : void
mnShowFrmPartidoPolitico() : void
mnShowFrmSufraga() : void
mnShowFrmAdministrador() : void
mnShowFrmCandidato() : void
mnShowFrmConfigurarEleccion() : void
mnShowFrmEntidad() : void
mnShowFrmDignidad() : void
mnShowFrrmPapeletaElectoral() : void
FrmSufraga
+
+
+
+
+
+
+
FrmSufraga() : void
PapeletasVotacion(int, List<Candidato>) : void
cargarPapeletas() : void
Candidatos(ConfigurarEleccion) : void
GetSetPapeleta(int, ConfigurarEleccion) : void
btnSetPapeleta_Click(object, EventArgs) : void
btnIniciarVotacion_Click(object, EventArgs) : void
1
1
FrmLeeHuella
+
+
+
+
+
+
FrmLeeHuella() : void
encenderDispositivo() : void
apagarDispositivo() : void
leerHuella() : bytes[]
validaNitidezHuella() : boolean
close() : void
FrmResultadoVotacion
+
+
+
+
+
+
+
+
+
+
presentarDatos() : void
setSizeGraphic() : void
cmbTipoEleccion_SelectedIndexChanged(object, EventArgs) : void
btnGenerar_Click() : void
crearGraphBar(ZedGraphControl, ConfigurarEleccion) : void
contextMenuBuilder(object, EventArgs) : void
presentarSaveAsForExportCSV(object, System.EventArgs) : void
generarCSVToStream() : void
verificarCSVString(string) : void
btnExportar_Click(object, EventArgs) : void
Formulario que
muestra los reportes
del sistema
El formulario permite
la lectura de la huella
dactilar - controla el
dispositivo electronico
168
169
class GUI Framew orks
01 GUI - SISTEMA DE VOTACION BIOELECTRONICA

FrmPrincipal
FrmPrincipal() : void
showMenu() : void
showFrmSplashScreen() : void
showFrmLogin() : boolean
mnShowFrmPartidoPolitico() : void
mnShowFrmSufraga() : void
mnShowFrmAdministrador() : void
mnShowFrmCandidato() : void
mnShowFrmConfigurarEleccion() : void
mnShowFrmEntidad() : void
mnShowFrmDignidad() : void
mnShowFrrmPapeletaElectoral() : void
FrmAdministrador
Formulario central del sistema

que permite el llamado a los
demas formularios
El uso de una Interfaz permite la

implementacion de metodos que
describen operaciones generales en los
formularios del sistema
Cada formulario mantiene como variable una entidad del

dominio del problema que representa la entidad actual con
la que el Actor interactua.
Asi mismo se mantiene un listado de entidades que permite
llenar grillas para la seleccion del Actor
interface
AdministracionBasica
+ OpcionSeleccionada: int
administradorActual: Administrador
listadoAdministradores: List<Administrador>
+
+
+
+
+
+
+
+
+
+
+
FrmAdministrador() : void
limpiarControlesDatos() : void
validarDatosIngresados() : void
cargarDatoSolicitado(string) : boolean
cargarListadoDatos() : boolean
seleccionElementoGrilla(object, EventArgs) : void
btnNuevo_Click(object, EventArgs) : void
btnGuardar_Click(object, EventArgs) : void
btnEliminar_Click(object, EventArgs) : void
btnBuscar_Click(object, EventArgs) : void
btnSalir_Click(object, EventArgs) : void
candidatoActual: Candidato
listadoCandidato: List<Candidato>
+
+
+
+
+
+
+
+
+
+
+
FrmCandidato() : void
configuracionEleccionActual: ConfigurarEleccion
listadoConfigurarEleccion: List<ConfigurarEleccion>
+
+
+
+
+
+
+
+
+
+
+
FrmConfigurarEleccion() : void
dignidadActual: Dignidad
listadoDignidad: List<Dignidad>
entidadActual: Entidad
listaldoEntidad: List<Entidad>
+
+
+
+
+
+
+
+
+
+
+
FrmDignidad() : void
+
+
+
+
+
+
+
+
+
+
+
FrmEntidad() : void
+
+
+
+
+
+
+
+
+
+
FrrmPapeletaElectoral
papeletaElectoralActual: PapeletaElectoral
listadoPapeletaElectoral: List<PapeletaElectoral>
+
+
+
+
+
+
+
+
+
+
+
FrrmPapeletaElectoral() : void
partidoPoliticoActual: PartidoPolitico
listadoPartidoPoliticos: List<PartidoPolitico>
+
+
+
+
+
+
+
+
+
+
+
+
FrmPartidoPolitico() : void
txtBuscar_LostFocus(object, EventArgs) : void
FrmCandidato
FrmPartidoPolitico
FrmConfigurarEleccion
FrmEstudiante
FrmDignidad
FrmEntidad
estudianteActual: Estudiante
listadoEstudiante: List<Estudiante>
+
+
+
+
+
+
+
+
+
+
+
+
FrmEstudiante() : void
txtBuscar_LostFocus(object, EventArgs) : void
+
+
+
+
+
+
+
+
+
+
+
+
+
+
170
02 DOMINIO DE PROBLEMA
Se considera una <<interface>> para obligar a las clases a implementar mtodos generales y
comunes
171
class 02 Domain Class
02 Domain Class - SISTEMA DE VOTACION BIOELECTRONICA

Estudiante
Candidato
codCandidato: int
foto: image
estado: char(1)
fechaCandidatizacion: date
fechaActualizacion: date
elegido: boolean
+
+
+
+
+
add() : int
update() : boolean
delete() : boolean
getByCod(string) : boolean
validate() : boolean
interface
BasicOperation
+
+
+
+
+
property get
+ getcodCandidato() : int
+ getfoto() : image
+ getestado() : char(1)
+ getfechaCandidatizacion() : date
+ getfechaActualizacion() : date
property set
+ setcodCandidato(int) : void
+ setfoto(image) : void
+ setestado(char(1)) : void
+ setfechaCandidatizacion(date) : void
+ setfechaActualizacion(date) : void
add() : boolean
update() : boolean
delete() : boolean
descripcion: string
property get
+ getdescripcion() : string
property set
+ setdescripcion(string) : void
PartidoPolitico
-
codPartidoPolitico: int
nombre: string
sigla: string
logotipo: imagen
estado: char(1)
fechaInscripcion: date
+
+
+
+
+
+
+
add() : int
getAll() : List<PartidoPolitico>
update() : boolean
delete() : boolean
Afiliarse(Dignidad) : boolean
property get
+ getcodPartidoPolitico() : int
+ getnombre() : string
+ getsigla() : string
+ getlogotipo() : imagen
+ getfechaInscripcion() : date
property set
+ setcodPartidoPolitico(int) : void
+ setnombre(string) : void
+ setsigla(string) : void
+ setlogotipo(imagen) : void
+ setfechaInscripcion(date) : void
+
+
+
+
+
+
+
getAll() : List<Estudiante>
add() : int
update() : boolean
delete() : boolean
solicitarAfiliacion() : void
solicitarPostularCandidatura() : void
validarHuella(byte[]) : void
property get
+ getCodEstudiante() : int
+ getidentificacion() : char(15)
+ getapellidos() : string
+ getnombres() : string
+ getsexo() : char(1)
+ gethuella() : Binary[]
+ isempadronado() : boolean
Dignidad
-
CodEstudiante: int
identificacion: char(15)
apellidos: string
nombres: string
sexo: char(1)
huella: Binary[]
estado: char(1)
afiliacionCandidatura: string
empadronado: boolean
property set
+ setCodEstudiante(int) : void
+ setidentificacion(char(15)) : void
+ setapellidos(string) : void
+ setnombres(string) : void
+ setsexo(char(1)) : void
+ sethuella(Binary[]) : void
+ setempadronado(boolean) : void
enumeration
TipoVoto
Descripcion
Voto
-
TipoVoto: string
fecha: date
hora: time
setVoto(int, int, int) : boolean

PapeletaElectoral
-
codPapeletaElectoral: int
estado: char(1)
listadoPartidosPoliticos: List<PartidoPolitico>
getTodoPartidosPoliticosActivos() : boolean
property get
+ getcodPapeletaElectoral() : int
property set
+ setcodPapeletaElectoral(int) : void
#
#
#
#
#
#
#
-
172
class 02 Domain Class

interface
BasicOperation
add() : boolean
update() : boolean
delete() : boolean
ConfigurarEleccion
-
codConfiguracionEleccion: int
nombreEleccion: string
descripcionEleccion: string
fechaVotacion: date
horaInicioVotacion: time
horaFinVotacion: time
estado: char(1)
FechaActualizacion: date
+
+
+
+
+
add() : int
update() : boolean
delete() : boolean
property get
+ getcodConfiguracionEleccion() : int
+ getnombreEleccion() : string
+ getdescripcionEleccion() : string
+ getfechaVotacion() : date
+ gethoraInicioVotacion() : time
+ gethoraFinVotacion() : time
+ getFechaActualizacion() : date
property set
+ setcodConfiguracionEleccion(int) : void
+ setnombreEleccion(string) : void
+ setdescripcionEleccion(string) : void
+ setfechaVotacion(date) : void
+ sethoraInicioVotacion(time) : void
+ sethoraFinVotacion(time) : void
+ setFechaActualizacion(date) : void
Subordinana
1..*
Entidad
codEntidad: int = uno

codEntidadPadre: int
nombreEntidad: string
descripcionEntidad: string
+
+
+
+
+
add() : int
update() : boolean
delete() : boolean
property get
+ getcodEntidad() : int
+ getcodEntidadPadre() : int
+ getnombreEntidad() : string
+ getdescripcionEntidad() : string
property set
+ setcodEntidad(int) : void
+ setcodEntidadPadre(int) : void
+ setnombreEntidad(string) : void
+ setdescripcionEntidad(string) : void
Administrador
-
codAdminsitrados: int
identificacion: char(15) = 1111
apellidos: string
nombres: string
sexo: char(1)
clave: string
estado: char(1)
+
+
+
+
+
+
add() : int
Login(string, string) : boolean
update() : boolean
delete() : boolean
property get
+ getclave() : string
+ getcodAdminsitrados() : int
property set
+ setclave(string) : void
+ setcodAdminsitrados(int) : void
+
+
+
+
+
173
DESIGN MODEL Data Model
Se considera un interface para obligar a las clases a implementar mtodos generales.

se hereda de una clase de conexin a la base de datos para que todos tengan una misma forma de
acceder a los datos proporcionado por la herencia de clases
03 MODELO DE DATOS
174
class 03 Data class model
AdministradorMD
interface
CRUD_MD
administrador: Administrador
+
#
#
+
+
+
+
+
+
+
+
+
add() : int
openDataBase() : boolean
closeDataBase() : boolean
delete(string) : boolean
update() : boolean
delete() : boolean
getAllAdministradores() : List<Administrador>
delete(int) : boolean
getById(int) : boolean
verificarLogin() : boolean
+
+
+
+
+
+
add() : boolean
update() : boolean
delete() : boolean
garantiza que las
clases de accesoa a
datos establescan el
CRUD
EstudianteMD
-
estudiante: Estudiante
+
+
#
+
#
+
+
+
+
+
+
add() : boolean
EstudianteMD(Estudiante) : void
update() : boolean
delete() : boolean
getByHuella(byte[]) : boolean
getAllEstudiante() : Lis<Estudiante>
property get
+ getestudiante() : Estudiante
property get
+ getadministrador() : Administrador
property set
+ setestudiante(Estudiante) : void
property set
+ setadministrador(Administrador) : void
CandidatoMD
+
#
+
#
+
+
+
+
+
+
+
ConectarDataBase_MD
candidato: Candidato
add() : int
update() : boolean
delete() : boolean
getAllCandidatos() : List<Candidato>
connStringDataBase: string {readOnly}
#
#
garantiza la coneccion
a la base de datos
desde un mismo origen
y la cadena de
coneccion es estatica
property get
+ getcandidato() : Candidato
property set
+ setcandidato(Candidato) : void
PartidoPoliticoMD
ConfigurarEleccionMD
-
configurarEleccion: ConfigurarEleccion
+
+
#
+
#
+
+
+
+
add() : int
getAllConfigurarEleccion() : void
update() : boolean
delete() : boolean
partidoPolitico: PartidoPolitico
+
#
+
#
+
+
+
+
+
add() : boolean
update() : boolean
delete() : boolean
getAllPartidoPolitico() : List<PartidoPolitico>
property get
+ getpartidoPolitico() : PartidoPolitico
property set
+ setpartidoPolitico(PartidoPolitico) : void
property get
+ getconfigurarEleccion() : ConfigurarEleccion
property set
+ setconfigurarEleccion(ConfigurarEleccion) : void
EntidadMD
dignidad: Dignidadx
+
+
#
+
#
+
+
+
+
add() : int
getAllDignidad() : List<Dignidad>
update() : boolean
delete() : boolean
property get
+ getdignidad() : Dignidadx
property set
+ setdignidad(Dignidadx) : void
PapeletaElectoralMD
entidad: Entidad
papeletaElectoral: PapeletaElectoral
+
#
+
#
+
+
+
+
+
add() : int
update() : boolean
delete() : boolean
getAllEndidad() : List<Entidad>
+
#
+
#
+
+
+
+
add() : int
update() : boolean
delete() : boolean
property get
+ getentidad() : Entidad
property set
+ setentidad(Entidad) : void
property get
+ getpapeletaElectoral() : PapeletaElectoral
property set
+ setpapeletaElectoral(PapeletaElectoral) : void
DignidadMD
175
176
DYNAMIC VIEW
analysis Readme
Sequence
Sistema de votacion
bioelectronica
Dynamic View
Collaboration
State
Activity
Diagramas de secuencia y colaboracin
Los diagramas se realizaron en secciones con el fin de poder apreciar la secuencia completa de dos
procesos principales del caso de estudio.
Diagramas de estado y actividad
177
DYNAMIC VIEW - Sequence
DS01 INGRESO AL SISTEMA

sd 01 Ingreso al sistema
DS01 Ingreso al sistema

frmPrincipal
:FrmPrincipal
frmSplash
:FrmSplashScreen
frmIngreso
:FrmLogin
administrador_DP
:Administrador
administrador_MD
:AdministradorMD
:Administrador
FrmPrincipal()
FrmSplashScreen()
showSplashScreen()
close()
FrmLogin()
ingresa identificacion()
setidentificacion(char(15))
ingresa Clave()
setclave(string)
bntIngresar(object, EventArgs)
Login(string, string) :boolean
verificarLogin() :boolean
close()
ingreso al sistema por parte del adminstrador del sistema
[si logeo = true]:showMenu()
178
sd 02 Administrar Estudiante - New Sav e
DS02 ADMINISTRACIN DE ESTUDIANTE

DS02 Administrar Estudiante - Nuevo
frmVentanaPrincipal_GUI frmEstudiante_GUI
:FrmPrincipal
:FrmEstudiante
estudiante_DP
:Estudiante
estudiante_MD
:EstudianteMD
:Administrador
FrmPrincipal()
mnShowFrmEstudiante()
FrmEstudiante()
limpiarControlesDatos()
cargarListadoDatos() :boolean
getAll() :List<Estudiante>
getAllEstudiante() :Lis<Estudiante>
btnNuevo_Click(object, EventArgs)
ingresa datos en los controles()

FrmLeeHuella()
encenderDispositivo()
leerHuella() :bytes[]
validaNitidezHuella() :
boolean
apagarDispositivo()
close()
validarDatosIngresados()
btnGuardar_Click(object, EventArgs)
setCodEstudiante(int)
setapellidos(string)
setnombres(string)
setempadronado(boolean)
setestado(char(1))
setfechaActualizacion(date)
sethuella(Binary[])
setsexo(char(1))
add() :int
validate() :boolean
add() :int
[codEstudiante > 0]:mensaje("datos
guardados satisfactoriamente")
:Estudiante
frmLeerHuellaDactilar
:FrmLeeHuella
179
sd 02 Administrar Estudiante - UpdSav e
DS02 Administrar Estudiante - Actualizar

:FrmPrincipal
:FrmEstudiante
estudiante_DP
:Estudiante
estudiante_MD
:EstudianteMD
:Administrador
FrmPrincipal()
FrmEstudiante()
seleccionElementoGrilla(object, EventArgs)
cargarDatoSolicitado(string) :
boolean
Modifica datos del estudiante()

FrmLeeHuella()
leerHuella() :bytes[]
validaNitidezHuella() :
boolean
apagarDispositivo()
close()
setCodEstudiante(int)
setapellidos(string)
setnombres(string)
setempadronado(boolean)
setestado(char(1))
sethuella(Binary[])
setsexo(char(1))
update() :boolean
validate() :boolean
update() :boolean
[codEstudiante > 0]:mensage("datos
guardados satisfactoriamente")
:Estudiante
frmLeerHuellaDactilar
:FrmLeeHuella
180
sd 02 Administrar Estudiante - Del
DS02 Administrar Estudiante - Eliminar

:FrmPrincipal
:FrmEstudiante
estudiante_DP
:Estudiante
estudiante_MD
:EstudianteMD
:Administrador
FrmPrincipal()
FrmEstudiante()
boolean
btnEliminar_Click(object, EventArgs)
mensaje(''Seguro de que desea eliminar los datos")
confirma eliminacion de datos()
delete() :boolean
delete() :boolean
[return = true ]:mensaje("datos
ELIMINADOS satisfactoriamente")
Adminsitracion de estudiantes - Eliminar un estudiante
181
sd 02 Administrar Estudiante - FindParam
DS02 Administrar Estudiante - Consultar

frmVentanaPrincipal_GUI
:FrmPrincipal
estudiante_DP
:Estudiante
estudiante_MD
:EstudianteMD
:Administrador
FrmPrincipal()
FrmEstudiante()
Ingresa identificacion()
txtBuscar_LostFocus(object, EventArgs)
validate() :boolean
btnBuscar_Click(object, EventArgs)
getByCod(string) :boolean
getById(int) :boolean
[return == false]:mensage("datos ingresados no

existen")
boolean
ingresa identificacion()
txtBuscar_LostFocus(object, EventArgs)
validate() :boolean
cargarDatoSolicitado(string) :boolean
[return == false]:mensaje("datos ingresados no existen")
:Estudiante
frmEstudiante_GUI
:FrmEstudiante
182
sd 03 Administrar Partido Politico - New Sav e
DS03 ADMINISTRAR PARTIDO POLTICO

03 Administrar Partido Politico - Nuevo
frmPrincipal
:FrmPrincipal
frmPartidoPolitico
:FrmPartidoPolitico
partidoPolitico_DP
:PartidoPolitico
partidoPolitico_MD
:PartidoPoliticoMD
:Administrador
FrmPrincipal()
mnShowFrmPartidoPolitico()
FrmPartidoPolitico()
getAll() :List<PartidoPolitico>
getAllPartidoPolitico() :List<PartidoPolitico>
btnNuevo_Click(object, EventArgs)
ingresar datos de partido politico()
setcodPartidoPolitico(int)
setestado(char(1))
setfechaInscripcion(date)
setlogotipo(imagen)
setnombre(string)
setsigla(string)
add() :boolean
validate() :boolean
add() :boolean
[return = true ]:mensaje("datos GUARDADOS satisfactoriamente")
183
sd 03 Administrar Partido Politico - UdpSav e
03 Administrar Partido Politico - Actualizar

frmPrincipal
:FrmPrincipal
frmPartidoPolitico
:FrmPartidoPolitico
partidoPolitico_DP
:PartidoPolitico
partidoPolitico_MD
:PartidoPoliticoMD
:Administrador
FrmPrincipal()
cargarDatoSolicitado(string)
:boolean
modificar datos de partido politico()
setestado(char(1))
setfechaInscripcion(date)
setlogotipo(imagen)
setnombre(string)
setsigla(string)
add() :boolean
validate() :boolean
add() :boolean
[return = true ]:mensaje("datos GUARDADOS satisfactoriamente")
184
sd 03 Administrar Partido Politico - Del
03 Administrar Partido Politico - Eliminar

frmPrincipal
:FrmPrincipal
frmPartidoPolitico
:FrmPartidoPolitico
partidoPolitico_DP
:PartidoPolitico
partidoPolitico_MD
:PartidoPoliticoMD
:Administrador
FrmPrincipal()
:boolean
btnEliminar_Click(object, EventArgs)
mensaje("Esta seguro de que desea eliminar esta informacion")
Confirma la eliminacion()
delete() :boolean
delete() :boolean
[return = true ]:mensaje("datos ELIMINADOS satisfactoriamente")
185
sd 03 Administrar Partido Politico - FindParam
03 Administrar Partido Politico - Consultar

frmPrincipal
:FrmPrincipal
frmPartidoPolitico
:FrmPartidoPolitico
partidoPolitico_DP
:PartidoPolitico
partidoPolitico_MD
:PartidoPoliticoMD
:Administrador
FrmPrincipal()
Ingresa codigo()
txtBuscar_LostFocus(object,
EventArgs)
validate() :boolean
getByCod(string)
:boolean
cargarDatoSolicitado(string) :boolean
[return = false]:mensaje("datos ingresados no existen")
186
DS03 SUFRAGIO DE ESTUDIANTE
187
DYNAMIC VIEW - Collaboration
DC01 COLLABORATION - INGRESO AL SISTEMA

sd 01 Collaboration - Ingreso al sistema
DC01 Collaboration - Ingreso al sistema

-> 1 FrmPrincipal()
-> 2 FrmSplashScreen()
frmPrincipal :
FrmPrincipal
frmSplash :
FrmSplashScreen
-> 3 FrmPrincipal()
-> 4 Close()
-> 5 FrmLogin()
-> 11 nmShowMenu()
-> 6 ingresa identificacion y clave

-> 7 bntIngresar(object, EventArgs)
-> 8 Login(string, string) administrador_MD

:AdministradorMD
frmIngreso :
FrmLogin
-> 9 verificarLogin() administrador_DP :

Administrador
Administrador
(from Use Case View)
-> 10 close()
DC02 COLLABORATION - ADMINISTRAR ESTUDIANTE

sd 02 Collaboration - Administrar Estudiante
DC02 Collaboration - Administrar Estudiante

-> 01 FrmPrincipal()
-> 02 mnShowFrmEstudiante()
frmVentanaPrincipal_GUI :
FrmPrincipal
-> 02 FrmEstudiante()
-> 07 seleccionElementoGrilla(object, EventArgs)

-> 09 btnEliminar_Click(object, EventArgs)
<- 10 Mensaje(''Seguro de que desea eliminar los datos")
-> 11 confirma eliminacion de datos
<- 12 Mensaje("datos ELIMINADOS satisfactoriamente")
-> 13 btnNuevo_Click(object, EventArgs)
-> 15 ingresa datos en los controles
<- 25 mensaje("datos guardados satisfactoriamente")
->
->
->
->
03
04
08
14
cargarListadoDatos()
frmEstudiante_GUI :
FrmEstudiante
->
->
->
->
05
12
22
23
getAll()
delete()
add()
ValidarDatos()
estudiante_DP :
Estudiante
:Administrador
-> 18 leerHuella()
frmLeerHuellaDactilar :
FrmLeeHuella
->
->
->
->
17 encenderDispositivo()
19 validaNitidezHuella()
20 apagarDispositivo()
21 close()
DC02 COLLABORATION - ADMINISTRAR PARTIDO POLTICO
-> 06 getAllEstudiante()
-> 13 delete()
-> 24 add()
estudiante_MD :
EstudianteMD
-> 16 FrmLeeHuella()
-> 22 validarDatosIngresados()
188
sd 03 Collaboration - Administrar PartidoPolitico
DC03 Collaboration - Administrar PartidoPolitico

-> 02 mnShowFrmPartidoPolitico()
frmVentanaPrincipal_GUI :
FrmPrincipal
-> 03 frmPartidoPolitico
-> 06 seleccionElementoGrilla(object, EventArgs)

-> 09 btnEliminar_Click(object, EventArgs)
<- 10 Mensaje(''Seguro de que desea eliminar los datos")
-> 11 confirma eliminacion de datos
<- 12 Mensaje("datos ELIMINADOS satisfactoriamente")
-> 13 btnNuevo_Click(object, EventArgs)
-> 19 ingresa datos en los controles
<- 20 mensaje("datos guardados satisfactoriamente")
->
->
->
->
04
05
07
14
cargarListadoDatos()
->
->
->
->
frmPartidoPolitico :
FrmPartidoPolitico
08
12
16
17
getAll()
delete()
add()
ValidarDatos()
partidoPolitico_DP :
PartidoPolitico
:Administrador
-> 06 getAllEstudiante()
-> 13 delete()
-> 18 add()
partidoPolitico_MD :
PartidoPoliticoMD
DC02 COLLABORATION - SUFRAGIO

sd 04 Collaboration - Sufragio
DC04 Collaboration - Sufragio

-> 02 mnShowFrmSufraga()
:FrmPrincipal
:Administrador
->
->
->
->
-> 03 FrmSufraga()
-> 12 cargarPapeletas()
:FrmSufraga
-> 05 FrmLeeHuella()
06
07
10
11
validaNitidezHuella()
apagarDispositivo()
close()
:FrmLeeHuella A
-> 08 sethuella(Binary[])
estudiante_DP :
Estudiante
-> 09 getByHuella(byte[])
-> 04
-> 15
<- 18
<- 19
btnIniciarVotacion_Click(object, EventArgs)
btnSetPapeleta_Click(object, EventArgs)
mensaje()
imprimirComprobante()
-> 07 leerHuella()
:EstudianteMD
:Estudiante
-> 13 getTodoPartidosPoliticosActivos()
-> 16 setVoto(int, int, int)

v oto_DP :Voto
-> 14 getAllPartidoPolitico()
-> 17 add()
:PartidoPoliticoMD
:VotoMD
papeletaElectoral_DP
:PapeletaElectoral
189
DYNAMIC VIEW - State
DE01 STATE DIAGRAM - POSTULACION A CANDIDATURA

stm 02 Candidato - State
Diagrama de Estado:
PostulacionCandidatura
Estudiante.PostulacionCandidatura
Se consider el proceso principal del sistema de votacin que

tener estudiantes que postulante a una candidatura para lo
cual se tom la Clase ESTUDIANTE con los siguientes mtodos
que actan como eventos del cambio de estados:
- solitarEmpadronamiento (): void
- solicitarAfiliacion (): void
#
#
#
#
#
#
#
-
CodEstudiante: int
apellidos: string
nombres: string
sexo: char(1)
huella: Binary[]
estado: char(1)
PostulacionCandidatura: string
+
+
+
+
+
+
+
add() : int
update() : boolean
delete() : boolean
solitarEmpadronamiento() : void
desafiliarse() : void
desistirDeCandidatura() : void
CierrePeriodo() : void
property get
+ getCodEstudiante() : int
+ gethuella() : Binary[]
+ isempadronado() : boolean
property set
+ setCodEstudiante(int) : void
+ sethuella(Binary[]) : void
+ setempadronado(boolean) : void
- solicitarPostularCandidatura (): void

- desafiliarse (): void
- desistirDeCandidatura (): void
- CierrePeriodo (): void
la
propiedad
que
guarda
el
cambio
es:
PostulacionCandidatura
Finalmente a este diagrama de estados se estn asociado los

diagramas de actividad que definen el cambio de estados.
v er. DA01 Activ ity Empadronar
v er. DA02 Activ ity SolicitarAfiliacion
v er. DA03 Activ ity SolicitarPostulacion
DE01 STATE
CANDIDATURA
DIAGRAM
POSTULACION
02 Domain Class::Estudiante
190
Candidato - State
DE01 STATE - Postulacion a Candidatura
iagrama de Estado:
ostulacionCandidatura
studiante.PostulacionCandidatura
iniciar Postulacion
02 Domain Class::Estudiante
add() : int
update() : boolean
delete() : boolean
solitarEmpadronamiento() : void
desafiliarse() : void
desistirDeCandidatura() : void
CierrePeriodo() : void
Estudiante
[SolicitarEmpadronamieto]
[CierrePeriodo]
v er. DA01 Activ ity Empadronar

sufragANTE
[solicitarAfiliacion]
[NO]
Evento a cumplirse para

afiliarse a un partido
politico
v er. DA02 Activ ity SolicitarAfiliacion
[desafiliarse]
[SI]
Aceptar
roperty get
getCodEstudiante() : int
getidentificacion() : char(15)
getapellidos() : string
getnombres() : string
getsexo() : char(1)
gethuella() : Binary[]
getestado() : char(1)
isempadronado() : boolean
getfechaActualizacion() : date
roperty set
setCodEstudiante(int) : void
setidentificacion(char(15)) : void
setapellidos(string) : void
setnombres(string) : void
setsexo(char(1)) : void
sethuella(Binary[]) : void
setestado(char(1)) : void
setempadronado(boolean) : void
setfechaActualizacion(date) : void
Evento a cumplirse
para ser sufragante
afiliADO
[solicitarPostularCandidatura]
[NO]
Evento a cumplirse
para postular a
candidato estundiantil
v er. DA03 Activ ity SolicitarPostulacion
[DesistirDeCandidatura]
Aceptar
[SI]
CandidATO
Final
CodEstudiante: int
apellidos: string
nombres: string
sexo: char(1)
huella: Binary[]
estado: char(1)
PostulacionCandidatura: string
191
DYNAMIC VIEW - Activity
En base a diagramas al diagrama de estado representado anteriormente tenemos:
DA01 ACTIVITY - EMPADRONAR

DA01 Activ ity Empadronar
Diagrama de Actividad:
Estudiante.solitarEmpadronamiento()
Administrador d
Estudiante
ActivityInitial - empadronamiento
ABRIR periodo de
empadronamiento
TENER matricula en
periodo actual
NO TENER Mora
institucional
VALIDAR Requerimientos
[NO]
cumple
INCLUIR en lista de no
v otantes
ActivityFinal
LISTAR en el padron
192
DA02 ACTIVITY SOLICITAR AFILIACION

DA02 Activ ity SolicitarAfiliacion
Estudiante.solicitarAfiliacion()
Admnistrador
Estudiante
ActivityInitial solicitarAfiliacion
SOLICITAR Requisitos
TENER aprobado el 50%

del plan de estudio
TENER certificado de
disciplina univ ersitario
NO TENER obserbacion
academica
SER estudiante regular en
el periodo actual
TENER derechos politicos
TENER certificado de
aceptacion de partido
politico
VALIDAR
Requerimientos
cumple
[NO]
[SI]
ActivityFinal
REGISTRAR como
Afiliado
193
DA03 ACTIVITY SOLICITAR POSTULACION

DA03 Activ ity SolicitarPostulacion
Estudiante.solicitarPostularCandidatura()
Administrador
Estudiante
ActivityInitial solicitarPostularCandidatura
SOLICITAR Requisitos
TENER aprobabacion del

partido politico
cumpie
[NO]
[SI]
REGISTRAR candidatura
DA04 ACTIVITY SUFRAGIO
ActivityFinal
194
Finalmente un proceso fundamental para el sistema de votacin es el sufragio que a nivel de diagrama de
estados no presenta cambios pues los votos son solo de un tipo y no registra cambios pero si se presentan
actividades donde se visualiza la participacin de varios roles.
195
COMPONENT MODEL
analysis Readme
Component
Model
Sistema de votacion
bioelectronica
Se analiza los componentes arquitectnicos de la aplicacin. Estos componentes arquitectnicos son de tipo
lgicos y fsicos por lo que se especifica la arquitectura a implementar para el sistema de votacin
bioelectrnico.
LA ARQUITECTURA LGICA implica uso de capas las cuales se estructuran por componentes los cuales
obedecen a la siguiente disposicin:
analysis Readme
01 GUI
Frameworks
Data Model
02 Domain
Class
03 Data Class
Model
04 Data Base
Schema
Esquema de componentes lgicos
Logical Model
196
De esta forma tenemos:

01 GUI componente de interfaz grfica Windows
02 Domain Class Clases del dominio del negocio Este se montara en SERVICO WEB ws
03 Data Class Model Componente de acceso a datos para el soporte del CRUD
04 Data Base Schema Esquema de la base de datos a implementarse en SQL SERVER 2008 R2
ARQUITECTURA DE COMPONENTES LGICOS
197
cmp Component Model
ARQUITECTURA DE COMPONENTES
Interop.GrFingerXLib.dll :
Interop.GrFingerXLib.dll
Service
References
Required
01 GUI - Destopk
GrFingerXLib.dll :
AxInterop.GrFingerXLib.dll
Framew ork 4.0 :

Framew ork .NET 4.0
TCP/ IP
Libreria de controles
personalizados :
Customer Control
Port :8080
02 Domain Class
WCF Provided
Web serv ice

delegate
IIS 7.0
03 Data Class Model
Provided Driver
Framew ork 4.0 :

Framew ork .NET 4.0
TCP/ IP
Port : 1525
SQL Serv er 2008

04 Data Base Schema
01 GUI Desktop
Mantiene 2 componente de tipo .dll para controlar el lector de huellas
Componente de controles personalizados para la interfaz grfica Windows
Referencia a web service con la implicacin de certificados de seguridad
Web service
02 Domain Class Clases del dominio del negocio Este se montara en SERVICO WEB ws
03 Data Class Model Componente de acceso a datos para el soporte del CRUD
IIS 7.0 servidor web para proporcionar la salida del web service que esta implementado con
Windows Communication Foundation
Puerto de salida 8080
SQL Server 2008
04 Data Base Schema Esquema de la base de datos a implementarse en SQL SERVER 2008 R2
ARQUITECTURA DE COMPONENTES DE CONEXIN
sql server | ODBC
198
cmp Connections
Connections Archicture
Service References
Required
The Connections package contains detailed wiring
diagrams of the explicit connections established
between components at run-time.
Typically this is shown as a dependency relationship
between a required interface on one component being
connected to a provided interface on a second
component. These dependency relationships show how
each components requirements for functionality are
met by other components, and how the system as a
whole is capable of performing the required work.
This component needs the

services of another
component to perform its
required work.
01 GUI - Destopk
TCP/ IP - INTERNET
This component exposes an

interface for other
components to use. The
interface is a contract to
provide specific behavior to
other components that
require that service.
WCF Provided
Web serv ice
TCP / IP
SQL SERVER
SQL Serv er 2008
Esquema funcional de componentes:

Ambiente de sufragio
Host
FIREWALL
Web service
(WCF)
Firew
all
DAT
A
Firewall
FIREWALLL
GUI
(usa lector de
huellas)
199
DEPLOYMENT MODEL
analysis Readme
Sistema de votacion
bioelectronica
Deployment
Model
La arquitectura de implementacin del sistema de votacin implica infraestructura que al usar UML se
representa a travs de nodos que conforma las terminales de los clientes, dispositivos y servidores.
En este caso se modelaron tres terminales para clientes locales, cabe recalcar que se pueden montar ms
terminales para procesos de sufragio.
deployment Clients
PC Terminal:
192.168.2.3
PC Terminal:
192.168.2.2
PC Terminal:
192.168.2.4
terminal I : mesa de votacion 1 - solo hombres

sistema operativo Win7
Habilitar internet - intranet
terminal II : mesa de votacion 1 - solo mujeres

terminal III :
Soporte en caso que la terminal I y II la cola se sature
Los dispositivos deben ir uno por terminar, este nos permite la autenticacin del Sufragante para el proceso
de votacin y por lo general siempre deberan acompaar a la terminal local.
deployment Dev ices
device
Lector
Biometrico 02
device
Lector
Biometrico 03
Lector de huella dactilar de sobremesa conexin a PC por usb

algoritmo. FAR: 0.001% FRR: 0.1%
ptica de excelente dureza (7 Moh), equivalente al cuarzo que permite guardar nmero de
serie en el dispositivo para aplicacin de mochila para licencias de software
Software de seguridad eNDeSS gratuito
Herramienta de desarrollo de software para integradores: SDK
Conexiones: USB o puerto paralelo
Disponible nuevo Kit de Desarrollo (SDK) en Java para entornos Linux y Windows.
Descripcin:
El lector de huella digital Nitgen Hamster es un perifrico para la seguridad del ordenador y
seguridad informtica en general. Est equipado con un mdulo de lectura de huella
dactilar basado en la tecnologa nica de biometra Nitgen.
Los servidores con los nodos principales que se encargar de proveer mediante un web service la informacin
de negocio a las terminales de los clientes, para el presente caso de estudio tenemos 3 Host definidos.
device
Lector
Biometrico 01
200
Esquema de diseo:
201
DEPLOYMENT MODEL
Esquema final de infraestructura

Web
Server
INTERNET
Data
Servers
202
CODIFICACIN
Para el desarrollo de este aplicativo se consider los siguientes lineamientos:
Anlisis y diseo Orientado a Objetos
Enterprise Architect 7.5, es el aplicativo usado para el anlisis y modelado del negocio
Lenguaje de programacin orientado a objetos
C#, este nos permite codificar los aspectos del diseo y anlisis orientado a objetos.
LINQ, nuevo paradigma funcional que trabaja con objetos que nos permite manipular los datos
que van y regresan desde la base de datos.
Visual Studio .Net, es el aplicativo que usado para la compilacin y codificacin del sistema.
Base de datos
SQL SERVER 2008 R2, el performance de los datos y la arquitectura de este motor de datos brinda
la robustez que se requiere para que el sistema funcione adecuadamente.
Entornos de produccin
WEB
Windows Communication Foundation - WCF es la tecnologa basado en WEB SERVICE para el
acceso a datos de forma segura a travs de la red.
WINDOWS
El aplicativo desktop se implement considerando que el sistema interacta con el dispositivo de
huella digital, el cual necesita drives para que el sistema actu de forma segura lo cual no se logra
en las aplicaciones web.
Finalmente se presenta el sistema considerando los requerimientos modelados.
203
SPLAHS SCREEN
Se considera el Splahs Screen para demostrar al usuario la espera necesaria mientras el sistema se conecta a
los servicios en el arranque o inicio de la aplicacin. Un Splash Screen es una imagen que se muestra en
pantalla, normalmente centrada, mientras esperamos que la aplicacin arranque. De esta forma, nada ms
dar arrancar a la aplicacin, ya vemos algo en pantalla y sabemos que la aplicacin est arrancando. En
cuanto aparezca la primera ventana real de nuestra aplicacin, esta Splahs Screen desaparece.
REQ - 01
Los usuarios que se encuentren registrados y hayan sido empadronados podrn ingresar al sistema, para lo
cual se autenticarn mediante su huella digital y podrn ser validados por el Sistema de acuerdo al rol de
cada usuario, y utilizar las funciones que le correspondan.
La seccin 1, destinado a la identificacin y acceso del usuario del sistema.

La seccin 2, permite cancelar el ingreso al sistema.
La Seccin 3, permite validar el acceso al usuario.
SECUENCIA
204
REQ - 02
Permite registrar y configurar los partidos polticos, candidatos y el tipo de eleccin al que se postular un
candidato.
SECUENCIA
Seccin 1: presenta las opciones para que el administrador del sistema, agregue, elimine, imprima y archive
la informacin de las candidaturas.
Seccin 2: permite al sistema asignar un cdigo para cada candidato registrado.
Seccin3: destinado a ingresar los datos del tipo de eleccin, partido, dignidad y postulante respectivamente
Seccin 4: permite asignar una imagen para cada candidato que se registre.
Seccin 5: muestra la lista de candidatos que quedarn debidamente inscritos.
205
REQ - 03
El administrador del sistema puede configurar una eleccin electoral, asignando los datos correspondientes
como nombre, descripcin, tipo, mbito y fecha en la que se llevar a cabo.
SECUENCIA
Seccin 1: permite al administrador del sistema agregar, archivar y eliminar un usuario.
Seccin 2: opcin mediante la cual se puede asignar un cdigo para cada usuario registrado.
Seccin 3: Se destina para ingresar todos los datos correspondientes a la eleccin que se vaya a realizar.
Seccin 4: Espacio en el que se muestra todos los usuarios habilitados para participar en una determinada
eleccin.
206
REQ - 04
Permite registrar y configurar las entidades o pantallas del sistema para tener acceso de los usuarios que se
encuentran registrados. El administrador del sistema puede habilitar las opciones que se visualizarn en
cada pantalla en base a las elecciones que se desarrollen.
SECUENCIA
Seccin 1: Opciones que permiten al administrador del sistema, crear, archivar, o eliminar una entidad.
Seccin 2: El administrador del sistema puede asignar la informacin que corresponde a cada entidad o
pantalla.
Seccin 3: Se visualizan todas las entidades que han sido creadas por el administrador.
207
REQ 05
ADMINISTRACIN DE PROCESOS DEL SISTEMA
El administrador puede configurar todos los procesos del sistema como son: periodos, partidos, padrn
electoral, candidatos, usuarios, administrar una eleccin, las entidades y la proyeccin de resultados finales,
los cuales contendrn la informacin de acuerdo a las elecciones que se realicen.
Seccin 1: Opcin que le permite al administrador del sistema configurar el periodo de una eleccin.
Seccin 2: Opcin que le permite al administrador del sistema configurar los diferentes partidos polticos
aprobados por la institucin.
Seccin 3: Opcin que le permite al administrador del sistema configurar el padrn electoral con las
personas autorizadas para realizar el sufragio.
Seccin 4: Opcin que le permite al administrador del sistema configurar la informacin de las personas que
sern candidatos de un partido poltico.
Seccin 5: Opcin que le permite al administrador del sistema configurar los diferentes usuarios que tendrn
acceso a ciertos procesos del sistema.
Seccin 6: Opcin que le permite al administrador del sistema configurar el tipo de eleccin que se
desarrollar en cualquier periodo de votacin de la Institucin educativa.
Seccin 7: Opcin que le permite al administrador del sistema mostrar los resultados finales de una eleccin
en forma grfica.
SECUENCIA
208
REQ 06
ADMINISTRACIN DE PADRON ELECTORAL
Permite que el administrador del sistema configure los procesos de eleccin y toda la informacin
concerniente a los mismos. El administrador del sistema podr habilitar un padrn electoral teniendo
registrado a todos los usuarios autorizados para el sufragio.
SECUENCIA
Seccin 1: Opcin que permite archivar, eliminar, agregar e imprimir un padrn electoral.
Seccin 2: Opcin que permite asignar un cdigo para cada padrn electoral que se vaya a registrar.
Seccin 3: Opcin que permite seleccionar el tipo de usuario que se va a empadronar para el sufragio.
Seccin 4: Opcin que permite el tipo de eleccin que se llevar a cabo.
Seccin 5: En esta seccin se visualiza los usuarios que estn habilitados para efectuar su voto.
209
REQ 07
ADMINISTRACIN DE PAPELETA ELECTORAL
Permite que el administrador del sistema habilite una papeleta electoral de acuerdo al tipo de eleccin que
se realizar y al tipo de usuario que vaya a cumplir con el voto.
El administrador del sistema puede configurar la informacin que el usuario final visualizar en la papeleta
virtual, definiendo el mbito de la eleccin, tipo de eleccin y usuarios a la cual ser dirigida la eleccin.
SECUENCIA
Seccin 1: Opcin que le permite al administrador del sistema seleccionar las opciones para configurar la
informacin de la papeleta virtual.
Seccin 2: Opcin con la cual el administrador del sistema asigna un cdigo a cada una de las papeletas que
se configure para una eleccin.
Seccin 4: Opcin donde el administrador puede visualizar la lista de papeletas habilitadas para el proceso
de sufragio
Seccin 3: Opcin para que el administrador del sistema configure la informacin que se visualizar en la
papeleta virtual para el usuario.
210
REQ 08
ADMINISTRACIN DE PARTIDOS
Permite que el administrador del sistema inscriba un partido poltico para que se visualicen en la papeleta
virtual de acuerdo al tipo de eleccin que se vaya a desarrollar.
El administrador del sistema puede configurar la informacin de los partidos polticos que han sido
autorizados por la Institucin, asignando el nombre del partido, la sigla y la insignia correspondiente.
SECUENCIA
Seccin 1: Opcin que permite crear, archivar, eliminar cualquier partido poltico.
Seccin 2: Opcin que permite asignar un cdigo de identificacin para cada partido poltico.
Seccin 4: Opcin que permite agregar una imagen correspondiente a cada partido.
Seccin 5: Opcin donde se visualiza la lista de partidos polticos inscritos.
Seccin 3: Opciones que permiten registrar la informacin bsica de un partido poltico.
211
REQ 09
ADMINISTRACIN DE PERIODOS
El administrador del sistema puede configurar el periodo asignndole el nombre respectivo, as como
tambin la fecha en la que se llevar a cabo el periodo de elecciones.
Seccin 1
: Opcin que permite agregue, archive o elimine un periodo de elecciones.
Seccin 2
: Opcin donde el sistema genera un cdigo a cada periodo que se cree.
Seccin 3
: Opcin donde el administrador del sistema puede habilitar el periodo que se ha creado.
Seccin 4
: Opcin que permite visualizar la lista de periodos que al administrador haya habilitado.
SECUENCIA
212
REQ 10
ADMINISTRACIN GRFICA DE RESULTADOS
El administrador del sistema puede proyectar los resultados finales en una grfica estadstica considerando
los reportes de cada sufragio que se realice.
Seccin 1: opcin que permite al administrador seleccionar cualquier tipo de eleccin realizada.
Seccin 2: Se visualizan los resultados obtenidos de la eleccin que al administrador elija.
SECUENCIA
213
REQ 11
Permite que el administrador del sistema registre la informacin de cada uno de los usuarios que estn
autorizados para realizar el voto.
El administrador del sistema registra la informacin que identificar a cada usuario, como es el nombre,
carrera, rea, imagen y registrar la huella digital para que pueda acceder de manera segura al sistema en el
momento que efecte el sufragio.
SECUENCIA
Seccin 1: Opcin que permite agregar, eliminar o guardar un usuario nuevo.
Seccin 2: Opcin que permite asignar un cdigo para cada registro que se realice.
Seccin 4: Opcin que permite seleccionar la foto que pertenecer a cada usuario.
Seccin 5: En esta seccin se visualiza la lista de estudiantes que se han registrado.
Seccin 6: Opcin con la cual se llama al proceso del lector de huella digital y almacenar la huella personal
del usuario.
Seccin 3: Opcin para el registro de la informacin personal de cada usuario.
214
SNTESIS
Como lo ha dicho Jan Bosch, un arquitecto prctico: Existe una considerable diferencia entre la
percepcin acadmica de la Arquitectura de Software y la prctica industrial es interesante
advertir que a veces los problemas que la industria identifica como los ms importantes y difciles,
no se identifican o se consideran no-problemas en la academia. La arquitectura del software
posee muchas aristas que van desde un marco de referencia global y genrico para el desarrollo
de soluciones, Microsoft Solutions Framework, MSF a lo que esta bajo el paraguas (explcito) de
arquitectura, con un buen nmero de aportes en materia de patrones de diseo y lineamientos
para implementarlos, primordialmente en modelos orientados a servicios.
En ese contexto, IT Management que a arquitectura o ingeniera es una prctica sumamente
concreta, las cuestiones tericas y las metodologas especficas basadas en arquitectura han
quedado sin elaborar y resulta necesario establecer un enfoque sistemtico y disciplinado para
llevar a cabo un desarrollo de software, una metodologa asi como mtodos que se emplean para
estos proceso que den como resultado un software de eficiente basado en el Conjunto de
procedimientos, tcnicas, herramientas y un soporte documental que ayudan a los desarrolladores
para realizar un software (Mario Piattini et al.)
Actualmente, el software tiene la tendencia de ser grande y complejo. Los usuarios demandan
interfaces cada vez ms completas y funcionalidades ms elaboradas, todo ello influyendo en el
tamao y la complejidad del producto final. Por ello, los programas deben ser estructurados de
manera que puedan ser revisados, corregidos y mantenidos, rpida y eficazmente, por gente que
no necesariamente ha colaborado en su diseo y construccin, permitiendo acomodar nueva
funcionalidad, mayor seguridad y robustez, funcionando en todas las situaciones que puedan
surgir, de manera previsible y reproducible. Por lo tanto ante problemas de gran complejidad, la
mejor forma de abordar la solucin es modelar.
Modelar es disear y estructurar el software antes de lanzarse a programar y es la nica forma de

visualizar un diseo y comprobar que cumple todos los requisitos para l estipulados, antes de que
la flotilla de programadores comience a generar cdigo. Modelando, los responsables del xito del
producto pueden estar seguros de que su funcionalidad es completa y correcta, que todas las
expectativas de los usuarios finales se cumplen, que las posibles futuras ampliaciones pueden ser
acomodadas, todo ello mucho antes de que la implementacin haga que los cambios sean difciles
o imposibles de acomodar. Modelando, se abstraen los detalles esenciales de un problema
complejo y se obtiene diseos estructurados que, adems, permiten la reutilizacin de cdigo,
reduciendo los tiempos de produccin y minimizando las posibilidades de introducir errores para
lo cual el uso de UML que es un lenguaje grfico que sirve para modelar, disear, estructurar,
visualizar, especificar, construir y documentar software poder una de las mejores alternativas a tu
favor.
215
REFERENCIAS
REPOSITORIOS
Existen unos cuantos repositorios de informacin arquitectnica, cuyas direcciones son ms o menos
permanentes. El ms importante hoy en da parece ser el del Software Engineering Institute en la
Universidad Carnegie Mellon de Pittsburgh, Pennsylvania (http://www.sei.cmu.edu/ata/ata_init.html). El
sitio del SEI incluye abundante literatura acadmica y todas las especificaciones o recomendaciones
metodolgicas.
Entre los organismos que definen estndares, son esenciales los servicios de informacin de RM-ODP en:
http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html, TOGAF en
http://www.software.org/pub/architecture/togaf.asp, DoDAF (hogar del C4ISR) en
http://www.software.org/pub/architecture/dodaf.asp. El estndar IEEE 1471-2000 se puede
encontrar en http://www.techstreet.com/cgi-bin/detail?product_id=879737. El marco de
referencia empresarial de Zachman se puede acceder desde
http://www.software.org/pub/architecture/zachman.asp
Las pginas de cabecera de la estrategia de arquitectura de Microsoft se hallan en

http://msdn.microsoft.com/architecture/. Las pginas de Patterns & Practices estn en
http://www.microsoft.com/resources/practices/completelist.asp. La
misma se encuentra delineada en un documento de Michael Platt en
estrategia
arquitectnica
http://msdn.microsoft.com/architecture/overview/default.aspx?pull=/library/enus/dnea/html/eaar
chover.asp.
REFERENCIAS BIBLIOGRFICAS
1. Bloomberg, J. (2004). The role of the service-oriented architect.
2. Clements, P. (Enero de 1996.). Coming attractions in Software Architecture Technical Report.
3. Dijkstra, E. (Enero de 1983). The Structure of the The Multiprogramming system. Communications of
the ACM.
4. IT, G. (2003). "Application architecture and design."
5. Jr., F. B. (1975). The mythical man-month.
6. Kron, F. D. y. H. (1976). Programming-in-the-large versus programming-in-the-small, IEEE Transaction in
Software Engineering.
7. Luis Felipe Cabrera, C. K., Don Box (Setiembre 2004). "An introduction to the Web Service Architecture
and its specifications."
8. Northrop, P. C. y. L. (Febrero de 1996). Software architecture: An executive overview.
9. Parnas, D. (Diciembre de 1972). On the Criteria for Decomposing Systems into Modules.
Communications of the ACM.
Numerosas editoriales, universidades, consorcios y centros de investigacin incluyen vnculos ligados a la AS.
Muy seguramente los lectores podrn suministrar otros sitios de referencia importantes.
216
10. Reed, J. B. y. K. (2001). Why We Need a Different View of Software Architecture. The Working IEEE/IFIP
Conference on Software Architecture (WICSA), Amsterdam.
11. Sharp, I. P. (27 al 31 de Octubre de 1969). Comentario en discusin sobre teora y prctica de la
ingeniera de software. Software Engineering Concepts and Techniques: Proceedings of the NATO
conferences, Roma.
12. Wirth, N. (Abril de 1971). Program development by stepwise refinement, Communications of the ACM.
13. WWISA (1999) "Worldwide Institute of Software Architects." Philosophy Volume, DOI:
14. http://www.microsoft.com/spanish/msdn/arquitectura.
15. http://www.sei.cmu.edu/publications/publications.html.
16. Grady Booch, James Rumbaugh, Ivar Jacobson, (1996) El Lenguaje Unificado de ModeladoAddison
Wesley.
17. Schneider G., Winters J.P., (2001) Applying Use Cases: A Practical Guide, Addison Wesley.
18. Booch, Grady. Object-Oriented Analysis and Design. Second Edition. Benjamin/Cummings, Redwood:
1994.
19. Jacobson, Ivar, Grady Booch, and James Rumbaugh. El Proceso Unificado de Desarrollo de Software.
Mxico: Addison-Wesley, 1999.
20. Kruchten, Philippe. "Architectural Blueprints--The 4+1 View Model of Software Architecture". IEEE
Software, Institute of Electrical and Electronics Engineers. November 1995, pp. 42-50.
21. Larman, Craig. UML y Patrones, Introduccin al anlisis y diseo orientado a objetos. Mxico: Prentice
Hall, 1999.
22. Martin, Robert C. "Design Principles and Design Patterns". Objectmentor
23. Muller, Pierre-Alain. Modlisation Object avec UML. Paris: Eyrolles, 1997.
24. Wilson, Scott F. Analyzing Requirements and Defining Solution Architectures. Redmond: Microsoft Press,
1999.
25. Fernndez Aramayo, David Ricardo. Arquitectura de Software. Universidad Tecmilenio, ITESM
Zapata Sanchez, Andres felipe. Arquitectura de Software www.fi.uba.ar
Meylin Siguas Villavicencio www.unpmsn.org
[Abd00] Aynur Abdurazik. Suitability of the UML as an Architecture Description Language with
applications to testing.
Reporte ISE-TR-00-01, George Mason University. Febrero de 2000.
[Alb03] Stephen Albin. The Art of Software Architecture: Design methods and techniques. Nueva
York, Wiley, 2003.
[Ale77] Christopher Alexander. A pattern language. Oxford University Press, 1977.
[AW99] David Akehurst y Gill Waters. UML deficiencies from the perspective of automatic
rendimiento model generation.
OOSPLA99 Workshop on Rigorous Modeling and Analysis with the UML: Challenges and
Limitations, Denver,
http://www.cs.kent.ac.uk/pubs/1999/899/content.pdf, Noviembre de 1999.
[ASR+02] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen y Juhani Warsta. Agile Software
Development Methods.
VTT Publications 478, Universidad de Oulu, Suecia, 2002.
217
[BBC+00] Felix Bachmann, Len Bass, Gary Chastek, Patrick Donohoe, Fabio Peruzzi. The
Architecture Based Design
Method. Technical Report, CMU/SEI-2000-TR-001, ESC-TR-2000-001, Enero de 2000.
[BCK98] Len Bass, Paul Clements y Rick Kazman. Software Architecture in Practice. Reading,
Addison-Wesley, 1998.
[Bez98] Konstantin Besnozov. Architecture of information enterprises: Problems and perspectives.
http://www.beznosov.net/konstantin/doc/cis6612-paper.pdf, Abril de 1998.
[BMR+96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal.
Pattern-oriented software
architecture A system of patterns. John Wiley & Sons, 1996.
[Boe95] Barry Boehm. Engineering Context (for Software Architecture). Invited talk, First
International Workshop on
Architecture for Software Systems. Seattle, Abril de 1995.
[Boo91] Grady Booch. Object-Oriented Design with Applications. The Benjamin/Cummings
Publishing Company, Inc,
1991.
[Bos00] Jan Bosch. Design and use of Software Architecture. Addison-Wesley, 2000.
[BR01] Jason Baragry y Karl Reed. Why We Need a Different View of Software Architecture. The
Working IEEE/IFIP Conference on Software Architecture (WICSA), Amsterdam, 2001.
[BRJ99] Grady Booch, James Rumbaugh e Ivar Jacobson. El Lenguaje Unificado de Modelado.
Madrid, Addison-Wesley, 1999.
[Bro75] Frederick Brooks Jr. The mythical man-month. Reading, Addison-Wesley, 1975.
[Cib98] C. U. Ciborra. Deconstructing the concept of strategic alignment. Scandinavian Journal of
Information Systems, vol. 9, pp. 67-82, 1998.
[CLC03] David Cohen, Mikael Lindvall y Patricia Costa. Agile Software Development. A DACS
State-of-the-Art Report, DACS Report, The University of Maryland, College Park, 2003.
[Cle96a] Paul Clements. A Survey of Architecture Description Languages. Proceedings of the
International Workshop on Software Specification and Design, Alemania, 1996.
[Cle96b] Paul Clements. Coming attractions in Software Architecture. Technical Report, CMU/SEI96-TR-008, ESC-TR- 96-008, Enero de 1996.
[CN96] Paul Clements y Linda Northrop. Software architecture: An executive overview. Technical
Report, CMU/SEI-96- TR-003, ESC-TR-96-003. Febrero de 1996.
[DD94] Peter Denning y Pamela Dargan. A discipline of software architecture. ACM Interactions,
1(1), pp. 55-65, Enero de 1994.
[CBK+95] Paul Clements, Len Bass, F. Kazman y Gregory Abowd. Predicting Software Quality by
Architecture-Level Evaluation, 485- 498. Proceedings, Fifth International Conference on Software
Quality. Austin, 23 al 26 de Octubre de 1995, pp. 485-498. Austin, American Society for Quality
Control, Software Division, 1995.
218
[DDT99] Serge Demeyer, Stphane Ducasse y Sander Tichelaar. Why FAMIX and not UML?: UML
Shortcomings for coping with round-trip engineering. UML99 Conference Proceedings, LNCS
Series, Springer Verlag, 1999.
[Dij68a] Edsger Dijkstra. The Structure of the THE Multiprogramming system. Communications of
the ACM, 26(1), pp. 49-52, Enero de 1983.
[Dij68b] Edsger Dijkstra. GO-TO statement considered harmful. ACM Communications of the
ACM, 11(3), pp. 147-148, Marzo de 1968.
[DIR99] N. Dunlop, J. Indulska y K. A. Raymond. CORBA and RM-ODP: Parallel or divergent?,
Distributed Systems Engineering, 6, pp. 82-91.
[DK76] Frank DeRemer y Hans Kron, Programming-in-the-large versus programming-in-the-small.
IEEE Transaction in Software Engineering, 2, pp. 80-86, 1976.
[Dou00] Bruce Powel Douglas. UML The new language for real-timed embedded systems.
http://wooddes.intranet.gr/papers/Douglass.pdf, 2000.
[Fie00] Roy Thomas Fielding. Architectural styles and the design of network-based software
architectures. Tesis doctoral, University of California, Irvine, 2000.
[Fow01] Martin Fowler. Is design dead?. XP2000 Proceedings,
http://www.martinfowler.com/articles/designDead.html, 2001.
[GAD+02] Yann-Gal Guhneuc, Herv Albin-Amiot, Rmi Douence y Pierre Cointe. Bridging the
gap between modeling and programming languages. Reporte tcnico, Object Technology
International, Julio de 2002.
[Gar95] David Garlan. Research Directions in Software Architecture. ACM Computing Surveys
27, 2, pp. 257-261, Junio de 1995.
[Gar00] David Garlan. Software Architecture: A Roadmap. En Anthony Finkelstein (ed.), The
future of software engineering, ACM Press, 2000.
[Gars/f] David Garlan. Software architectures. Presentacin en transparencias,
http://www.sti.uniurb.it/events/sfm03sa/slides/garlan-B.ppt.
[Gli00] Martin Glinz. Problems and deficiencies of UML as a requirements specification language.
En Proceedings of the 10th International Workshop of Software Specification and Design (IWSSD10), San Diego, noviembre de 2000, pp. 11- 22.
[GoF95] Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Design Patterns: Elements
of reusable objectoriented software. Reading, Addison-Wesley, 1995.
[HHR+96] Pat Hall, Fiona Hovenden, Janet Rachel y Hugh Robinson. Postmodern Software
Development. MCS Technical Reports, 1996.
[Hig01] Jim Highsmith. The great methodologies debate. Part I. Cutter IT Journal, 14(12),
Diciembre de 2001.
[GS94] David Garlan y Mary Shaw. An introduction to software architecture. CMU Software
Engineering Institute Technical Report, CMU/SEI-94-TR-21, ESC-TR-94-21, 1994.
219
[HNS99] Christine Hofmeister, Robert Nord y Dilip Soni. Describing Software Architecture with
UML. En Proceedings of the First Working IFIP Conference on Software Architecture, IEEE
Computer Society Press, pp. 145-160, San Antonio, Febrero de 1999.
[HNS00] Christine Hofmeister, Robert Nord y Dilip Soni. Applied software architecture, Reading,
Addison Wesley, 2000.
[Hock00] Dee Hock. Birth of the chaordic age. San Francisco, Berrett-Koehler.
[KAB+96] Rick Kazman, Gregory Abowd, Len Bass y Paul Clements. Scenario-Based Analysis of
Software Architecture.
IEEE Software, 13(6), pp. 47-55, Noviembre de 1996.
[Keen91] P. G. W. Keen. Relevance anr rigor in information systems research, en H.-E. Nissen, H.
K. Klein y R.
Hisrchheim (eds), Information Systems Research: Contemporary approaches and emergent
traditions, Elsevier, 1991.
[KNK03] Rick Kazman, Robert Nord, Mark Klein. A life-cycle view of architecture analysis and
design methods. Technical Report, CMU/SEI-2002-TN026, Setiembre de 2003.
[Kros/f] John Krogstie. UML, a good basis for the development of models of high quality?.
Andersen Consulting Noruega & IDI, NTNU,
http://dataforeningen.no/ostlandet/metoder/krogstie.pdf, sin fecha.
[Kru95] Philippe Kruchten. The 4+1 View Model of Architecture. IEEE Software 12(6), pp. 42-50,
Noviembre de 1995.
[Lar03] Craig Larman. UML y Patrones. 2a edicin, Madrid, Prentice Hall.
[MB02] Ruth Malan y Dana Bredemeyer. Less is more with Minimalist Architecture. IEEE IT
Professional, Setiembre-Octubre de 2002.
[McC96] Steve McConnell. Missing in Action: Information hiding. IEEE Software, 13(2), Marzo de
1996.
[MKM+96] Robert Monroe, Andrew Kompanek, Ralph Melton y David Garlan. Stylized architecture,
design patterns, and objects. http://citeseer.nj.nec.com/monroe96stylized.html.
[MKM+97] Robert Monroe, Andrew Kompanek, Ralph Melton y David Garlan. Architectural Styles,
design patterns, and objects. IEEE Software, pp. 43-52, Enero de 1997.
[NATO76] I. P. Sharp. Comentario en discusin sobre teora y prctica de la ingeniera de software

en conference de NATO Science Committee, Roma, 27 al 31 de Octubre de 1969. Software
Engineering Concepts and Techniques:
Proceedings of the NATO conferences. J. N. Bruxton y B. Randall (eds.), Petrochelli/Charter, 1976.
[Par72] David Parnas. On the Criteria for Decomposing Systems into Modules. Communications
of the ACM 15(12), pp. 1053-1058, Diciembre de 1972.
[Par74] David Parnas. On a Buzzword: Hierarchical Structure, Programming Methodology, pp.
335-342. Berlin, Springer-Verlag, 1978.
[MS03] Geoffrey Lory, Derick Campbell, Allison Robin, Gaile Simmons y Patricia Rytkonen.
Microsoft Solutions Framework Version 3.0 overview.
http://www.microsoft.com/technet/itsolutions/techguide/msf/msfovrvw.mspx, Junio de 2003.
220
[Par76] David Parnas. On the Design and Development of Program Families. IEEE Transactions
on Software Engineering SE-2, 1, pp. 1-9, Marzo de 1976.
[Per97] Dewayne Perry. Software Architecture and its relevance for Software Engineering.
Coord97, 1997.
[Pfl02] Shari Lawrence Pfleeger. Ingeniera de Software: Teora y Prctica. Madrid, Prentice-Hall.
[Platt02] Michael Platt. Microsoft Architecture Overview: Executive summary,
http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnea/html/eaarchover.asp,
2002.
[Pre02] Roger Pressman. Ingeniera del Software: Un enfoque prctico. Madrid, McGraw Hill, 2001.
[PW92] Dewayne E. Perry y Alexander L. Wolf. Foundations for the study of software architecture.
ACM SIGSOFT
Software Engineering Notes, 17(4), pp. 4052, Octubre de 1992.
[RJB00] Jamers Rumbaugh, Ivar Jacobson, Grady Booch. El lenguaje unificado de modelado.
Manual de Referencia. Madrid, Addison-Wesley, 2000.
[Ross77] Douglas Ross. Structured analysus (SA): A language for communicating ideas. IEEE
Transactions on Software Engineering, SE-3(1), enero de 1977.
[Sch00] Klaus-Dieter Schewe. UML: A modern dinosaur? A critical analysis of the Unified
Modelling Language. En H. Kangassalo, H. Jaakkola y E. Kawaguchi (eds.), Proceedings of the
10th European-Japanese Conference on Information Modelling and Knowledge Bases, Saariselk,
Finlandia, 2000.
[SG96] Mary Shaw y David Garlan. Software Architecture: Perspectives on an emerging discipline.
Upper Saddle River, Prentice Hall, 1996.
[Shaw84] Mary Shaw. Abstraction Techniques in Modern Programming Languages. IEEE
Software, Octubre, pp. 10-26, 1984.
[Shaw89] Mary Shaw. Large Scale Systems Require Higher- Level Abstraction. Proceedings of
Fifth International Workshop on Software Specification and Design, IEEE Computer Society, pp.
143-146, 1989.
[Shaw96] Mary Shaw. Some Patterns for Software Architecture, en Pattern Languages of Program
Design, Vol. 2, J. Vlissides, J. Coplien, y N. Kerth (eds.), Reading, Addison-Wesley, pp. 255-269,
1996.
[Shaw01] Mary Shaw. The coming-of-age of Software Architecture research. Proceedings of the
23rd International Conference on Software Engineering (ICSE 2001), 2001.
[StS/f] Harald Strrle. Turning UML subsystems into architectural units. Reporte, LudwigMaximilians-Universitt Mnchen, http://www.pst.informatik.unimuenchen.de/personen/stoerrle/Veroeffentlichungen/PosPaperICSEFormat.pdf, sin fecha.
[Tem01] Theodor Tempelmeier. Comments on Design Patterns for Embedded and Real-Time
Systems. En: A. Schrr (ed.): OMER-2 (Object-Oriented Modeling of Embedded Realtime
systems) Workshop Proceedings. Mayo 9-12, 2001,Herrsching, Alemania. Bericht Nr. 2001-03,
Universitt der Bundeswehr Mnchen, Fakultt fr Informatik, Mayo de 2001.
[Spo71] C. R. Spooner. A Software Architecture for the 70's: Part I - The General Approach.
Software - Practice and Experience, 1 (Enero-Marzo), pp. 5-37, 1971.
221
[Tem99] Theodor Tempelmeier. UML is great for Embedded Systems Isnt it? En: P. Hofmann,
A. Schrr (eds.): OMER (Object-Oriented Modeling of Embedded Realtime systems) Workshop
Proceedings. Mayo 28-29, 1999, Herrsching (Ammersee), Alemania. Bericht Nr. 1999-01,
Universitt der Bundeswehr Mnchen, Fakultt fr Informatik, Mayo de 1999.
[TMA+S/f] Richard Taylor, Nenad Medvidovic, Kennet Anderson, James Whitehead Jr, Jason
Robbins, Kari Nies, Peyman Oreizy y Deborah Dubrow. A component- and message-based
architectural style for GUI software. Reporte para el proyecto F30602-94-C-0218, Advanced
Research Projects Agency, sin fecha.
[Tra02] Aron Trauring. Software methodologies: The battle of the Gurus. Info-Tech White Papers,
2002.
[Wir71] Niklaus Wirth. Program development by stepwise refinement, Communications of the
ACM, 14(4), pp. 221-227,Abril de 1971.
[WL97] Sharon White y Cuauhtmoc Lemus-Olalde. The software architecture process.
http://nas.cl.uh.edu/whites/webpapers.dir/ETCE97pap.pdf, 1997.
[WWI99] WWISA. Philosophy. Worldwide Institute of Software Architects, http://www.wwisa.org,
1999.
[Zac87] John A. Zachman, A Framework for Information Systems Architecture, IBM Systems
Journal, 26(3), , 1987.
[ZHH+99] Guoqiang Zhong, Babak Hodjat, Tarek Helmy y Makoto Amamiya. Software agent
evolution in adaptive agent oriented software architecture. IWPSE99 Proceedings, 1999.
Documentos guas
http://www.microsoft.com/spain/misc/avisolegal.htm
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.asp
222
Contenido
Introduccin ....................................................................................................................................................... 4
ARQUITECTURA DE SOFTWARE .......................................................................................................................... 6
Definicin........................................................................................................................................................ 6
Arquitectura ................................................................................................................................................... 6
Introduccin ................................................................................................................................................... 6
Definiciones ................................................................................................................................................ 7
Historia de la Arquitectura de Software ..................................................................................................... 8
Funciones Principales de un Arquitecto de Software ............................................................................... 13
Modelos o vistas ........................................................................................................................................... 13
Conceptos fundamentales ........................................................................................................................ 16
Procesos y Metodologas .............................................................................................................................. 22
Campos de la Arquitectura de Software....................................................................................................... 24
MTODOS DE MODELADO DE SOFTWARE ....................................................................................................... 36
ANLISIS ESTRUCTURADO ................................................................................................................................ 36
Objetivos: ..................................................................................................................................................... 36
Elementos: .................................................................................................................................................... 37
Objeto de datos ............................................................................................................................................ 37
MODELADO FUNCIONAL Y FLUJO DE INFORMACIN .................................................................................. 39
AMPLIACIONES ............................................................................................................................................. 40
MODELADO DEL COMPORTAMIENTO .......................................................................................................... 41
DICCIONARIO DE DATOS............................................................................................................................... 41
CASO DE ESTUDIO MODELADO ESTRUCTURADO .......................................................................................... 43
DICCIONARIO DE DATOS............................................................................................................................... 45
DESCRIPCIN DE ENTIDADES: ...................................................................................................................... 45
DICCIONARIO DE DATOS DETALLADO .......................................................................................................... 46
MODELO ENTIDAD RELACIN ...................................................................................................................... 48
DIAGRAMA DE FLUJO DE DATOS - DFD ........................................................................................................ 50
Nivel 0 ........................................................................................................................................................... 50
Nivel 1 ........................................................................................................................................................... 51
ARQUITECTURA DE SOFTWARE FINAL .......................................................................................................... 52
Enfoque basado en el anlisis de porte y modelos i* .................................................................................. 57
Introduccin .................................................................................................................................................. 57
Modelado i* ................................................................................................................................................. 58
Identificacin de actores del entorno organizacional basada en el modelo de porter ................................ 59
Primera fuerza: COMPETIDORES .................................................................................................................. 60
OBTENCIN DE REQUISITOS............................................................................................................................. 57
223
Segunda fuerza: RIVALIDAD ENTRE COMPETIDORES ................................................................................... 62

Tercera fuerza: SUSTITUTOS ......................................................................................................................... 62
Cuarta Fuerza: PROVEEDORES ...................................................................................................................... 62
Quinta Fuerza: CLIENTES .............................................................................................................................. 63
CADENA DE VALOR ....................................................................................................................................... 63
MODELADO DHARMA .................................................................................................................................. 65
Identificacin de actores del entorno .......................................................................................................... 65
Identificacin de dependencias .................................................................................................................... 65
Diagrama i* .................................................................................................................................................. 66
Modelado del entorno del sistema .............................................................................................................. 67
Identificacin de dependencias relevantes para el sistema ......................................................................... 67
Identificacin de actores adicionales en el entorno del sistema ................................................................. 68
Descomposicin del sistema ........................................................................................................................ 70
Conclusiones ................................................................................................................................................. 72
REQUERIMIENTOS ............................................................................................................................................ 73
1.
IDENTIFICACIN: ................................................................................................................................. 78
2.
ANLISIS Y NEGOCIACIN: .................................................................................................................. 79
Ingeniera de requerimientos ....................................................................................................................... 80

3.
LA ESPECIFICACIN DEBE SER: ............................................................................................................ 81
4.
MODELADO: ........................................................................................................................................ 83
5.
VALIDACIN ........................................................................................................................................ 83
6.
GESTIN .............................................................................................................................................. 84
Tcnicas utilizadas: ....................................................................................................................................... 84

ANLISIS ORIENTADO A OBJETOS .................................................................................................................... 86
La Orientacin a Objetos, OO ....................................................................................................................... 86
Qu es un Objeto .......................................................................................................................................... 87
Qu es una Clase .......................................................................................................................................... 88
Herencia ....................................................................................................................................................... 88
Interfaz ......................................................................................................................................................... 89
El Lenguaje Unificado de Modelado, UML ................................................................................................... 90
Bloques bsicos de construccin de UML .................................................................................................... 90
CASO DE ESTUDIO ANLISIS Y DISEO ORIENTADO A OBJETOS ............................................................... 108
Antecedentes ............................................................................................................................................. 109
ESPECIFICACION DE REQUERIMIENTOS...................................................................................................... 110
Propsito .................................................................................................................................................... 110
mbito y Alcance ........................................................................................................................................ 110
Definiciones, acrnimos y abreviaturas ..................................................................................................... 111
Cmo utilizar UML ...................................................................................................................................... 105
224
Visin General del Documento ................................................................................................................... 111

Descripcin Global ...................................................................................................................................... 111
Perspectiva del Producto ............................................................................................................................ 111
Funciones del Sistema ................................................................................................................................ 113
DESCRIPCIN DE REQUERIMIENTOS .......................................................................................................... 115
REQ - 01 ...................................................................................................................................................... 115
ADMINISTRACIN DE LOGUEOS ................................................................................................................. 115
REQ - 02 ...................................................................................................................................................... 116
ADMINISTRACIN DE CANDIDATURAS....................................................................................................... 116
REQ - 03 ...................................................................................................................................................... 116
ADMINISTRACIN DE ELECCIONES ............................................................................................................. 116
REQ - 04 ...................................................................................................................................................... 117
ADMINISTRACIN DE ENTIDADES .............................................................................................................. 117
REQ 05 ..................................................................................................................................................... 119
ADMINISTRACIN DE PROCESOS DEL SISTEMA ......................................................................................... 119
REQ 06 ..................................................................................................................................................... 119
ADMINISTRACIN DE PADRON ELECTORAL ............................................................................................... 119
REQ 07 ..................................................................................................................................................... 120
ADMINISTRACIN DE PAPELETA ELECTORAL ............................................................................................. 120
REQ 08 ..................................................................................................................................................... 121
ADMINISTRACIN DE PARTIDOS ................................................................................................................ 121
REQ 09 ..................................................................................................................................................... 122
ADMINISTRACIN DE PERIODOS ................................................................................................................ 122
REQ 10 ..................................................................................................................................................... 122
ADMINISTRACIN GRFICA DE RESULTADOS ............................................................................................ 122
REQ 11 ..................................................................................................................................................... 123
ADMINISTRACIN DE USUARIOS ................................................................................................................ 123
REQUERIMIENTOS NO FUNCIONALES ........................................................................................................ 124
ANLISIS Y DISEO ..................................................................................................................................... 126
ROADMAP................................................................................................................................................... 126
REQUIREMENTS .......................................................................................................................................... 127
NON-FUNCTIONAL REQUIREMENTS ........................................................................................................... 140
USE CASE .................................................................................................................................................... 142
FUNCTION USE CASE ............................................................................................................................... 143
DIAGRAMA - GENERAL USE CASE ............................................................................................................... 144
ECENARIO - USE CASE ................................................................................................................................. 146
DESCRIPTION ECENARIO - USE CASE .......................................................................................................... 147
FUNCTIONAL REQUIREMENTS .................................................................................................................... 130
225
DIAGRAMA SPECIFIC USE CASE................................................................................................................ 158

DOMAIN MODEL......................................................................................................................................... 162
DESIGN MODEL ........................................................................................................................................... 164
DESIGN MODEL Logical Model ................................................................................................................ 167
DESIGN MODEL Data Model .................................................................................................................... 174
DYNAMIC VIEW .......................................................................................................................................... 177
DYNAMIC VIEW - Sequence ........................................................................................................................ 178
DYNAMIC VIEW - Collaboration .................................................................................................................. 188
DYNAMIC VIEW - State ............................................................................................................................... 190
DYNAMIC VIEW - Activity ........................................................................................................................... 192
COMPONENT MODEL ................................................................................................................................. 196
DEPLOYMENT MODEL ................................................................................................................................ 200
CODIFICACIN ............................................................................................................................................ 203
SPLAHS SCREEN .......................................................................................................................................... 204
REQ - 01 ...................................................................................................................................................... 204
ADMINISTRACIN DE LOGUEOS ................................................................................................................. 204
REQ - 02 ...................................................................................................................................................... 205
ADMINISTRACIN DE CANDIDATURAS....................................................................................................... 205
REQ - 03 ...................................................................................................................................................... 206
ADMINISTRACIN DE ELECCIONES ............................................................................................................. 206
REQ - 04 ...................................................................................................................................................... 207
ADMINISTRACIN DE ENTIDADES .............................................................................................................. 207
REQ 05 ..................................................................................................................................................... 208
ADMINISTRACIN DE PROCESOS DEL SISTEMA ......................................................................................... 208
REQ 06 ..................................................................................................................................................... 209
ADMINISTRACIN DE PADRON ELECTORAL ............................................................................................... 209
REQ 07 ..................................................................................................................................................... 210
ADMINISTRACIN DE PAPELETA ELECTORAL ............................................................................................. 210
REQ 08 ..................................................................................................................................................... 211
ADMINISTRACIN DE PARTIDOS ................................................................................................................ 211
REQ 09 ..................................................................................................................................................... 212
REQ 10 ..................................................................................................................................................... 213
ADMINISTRACIN GRFICA DE RESULTADOS ............................................................................................ 213
REQ 11 ..................................................................................................................................................... 214
ADMINISTRACIN DE USUARIOS ................................................................................................................ 214
SNTESIS .......................................................................................................................................................... 215
REFERENCIAS .................................................................................................................................................. 216
ADMINISTRACIN DE PERIODOS ................................................................................................................ 212
226
227

Arquitectura de SW - BOOK

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Arquitectura de SW - BOOK

Diunggah oleh

Hak Cipta:

Format Tersedia

ARQUITECTURA

Ing. Patricio Michael Paccha A._

Ingeniero En Sistemas Informticos Y Computacin_

CARRERA DE SISTEMAS INFORMATICOS

(593) 072 961 200 Ext.

(593) 072 961 200 Ext.

Ingeniero En Sistemas Informticos Y Computacin.

Ing. Patricio Michael Paccha Angamarca.

ARQUITECTURA DEL SOFTWARE

En general, las definiciones entremezclan despreocupadamente (1) el trabajo dinmico de estipulacin de la

En una definicin semejante, hay que aclararlo, la idea de componente no es la de la correspondiente

La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus

Historia de la Arquitectura de Software

En la conferencia de la NATO de 1969, un ao despus de la sesin en que se fundara la ingeniera de

Evolucin de la Arquitectura de Software.

SOA es la prxima ola de desarrollo de aplicaciones. Es ms rpida, mejor y ms barata.

Mejorar la productividad de los empleados. Un acceso ptimo a los sistemas, la informacin y la

Aplicaciones ms productivas y flexibles. La estrategia de orientacin a servicios permite a IT

Funciones Principales de un Arquitecto de Software

La visin esttica: describe qu componentes tiene la arquitectura.

Monoltica. Donde el software se estructura en grupos funcionales muy acoplados.

Arquitectura de tres niveles. Especializacin de la arquitectura cliente-servidor donde la carga se

Otras arquitecturas afines menos conocidas son:

Tomadas en su conjunto, destacan ms bien un consenso. Independientemente de las discrepancias entre

Lenguajes de descripcin arquitectnica

Tabla 1 - Vistas en los marcos de referencia

La estrategia de arquitectura de Microsoft define, en consonancia con las conceptualizaciones ms

Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]

En lo que respecta a la estrategia arquitectnica de Microsoft, el marco general de Microsoft Solutions

La arquitectura del software es hoy en da un conjunto inmenso y heterogneo de reas de investigacin

Campos de la Arquitectura de Software

1) ARQUITECTURA COMO ETAPA DE INGENIERA Y DISEO ORIENTADA A OBJETOS.

Lo que sigue al momento arquitectnico es business as usual, y a cualquier configuracin, topologa o

2) ARQUITECTURA ESTRUCTURAL, BASADA EN UN MODELO ESTTICO DE ESTILOS, ADLS Y VISTAS.

3) ESTRUCTURALISMO ARQUITECTNICO RADICAL.

4) ARQUITECTURA BASADA EN PATRONES.

Es la corriente ms nueva. Se trata de un movimiento predominantemente europeo, con centro en Holanda.

6) ARQUITECTURA BASADA EN ESCENARIOS.

DIFERENCIAS ENTRE ARQUITECTURA Y DISEO

1) Una postura afirma que arquitectura y diseo son lo mismo.

2) DISEO DEL CDIGO.

Fundndose en el concepto de arquitectura conceptual de Hofmeister, Nord y Soni [HNS00] y en un modelos

PROBLEMAS ABIERTOS EN ARQUITECTURA DE SOFTWARE

El estudio de la arquitectura del software est siguiendo a la prctica, no liderndola. El estudio de la

Jason Baragry ha cuestionado la metfora de la arquitectura de edificios como columna vertebral de la

Tabla 3. Descripcin de las arquitecturas

Tampoco conviene sobredimensionar el contraste, imaginando que la academia est desconectada de la

Relevancia de la Arquitectura de Software

Una de las demostraciones ms elocuentes de la capacidad de la arquitectura del software como

Finalmente, Shaw y Garlan aplican diversas tablas de comparacin de atributos, en un ejercicio de

MTODOS DE MODELADO DE SOFTWARE

Considero dos puntos importantes para modelar sistemas informticos:

Los primeros trabajos entre los 60s y 70s

Describir lo que requiere el cliente

A qu responde el modelo de datos:

Cules son los objetos de datos primarios que va a procesar el sistema?

Examinar los datos en el contexto de una aplicacin de procesamiento de datos

Representacin de cualquier composicin de informacin compuesta que deba gestionar el

Estructura del objeto

Encapsula datos, NO operaciones (no es OO)

Nombrar una ocurrencia del objeto de datos (Cdigo de llave primaria)

El conjunto adecuado de atributos para un objeto se determina segn el contexto:

MODELADO FUNCIONAL Y FLUJO DE INFORMACIN

Diagrama de Flujo de Datos (DFD)