Introducción a UML, ADOO y el proceso unificado

INDICE
UML Y EL DESARROLLO DE SOFTWARE ORIENTADO A

OBJETOS 2
POR QUE DEBEMOS MODELAR 3

PAUTAS PARA UN BUEN MODELADO 5
MODELADO ORIENTADO A OBJETOS 6
QUE ES UN OBJETO? 6
IDENTIDAD 7
ESTADO 7
COMPORTAMIENTO 8
QUE ES UN MENSAJE? 9
PERSISTENCIA 9
QUE ES UNA CLASE? 10
ENCAPSULACIN 11
RELACIONES ENTRE CLASES 12
DIFERENCIAS ENTRE DIAGRAMAS DE CLASES Y OBJETOS 17
QUE ES UN PROCESO DE DESARROLLO DE SOFTWARE? 18
ANLISIS Y DISEO ORIENTADO A OBJETOS (A/DOO) 23
INTRODUCCIN AL A/DOO 23
Q U ES ANLISIS Y DISEO? 24
Q U SON EL ANLISIS Y EL DISEO ORIENTADOS A OBJETOS? 24
EJEMPLO 24
DEFINICIN DE LOS CASOS DE USO 24
DEFINICIN DE UN MODELO DEL DOMINIO 25
DEFINICIN DE LOS DIAGRAMAS DE INTERACCIN 26
DEFINICIN DE LOS DIAGRAMAS DE CLASES DE DISEO 27
UML 28
DESARROLLO ITERATIVO Y EL PROCESO UNIFICADO 28
INTRODUCCIN 28
LA IDEA MS IMPORTANTE DEL UP: DESARROLLO ITERATIVO 29
BENEFICIOS DEL DESARROLLO ITERATIVO 29
LONGITUD DE UNA ITERACIN Y FIJACIN DE LA DURACIN 29
CONCEPTOS DEL UP 30
LAS FASES DEL UP 30
LAS DISCIPLINAS DEL UP 31
INICIO 31
INTRODUCCION AL ANALISIS Y DISEO ORIENTADO A
OBJETOS Y AL PROCESO UNIFICADO
Q U ARTEFACTOS PODRAN CREARSE EN LA FASE DE INICIO? 32
COMPRENSIN DE LOS REQUISITOS 32
TIPOS DE REQUISITOS 32
MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN

CONTEXTO 33
INTRODUCCIN 33
OBJETIVOS 33
CASOS DE USO 34
CASOS DE USO Y REQUISITOS FUNCIONALES 34
TIPOS DE FORMALIDAD 35
EJEMPLO DE ESTE ESTILO DE PLANTILLA: 36
LA VARIACIN DE DOS COLUMNAS 37
EXPLICACIN DE LAS SECCIONES 37
PERSONAL INVOLUCRADO Y LISTA DE INTERESES 37
PRECONDICIONES Y GARANTAS DE XITO (POSTCONDICIONES) 38
ESCENARIO PRINCIPAL DE XITO Y PASOS (O FLUJO BSICO) 38
ESCENARIO PRINCIPAL DE XITO (O FLUJO BSICO): 38
EXTENSIONES (O FLUJOS ALTERNATIVOS) 39
BIBLIOGRAFA 39
Ezequiel Rozic - Silvia Herzovich 1

UML y el desarrollo de software Orientado a Objetos

Esta claro a esta altura de las circunstancias de los tiempos que corren que es
imposible pensar en el desarrollo de sistemas informticos en al actualidad sin
una metodologa de modelado que avale y sustente dichos desarrollos.
La complejidad y magnitud de los mismos (desarrollos de sistemas para Intranet

empresariales con cientos o miles de terminales interconectadas, desarrollos de
sistemas para Internet con un numero elevadsimo de accesos simultneos
distribuidos a lo largo del mundo, etc, etc, etc) implica o conlleva que si uno
desea llegar a buen trmino con los mismos debe tener como soporte primario
una metodologa de modelado.
Es bueno aclarar y no quiero que se forme un concepto errneo que para

sistemas informticos de poca complejidad tambin es necesario contar con una
metodologa de modelado que los sustente, pero es ms difcil de demostrar ya
que si usted esta en su da de suerte y cree que los planetas se alinearon para
que a usted le salgan las cosas bien y es un buen programador por una cuestin
meramente azarosa podra desarrollar un sistema informtico pequeo de
principio a fin sin esbozar formalmente en papel ninguna metodologa de
modelado, sentarse directamente a programar y llegar a buen trmino en el
desarrollo en cuestin, pero es importante resaltar un par de cosas.
1. Usted, como dije antes no formaliz en papel la metodologa de

modelado, pero mentalmente tenia claro como iba a desarrollar su
sistema informtico.
2. Pudo trabajar de esta manera por la baja complejidad y magnitud del
sistema
3. Seguramente si el da de maana la empresa para la que desarrollo el
sistema posee un crecimiento importante, su sistema informtico no le
servir o el costo de adaptarlo para las nuevas circunstancias ser mayor
que desarrollar uno nuevo.

4. En caso de lograr adaptarlo, la performance del mismo ser menor que el

de un sistema desarrollado con una metodologa de modelado debido a
que:
a. Su sistema tendr ms lneas de cdigo de las necesarias para
realizar la gestin del sistema en cuestin
b. Por lo citado anteriormente el mismo ser un parche adaptado a
las circunstancias del momento y no una solucin real a las
necesidades de la empresa.
c. Ser muy poco probable que soporte futuras adecuaciones.
d. Tiene altas probabilidades que el sistema en cuestin colapse de
forma inesperada.
Quiero ser claro con lo citado anteriormente, no es que este desmereciendo su
trabajo, sino que deseo que entienda que esa no es la forma correcta de
trabajar.
Adems usted se preguntar que tiene que ver todo lo anterior con UML, pues
bien UML (Unified Modeling Lenguaje, es un lenguaje unificado modelado de
propsito general orientado a objetos, pero es importante que entienda que UML
no es una metodologa de desarrollo de softwareen si mismo).
Hechas estas aclaraciones empecemos a ver que caractersticas debe cumplir

una metodologa de modelado de forma general.
Por que debemos modelar

Quiero hacer una aclaracin a esta altura que me parece pertinente. Nosotros,
los que trabajamos en sistema no somos los nicos que necesitamos y
realizamos metodologas de modelado, de echo todas las dems ciencias o
carreras tambin poseen sus propias metodologas de modelados. Por citar
algunos ejemplos Los arquitectos y los ingenieros civiles antes de realizar una
obra realizan los planos, maquetas y demos en 3D realizadas en computadora
para mostrar como va a ser la obra y como quedar la misma una vez
terminada.

Los diseadores de autos antes de fabricar un modelo especifico realizan

tambin los planos, maquetas, croquis, simulaciones en 3D y Concept para
demostrar como ser el modelo del auto en cuestin.
Los cineastas antes de empezar a filmar o rodar una pelcula realizan lo que se
llama storyboarding (representacin de la pelcula en pequeos cuadros o
diapositivas dibujados a mano).
Los diseadores de circuitos electrnicos antes de implementar los mismos

