Unidad 1.

- Conceptos introductorios


1.1. La arquitectura de 4+1 vistas

La arquitectura software trata el diseo e implementacin de la estructura de alto
nivel del software. Es el resultado de ensamblar un cierto nmero de elementos
arquitectnicos para satisfacer la funcionalidad y ejecucin de los requisitos del
sistema; as como los requisitos no funcionales del mismo: fiabilidad,
escalabilidad, portabilidad, disponibilidad, etc. Perry y Wolf (1992) describen una
arquitectura software como:

Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones}

Es muy complejo capturar la arquitectura software en un slo modelo (o
diagrama). Para manejar esta complejidad se representan diferentes aspectos y
caractersticas de la arquitectura en mltiples vistas. Una vista es una
presentacin de un modelo, la cual es una descripcin completa de un sistema
desde una particular perspectiva (Kruchten, 1995). El modelo ms aceptado a la
hora de establecer las vistas necesarias para describir una arquitectura software
es el modelo 4+1 (Kruchten, 1995).

Este modelo define 4 vistas principales:
1. Vista Lgica (Logical View), modelo de objetos, clases, entidad relacin,
etc.
2. Vista de Proceso (Process View), modelo de concurrencia y sincronizacin.
3. Vista de Desarrollo (Development View), organizacin esttica del software
en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.).
4. Vista Fsica (Physical View), modelo de correspondencia software -
hardware (aspectos de distribucin en mquinas, por ejemplo)

Y una vista ms, la "+1", que se muestra y traza en cada una de las anteriores y
que est formada por las necesidades funcionales que cubre el sistema, y que en
ocasiones identificamos como vista de "casos de uso". De donde deducimos que
segn este modelo, la arquitectura es en realidad evolucionada desde escenarios
El modelo 4+1 aplica la ecuacin de Perry y Wolf (1992) de forma independiente
para cada vista, por ejemplo, cada vista puede definir un conjunto de elementos
para su uso (componentes, contenedores y conectores).

Cada vista es descrita usando su particular y ms adecuada notacin (por
ejemplo, existen diagramas UML que se adaptan ms a una vista que otra). Para
cada vista los arquitectos pueden escoger cierto esquilo arquitectnico (patrn
arquitectnico), permitiendo la coexistencia de mltiples estilos en un sistema.
Y por ltimo, tambin comentar que el modelo de vistas 4+1 es genrico: otras
notaciones y herramientas a parte de UML pueden usarse, y cualquier mtodo de
diseo, especialmente para las descomposiciones lgicas y de proceso.

Descripcin 4+1 Entonces, para hacer un diseo completo de la Arquitectura de
Software debemos documentar nuestro sistema en diferentes Vistas o
ngulos, aqu es donde viene el uso del modelo 4 + 1 de Pilippe
Kruchten.

Descripcin vista
lgica

En la Vista Lgica hablamos principalmente de los requerimientos
funcionales del sistema y de lo que el sistema debe de hacer, las
funciones y servicios que se han definido. Nos vamos a enfocar a lo que
hemos definido como dominio de la aplicacin, lo que son las clases y
objetos principales que formaran el corazn o "core" de nuestra
aplicacin. Esta vista la vamos a complementar con los diagramas
UML:
Diagrama de Clases
Diagrama de Paquetes

Descripcin vista de
despliegue

En la Vista de Despliegue o Vista de Desarrollo se va a mostrar
principalmente como est dividido nuestro sistema de software en
componentes, y muestra las dependencias entre estos componentes.
Los componentes fsicos incluyen archivos, cabeceras, bibliotecas
compartidas, mdulos, ejecutables, o paquetes. Tambin va a
mostrar la organizacin y las dependencias entre el conjunto de
componentes, y como se comunican entre ellos. Esta vista la vamos a
complementar con los diagramas UML:
Diagrama de Componentes
Diagrama de Paquetes

Descripcin vista de
procesos

En la Vista de Procesos representamos los flujos de trabajo paso a
paso de negocio y operacionales de los componentes que conforman el
sistema.
Tambin va a mostrar algunos de los requisitos no funcinales, como
son ejecucin, disponibilidad, tolerancia a fallas, integridad, seguridad,
confiabilidad entre otros. Esta vista la vamos a complementar con los
diagramas UML:
Diagrama de Actividad

