- 1 / 1 -

Propsito
El prposito del flujo de trabajo "Anlisis y
Diseo es:
Transformar los requerimientos en un modelo
de diseo del sistema a implementar.
Definir una arquitectura robusta para el
sistema.
Adaptar el diseo a un entorno de
implementacin, diseando pensando en la
eficiencia.
Como resultado de las actividades de este flujo
de trabajo, se desarrolla la realizacin de los caos
de uso (diagramas de interaccin y de clases -
principalmente - los cuales muestran la forma
cmo trabajar la herramienta) identificados en
la etapa de Requerimientos.
Conceptos
1 Arquitectura del software
A continuacin se incluyen dos definiciones
sobre los que es la arquitectura del software.
David Garlan and Mary Shaw.
"Como el tamao y la complejidad de las
herramientas de software se ha
incrementado, el problema de diseo va
ms all del diseo de los algoritmos y las
estructuras de datos: disear y especificar
la estructura total del sistema surge como
un nuevo tipo de problema ....
1

Rational Software Corp.
"la arquitectura de una herramienta de
software es la organizacin o estructura de
los componentes significantes los cuales
interactan a travs de interfaces. [1]

1Traducido de "An Introduction to Software Architecture
Mary Shaw and David Garlan. School of Computer
Science. Carnegie Mellon University. www.sei.cmu.edu
En trminos generales, el trmino
"Arquitectura del software hace referencia al
diseo estructural del software.
1 Patrones de Diseo
Un patrn de define como:
"... una solucin a un problema de diseo
que aparece con frecuencia. [2]
"Los diseadores expertos en orientacin
a objetos (y tambin otros diseadores
de software) van formando un amplio
repertorio de los principios generales y de
expresiones que los guan la crear
software. A unos y a otras podemos
asignarle el nombre de patrones.
2

Lecturas
Un proceso centrado en la arquitectura.
Capitulo 4 de "El Proceso Unificado de
Desarrollo de Software de Ivar Jacobson,
Gray Booch y James Rumbaugh.
Patrones GRASP. Capitulo 18 del libro de
Craig Larman.
Actividades
Las principales actividades a desarrollar en este
flujo de trabajo son: "Analizar la arquitectura,
"Analizar los casos de uso, "Disear los casos de
uso, "Disear las clases, y "Disear la base de
datos.
A continuacin se describen cada una de estas
actividades.
.1Analizar la arquitectura
El propsito de esta actividad es :
Definir la arquitectura (estructura) candidata
para el sistema, basndose en la experiencia
obtenida en el diseo de sistemas

2Tomado de "UML y Patrones, capitulo 18. Craig Larman.
Prentice-Hall.
R RU UP P : : E Et ta ap pa a d de e A An n l li is si is s y y D Di is se e o o
Desarrollo de Software I
Notas de Clase No. 3 (DSI-NC03)

Antonio Vlez
antvelez@uvpalmira.edu.co
Universidad del Valle - Palmira

- 2 / 2 -
(herramientas) similares.
Definir los patrones arquitectnicos a utilizar y
convenciones de modelado para la
herramienta a implementar.
Proveer una entrada para el proceso de
planificacin.
Los pasos a seguir a fin de obtener resultados
son:
.1.1Definir la organizacin de la herramienta
El propsito es crear una estructura para el
modelo de diseo. Las herramientas de
software se organizan tradicionalmente en
capas (layers) a fin de moderar la complejidad
de la herramienta.
.1.2Identificar elementos de anlisis
De acuerdo a la estructura definida para la
implementacin de la herramienta, se
seleccionan los patrones de diseo que se van
a utilizar.
.2Analizar los casos de uso
El propsito de esta actividad es:
Identificar las clases que ejecutan el flujo de
eventos de cada caso de uso.
Distribuir el comportamiento descrito en el
flujo detallado de los casos de uso, entre las
distintas clases identificadas.
Especificar la responsabilidad e identificar los
atributos y asociaciones de cada clases.
Los pasos a seguir a fin de obtener resultados
son (para cada caso de uso):
.2.1Identificar las clases del comportamiento
(flujo de eventos) del caso de uso.
Uno de los primeros pasos que se deben
realizar es la identificacin de un primer
conjunto de clases candidatas, entre las
cuales se distribuir el comportamiento
especificado en la descripcin de cada caso de
uso.
En todo el proceso que incluye la identificacin
y diseo de las clases se recomienda el uso de
los patrones de diseo.
Las tcnicas de identificacin de clases
recomienda ver el sistema desde tres
perspectivas distintas:
la frontera, entre el sistema y los actores;
(tradicionalmente, las clases que
corresponden a la interfaz de usuario);
la informacin manipulada y procesada por
el sistema, y
la lgica y control de la herramienta
Los estereotipos iniciales para estas clases
son boundary, entity y control;
respectivamente (estos estereotipos pueden
cambiar durante el proceso de diseo).
La identificacin de cada una de las clases
debe comprender: el nombre de la clase, su
estereotipo y una breve descripcin.
.2.2Distribuir el comportamiento entre las
distintas clases.
Para cada uno de los subflujos (tambin
llamados escenarios) identificados en la
especificacin de los casos de uso, se debe:
Crear uno o ms diagramas de interaccin
(colaboracin). Usualmente se elabora un
diagrama para el flujo bsico y un
diagrama por cada flujo alterno (si se
considera necesario, dependiendo de la
complejidad del mismo)
Identificar las clases responsables de
realizar el comportamiento descrito en el
flujo de eventos.
Ilustrar la interaccin entre clases en el
diagrama de interaccin. Un diagrama de
interaccin debe iniciar con un actor, ya
que es ste quien inicia la interaccin con
el caso de uso.