tambin realizan los modelos en papel de los mismos. Y as podra seguir
citando infinidad de ejemplos.
Con lo cual con lo dicho hasta este momento la primera pregunta que se me
ocurre y que nos va a servir para entender por que aplicamos una metodologa
de modelado es la siguiente:
Qu es un modelo?
Con todo lo que ya dijimos hasta este momento creo que dicha pregunta se auto
contesta simplemente diciendo que un modelo es una simplificacin de la
realidad.
Con lo cual de la respuesta anterior surge una segunda pregunta que es la

siguiente:
Por qu modelamos?
Y con los ejemplos que dimos la respuesta a esta pregunta tambin es

inmediata.
Nosotros construimos modelos para poder comprender ms claramente el

sistema que estamos desarrollando.
Por medio del modelado logramos visualizar o imaginar como queremos que
sea nuestro sistema en cuestin.
Adems los modelos nos permiten especificar como deseamos que sea la
estructura y el comportamiento de nuestro sistema.

Queda absolutamente claro que al realizar diversos tipos de modelo indirecta y

directamente estamos documentando las acciones que llevamos a cabo y
decisiones que tomamos para realizar dichas acciones.
Y por ltimo al disear modelos estamos definiendo plantillas y esquemas en

comn entendibles y asimilables por todos los integrantes del equipo de
desarrollo.
Esta claro a esta altura que diseamos y construimos modelos para sistemas
complejos pues nos es imposible, como humanos que somos, entender el
sistema en su totalidad.
Ahora bien, existen un conjunto de pautas o normas que nos ayudaran a

construir buenos modelos.
Pautas para un buen modelado

Para realizar un buen modelado es importante que tenga en cuenta lo siguiente.
La decisin sobre que tipo de modelo crear tiene una muy fuerte influencia, casi
indisoluble, sobre como se resuelve un problema y como se moldea la solucin.
Lo que quiero decir con esto es que si el problema es encarado por alguien que
trabaja con la metodologa de Anlisis Estructurado, seguramente el modelo
que se cree esta orientado hacia el flujo de los datos de un proceso hacia otro
haciendo hincapi fuertemente en los algoritmos que sustentan dichos procesos
(de echo la metodologa de Yourdon es una metodologa de modelado orientada
a procesos y flujos de datos).
Ahora bien si el problema es encarado por alguien que trabaja en el desarrollo

de base de datos seguramente la metodologa que utilizar ser la de el modelo
Entidad Relacin.
Pero si la persona que encara el problema en cuestin trabaja utilizando el AOO

y DOO (anlisis y diseo orientad a objetos) seguramente aplicara un modelo el
cual se resuelva por medio de objetos y la interaccin entre los mismos.

Otro detalle que es importante es que cualquier modelo puede expresarse a

diferentes niveles de exactitud en funcin de las necesidades.
Por ejemplo con los ejemplos que dimos anteriormente tomemos el ejemplo de
desarrollo de un nuevo modelo de autos. En este caso a la gerencia de
Marketing por ah le alcanza con ver el croquis del auto para saber si el mismo
tendr una buena penetracin en el mercado segn los requerimientos actuales
sobre gusto o estilo de autos que poseen los clientes. A su vez a los ingenieros
aplicados a la aerodinmica del auto lo nico que necesitan es el Concept para
realizar las pruebas en el tnel de viento y por su parte los ingenieros
responsables del diseo del modelo en cuestin querrn todos los planos del
modelo y de cada una de las piezas que lo componen para ver si es viable y
factible la construccin del mismo.
Otra cuestin a tener en cuenta es que los mejores modelos son lo que estn
ligados fuertemente a la realidad. Como contraejemplo nadie comprara un auto
que tuviera las ruedas en el techo y apoyara su chasis directamente al piso ya
que eso no seria un auto y no satisface las funcionalidades que provee un auto.
Con todos los ejemplos dados hasta el momento queda absolutamente claro que
una buena metodologa de modelado esta compuesta por ms de un modelo,
mas bien podramos decir que esta formada por un conjunto de pequeos
modelos independientes entre si.
Modelado Orientado a Objetos

La visin del modelado de sistemas orientado a objetos esta basada en tratar de
ver el problema en cuestin y por ende su solucin como un conjunto de objetos
o clases que interactan entre si.
Aclaremos un poco esto ltimo.
Que es un Objeto?
Un objeto es una unidad atmica que encapsula un estado y un comportamiento.
Con lo cual un objeto representa una entidad fsica (por ejemplo un auto) o

abstracta (por ejemplo un proceso de facturacin) del problema o del espacio de

la solucin.
Los objetos poseen las siguientes caractersticas fundamentales:
1. Todo objeto posee identidad

2. Todo objeto posee un estado
3. Todo objeto posee un comportamiento
Identidad
Cada objeto posee un OID (identificador de objeto) el cual establece la identidad
del objeto. Adems el OID satisface ciertas caractersticas fundamentales:
Dicho OID es nico para cada objeto del sistema y el mismo posee un
alcance global dentro del sistema en cuestin. No pueden existir dos
objetos con el mismo OID. Si usted elimina un objeto y lo vuelve a crear el
OID del nuevo objeto ser diferente al OID del objeto eliminado ms all
que a simple vista dichos objetos sean idnticos.
Como acabamos de explicar queda absolutamente claro que el OID de un
objeto es generado en el momento de su creacin
El OID es independiente de la ubicacin fsica del objeto en cuestin
El OID es independiente de las propiedades del objeto, con lo cual esto
garantiza la independencia con respecto a la estructura y los valores de la
misma.
El OID persiste durante toda la vida del objeto y si el objeto se elimina el
OID del mismo no se vuelve a utilizar.
Los OID no se pueden controlar ni manipular y la administracin de los
mismos es transparente.
Estado
El estado de un objeto queda determinado por los valores que toman los
atributos de dicho objeto en un instante dado.

Cada atributo toma un valor de un dominio concreto (se llama dominio por si no
lo sabe al conjunto de valores posibles y vlidos que puede tomar un atributo.
Suponga que tenemos un objeto EMPLEADO y que posee un atributo
antigedad, el dominio de dicho atributo estar dado por los nmeros enteros
positivos comprendidos entre 0 y 65, debido que un empleado ingresado este
ao no posee antigedad, asumimos que la antigedad se toma en aos, y no
puede tener un valor mayor a 65 pues una persona a los 65 aos debe jubilarse,
con lo cual este nmero le da un margen para las personas que trabajan un par
de aos ms ya que por las leyes del menor una persona menor a 12 aos no
debera trabajar con lo cual el dominio podra ser de 0 a 53 si es que uno es
estricto con las leyes vigentes).
El estado de un objeto satisface ciertas caractersticas:
Como ya dejamos entrever anteriormente el estado evoluciona con el