Descripcin vista fsica
En la Vista Fsica representamos como estn distribuidos los
componentes entre los distintos equipos que conforman la solucin
incluyendo los servicios.
Los elementos definidos en la vista lgica se mapean a componentes
de software o de hardware. Esta vista la vamos a complementar con los
diagramas UML:
Diagrama de Deployment

Descripcin vista +1
Por ultimo tenemos la Vista +1 o Vista de Escenarios, esta vista va a
ser representada por los casos de uso, que nos van a ayudar a unir las
otras cuatro vistas, as desde un caso de uso podemos ver cmo se van
ligando las otras cuatro vistas, con esto tenemos una trazabilidad de
componentes, clases, equipo, paquetes, etc., para realizacin cada
caso de uso. Esta vista la vamos a complementar con los diagramas
UML:
Diagrama de Casos de Uso
Relacin entre las vistas

Como sucede en otras muchas ocasiones, si bien el modelo no es una
metodologa s que "sugiere" un mtodo de trabajo. Parece lgico que la vista de
escenarios o casos de uso sea la de arranque, y que de ah se pase a la vista
lgica. Desde la vista lgica afrontaremos la de desarrollo y procesos, una vez que
tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de
ejecucin. Para con todo concluir en la vista fsica. Todo ello, obviamente, con sus
correspondientes y tpicas iteraciones.

Arquitectura y UML

Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su
translacin a un lenguaje de modelado concreto como UML. Hay que tener en
cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no
exista una clara relacin entre ambos, lo que a menudo produce confusin al
diseador que en la actualidad quiere modelar una arquitectura con ambas
herramientas. A modo de resumen la translacin se presenta en la siguiente tabla:

Vista UML
Escenarios Casos de Uso
Lgica Clases, de Estados y Colaboracin
Desarrollo Componentes
Fsica Despliegue
Procesos Actividad, Estados, Secuencia

1.2. Desarrollo orientado a objetos

Enfoque de Orientacin a Objetos
El enfoque de orientacin a objetos es una forma de observar la realidad. El
enfoque como su nombre lo indica se basa en el concepto de objeto:
Es todo aquello que tiene caractersticas que lo hacen nico e indivisible dentro
del entorno al que pertenece. Siempre es posible establecer propiedades o
atributos de un objeto, lo mismo que su grado de respuesta a estmulos externos
(comportamientos del objeto). Percibimos tal cual por sus caractersticas y su
respuesta ante el entorno. Un elemento notable es que las caractersticas de un
objeto pueden ser por s mismas otros objetos.
La orientacin a objetos promete mejoras de amplio alcance en la forma de
diseo, desarrollo y mantenimiento del software ofreciendo una solucin a largo
plazo a los problemas y preocupaciones que han existido desde el comienzo en el
desarrollo de software: la falta de portabilidad del cdigo y reusabilidad, cdigo
que es difcil de modificar, ciclos de desarrollo largos y tcnicas de codificacin no
intuitivas. Un lenguaje orientado a objetos ataca estos problemas. Tiene tres
caractersticas bsicas:
basado en objetos,
basado en clases
capaz de tener herencia de clases.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto.
Podemos definir un objeto como un conjunto complejo de datos y programas que
poseen estructura y forman parte de una organizacin.
Esta definicin especifica varias propiedades importantes de los objetos. En primer
lugar, un objeto no es un dato simple, sino que contiene en su interior cierto
nmero de componentes bien estructurados. En segundo lugar, cada objeto no es
un ente aislado, sino que forma parte de una organizacin jerrquica o de otro
tipo.
Estructura de un Objeto:
Un objeto puede considerarse como una especie de cpsula dividida en tres
partes:
1. RELACIONES. Las relaciones permiten que el objeto se inserte en la
organizacin y estn formadas esencialmente por punteros a otros objetos.
2. PROPIEDADES. Las propiedades distinguen un objeto determinado de los
restantes que forman parte de la misma organizacin y tiene valores que
dependen de la propiedad de que se trate. Las propiedades de un objeto
pueden ser heredadas a sus descendientes en la organizacin.
3. METODOS. Los mtodos son las operaciones que pueden realizarse sobre
el objeto, que normalmente estarn incorporados en forma de programas
(cdigo) que el objeto es capaz de ejecutar y que tambin pone a
disposicin de sus descendientes a travs de la herencia.