Para cada una de las clases identificadas en
los pasos previos, se debe:
.2.3Describir la responsabilidad de la clase
Una responsabilidad es una sentencia de lo
que puede proveer (hacer) un objeto. Una
responsabilidad involucra una operacin
(usualmente ms).
A cada una de las clases identificadas se les
- 3 / 3 -
debe asignar las responsabilidades. Una clase
con una nica responsabilidad es tal vez una
clase muy simple; mientras que una clase con
una docena o ms de responsabilidades es tal
vez muy compleja y es recomendable dividirla
en varias clases.
Para asignar de forma ms adecuada las
responsabilidades a las distintas clases, vase
los patrones GRASP y entre otros.
.2.4Definir atributos
Los atributos son informacin que debe ser
almacenada por una clase (el objeto es
propietario de la informacin, otros objetos no
la pueden referenciar)
Si en algn caso, la informacin reviste un
comportamiento complejo, es compartida por
dos o ms objetos, o es pasada por referencia
entre dos o ms objetos; dicha informacin
debe ser modelada como una clase separada.
Los atributos deben ser llamados con nombres
(sustantivos) que clarifica la informacin a
representar (almacenar).
La descripcin del atributo debe describir la
informacin que se almacenar en l.
El tipo del atributo es un tipo de dato simple
como entero, cadena de texto, valor de
verdad.
.2.5Establecer relaciones entre clases
El estudio de las relaciones entre las clases
inicia con la distribucin del comportamiento
entre clase (vase el numeral 2.2). Los
enlaces entre dos clases en un diagrama de
colaboracin indican que objetos de una clase
deben comunicarse con objetos de otra clase
para proveer la funcionalidad del caso de uso.
Estos enlaces pueden ser realizados
(implementados) de diversas formas:
1 Los objeto puede tener alcance global.
2 Los objeto se puede pasar como un
parmetros de un mtodo.
3 Los objetos pueden tener asociacin
permanente con otros objetos.
4 Los objetos pueden ser creados y
destruidos dentro de la operacin
(implementacin del mtodo), en este
caso, dichos objetos son considerados
como locales a la operacin.
Como resultado de este anlisis se elabora un
diagrama de clases, el cual contendr
bsicamente las clases y las relaciones
(inicialmente de asociacin y composicin).
.2.6Describir la dependencia de eventos entre las
clases
En ocasiones, los objetos necesitan necesitan
conocer cuando sucede algn evento en un
objeto fuente (target), sin que el objeto
fuente tenga conocimiento de todos los
objetos que tienen que ser notificados de la
ocurrencia de dicho evento. Una forma de
mostrar dicha notificacin es a travs de una
asociacin de subscripcin (la asociacin de
subscripcin indica que el objeto subscripto
debe ser notificado cuando un evento en
particular ocurre en el objeto subscriptor). Los
objetos subscriptores son generalmente
entidades (objetos pasivos que generalmente
almacenan informacin).
.3Disear los casos de uso
El principal propsito de esta actividad es:
Refinar y distribuir los requerimientos como
operaciones entre las distintas clases.
Para obtener dicho resultado, se realizan (para
cada uno de los casos de uso identificados) las
siguientes pasos:
.3.1Refinar la interaccin entre los objetos
En este caso, se refina los diagramas de
interaccin elaborados en actividades
anteriores.
.3.2Describir el comportamiento relacionado con
la persistencia
Una de los objetivos del paradigma de
programacin orientada a objetos es el
encapsular los detalles de la implementacin
(lo cual se logra con clases que realizan
actividades especificas).
Respecto a la persistencia, lo que se quiere es
tener objetos persistentes siendo observados por
objetos transitorios (no persistentes).
En la practica, en diversas ocasiones se la
aplicacin necesita controlar distintos aspectos
de la persistencia:
- 4 / 4 -
cuando los objetos persistentes son ledos y
escritos (insercin y actualizacin)
cuando son borrados los objetos persistentes.
.4Disear las clases
El propsito de esta actividad es:
Asegurar que las clases proveen el
comportamiento requerido en los casos de
uso.
Para obtener dicho resultado, se realizan (para
cada uno de los casos de uso identificados) las
siguientes pasos:
.4.1Definir las operaciones (mtodos)
Para identificar los mtodos de cada clase se
debe:
Estudiar las responsabilidades de cada
clase, definiendo una operacin para cada
responsabilidad. Se recomienda usar la
descripcin de la responsabilidad como
descripcin inicial de la operacin.
Estudiar la interaccin entre objetos para
determinar como son usadas. Extienda la
descripcin de la operacin por cada uno
de los casos de uso; refinando la
descripcin, el tipo de dato que retorna
(devuelve) y los parmetros.
Los mensajes es una la base para la
identificacin de operaciones.
.4.2Definir atributos
Los atributos permiten almacenar informacin
en una instancia (objeto), y son usados para
representar el estado de una instancia. Para
cada atributo se debe definir:
El nombre
El tipo, el cual debe ser un tipo de dato
elemental soportado por un lenguaje de
programacin.
El valor por defecto o valor inicial, con el
cual es inicializado el atributo cuando es
creada una instancia.
La visibilidad, la cual puede ser: pblico
(public), privado (private) o protegido
(protected)
.4.3Definir asociacin y composicin
Para cada una de las asociaciones
identificadas previamente, se debe:
Establecer la navegabilidad. Dicha
navegabilidad se puede identificar a partir
de los diagramas de interaccin.
Si hay atributos es la asociacin, cree una
"clase asociacin con los atributos de
sta.
.4.4Definir generalizacin
Las clases pueden ser organizadas en una
jerarqua de generalizacin para reflejar
comportamiento y estructura en comn.
.5Disear lo base de datos
El propsito de esta actividad es:
Asegurar que los datos persistentes son
almacenados consistentemente y de forma
eficiente.
Definir el comportamiento que debe ser
implementado en la base de datos.
Para obtener dicho resultado, se realizan (para
cada uno de los casos de uso identificados) las
siguientes pasos:
.5.1Mapear el diseo de clases persistentes al
modelo de datos
Elaborar el modelo de datos a partir de las
clase identificadas como persistentes.
Bibliografa
[1] Rational Software Corp. The Rational
Unified Process. Informacin obtenida de
la versin de evaluacin que provee
Rational Software Corp.
[2] James Rumbaugh, Ivar Jacobson, Gray
Booch. El Proceso Unificado de Desarrollo
de Software. Libro. Addison Wesley.
[3] James Rumbaugh, Ivar Jacobson, Gray
Booch. El Lenguaje Unificado de
Modelamiento - Manual de Referencia.
Libro. Addison Wesley.
[4] Object Management Group. OMG Unified
Modeling Language Specification. Paper.
- 5 / 5 -
Disponible en www.omg.org/uml
Otros documentos de interes.
[5] UML Basic : A Introduction to Unified
Modeling Language. Paper. Disponible en
www.therationaledge.com
[6] Sandra P. Morales, Antonio J. Vlez.
Arquitectura de Software. Arquitectura de
Software; aparte de la tesis titulada
"Arquitecturas de Interfaces de Usuario.
2002.
IMPORTANTE
Las notas de clase "NO SON, NI REEMPLAZA la
bibliografa del curso. En ellas, solo encontrar
un resumen de los temas tratados, y deben ser
vistas como gua de estudio y/o trabajo.