transcurso del tiempo.
Algunos atributos pueden ser constantes
El estado de un objeto se ve afectado por el comportamiento de dicho
objeto. El comportamiento describe las acciones y reacciones del objeto
en cuestin agrupando las competencias del mismo.
Las operaciones de un objeto sobre otro tambin afectan al estado de
estos. Las operaciones de un objeto son consecuencia de un estimulo
externo representado por medio de un mensaje enviado desde otro
objeto.
Comportamiento
El comportamiento modela la interaccin entre los objetos.
La interaccin entre los objetos se modela por medio de los mensajes de los
objetos.

El comportamiento global del sistema queda representado y se base en la

comunicacin entre los diferentes objetos que lo componen.
Un sistema informtico puede verse como un conjunto de objetos autnomos y

concurrentes que trabajan de manera coordinada en la consecucin u obtencin
de un fin especfico.
Como dijimos anteriormente el comportamiento agrupa las competencias de un

objeto y describe las acciones y reacciones de ese objeto.
Que es un mensaje?
A la unidad de interaccin entre los objetos se la denomina mensaje. El mensaje
es el soporte de una comunicacin que vincula dinmicamente los objetos que
fueron separados previamente en el proceso de descomposicin del sistema.
Como dijimos antes un estmulo causar la invocacin de una operacin, la

creacin o destruccin de un objeto o la aparicin de una seal, etc.
Con lo cual podemos asumir que un mensaje es la especificacin de un estmulo

dado.
Un mensaje desencadenar una accin en el objeto destinatario. Y dicho objeto

debe poseer la inteligencia necesaria para poder interpretar y tratar dicho
mensaje.
Persistencia
Existe una caracterstica ms que se puede derivar de las tres caractersticas
anteriores y que es la de persistencia de los objetos.
La persistencia de los objetos define la capacidad de un objeto de trascender en

el espacio/tiempo.
Dicha caracterstica garantiza que podemos materializar cualquier objeto tomado

de memorias secundaria para usarlo en la ejecucin del sistema y podremos
reconstruirlo en el mismo estado que se encontraba antes de dejarlo en dicha
memoria.

Esta caracterstica debera ser transparente para el usuario ya que un objeto

existe desde el momento de su creacin hasta el momento que se decide
destruirlo, pero los lenguajes orientados a objetos que existen en la actualidad
no proponen un soporte totalmente adecuado o purista sobre dicha
caracterstica.
Que es una clase?

Subjetivamente el mundo real puede ser visto desde diferentes tipos de
abstracciones de la realidad.
Existen para ello diferentes mtodo de abstraccin los cuales pasamos a

enumerar.
Clasificacin / Instanciacin
Composicin / Descomposicin
Agrupacin / Individualizacin
Especializacin / Generalizacin
Dentro de estos mtodos la clasificacin es uno de los mtodos ms utilizados.
Pues ahora bien existen diferentes maneras de interpretar que es una clase.
Se entiende como clase:
1. A una descripcin de un conjunto de objetos similares.

2. Define el mbito de definicin de un conjunto de objetos.
Cabe a esta altura realizar un par de aclaraciones que le pueden ayudar a
entender el tema en cuestin.
1. Cada objeto que existe en el sistema pertenece a una clase especifica

que dio su origen (podramos pensar a una clase determinada como la
gran fabrica de objetos que poseen las caractersticas de esa clase. O
tambin podemos pensar que la clase es una matriz para fabricar dichos
objetos).
2. Con lo que acabamos de decir queda como corolario que los objetos se
crean por instanciacin de una clase.

Las clases poseen una caracterstica fundamental que heredan los objetos y es
la caracterstica o propiedad de encapsulacin.
Encapsulacin
El encapsulamiento provee al modelo orientado a objetos de ciertas
caractersticas muy deseables como las que pasamos a describir:
1. Se protegen los datos de accesos indebidos o indeseados.

2. El acoplamiento entre las clases disminuye (se denomina acoplamiento
bajo el entorno orientado a objetos a la dependencia funcional existente
entre dos clases distintas)
3. Como consecuencia del punto anterior aumenta la cohesin (la cohesin
bajo el entorno orientado a objetos implica que una clase u objeto
derivado de una clase se ocupa de una funcionalidad especifica, por
ejemplo en un entorno ideal de objetos supongamos que tenemos un
objeto FACTURA el mismo tendr toda la lgica necesaria para realizar
la funcionalidad correspondiente a la factura, pero no debera ocuparse
de la persistencia de la misma, o sea como y donde se guarda y se
recupera la factura. Si esto ltimo sucediera la clase que genera la
factura y el objeto FACTURA en si no sera cohesivo ya que se esta
ocupando de dos funcionalidades diferentes y sobre todo la ultima no es
una funcionalidad propia o que haga a la esencia de una factura).
4. Favorece la modularidad y el mantenimiento.
Los atributos de la clase y por ende de los objetos no deberan ser manipulados
directamente por el resto de los objetos.
El encapsulamiento se aplica sobre los atributos y mtodos o mensajes de una

clase y por ende se deriva a los objetos instanciados de la misma.
Existen tres niveles de encapsulamiento los cuales pasamos a describir:
Privado: Es el ms fuerte de todos los atributos y/o mtodos que se definan

como privados estarn totalmente invisibles para el resto de las clases del
sistema.

Protegidos: Los atributos y/o mtodos que se definan como protegidos

nicamente estarn accesibles para las clases derivadas de la original
Pblicos: Los atributos y/o mtodos que se definan como pblicos estarn
accesibles desde cualquier otra clase del sistema. Ahora vale en este momento
hacer una aclaracin muy importante. Si define los atributos de una clase como
pblicos esta rompiendo y transgrediendo el principio bsico de
encapsulamiento que poseen las clases. Tenga esto siempre bien presente.
Veamos como se representa una clase en UML con sus atributos y mtodos o
operaciones.
Observe la clase estudiante que posee los atributos privados NroExpediente,

DNI, Apellido y Nombre y los mtodos pblicos Alta(), Matricular() y
VerExpediente()
Relaciones entre clases

La relacin entre objetos en realidad puede representarse como la relacin entre
las clases de las cuales derivaron los mismos.
ASOCIACIN
El primer tipo de relacin entre clases es la asociacin.
La asociacin representa la relacin bidireccional entre dos clases. Una

asociacin es una abstraccin o generalizacin de la relacin entre dos objetos.
Veamos un ejemplo de lo recin expresado utilizando UML.

La primera parte muestra la relacin entre el objeto UBA que es una universidad
con el objeto Ezequiel que es un Alumno. Se generaliza esta relacin entre
ambos objetos y se genera la asociacin entre las clases Universidad y
Estudiante.
Las asociaciones poseen una especificacin de multiplicidad la cual indica cual

es el grado de la asociacin entre los objetos que la componen
bidireccionalmente.
En este caso 1 Universidad puede poseer n alumnos distintos y a su vez 1

alumno puede estar cursando en n universidades distintas.
Tenga cuidado pues esto da la sensacin de ser similar al grado de los