Clases e Instancias
Dentro de la definicin de objetos hay algunos que sern muy parecidos ya sea
que comparten la misma definicin de caractersticas. Una clase es una ayuda
notacional en el anlisis para establecer las propiedades y funciones que sern
comunes a todos los objetos que se generen a partir de ella, tal y como lo muestra
la figura 1.2.





Figura 1.2. Clase en notacin UML

En la notacin de la metodologa UML se utiliza un rectngulo con tres divisiones
para definir una clase. En la primera se indica el nombre de la clase, la segunda
contendr todas las propiedades del objeto y la tercera contiene las funciones por
media de las cuales el objeto responde a estmulos de su entorno.
En el enfoque orientado a objetos, todos los objetos se generan a partir de clases.
Incluso cuando solo se genere uno, de forma que todo objeto est asociado a la
clase a partir de la que se gener y se dice que dicho objeto es una instancia de
clase que puede usar directamente las caractersticas y funciones asociadas a la
clase. La clase es un elemento conceptual que permite definir y modelar, el objeto
o instancia de clase es una ejemplificacin de clase. Una instancia de clase tiene
valores de atributos y puede invocar sus mtodos.
Encapsulamiento
Cuando interactuamos con un objeto nicamente nos interesa conocer las
caractersticas y atributos que nos permiten establecer dicha interaccin, es decir
el objeto publica ciertas caractersticas y mtodos, pero encapsula las dems ya
que no es fundamental para el exterior conocerlas para poder interactuar con el
objeto. nicamente se requiere conocer aquellas que se exhiban como pblicas.
Polimorfismo
El polimorfismo se define como la caracterstica de que un objeto que pide la
ejecucin de una funcin a otro objeto no necesita saber la naturaleza del objeto
dueo de la funcin. El polimorfismo ms comn lo tenemos en un operador como
el de suma o multiplicacin, ya que la operacin se realiza aun cuando los
operndoos sean distintos. La implementacin del operador tiene el cuidado de
hacer correctamente la operacin para el tipo de datos que est participando como
se muestra en la figura 1.3.

Figura 1.3. La clase animal y las subclases len y pjaro. Polimorfismo.

Herencia
El concepto de herencia va asociado a la Generalizacin Especializacin- en el
que se establece que cierta clase de objetos puede tener clases de objetos ms
especializados las cuales por ser especializaciones, tendrn todos los elementos
de la clase genrica y modificarn la funcionalidad heredada o agregarn nueva
funcionalidad para especializarse.
En la notacin UML la relacin de herencia entre dos clases se indica por medio
de una flecha hueca que apunta a la clase ascendiente, esto es porque, en una
relacin de herencia el padre no se construye teniendo en cuenta que se pueden
derivar de l clases ms especializadas. Por otro lado las clases que son
descendientes es importante que sepan quin es su ascendiente pues de l estn
tomando propiedades y funciones. Ejemplo de herencia la figura 1.4.


Figura1.4. Herencia de clase

Asociaciones estticas
Permiten la estructuracin de los objetos incorporando reglas del negocio. En su
forma ms simple es un vnculo entre dos objetos. Al nivel de anlisis se
documentan como vnculos entre clases, sin embargo, es importante recordar que
las clases son definiciones generales de un tipo de objeto, lo que implica que no
son colecciones de objetos y por lo tanto las asociaciones estticas no son
asociaciones entre conjuntos de objetos como se pueden dar en el modelo
Entidad Relacin tradicional.
La asociacin se indica con una lnea uniendo a las dos clases. La lnea puede
tener una etiqueta que indique la forma en la que se est interpretando la
asociacin. Muchas reglas del negocio se refieren a los niveles mximos y
mnimos de vinculacin entre distintos objetos de la aplicacin. Por ejemplo, un
objeto Cliente solo debe estar asociado a un solo agente de Ventas, aunque un
Agente Vendedor puede estar vinculado a ms de un cliente. Este tipo de
informacin es la multiplicidad o cardinalidad de la asociacin y se indica
colocando un rango en los extremos de la asociacin.
Existen casos en los que una clase se asocia con ms de una clase, en donde es
conveniente no slo mostrar la multiplicidad, sino tambin cmo el analista
concibe el vnculo de la clase en cada asociacin. En estos casos se le define un
rol a la clase en a cada asociacin que participa como se muestra en la figura 1.5.

Figura 1.5: Asociaciones estticas

Asociaciones de agregacin o composicin.
Un caso particular de asociacin esttica, es cuando se encuentra que un objeto
no slo est asociado con otro, sino que adems uno es parte del otro. Este tipo
de situacin se le llama asociacin de agregacin. La agregacin podemos
establecerla en dos tipos: por composicin y por agregacin simple como se
muestra en la figura 1.6. En la primera, los objetos y la asociacin se dieron
simultneamente y cuando desaparezca un objeto, el otro tambin desaparecer,
as como la asociacin. Por lo regular se da cuando modelamos un objeto como
propiedad de otro objeto.

Figura 1.6 Agregacin y composicin.
La agregacin simple es la ms comn y se da cuando tenemos documentos,
tales como facturas, rdenes de entrada de almacn, recibos de pago, etc. Ya que
el documento es el objeto central y tiene una serie de caractersticas con cierto
grado de opcionalidad, que hacen no necesiten estar los dos para que la
agregacin se d. En UML la agregacin se denota con un rombo en el extremo
de la asociacin en donde se encuentra la clase a la que se le estn agregando
objetos. La agregacin por composicin se denota con el rombo slido, mientas
que la agregacin simple es con el rombo vaco.
En general es conveniente indicar las asociaciones de agregacin pues sugieren
que las operaciones de mantenimiento a esos objetos tienen que hacerse dentro
de una misma transaccin, lo cual ayuda a identificar la complejidad de los
modelos de objetos que se estn obteniendo. Siempre ser ms fcil dar
mantenimiento a una familia de objetos que a dos o ms familias de objetos como
lo sugieren las asociaciones de agregacin.

1.3. Diagramacin

Modelos.
Un modelo representa a un sistema software desde una perspectiva especfica. Al
igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la
misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en
un aspecto distinto del sistema. La finalidad de los diagramas es presentar
diversas perspectivas de un sistema a las cuales se les conoce como modelo, es
decir los diagramas ayudan a visualizar todas las caras del sistema, desde su
funcionalidad, la interaccin que van a tener otras personas con el mismo, la
interaccin que va a tener otro sistema con el mismo, las posibles fallas antes de
su construccin y dems aspectos que influyen en la creacin del sistema como
tal. Los modelos de UML que se tratan en esta parte son los siguientes:
Diagrama de Distribucin.



Diagrama de Casos de Uso.



Diagrama de Secuencia.


Diagrama de Colaboracin.


Diagrama de Estados


Diagrama de clases.


2. Diseo orientado a objetos

2.1. Diseo del sistema en base a procesos
La primera actividad en el proceso de desarrollo de sistemas involucra al equipo
de trabajo en el conocimiento del problema para establecer los requerimientos en
trminos confiables y especificaciones formales y concretas.
El proceso de anlisis de requerimientos pretende acelerar las curvas de
aprendizaje mediante subprocesos que permitan extraer el conocimiento clave de
los usuarios hacia estructuras incrementales de conocimiento, de tal forma que los
miembros del equipo de desarrollo, puedan llegar ms rpidamente a la parte
acelerada de la curva de aprendizaje. Sin embargo, sta adquisicin de
conocimientos no ser slo capacitacin, sino tambin, debe aprovecharse para
establecer los requerimientos bsicos del sistema. El Modelo de Requerimientos
se constituye a su vez de tres modelos:

Modelo de casos
Modelo de Interfaz
Modelo de Dominio del Problema

Cada uno contempla parte del conocimiento del usuario orientado a la
especificacin de las funciones bsicas del sistema. El Modelo de Casos extrae el
conocimiento funcional fundamental del problema de una forma estructurada y
progresiva, siendo la base para establecer la estructura del sistema. Este modelo
orienta todos las dems procesos del mtodo. El modelo de Interfaz establece el
vnculo visual entre el desarrollador y el usuario para concretar aspectos de la
interaccin que el sistema pudiese tener con su entorno externo, permitiendo la
retroalimentacin temprana de aspectos fundamentales para el conocimiento de la
aplicacin. En el Modelo del Dominio del Problema se establecern los principales
objetos que constituirn al sistema y las relaciones que tienen entre s.