diagramas de entidad relacin pero conceptualmente es totalmente diferente ya
que estamos hablando de la relacin entre objetos o lo que es peor todava entre
clases. Por lo general se define la multiplicidad mnima y mxima para una clase
involucrada en una asociacin y la mnima no puede ser igual a 0 (cero), o sea
debe ser >=1 debido a que se garantiza la existencia de las clases que
componen la asociacin.
Adems de la asociacin entre clases existen otras formas de relacionar las

clases como la agregacin.
AGREGACIN
La agregacin representa una relacin de tipo parte de entre objetos.

Con respecto a la agregacin existen como subniveles lo cuales se generan en

funcin de la siguiente caracterizacin.
Si un objeto parte no puede comunicarse directamente con objetos externos

distintos al objeto agregado se dice que la misma es una relacin de agregacin
inclusiva. Ahora bien, si el objeto parte puede comunicarse directamente con
objetos externos distintos al objeto agregado se dice que dicha relacin de
agregacin no es inclusiva.
Adems si la composicin del objeto agregado puede cambiar se dice que la

relacin de agregacin es dinmica. Si la composicin del objeto agregado no
puede cambiar se dice que la relacin de agregacin es esttica.
Veremos como se representa la agregacin entre clases en UML.
En este caso es el rombo negro es debido a que la agregacin entre

departamentos de una empresa y la empresa en cuestin es una agregacin
inclusiva debido a que no le esta permitido en esta solucin a un departamento
tener relacin por fuera del objeto agregado, si esto no fuera as el rombo que
representa la relacin de agregacin sera de color blanco.
Adems dicha relacin de agregacin es dinmica ya que la empresa puede

agregar o quitar departamentos en el momento que lo considere conveniente.

Observe adems como se indica la multiplicidad de la relacin de agregacin

donde se indica que un departamento o ms de uno son parte de la empresa.
Tambin existe la generalizacin entre clases la cual pasaremos a explicar.
GENERALIZACIN
La generalizacin permite gestionar la relacin entre las mismas por medio de

un ordenamiento jerrquico. Esto quiere decir que para generalizar lo que se
realiza es la factorizacin de los atributos y mtodos en comn en clases ms
generales.
En general son trminos usuales al hablar de generalizacin los trminos de

clase padre y clase hija o de superclase y subclase o clase base y clase
derivada.
La generalizacin se puede obtener de dos maneras diferentes.
1. Por medio de la abstraccin de la generalizacin lo que implica que de un

determinado grupo de clases se factoriza los atributos y mtodos
comunes de las clases en cuestin agrupndolos en una superclase o
clase padre.
2. Por medio de la especializacin de una clase padre o genrica se derivan
todas las subclases posibles al dominio de estudio del sistema en
cuestin. Las subclases encontradas heredan los atributos, mtodos y
asociaciones de la clase padre o superclase.
Algo que es muy importante resaltar es que no importa por cual de los dos
mtodos se obtenga la generalizacin el resultado obtenido es el mismo y
ambos mtodos son transitivos.
Veamos un ejemplo de generalizacin realizado en UML para que le quede ms

claro.

De la generalizacin se desprende otro concepto o caracterstica muy importante

la cual se llama polimorfismo.
POLIMORFISMO
La idea de polimorfismo es que una caracterstica de una clase puede tomar

formas diferentes, pero seamos ms especficos para que la idea quede clara.
El polimorfismo permite que dado un mtodo o mensaje el mismo realice o

desencadene la ejecucin de operaciones diferentes. Para que esto pueda
suceder deberemos tener una estructura jerrquica de clases. Con lo cual lo que
estamos pidiendo concretamente es que cuando un mensaje de una superclase
o clase padre es heredado por una subclase o clase hija esta ltima posea la
posibilidad de modificar localmente (dentro de la subclase) de modificar las
operaciones que realiza dicho mensaje o mtodo.
Por ejemplo supongamos que tenemos una superclase cuenta bancaria la cual
posee dos subclases cuenta corriente y caja de ahorro. Podramos tener un
mtodo el cual le pedimos cual es el dinero disponible para gastar. Ahora
cuando dicho mtodo se instancia sobre cada una de las subclases en el caso
de la caja de ahorro nos dir que el monto disponible es nuestro saldo menos el
tope mnimo que posee la caja de ahorro para no ser cerrada, pero si

instanciamos dicho mtodo en la subclase cuenta corriente nos dir que el

monto disponible para gastar es el saldo de la cuenta corriente ms el monto
disponible para girar en descubierto.
Asociado al concepto de polimorfismo se encuentra el concepto de sobrecarga.

La sobrecarga permite que dado un mensaje en particular segn el entorno en el
que se ejecuta el mismo permite devolver resultados distintos.
Fjese que si no existiera el polimorfismo la sobrecarga sera imposible.
Un ejemplo tpico de sobrecarga es el operador + dentro de los lenguajes de

programacin. Si los operandos son nmeros el operador + devuelve la suma de
los nmeros sumados. Ahora bien, si los operandos son cadenas de caracteres
el operador + concatena ambas cadenas en una cadena de caracteres nica.
Diferencias entre diagramas de clases y objetos

Vale la pena hacer una aclaracin especial en este punto sobre los diagramas
de clases y los diagramas de objetos.
A saber los diagramas de clases y los diagramas de objetos son dos vistas
diferentes y complementarias del modelo.
Mientras que el diagrama de clase muestra la abstraccin de una parte del
dominio el diagrama de objetos representa una situacin concreta del dominio.
Esto sucede debido que las clases son abstracciones o generalizaciones de
algn tipo de objetos mientras los objetos son representaciones o instancias
puntuales de dichas clases. Si esto ltimo no le queda claro vuelva a leer la
parte de las relaciones de asociacin.
Adems las clases son abstractas como ya dijimos antes y no son instanciadas
(las clases), en el momento que esto sucede se convierten en objetos, con lo
cual los diagramas de clases nos permiten tener una compresin integral del
modelo.
Hechas ya todas las aclaraciones y explicaciones necesarias para entender los
conceptos bsicos del mundo de objetos entremos en el tema que nos interesa.

Que es un proceso de desarrollo de software?

El proceso de desarrollo de software define quien debe hacer que cosa debe
hacer, cuando debe hacerla y como debe hacerlo.
Como se imaginar no existe un proceso de desarrollo de software universal.
Segn las caractersticas propias de cada proyecto exigen que el proceso sea
configurable.
Para ello en el ao 1998 los tres amigos (Grady Booch, James Rumbauch y
Ivar Jacobson, que adems son los creadores del UML) definieron un proceso
de desarrollo el cual llamaron RUP (Rational Unified Process) que de forma
generalizada se denomina proceso unificado el cual permite realizar Ingeniera
de Negocio, Gestin de Requerimientos, Ingeniera de Datos, Diseo de
interfaces, Pruebas Funcionales, Pruebas de desempeo, Gestin de Cambios y
Configuracin.
El RUP esta formado por un conjunto de disciplinas las cuales las podemos
agrupar en dos grupos bien definidos. Disciplinas primarias y disciplinas de
apoyo.
Las disciplinas primarias estan compuestas por el Modelado de Negocio, los
Requerimientos, el Anlisis y el Diseo, la Implementacin, las Pruebas y el
Despliegue.
Las disciplinas de apoyo estn compuestas por el Entorno, la Gestin del
Proyecto y la Gestin de Configuracin y Cambios.
El RUP es independiente del proceso, lo que implica que no esta ligado a ningn
ciclo de vida de desarrollo de software en particular, sin embargo el RUP posee
las siguientes caractersticas fundamentales:
Es un proceso dirigido por Casos de Uso
Es un proceso centrado en la Arquitectura
Es un proceso iterativo e incremental
Expliquemos cada uno de estas caractersticas.

Dirigido por casos de uso es por que los casos de uso son un artefacto bsico
para establecer el comportamiento deseado del sistema, para verificar la
arquitectura y la comunicacin entre las personas involucradas en el proyecto.
Centrado en la arquitectura es por que la misma se utiliza como un artefacto
bsico para conceptualizar, gestionar, construir y evolucionar el sistema en
desarrollo.
Para ello existe un diagrama que visualiza las diferentes vistas arquitectnicas
4+1 (Kruchten 1995)
Iterativo e incremental implica que el ciclo de vida iterativo garantiza la evolucin

de los prototipos ejecutables que se muestran a los usuarios. Esto implica que
en cada iteracin se vuelve a realizar todo el ciclo de vida en cascada pero a
menor escala.
Adems los objetivos de la iteracin se establecen en funcin de la evaluacin
realizada en las iteraciones anteriores, ms especficamente en la anterior a la
actual. Esto garantiza un ida y vuelta entre el usuario y el equipo de desarrollo y
disminuye la posibilidad de malos entendidos entre las partes.

Cada proceso iterativo esta compuesto de las siguientes etapas en el ciclo de

vida en cascada son las siguientes: Anlisis, Diseo, Codificacin y Pruebas e
Integracin (estas son las etapas que se iteran n veces).
Cada iteracin comprende la planificacin de la iteracin, esto es lo que se
denomina el estudio de riesgo, luego se analizan los casos de uso para los
diferentes escenarios. En funcin de esto se disean las opciones
arquitectnicas.
Luego se realiza la codificacin integrando en la misma el viejo cdigo de las
iteraciones anteriores con el nuevo cdigo de la iteracin actual en la etapa de
construccin de la misma.
Cuando la codificacin se encuentra finalizada se realiza la evaluacin del
ejecutable que ser el prototipo a presentar para ver si satisface los criterios
definidos para esta iteracin.
Y por ltimo se realiza la preparacin de la entrega e instalacin del prototipo
con la documentacin correspondiente.
El ciclo de vida esta formado por fases y cada fase esta compuesta por un
nmero de iteraciones. Se define como fase al intervalo de tiempo entre dos
hitos importantes del proceso cuando se cumplen un grupo de objetivos bien
definidos, se terminan los artefactos y se decide si pasar o no a la prxima fase.
Definimos como Artefacto un resultado parcial o final producido y utilizado
durante el proyecto. Los artefactos son las entradas y salidas de las actividades,
son ejemplos de artefactos un documento, un modelo o un elemento de un
modelo.
Las fases definidas en el ciclo de vida del RUP son las siguientes:
1. Inicio
2. Elaboracin
3. Construccin
4. Transicin
Inicio: Se definen los objetivos del proyecto y la funcionalidad y capacidades del
producto.

Elaboracin: Se estudian en profundidad la funcionalidad como el dominio del

problema.
Adems se define una arquitectura bsica y se planifica el proyecto teniendo en
cuenta los recursos disponibles.
Construccin: Se desarrolla el producto a travs de iteraciones donde en cada
iteracin se realizan tareas de anlisis, diseo e implementacin.
En esta etapa se refina y profundiza sobre la arquitectura bsica definida en la
etapa anterior a medida que se va construyendo la misma. Esto permite realizar
los cambios necesarios en la estructura. La mayora del trabajo de dicha etapa
es de programacin y realizacin de pruebas, pero junto con estas tareas se
realiza la documentacin de las mismas.
Transicin: En esta etapa se entrega el producto para que sea usado por el
usuario real. Adems se realizan las tareas de instalacin, configuracin,
entrenamiento, soporte y mantenimiento. Se concluye con los manuales y se
refina la informacin anterior.
Ahora que explicamos el ciclo de vida del desarrollo de software veremos un
grfico que representa la relacin entre las diferentes fases del ciclo de vida con
las distintas disciplinas del proyecto y muestra el esfuerzo respecto de las fases
para cada iteracin.

Como conclusin de todo lo expuesto es importante resaltar que para tener un

buen desarrollo de los sistemas de informacin es necesario contar con tres
pilares fundamentales. Una notacin clara que evite las ambigedades (nosotros
utilizaremos UML como notacin), un proceso bien definido (el proceso utilizado
es el UP proceso unificado o mejor conocido como RUP) y una herramienta
eficiente que potencie y utilice gilmente el proceso de desarrollo seleccionado
codificando con la notacin elegida (dicha herramienta en la actualidad puede
ser el Racional XDE o el Racional Rose que son las ms difundidas , aunque
existen herramientas provistas por otros desarrolladores).

Anlisis y Diseo Orientado a Objetos (A/DOO)

Programar es divertido, pero desarrollar software de calidad es difcil. El anlisis
y el diseo definen cmo solucionar el problema, qu programar y que este
diseo de forma sea fcil de comunicar, revisar, implementar y evolucionar.
El Lenguaje Unificado de Modelado (UML) se ha convertido en el lenguaje
aceptado universalmente para los planos del diseo software.
En la creacin de sistemas complejos es importante la utilizacin de patrones de
diseo que nos permitan describir fragmentos de diseo y reutilizar ideas de
diseo.
Introduccin al A/DOO
UML es una notacin visual estndar. UML no es A/DOO o un mtodo, es
simplemente una notacin.
El A/DOO esta fuertemente relacionado con la actividad que es un requisito
previo del anlisis de requisitos, que incluye escribir casos de uso.
El anlisis de requisitos y el A/DOO requieren que se presenten en el
contexto de algn proceso de desarrollo, para ello utilizaremos el proceso de
desarrollo iterativo conocido como Proceso Unificado.
La construccin de software conlleva innumerables habilidades y pasos ms all

del anlisis de requisitos, el A/DOO y la programacin orientada a objetos. Por
ejemplo, la ingeniera de usabilidad y el diseo de interfaces de usuario son
claves para el xito, de igual modo que el diseo de base de datos.

Qu es anlisis y diseo?
El Anlisis pone nfasis en una investigacin del problema y los requisitos, en
vez de ponerlo en una solucin. (Estudio de los objetos del dominio)
El Diseo pone nfasis en una solucin conceptual que satisface los requisitos,
en vez de ponerlo en la implementacin. (Ej.: Descripcin del esquema de una
base de datos y objetos software). Finalmente, los diseos pueden ser
implementados (diseo de objetos o diseo de base de datos.)
Qu son el anlisis y el diseo orientados a objetos?