2.1.1. Actividades y Casos de uso

Modelado de casos de uso
Un caso real de uso describe el diseo concreto del caso de uso a partir de una
tecnologa particular de entrada y salida, as como de su implementacin global.
Por ejemplo, si interviene una interfaz grfica para el usuario, el caso de uso real
incluir diagramas de las ventanas en cuestin y una explicacin de la interaccin
de bajo nivel con los artefactos de la interfaz. Los diagramas de casos de uso
pueden llegar a ser bastante grandes esto no es malo con los modelos grandes,
siempre y cuando se agregue valor al esfuerzo global. El hecho es que se puede
llegar a crear un modelo de gran tamao que describe los requisitos para su
sistema, y puede incluir un modelo de casos de uso general que se han creado
durante meses o aos de trabajo evolutivo. No deben ser creados todos por
adelantado antes de empezar a programar. Ahora veamos lo que el simple
diagrama de la figura. 2.1 podra evolucionar. El diagrama de casos de uso en la
figura 2.2. Abajo proporciona un ejemplo de un diagrama de casos de uso UML.:


Figura 2.2. Un simple diagrama de casos de uso para una universidad

Ahora veamos lo que el simple diagrama de la figura. 2.1 podra evolucionar. El
diagrama de casos de uso en la figura 2.2. Abajo proporciona un ejemplo de un
diagrama de casos de uso UML.:


Figura 2.2: Un simple diagrama de casos de uso para restauran

En el ejemplo representado en la figura 2.2. Los estudiantes se matriculan en
cursos con la ayuda del encargado de admisin. Los profesores ingresan las notas
obtenidas por los estudiantes de las actividades asignadas y el encargado
administrador autoriza la publicacin de calificaciones a los estudiantes. La
asociacin entre el estudiante e inscrito en seminario seala que el caso de uso es
invocado, inicialmente por un estudiante y no por un encargado de admisin (el
encargado de admisin es tambin un actor y est involucrado en este caso de
uso). Entendiendo que las asociaciones no representan flujo de informacin es
importante, simplemente indican que un actor es de alguna manera involucrado en
un caso de uso. La informacin fluye de ida y vuelta entre el actor y el caso de
uso, por ejemplo, los estudiantes deben indicar a qu seminarios quieren
inscribirse en el sistema y tendra que indicar a los estudiantes si han sido inscritos



Figura 2.3: Diagrama de casos de uso ms complejo de la misma universidad

Los Diagramas de casos de uso dan una visin general muy buena de los
requisitos. A menudo se dibuje un diagrama de casos de uso mientras se estn
identificando los actores del caso de uso y las asociaciones entre ellos.
(Schneider y Winters, 2001) sugieren que los diagramas de casos de uso deben
ser desarrollados desde el punto de vista del usuario y no del desarrollador. Su
objetivo es modelar los requisitos de comportamiento para el sistema y cmo los
usuarios trabajan con el sistema para satisfacer sus necesidades, no lo que los
desarrolladores creen que deben construir.

Identificacin de los actores
Un actor representa a cualquier cosa o alguien que interacta con el sistema. Esto
puede incluir a las personas (no slo el usuario final), los sistemas externos, y
otras organizaciones. Los actores son siempre externos al sistema que est
siendo modelado, ellos nunca son parte del sistema. Para ayudar a encontrar a los
actores en el sistema, debe hacerse las siguientes preguntas (Schneider y Winters
2001; Leffingwell y Widrig 2000):

Quin es el principal cliente de su sistema?
Quin obtiene la informacin de este sistema?
Quin proporciona informacin al sistema?
Quin instala el sistema?
Quin opera el sistema?
Quin apaga el sistema?
Qu otros sistemas interactan con este sistema?
Hay algo que suceder de forma automtica a una hora predeterminada?
Quin suministro, utilizacin, o eliminar la informacin del sistema?
De dnde viene el sistema de obtener informacin?

Un caso de uso es una secuencia de acciones que proporcionen un valor medible
para un actor. Otra forma de verlo es un caso de uso es, describe una manera en
la que un actor del mundo real interacta con el sistema.