Durante el anlisis orientado a objetos, se presta especial atencin a
encontrar y describir los objetos o conceptos- en el dominio del problema. Por
ejemplo, en el caso del sistema de informacin de la biblioteca, algunos de los
conceptos son Libro, Biblioteca y Socio.
Durante el diseo orientado a objetos, se presta especial atencin a la
definicin de los objetos software y en cmo colaboran para satisfacer los
requisitos. Por ejemplo, en el sistema de la biblioteca, un objeto software Libro
podra tener un atributo Ttulo y un mtodo obtenerCapitulo.
Por ltimo, durante la implementacin o programacin orientada a objetos, los
objetos de diseo se implementan como la clase Libro.
Ejemplo
Un juego de dados en el que un jugador lanza dos dados. Si el total es siete,
gana; en otro caso, pierde.
Definicin de los casos de uso

El anlisis de requisitos podra incluir una descripcin de los procesos del
dominio relacionados, que podran representarse como casos de uso.

Definicin de
Definicin del Definicin de
Definicin de diagramas de
modelo del diagramas de
casos de uso clases de
dominio interaccin
diseo
Los casos de uso no son artefactos orientados a objetos -son simplemente

historias escritas-. Sin embargo, son una herramienta importante del Proceso
Unificado. Por ejemplo, aqu est una visin breve del caso de uso Jugar una
Partida de Dados.
Jugar una partida de dados: Un jugador recoge y lanza los dados. Si el valor
de las caras de los dados suman siete, gana; en otro caso, pierde.
Definicin de un modelo del dominio

La finalidad del AOO es crear una descripcin del dominio desde la perspectiva
de la clasificacin de objetos que conlleva una identificacin de los conceptos,
atributos y asociaciones que se consideran significativas. El resultado se puede
expresar en un modelo del dominio, que se ilustra mediante un conjunto de
diagramas que muestran los objetos o conceptos del dominio.
Definicin de
dominio interaccin
diseo
Modelo del dominio parcial del juego de dados

Jugador 1 Lanza 2 Dado

nombre valorCara
1 2
Juega
1
JuegoDados 1 Incluye
Este modelo ilustra los conceptos importantes Jugador, Dado y JuegoDados,

con sus asociaciones y atributos. Un modelo del domino es una visualizacin de
los conceptos en el dominio del mundo real.
Definicin de los diagramas de interaccin

La finalidad del diseo orientado a objetos es definir los objetos software y sus
colaboraciones. El diagrama de interaccin muestra el flujo de mensajes entre
los objetos software y, por tanto, la invocacin de mtodos.
Definicin de
dominio interaccin
diseo
Diagrama de interaccin que muestra los mensajes entre los objetos software

:JuegoDados dado1 : Dado dado2 : Dado
jugar()
lanzar()
vc1 := obtenerValorCara()
lanzar()
vc2 := obtenerValorCara()
Definicin de los diagramas de clases de diseo

Adems de la vista dinmica de las colaboraciones entre los objetos que se
muestra mediante los diagramas de interaccin, es til crear una vista esttica
de las definiciones de las clases mediante un diagrama de clases de diseo.
Definicin de
dominio interaccin
diseo
Por ejemplo, en el juego de dados, un estudio del diagrama de interaccin nos

conduce al diagrama de clases de diseo parcial que se muestra en la siguiente
Figura. Puesto que se enva el mensaje jugar al objeto JuegoDados,
JuegoDados requiere un mtodo jugar, mientras la clase Dado requiere los
mtodos lanzar y obtenerValorCara.

JuegoDados Dado
dado1 : Dado 1 2 valorCara : int

dado2 : Dado
obtenerValorCara() : int
lanzar ()
jugar()
UML
El Lenguaje Unificado de Modelado (UML) es un lenguaje para especificar,
visualizar, construir y documentar los artefactos de los sistemas software, as
como para el modelado del negocio y otros sistemas no software.
UML se ha convertido en la notacin visual estndar para el modelado orientado
a objetos; se aplica principalmente durante el A/DOO, precedido, normalmente,
por el anlisis de requisitos.
Desarrollo Iterativo y el Proceso Unificado
Introduccin
El desarrollo iterativo es un enfoque para el desarrollo de software. El Proceso
Unificado es un ejemplo de proceso iterativo para proyectos que utilizan el
A/DOO.
Un proceso de desarrollo de software describe un enfoque para la
construccin, desarrollo y, posiblemente, mantenimiento de software.
El Proceso Unificado de Rational o RUP es un refinamiento detallado del
Proceso Unificado.

La idea ms importante del UP: desarrollo iterativo

El UP fomenta el desarrollo iterativo. En este enfoque, el desarrollo se
organiza en una serie de mini-proyectos cortos, de duracin fija llamados
iteraciones; el resultado de cada uno es un sistema que puede ser probado,
integrado y ejecutado. Cada iteracin incluye sus propias actividades de anlisis
de requisitos, diseo, implementacin y pruebas.
El ciclo de vida iterativo se basa en la ampliacin y refinamiento sucesivos del
sistema mediante mltiples iteraciones, con retroalimentacin cclica y
adaptacin como elementos principales que dirigen para converger hacia un
sistema adecuado. El sistema crece incrementalmente a lo largo del tiempo,
iteracin tras iteracin, y por ello, este enfoque tambin se conoce como
desarrollo iterativo e incremental.
El resultado de cada iteracin es un sistema ejecutable, pero incompleto. La
salida de una iteracin no es un prototipo experimental sino un subconjunto con
calidad de produccin del sistema final.
En general, cada iteracin aborda nuevos requisitos y ampla el sistema
incrementalmente.
Beneficios del desarrollo iterativo

La retroalimentacin iterativa y la adaptacin nos conducen hacia el sistema
deseado. La inestabilidad de los requisitos y el diseo disminuyen a lo largo del
tiempo.
Longitud de una iteracin y fijacin de la duracin

El UP recomienda que la longitud de una iteracin sea de dos a seis semanas.
Una idea clave es que se fija la duracin de las iteraciones.

Conceptos del UP
La idea fundamental para apreciar y utilizar el UP es el desarrollo iterativo,
fijando iteraciones cortas, y adaptable. Otra idea del UP implcita, es el uso de
las tecnologas de objetos, entre las que se encuentra el A/DOO y la
programacin orientada a objetos.
Algunos conceptos claves son:

Abordar cuestiones de alto riesgo y muy valiosas en las primeras iteraciones.
Involucrar continuamente a los usuarios para evaluacin, retroalimentacin y
requisitos.
Construir en las primeras iteraciones una arquitectura que constituya un
ncleo central consistente.
Verificar la calidad continuamente; pruebas muy pronto, con frecuencia y de
manera realista.
Aplicar casos de uso.
Modelar software visualmente (con UML).
Gestionar los requisitos con cuidado.
Manejar peticiones de cambio y gestin de configuraciones.
Las fases del UP