Identificacin de casos de uso
Una forma en preguntando a sus interesados las siguientes preguntas desde el
punto de vista de los actores:
Cules son los usuarios de este rol tratando de realizar?
Qu deben ser capaces los usuarios de hacer?
Cules son las principales tareas de los usuarios en este papel?
Qu informacin necesitan examinar, crear o cambiar los usuarios de este
perfil? Qu informacin necesitan los usuarios de este perfil del sistema?
Qu hacen los usuarios en este perfil que necesitan informar al sistema?

Los sistemas y sus fronteras
Un caso de uso describe la interaccin con un "sistema". Las fronteras ordinarias
del sistema son:
la frontera hardware/software de un dispositivo o sistema de cmputo
el departamento de una organizacin
la organizacin entera




Figura 2.4 fronteras de un sistema

Es importante definir la frontera del sistema como se muestra en la figura 2.4, para
identificar lo que es interno o externo, as como las responsabilidades del sistema.
El ambiente externo est representado nicamente por actores.

Casos de uso primario, secundario y opcional.
Los casos deberan clasificarse en primarios, secundarios u opcionales. Ms
adelante, a partir de estas designaciones, clasificaremos nuestro conjunto de
casos de uso para establecer prioridades en su desarrollo.
Los casos primarios de uso representan los procesos comunes ms importantes,
como Comprar productos.
Los casos secundarios de uso representan procesos menores o raros; por
ejemplo, los casos opcionales de uso representan procesos que pueden no
abordarse.

2.1.2. Interfaz de usuario

Un caso real de uso describe el diseo concreto del caso de uso a partir de una
tecnologa particular de entrada y salida, as como de su implementacin global.
Por ejemplo, si interviene una interfaz grfica para el usuario, el caso de uso real
incluir diagramas de las ventanas en cuestin y una explicacin de la interaccin
de bajo nivel con los artefactos de la interfaz.

Una alternativa podra consistir en que el diseador realizara storyboards o
secuencias de las pantallas de la interfaz general para el usuario y despus
incorporar los detalles durante la implementacin. Los storyboards son de gran
utilidad, si antes de la implementacin los diseadores o el cliente necesitan
descripciones rigurosamente detalladas. La interfaz de usuario UI2 es la parte del
software con el que un usuario interacta directamente. Un prototipo de interfaz de
usuario es un modelo de baja fidelidad de la interfaz de usuario para el sistema.
Representa las ideas generales de la IU, pero no los detalles exactos.
Esencialmente los prototipos de IU representan los requisitos de una manera
independiente de la tecnologa, al igual que los modelos de casos de uso
esenciales para hacer sus necesidades conductuales. Un prototipo de IU es
realmente el estado inicial, el inicio de la interfaz para el sistema. Estos modelos
de requisitos de interfaz de usuario, evolucionan a travs del anlisis y diseo para
dar lugar a la interfaz de usuario final para su sistema.

Cuando un equipo est creando un elemento esencial del prototipo de interfaz de
usuario, este itera entre las siguientes tareas: Explorar el uso del sistema. Su
equipo explorar el uso del sistema a travs de diversos medios. Modelo de los
elementos principales de la IU. Elementos de la interfaz, como las pantallas de
informes potenciales, se puede modelar usando papel de rota folio. Modelo de
elementos menores de la IU. Tales como campos de entrada, las listas, y los
contenedores (elementos de la IU que se agregan otros elementos de menor
importancia



Figura 2.5: Un prototipo de interfaz de usuario.

La creacin de un prototipo de interfaz de usuario es una tcnica de anlisis
iterativo en el que los usuarios participan activamente en el bosquejo en marcha
de la interfaz de usuario para un sistema como se muestra en la figura 2.5. Los
prototipos de interfaz de usuario tienen varios propsitos:
Como el anlisis de un artefacto que le permite explorar el espacio del
problema con las partes interesadas;
Como un artefacto de diseo que le permite explorar el espacio de la
solucin de su sistema;
Como un vehculo para que usted se comunique el posible diseo de la
interfaz de usuario (s) de su sistema, y
Como un fundamento potencial desde donde continuar desarrollando el
sistema.

Mientras se estn determinando las necesidades de los stakeholders se puede
decidir transformar sus prototipos de interfaz de usuario, si ha creado bocetos.
Figura 2.6 que representa un esquema de dos pantallas potenciales o pginas
HTML basado en el prototipo de interfaz de usuario figura. 2.5. Transformar en
realidad no es la palabra aqu, ya que estoy usando una tecnologa de
modelizacin completamente diferente (una pizarra en lugar de papel) por lo que
en efecto se est reemplazando lo esencial del prototipo de interfaz de usuario con
los bocetos.

Figura 2.6: esquema de la pantalla para inscribirse en un seminario.

Una vez que entienda las necesidades de la interfaz de usuario de sus
stakeholders, el siguiente paso es construir en realidad un prototipo. Usando una
herramienta de creacin de prototipos o lenguaje de alto nivel como Java .Net u
otro, se desarrolla la pantalla, pginas y los informes que necesitan los usuarios.
Con la plataforma de interfaz de usuario seleccionada, puede iniciar la conversin
de los aspectos individuales de su interfaz de usuario. Es posible que desee crear
bocetos, como se ve en la figura. 2.6 o ir directamente a una aplicacin concreta,
como la pgina HTML que se muestra en la figura 2.7. Los dibujos son ms
inclusivos, y sus partes interesadas pueden participar activamente en su creacin,
a pesar de que la actual pgina HTML es mucho ms cercana al cdigo de
trabajo.



Figura 2.7. Una pgina HTML para inscribirse en un seminario.

Es fundamental comprender que no es necesario crear un prototipo para todo el
sistema. Es muy comn que al prototipo de una pequea porcin de la interfaz de
usuario, tal vez una sola pantalla o la pgina HTML, antes de pasar a su
aplicacin.
2.2. Diseo de la lgica.
2.1.2. Clases y Objetos.
En un caso de uso conducido por Modelado de objetos con UML se describen una
tcnica llamada anlisis de robustez, algo que el Rational Unified Process (RUP)
se refiere a su uso como anlisis de casos (IBM 2003). La idea bsica es que
usted puede analizar los pasos de un caso de uso para validar la lgica de
negocio dentro de l y garantizar que la terminologa es consistente con otros
casos de uso que ha analizado anteriormente. En otras palabras, usted lo puede
utilizar para asegurarse de que sus casos de uso son lo suficientemente robustos
para representar los requisitos de uso para el sistema que estamos construyendo.
Otro uso es el de identificar objetos potenciales o responsabilidades de objeto
para apoyar la lgica en el caso de uso, actuando efectivamente como un puente
hacia otros diagramas tales como diagramas de secuencia UML y los diagramas
de clases UML.

Un modelo conceptual explica (a sus creadores) los conceptos significativos en un
dominio del problema; es el artefacto ms importante a crear durante el anlisis
orientado a objetos. Una cualidad esencial que debe ofrecer un modelo conceptual
es que representa cosas del mundo real, no componentes del software. Una de las
primeras actividades centrales de un ciclo de desarrollo consiste en crear un
modelo conceptual para los casos de uso del ciclo actual. Esto no puede hacerse
si no se cuentan con los casos y con otros documentos que permitan identificar los
conceptos (objetos).

La creacin no siempre es lineal; por ejemplo, el modelo conceptual puede
formularse en paralelo con el desarrollo de los casos de uso. El paso esencial de
un anlisis o investigacin orientado a objetos es descomponer el problema en
conceptos u objetos individuales: las cosas que sabemos. Un modelo conceptual
es una representacin de conceptos en un dominio del problema (Fowler, 1996).
En UML, se ilustra con un grupo de diagramas de estructura esttica donde no se
define ninguna operacin. La designacin de modelo conceptual ofrece la ventaja
de subrayar fuertemente una concentracin en los conceptos del dominio, no en
las entidades del software. Puede mostrarnos:
conceptos
asociaciones entre conceptos
atributos de conceptos

En la figura 2.8, vemos un modelo conceptual parcial del dominio de una tienda y
las ventas. Explica grficamente que el concepto de Pago y Venta son importantes
en este dominio del problema, ya que Pago se relaciona con Venta en una forma
que conviene sealar y qu Venta tiene fecha y hora.