1. Inicio: fase de viabilidad, donde se lleva a cabo slo el estudio suficiente
para decidir si continuar o no. Visin aproximada, anlisis del negocio,
alcance, estimaciones imprecisas.
2. Elaboracin: fase donde se implementa, de manera iterativa, la
arquitectura que constituye el ncleo central y se mitigan las cuestiones
de alto riesgo. Visin refinada, implementacin iterativa del ncleo central
de la arquitectura, resolucin de los riesgos altos, identificacin de ms
requisitos y alcance, estimaciones ms realistas.

3. Construccin: implementacin iterativa del resto de requisitos de menor

riesgo y elementos ms fciles, preparacin para el despliegue.
4. Transicin: pruebas beta, despliegue.
Las disciplinas del UP

El UP describe actividades de trabajo, como escribir casos de uso, en
disciplinas. Una disciplina es un conjunto de actividades (y artefactos
relacionados) en un rea determinada. En el UP, un artefacto es el trmino
general para cualquier producto del trabajo.
Disciplinas en el UP:
Modelado del Negocio. Esto incluye el modelado de los objetos del dominio.
Requisitos. Anlisis de los requisitos para una aplicacin, como escritura de
casos de uso e identificacin de requisitos no funcionales.
Diseo. Todos los aspectos de diseo, incluyendo la arquitectura global,
objetos, bases de datos, red y cosas parecidas.
Inicio
La fase de inicio consiste en vislumbrar el alcance del producto, visin y anlisis
del negocio.
El propsito de la fase de inicio es establecer una visin comn inicial de los
objetivos del proyecto, determinar si es viable y decidir si merece la pena llevar a
cabo algunas investigaciones serias en la fase de elaboracin.

Qu artefactos podran crearse en la fase de inicio?

Artefacto Comentario
Visin y Anlisis del Negocio Describe los objetivos y las restricciones de alto
nivel, el anlisis del negocio y proporciona un
informe para la toma de decisiones.
Modelo de Casos de Uso Describe los requisitos funcionales y los no
funcionales relacionados.
Especificacin Complementaria Describe otros requisitos.
Glosario Terminologa clave del dominio
Lista de Riesgos & Plan de Gestin Describe los riesgos del negocio, tcnicos, recursos,
del Riesgo planificacin, y las ideas para mitigarlos o darles
respuesta.
Prototipos y pruebas-de-conceptos Para clarificar la visin y validar las ideas tcnicas.
Plan de Iteracin Describe qu hacer en la primera iteracin de la
elaboracin.
Comprensin de los requisitos

Los requisitos son capacidades y condiciones con las cuales debe ser
conforme el sistema. El primer reto del trabajo de los requisitos es encontrar,
comunicar y recordar (registrar) lo que se necesita realmente, de manera que
tenga un significado claro para el cliente y los miembros del equipo de
desarrollo.
La respuesta iterativa es utilizar un proceso que acepte el cambio y la
retroalimentacin como motores centrales en el descubrimiento de los requisitos.
Tipos de requisitos
Funcional (Functional): caractersticas, capacidades y seguridad.
Facilidad de uso (Usability): factores humanos, ayuda, documentacin.
Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperacin de
un fallo y grado de previsin.
Rendimiento (Performance): tiempos de respuesta, productividad, precisin,
disponibilidad, uso de los recursos.

Soporte (Supportability): adaptabilidad, facilidad de mantenimiento,

internacionalizacin, configurabilidad.
Requisitos adicionales:
Implementacin: limitacin de recursos, lenguajes y herramientas, hardware.
Interfaz: restricciones impuestas para la interaccin con sistemas externos.
Operaciones: gestin en su puesta en marcha.
Empaquetamiento
Legales: licencias, etc.
Lo normal es dividir los requisitos en funcionales (comportamiento) y no

funcionales (todos los dems).
El artefacto Visin resume los requisitos de alto nivel. El Glosario agrupa y
clarifica los trminos que se utilizan en los requisitos (diccionario de datos).
Los prototipos son un mecanismo para clarificar qu es lo que se quiere o es
posible.
Modelo de Casos de Uso: Escritura de Requisitos en

Contexto
Introduccin
Los casos de uso son un mecanismo utilizado para descubrir y registrar los
requisitos (especialmente los funcionales).
El UP define el Modelo de Casos de Uso en la disciplina Requisitos.
Bsicamente, es el conjunto de todos los casos de uso; es un modelo de la
funcionalidad y entorno del sistema.
Objetivos
Los clientes y los usuarios finales tienen objetivos (tambin conocidos como
necesidades) y quieren sistemas informticos que les ayuden a conseguirlos.

Hay varias formas de capturar estos objetivos y requisitos del sistema; las
mejores son simples y familiares, porque esto hace que sea ms fcil -
especialmente para clientes y usuarios finales contribuir a su definicin o
evaluacin. Eso reduce el riesgo de perder el hilo.
Los casos de uso son un mecanismo para ayudar a mantenerlo simple y
entendible para todo el personal involucrado. De manera informal, son historias
del uso de un sistema para alcanzar los objetivos.
Casos de uso
En primer lugar, algunas definiciones informales: un actor es algo con
comportamiento, como una persona (identificada por un rol), sistema
informatizado u organizacin; por ejemplo, un cajero.
Un escenario es una secuencia especfica de acciones e interacciones entre los
actores y el sistema objeto de estudio; tambin se denomina instancia de caso
de uso. Es una historia particular del uso de un sistema; por ejemplo, el
escenario de xito de compra de artculos con pago en efectivo, o el escenario
de fallo al comprar debido al rechazo de la transaccin de pago con la tarjeta de
crdito. Informalmente entonces, un caso de uso es una coleccin de
escenarios con xito y fallo relacionados, que describe a los actores utilizando
un sistema para satisfacer un objetivo.
Una actitud clave en el trabajo con casos de uso es centrarse en la pregunta:
Cmo puedo, utilizando el sistema, proporcionar un valor observable al
usuario, o cumplir sus objetivos?
Casos de uso y requisitos funcionales

Los casos de uso son requisitos funcionales que indican qu har el sistema; no
describen el funcionamiento interno del sistema, sino que se describe el sistema
en base a las responsabilidades que tiene.
A travs de la definicin de las responsabilidades del sistema con casos de uso,
es posible especificar qu debe hacer el sistema (los requisitos funcionales) sin

decidir cmo lo har (el diseo). De hecho, la definicin de anlisis frente al

diseo se resume como el qu frente al cmo.
Tipos de formalidad
Los casos de uso se escriben como formatos diferentes, dependiendo de la
necesidad:
Breve: resumen conciso de un prrafo, normalmente del escenario
principal con xito.
Informal: formato de prrafo en un estilo informal. Mltiples prrafos que
comprenden varios escenarios.
Completo: el ms elaborado. Se escriben con detalle todos los pasos y
variaciones, y hay secciones de apoyo como precondiciones y garantas de
xito. (Ver www.usecases.org)

Ejemplo de este estilo de plantilla:

Caso de uso. :
Actor principal:
Personal involucrado e intereses:

Precondiciones:
Garantas de xito (Postcondiciones):
Escenario principal de xito (o Flujo Bsico):
Flujos Alternativos:
Extensiones:
Requisitos especiales:

Lista de tecnologa y variaciones de datos

Frecuencia:
Temas abiertos:

La variacin de dos columnas

Algunos prefieren el formato en dos columnas o conversacional, que destaca el
hecho de que se establece una interaccin entre los actores y el sistema.
Caso de uso..:
Actor principal:
Escenario principal de xito:
Accin del actor (o intencin) Responsabilidad del Sistema
1. .
2. .
3. .
4.
5.
6.
7.
8. ..
9. ..
Explicacin de las secciones

Actor principal: El actor principal que recurre a los servicios del sistema para
cumplir un objetivo.
Personal involucrado y lista de intereses

Esta lista sugiere y delimita qu es lo que debe hacer el sistema. Citando a
Cockburn: El [sistema] funciona siguiendo un contrato entre el personal
involucrado, donde los casos de uso detallan la parte de comportamiento del
contrato() El caso de uso, como contrato de comportamiento, captura todo y
slo el comportamiento relacionado con la satisfaccin de los intereses del
personal involucrado.
Qu debera estar en un caso de uso?
Lo que satisfaga los intereses de todo el personal involucrado.

Personal involucrado e intereses:

Cajero: quiere entradas precisas, rpidas, y sin errores de pago, ya que
las prdidas se deducen de su salario.
Vendedor: quiere que las comisiones de las ventas estn actualizadas.
..
Precondiciones y garantas de xito (postcondiciones)

Las precondiciones establecen lo que siempre debe cumplirse antes de
comenzar un escenario en el caso de comenzar un escenario en el caso de uso.
Las precondiciones no se prueban en el caso de uso, sino que son condiciones
que se asumen que son verdad.
Las garantas de xito (o postcondiciones) establecen qu debe cumplirse
cuando el caso de uso se completa con xito.
Precondiciones: El cajero se identifica y autentica.

Garantas de xito (Postcondiciones): Se registra la venta. El impuesto se
calcula de manera correcta. Se actualizan la Contabilidad y el Inventario. Se
registran las comisiones. Se genera el recibo.
Escenario principal de xito y pasos (o Flujo Bsico)

Describe el camino de xito tpico que satisface los intereses del personal
involucrado.
Escenario principal de xito (o Flujo Bsico):

1. El Cliente llega a una terminal con mercancas para comprar.
2. El Cajero comienza una nueva venta.
3. El Cajero introduce el identificador del artculo.
4.
El Cajero repite los pasos 3-4 hasta que se indique.
5.

Extensiones (o Flujos Alternativos)

Indican todos los otros escenarios o bifurcaciones, tanto de xito como de
fracaso. En una extensin se etiqueta con el n de paso del escenario principal
de xito, primero identifica la condicin y despus la respuesta.
Extensiones (o Flujos Alternativos):

3 a. Identificado no vlido:
1. El Sistema seala el error y rechaza la entrada
Bibliografa
UML y Patrones Una introduccin al anlisis y diseo orientado a objetos y al proceso
unificado , Craig Larman

Introducción a UML, ADOO y el proceso unificado

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introducción a UML, ADOO y el proceso unificado

Transféré par

Droits d'auteur :

Formats disponibles

INDICE

UML Y EL DESARROLLO DE SOFTWARE ORIENTADO A

POR QUE DEBEMOS MODELAR 3

ANLISIS Y DISEO ORIENTADO A OBJETOS (A/DOO) 23

DESARROLLO ITERATIVO Y EL PROCESO UNIFICADO 28

Q U ARTEFACTOS PODRAN CREARSE EN LA FASE DE INICIO? 32

COMPRENSIN DE LOS REQUISITOS 32

MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN

Ezequiel Rozic - Silvia Herzovich 1

UML y el desarrollo de software Orientado a Objetos

La complejidad y magnitud de los mismos (desarrollos de sistemas para Intranet

Es bueno aclarar y no quiero que se forme un concepto errneo que para

1. Usted, como dije antes no formaliz en papel la metodologa de

Ezequiel Rozic - Silvia Herzovich 2

4. En caso de lograr adaptarlo, la performance del mismo ser menor que el

Hechas estas aclaraciones empecemos a ver que caractersticas debe cumplir

Por que debemos modelar

Ezequiel Rozic - Silvia Herzovich 3

Los diseadores de autos antes de fabricar un modelo especifico realizan

Los diseadores de circuitos electrnicos antes de implementar los mismos

Con lo cual de la respuesta anterior surge una segunda pregunta que es la

Y con los ejemplos que dimos la respuesta a esta pregunta tambin es

Nosotros construimos modelos para poder comprender ms claramente el

Ezequiel Rozic - Silvia Herzovich 4

Queda absolutamente claro que al realizar diversos tipos de modelo indirecta y

Y por ltimo al disear modelos estamos definiendo plantillas y esquemas en

Ahora bien, existen un conjunto de pautas o normas que nos ayudaran a

Pautas para un buen modelado

Ahora bien si el problema es encarado por alguien que trabaja en el desarrollo

Pero si la persona que encara el problema en cuestin trabaja utilizando el AOO

Ezequiel Rozic - Silvia Herzovich 5

Otro detalle que es importante es que cualquier modelo puede expresarse a

Modelado Orientado a Objetos

Aclaremos un poco esto ltimo.

Ezequiel Rozic - Silvia Herzovich 6

abstracta (por ejemplo un proceso de facturacin) del problema o del espacio de

Los objetos poseen las siguientes caractersticas fundamentales:

1. Todo objeto posee identidad

Ezequiel Rozic - Silvia Herzovich 7

El estado de un objeto satisface ciertas caractersticas:

Como ya dejamos entrever anteriormente el estado evoluciona con el

Ezequiel Rozic - Silvia Herzovich 8

El comportamiento global del sistema queda representado y se base en la

Un sistema informtico puede verse como un conjunto de objetos autnomos y

Como dijimos anteriormente el comportamiento agrupa las competencias de un

Como dijimos antes un estmulo causar la invocacin de una operacin, la

Con lo cual podemos asumir que un mensaje es la especificacin de un estmulo

Un mensaje desencadenar una accin en el objeto destinatario. Y dicho objeto

La persistencia de los objetos define la capacidad de un objeto de trascender en

Dicha caracterstica garantiza que podemos materializar cualquier objeto tomado

Ezequiel Rozic - Silvia Herzovich 9

Esta caracterstica debera ser transparente para el usuario ya que un objeto

Que es una clase?

Existen para ello diferentes mtodo de abstraccin los cuales pasamos a

Se entiende como clase:

1. A una descripcin de un conjunto de objetos similares.

1. Cada objeto que existe en el sistema pertenece a una clase especifica

Ezequiel Rozic - Silvia Herzovich 10

1. Se protegen los datos de accesos indebidos o indeseados.

El encapsulamiento se aplica sobre los atributos y mtodos o mensajes de una

Existen tres niveles de encapsulamiento los cuales pasamos a describir:

Privado: Es el ms fuerte de todos los atributos y/o mtodos que se definan