Grai Gum Ly Patrones Recor Regi Do

1
ANLISIS Y DISEO ORIENTADOS A OBJETOS
/bjeti'os
0
$omparar y contrastar el anlisis y el diseo. 1efinir el anlisis y el diseo orientados a objetos. 2elacionar por analog"a el anlisis y el diseo orientado a objetos con el fin de organizar una empresa.
0 0
1.1
Aplicacin del lenguaje U L ! del an"li#i# ! el di#e$% %&ien'ad%# a %(je'%#

Desarrolle habilidades en el anlisis y diseo orientados a objetos. Qu significa contar con un sistema orientado a objetos que est bien diseado? En este libro ayudamos a programadores y estudiantes para que adquieran y utilicen habilidades prcticas en el anlisis y el diseo orientados a objetos. Esas destrezas son indispensables para crear sistemas de soft are bien diseados! robustos y de fcil mantenimiento! utilizando la tecnolog"a de objetos y los lenguajes de programaci#n orientados a objetos como $%%! &a'a o (malltal). El pro'erbio *El hbito no hace al monje+ se aplica perfectamente a la tecnolog"a de objetos. El hecho de conocer un lenguaje orientado a objetos ,&a'a! por ejemplo- y adems tener acceso a una rica biblioteca ,como la de &a'a- es un primer paso necesa . rio pero insuficiente para crear sistemas de objetos. (e requiere adems analizar y disear un sistema desde la perspecti'a de los objetos.
En esta edicin se adopt el criterio de no usar acentos en los modelos conceptuales, diagramas y programas.
Nota del editor:
1 ANLISIS Y DISEO ORIENTADOS A OBJETOS
3a prctica del anlisis y el diseo orientados a objetos se e4plica con un caso de estudio relati'amente e4hausti'o que 'amos desarrollando a lo largo del libro5 ambos aspectos se profundizan lo suficiente para que se traten y resuel'an muchos de los detalles ms engorrosos que plantea un problema realista. *673+ son las siglas de Uni)ied %deling Language ,3enguaje 6nificado de $onstrucci#n de 7odelos-! notaci#n ,esquemtica en su mayor parte- con que se construyen sistemas por medio de conceptos orientados a objetos. En este libro ayudaremos a los programadores para que aprendan la notaci#n de 673 y la apliquen a un estudio de casos. $#mo deber"an asignarse las responsabilidades a las clases de objetos? $#mo deber"an interactuar stos? Qu papel debe destinrsele a cada clase? Estas son preguntas muy importantes cuando se disea un sistema. 8lgunas soluciones ya probadas y eficaces de los problemas de diseo pueden e4presarse ,y se han plasmado- como un conjunto de principios! con heur"stica o pa'&%ne# ,f#rmulas de soluci#n de problemas que codifican los principios aceptados del diseo-. En este libro enseamos los patrones y as" fa'orecemos el aprendizaje rpido y la utilizaci#n hbil de los tecnicismos fundamentales de esta tecnolog"a. 1ebido a las numerosas acti'idades que posiblemente e4ijan las condiciones durante la implementaci#n! c#mo deber"a proceder el programador o equipo de programadores? En esta obra presentamos un ejemplo del p&%ce#% de de#a&&%ll% que describe un orden posible de acti'idades y un ciclo de 'ida del desarrollo. 9ero no prescribe un proceso ni un mtodo definiti'os: se limita a ofrecer una muestra de pasos comunes.
Ejemplos de acti'idades 9rincipios y directrices 8nlisis y diseo orientados a objetos
<emas y habilidades
9atrones
;otaci#n de 673
Estudio de casos
Figura 1.1 Temas y habilidades que se incluyen en el libro
En conclusi#n! en este libro se ayuda al programador5 0 0 0 8 aplicar los principios y patrones para aprender a realizar mejores diseos. 8 efectuar 'arias acti'idades comunes en el anlisis y en el diseo. 8 crear elementos >tiles en la notaci#n de 673.
<odo lo anterior lo ejemplificamos dentro del conte4to de un estudio de casos.
1.*
A#ignacin de &e#p%n#a(ilidade#
La asignacin de responsabilidades a los componentes es la habilidad ms importante del diseo.
=ay muchas posibles acti'idades y elementos en el anlisis y en el diseo! as" como gran cantidad de principios y directrices. (up#ngase que tu'iramos que elegir una sola habilidad prctica entre todos los temas aqu" e4puestos5 una habilidad tan solitaria como una *isla desierta+ por as" decirlo. $ul seria?
3a habilidad ms importante en el anlisis y el diseo orientados a objetos es asignar eficientemente las responsabilidades a los componentes del soft are.
9or qu? 9orque es la acti'idad que debe efectuarse ,es ineludible- y que influye ms profundamente en la solidez! en la capacidad de mantenimiento y en la reutilizabilidad de los componentes del soft are. El segundo lugar por orden de importancia aparece la obtenci#n de los objetos o las abstracciones adecuadas. 8mbos aspectos son decisi'os5 ponemos de relie'e la asignaci#n de responsabilidades porque tiende a ser ms dif"cil de dominar. En un objeto real! un programador tal 'ez no tenga la oportunidad de efectuar alguna otra acti'idad relacionada con el anlisis o con el diseo5 el proceso de desarrollo *con prisa por codificar+. 9ero incluso en tales casos es ine'itable la asignaci#n de responsabilidades. 9or ello! en la fase de diseo de este libro ponemos de relie'e los principios de la asig naci#n de responsabilidades y ofrecemos las herramientas que le ayudarn al programador a dominarla.
;ue'e principios fundamentales de la asignaci#n de responsabilidades! codificados en los patrones de ?28(9! se describen y se aplican para ayudarle al lector a dominar este aspecto.
3o anterior no significa que el resto de las acti'idades carezcan de importancia. 9or ejemplo! es indispensable crear un modelo conceptual que identifique los conceptos ,objetos- en el dominio del problema. 9ero! en cuanto habilidad de tipo *isla desierta+! el hecho de saber asignar responsabilidades es lo que en definiti'a hace o destruye a un sistema.
1.+
,-u. #%n el an"li#i# ! el di#e$%/
Anlisis: investigacin.
9ara crear una aplicaci#n de soft are hay que describir el problema y las necesidades o requerimientos5 en qu consiste el conflicto y qu debe hacerse. El 8nlisis se centra en una investigacin del problema! no en la manera de definir una soluci#n. 9or ejemplo! si se desea un nue'o sistema de informaci#n computarizada de una biblioteca! cules procesos de la instituci#n se relacionan con su uso? Diseo: solucin 9ara desarrollar una aplicaci#n! tambin es necesario contar con descripciones detalladas y de alto ni'el de la soluci#n l#gica y saber c#mo satisface los requerimientos y las restricciones. El 1iseo pone de relie'e una solucin lgica: c#mo el sistema cumple con los requerimientos. =e aqu" un ejemplo5 de qu manera el soft are del sistema de informaci#n de la biblioteca capturar y registrar los prstamos de libros? En definiti'a! los diseos se implementan en soft are y en hard are.
1.0
,-u. #%n el an"li#i# ! el di#e$% %&ien'ad%# a %(je'%#/
Anlisis orientado a objetos: conceptos!
3a esencia del anlisis y el diseo orientados a objetos consiste en situar el dominio de un problema y su soluci#n l#gica dentro de la perspecti'a de los objetos ,cosas! conceptos o entidades-! como se ad'ierte en la figura A.B.
Diseo orientado a objetos: objetos de so"t#are!
1urante el anlisis orientado a objetos se procura ante todo identificar y describir los objetos Co conceptosC dentro del dominio del problema 9or ejemplo! en el caso del sistema de informaci#n de la biblioteca! algunos de los conceptos son 3ibro! Diblioteca y $liente.
8nlisis
1iseo
$onstrucci#n
@n'estigaci#n del problema
(oluci#n l#gica
$#digo
1igu&a A.B (ignificado de las acti'idades de desarrollo.
1urante el di#e$% %&ien'ad% a %(je'%#2 se procura definir los objetos l#gicos del soft are que finalmente sern implementados en un lenguaje de programaci#n orientado a objetos. 3os objetos tienen atributos y mtodos. 8s"! en el sistema de la biblioteca un objeto de soft are Libro puede tener un atributo t$tulo y un mtodo imprimir ,figura. A.E-. Finalmente! durante la c%n#'&uccin o p&%g&a3acin %&ien'ada a %(je'%#2 se implementan los componentes del diseo! como una clase Libro en $%%! &a'a! (malltal) o Gisual Dasic.
$oncepto del dominio
2epresentaci#n en el anlisis de conceptos
3ibro titulo
2epresentaci#n en un lenguaje de programaci#n orientado a objetos
9ublic class 3ibro H public 'oid print,-: pri'ate (tring title:
1igu&a 1.+ 3a orientaci#n a objetos se centra en la representaci#n de objetos.
1.4
Una anal%g5a6 %&gani7acin de la e3p&e#a
ic&%89a%#
La organizacin de una empresa y el anlisis y el diseo orientados a objetos guardan semejanzas.
8lgunos de los principales pasos del anlisis y del diseo orientados a objetos pueden e4plicarse por analog"a con la forma en que se organiza una compa"a.
1.5.1
MicroChaos est creciendo rpidamente...

@magine ser el fundador y director general de 7icro$haos! compa"a recin creada y especializada en el soft are que aplica los modelos matemticos de la teor"a del caos al anlisis del mercado accionario ,esto ya se ha hecho en el mundo de las finanzas-. (u producto principal es %icro&utter"ly
En el inicio tan prometedor de la compa"a todo mundo compart"a el trabajo5 contestaban el telfono! surt"an los pedidos! escrib"an los programas de computaci#n. 3a compa"a hab"a alcanzado un 4ito e4traordinario5 hab"a muchos empleados de ingreso reciente y el
personal se haba vuelto dispersivo porque realizaba demasiadas tareas diferentes. Ha llegado,
pues, el momento de implantar una organizacin m s rigurosa. !"mo procedera usted, en su calidad de director general, para organizar a los empleados y las actividades#
1.5.2 Qu son los procesos de negocios?
El primer paso consiste en analizar lo que debe hacer una empresa Csus procesos de negociosC si quiere seguir funcionando5 realizar 'entas! pagar a empleados y acreedores! desarrollar programas de computaci#n. 1esde el punto de 'ista del mtodo del anlisis y del diseo orientados a objetos! este paso nos recuerda el an"li#i# de &e:ue&i3ien'%#! en el cual los procesos y las necesidades de los negocios se descubren y se e4presan en los ca#%# de u#%. 3os casos son descripciones narrati'as te4tuales de los procesos de una empresa o sistema! como se muestra en seguida5 8a#% de u#%6 De#c&ipcin6 $olocar un pedido. Este caso de uso comienza cuando un cliente telefonea a un representante de 'entas para hacer una compra de 7icroDutterfly. El representante anota en una nue'a orden la informaci#n relati'a al cliente y al producto.
@dentificar los procesos y registrarlos en los casos de uso no es en realidad una acti'idad del anlisis orientado a objetos: de ninguna manera se centra en objetos. $on todo! se trata de un paso importante y generalizado en los mtodos del anlisis y diseo orientados a objetos. 8simismo! los casos de uso forman parte del lenguaje 673. 8 continuaci#n mostramos al lector grficamente nuestra analog"a5
Anal%g5a de la e3p&e#a $ules son los procesos de negocios? An"li#i# ! di#e$% %&ien'ad%# a %(je'%# D%cu3en'%# &elaci%nad%#
8nlisis de requerimientos
$asos de uso
1.5.3 Cules son los papeles o las unciones en la organi!aci"n?

El siguiente paso consiste en identificar los papeles de las personas que inter'endrn en los procesos5 cliente! representante de 'entas! ingeniero de soft are! etctera. En la perspecti'a del anlisis y del diseo orientados a objetos! este paso nos recuerda al an"li#i# del d%3ini% %&ien'ad% a %(je'%# que e4presamos
con un 3%del% c%ncep'ual. Este modelo presenta las di'ersas categor"as de las cosas en el dominio: no s#lo los papeles de las personas sino tambin todas las cosas de inters! seg>n se obser'a en la figura A.I.
$liente
9edido
2epresentante de 'entas
1igu&a 1.0 $onceptos en la empresa.
8nalog"a de la empresa
8nlisis y diseo orientados a objetos 8nlisis de requerimientos
1ocumentos relacionados
$ules son los procesos de negocios? $ules son los papeles de los empleados?
$asos de uso
8nlisis del dominio
7odelo conceptual
1.5.# Qu unciones cumple cada empleado? C"mo cola$ora el personal?

6na 'ez identificados los procesos de su empresa y el personal! es el momento de determinar la manera de cumplir los procesos. (e trata de una acti'idad de diseo! o sea orientada a las soluciones. &unto con los empleados! defina las responsabilidades de ellos a fin de efectuar las tareas necesarias para lle'ar a cabo un proceso. <ambin necesita definir de qu manera los empleados colaborarn o compartirn el trabajo. 1esde el punto de 'ista del anlisis y del diseo orientados a objetos! esta acti'idad se parece al di#e$% %&ien'ad% a %(je'%# que pone de relie'e la a#ignacin de &e#p%n#a(ilidade# . 3a asignaci#n significa distribuir las funciones y las responsabilidades entre 'arios objetos de soft are en la aplicaci#n! del mismo modo que se asignan a los papeles de los empleados.
3os objetos de soft are normalmente colaboran o interact>an para cumplir con sus responsabilidades! como lo hacen las personas. 3a descripci#n de la asignaci#n de las responsabilidades y las interacciones de objetos a menudo se e4presan grficamente con diag&a3a# de di#e$% de cla#e y con diag&a3a# de c%la(%&acin: unos y otros muestran la definici#n de clases y el flujo de mensajes entre los objetos de soft are.
8nalog"a de la empresa $ules son los procesos del negocio? $ules son los papeles de los empleados? Qu funciones cumplen los empleados? $#mo interact>an ellos?
8nlisis y diseo orientados a objetos 8nlisis de requerimientos 8nlisis del dominio 8signaci#n de responsabilidades! diseo de interacciones
1ocumentos relacionados $asos de uso 7odelo conceptual 1iagramas de diseo de clases! diagramas de colaboraci#n
1.;
Un eje3pl% del an"li#i# ! del di#e$% %&ien'ad%# a %(je'%#
Un simple ejemplo nos permite ver todo el panorama.
(e necesita abundante informaci#n para e4plicar cabalmente el anlisis y el diseo orientados a objetos. 9ara no perdernos en muchos detalles! ofrecemos al lector ua e4plicaci#n sucinta sobre algunos de los pasos y diagramas usando para ello un ejemplo simple5 un Jjuego de dadosJ en que un jugador lanza dos dados. (i el total es siete! gana y de lo contrario pierde. 3as notaciones utilizadas forman parte del lenguaje U L. /bser'e! por fa'or! que en el ejemplo no estn representados todos los pasos posibles ni los diagramas: tan s#lo aparecen los ms comunes y esenciales.
1.%.1 &e inici"n de los casos de uso

9ara entender los requerimientos se necesita! en parte! conocer los procesos del dominio y el ambiente e4terno! o sea los factores e4ternos que participan en los procesos. 1ichos procesos de dominio pueden e4presarse en casos de uso! o sea! en descripciones narrati'as de los procesos del dominio en un formato estructurado de prosa.
De)ini& l%# ca#%# de u#% De)ini& el 3%del% c%ncep'ual De)ini& l%# diag&a3a# de c%la(%&acin De)ini& l%# diag&a3a# de di#e$% de cla#e#
3os casos de uso no son propiamente un elemento del anlisis orientado a objetos: se limitan a describir procesos y pueden ser igualmente eficaces en un proyecto de tecnolog"a no orientada a objetos. ;o obstante! constituyen un paso preliminar muy >til porque describen las especificaciones de un sistema.
9or ejemplo! en el juego de dados el caso de uso de 'uega un 'uego 8a#% de u#%6 <a&'icipan'e#6 De#c&ipcin6 &uega un &uego. &ugador. Este caso de uso comienza cuando el jugador recoge y hace rodar los dados. (i los puntos suman siete! gana y pierde si suman cualquier otro n>mero.
1.%.2 &e inici"n de un modelo conceptual

El anlisis orientado a objetos tiene por finalidad estipular una especificaci#n del dominio del problema y los requerimientos desde la perspecti'a de la clasificaci#n por objetos y desde el punto de 'ista de entender los trminos empleados en el dominio. 9ara descomponer el dominio del problema hay que identificar los conceptos! los atributos y las asociaciones del dominio que se juzgan importantes. El resultado puede e4presarse en un 3%del% c%ncep'ual! el cual se muestra grficamente en un grupo de diagramas que describen los conceptos ,objetos-.
De)ini& l%# ca#%# de u#%
De)ini& el 3%del% c%ncep'ual
De)ini& l%# diag&a3a# de c%la(%&acin
De)ini& l%# diag&a3a# de di#e$% de cla#e#
9or ejemplo! como se aprecia en la figura A.K! en el dominio del juego de dados! una parte del modelo conceptual muestra los conceptos 'ugador, Dados y 'uegodeDados, sus asociaciones y atributos. &ugador nombre A &uega A A 3anza B 1ados 'alor7ostrado B
&uegode1ados
@ncluye
1igu&a 1.4 7odelo conceptual del juego de dados. El modelo conceptual no es una descripci#n de los componentes del soft are: representa los conceptos en el dominio del problema en el mundo real.
1.%.3 &e inici"n de los diagramas de cola$oraci"n

El diseo orientado a objetos tiene por objeto definir las especificaciones l#gicas del soft are que cumplan con los requisitos funcionales! basndose en la descomposici#n por clases de objetos. 6n paso esencial de esta fase es la asignaci#n de responsabilidades entre los objetos y mostrar c#mo interact>an a tra's de mensajes! e4presados en diag&a3a# de c%la(%&acin. Estos presentan el flujo de mensajes entre las instancias y la in'ocaci#n de mtodos.
9or ejemplo! supongamos que se desea una simulaci#n en el soft are del juego de dados. El diagrama de colaboraci#n de la figura A.L muestra grficamente el paso esencial del juego! en'iando mensajes a las instancias de las clases 'ugador y Dado.
&ugar,-
5&ugador
A5rA 5M lanzar,-
d1 % &ado d$ % &ado
B5rB 5M lanzar,-
1igu&a 1.; 1iagrama de colaboraci#n que muestra los mensajes entre los objetos de soft are.
1.%.# &e inici"n del dise'o de clases

9ara definir una clase es preciso contestar 'arias preguntas5 0$#mo se conectan unos objetos a otros? 0 $ules son los mtodos de una clase? (i el lector quiere contestar las preguntas anteriores! e4amine detenidamente los dia. gramas de colaboraci#n que indican las cone4iones necesarias entre objetos! y tambin los mtodos que cada clase de soft are debe definir. El diag&a3a de di#e$% de cla#e# es el que e4presa esos detalles. 7uestra las definiciones de clase que han de implementarse en el soft are.
9or ejemplo! en el juego de dados! al e4aminar el diagrama de colaboraci#n! obtenemos el siguiente diagrama del diseo de clases. 9uesto que un mensaje juego se en'"a a una instancia 'ugador, 'ugador requiere un mtodo jugar, mientras que Dado requiere un mtodo lan(ar. 8 diferencia del modelo conceptual! este diagrama no muestra grficamente conceptos del mundo real: describe >nicamente los componentes del soft are. 9ara indicar de qu manera los objetos se conectan entre s" a tra's de atributos! una l"nea con una flecha en la punta indicar un atributo. 9or ejemplo! 'uegodeDados posee un atributo que apunta a una instancia de un 'ugador.
&ugador nombre jugar,A &uega A
3anza A
1ado B 'alor7ostrado lanzar,B
&uegode1ados inicializar,-
@ncluye
1igu&a 1.= 1iagrama del diseo de clases para los componentes de soft are. El diagrama del diseo de clases de la figura A.N no est completo: representa >nicamente el inicio de las especificaciones del soft are que se requieren para definir cabalmente cada clase.
1.%.5 (esumen del e)emplo del )uego de dados

El juego de dados es un problema muy simple! que incluimos para centrarnos en algunos de los pasos y artefactos del anlisis y diseo orientados a objetos y no en el dominio del problema. En cap"tulos subsecuentes trataremos ms a fondo esos tres aspectos! sir'indose para ello de un problema ms complejo y realista.
1.=
8%3pa&acin en'&e el an"li#i# ! el di#e$% %&ien'ad%# a %(je'%# ! l%# di#e$%# %&ien'ad%# a )unci%ne#
3os proyectos de soft are son complejos! y la estrategia primaria para superar la complejidad es la descomposici#n ,di'ide y 'encers-5 di'idir el problema en unidades manejables. 8ntes del ad'enimiento del anlisis y diseo orientados a objetos! el mtodo usual de descomponer un problema eran el an"li#i# ! el di#e$% estructurados cuya dimensi#n de descomposici#n es fundamentalmente por funci#n o proceso! lo cual origina una di'isi#n jerrquica de procesos constituidos por subprocesos. (in embargo! e4isten tambin otras dimensiones de descomposici#n: el anlisis y el diseo orientados a objetos buscan ante todo descomponer un espacio de problema por objetos y no por funciones! como se ad'ierte en la figura A.O.
(istema de informaci#n de la biblioteca
8Q1 orientados a objetos 1escomposici#n por objetos o conceptos $atlogo Dibliotecario
8Q1 estructurados 1escomposici#n por funciones o procesos (istema
3ibro
Diblioteca
2egistrar prstamos
8gregar recursos
2eportar multas
1igu&a 1.> $omparaci#n entre la descomposici#n orientada a objetos y la descomposici#n orientada a funciones.
1.>
Ad?e&'encia6 el @an"li#i#A ! el @di#e$%A pueden p&%?%ca& gue&&a# 'e&3in%lgica#

3a di'isi#n entre anlisis y diseo es poco clara: el trabajo de los dos e4iste en un continuo ,figura A.P-! y los profesionales de los mtodos del *anlisis+ y *diseo+ clasifican una acti'idad en 'arios puntos del continuo. 1e ah" que no con'enga adoptar una actitud r"gida ante lo que constituye un paso del anlisis o del diseo.
7s orientado al anlisis
7s orientado al diseo
. qu . requerimientos . in'estigaci#n del dominio . c#mo . soluci#n l#gica
1igu&a 1.B 3as acti'idades de anlisis y diseo e4isten en un continuo. 1ebatir sobre la definici#n no resulta constructi'o en absoluto! ya que las personas les dan distintos significados a esos dos trminos y no se emplean con el mismo sentido en los mtodos5 lo importante es saber resol'er el problema de crear soft are y darle mantenimiento con mayor eficiencia! con mayor rapidez y a un precio menor. $on todo! en la prctica con'iene contar con una distinci#n constante entre investigacin ,anlisis- y solucin ,diseo-! porque es >til tener un paso bien definido que indague la naturaleza del problema antes de buscar la manera de crear una soluci#n. 8dems genera e4pectati'as de un comportamiento apropiado entre los miembros del equipo: por ejemplo! durante el anlisis esperan subrayar la comprensin del problema! posponen las cuestiones concernientes a la soluci#n! al desempeo y a otros aspectos.
1.B
El Uni)ied
%deling Language2 U L
El 673 ,3enguaje 6nificado para la $onstrucci#n de 7odelos- se define como un *lenguaje que permite especificar! 'isualizar y construir los artefactos de los sistemas de soft are...+ RD&2PNS. Es un sistema notacional ,que! entre otras cosas! incluye el significado de sus notaciones- destinado a los sistemas de modelado que utilizan conceptos orientados a objetos. El 673 es un estndar incipiente de la industria para construir modelos orientados a objetos. ;aci# en APPI por iniciati'a de ?rady Dooch y &im 2umbaugh para combinar sus dos famosos mtodos5 el de Dooch y el /7< )*bject %odeling +echni,ue, <cnica de 7odelado de /bjetos-. 7s tarde se les uni# @'ar &acobson! creador del mtodo //(E )*bject-*riented .o"t#are Engineering, @ngenier"a de (oft are /rientada a /bjetos-. En respuesta a una petici#n de /7? )*bject %anagement /roup, asociaci#n para fijar los estndares de la industria- para definir un lenguaje y una notaci#n estndar del lenguaje de construcci#n de modelos! en APPN propusieron el 673 como candidato. 'rescindiendo de la aceptacin que pueda tener, este lengua(e recibi la aprobacin de facto en la industria, pues sus creadores representan m)todos muy difundidos de la primera generacin del an lisis y dise*o orientados a ob(etos. +uchas organizaciones dedicadas al desarrollo de soft,are y los proveedores de herramientas de "-./ 0"omputer -ided .oft,are /ngineering1 lo adoptaron, y muy probablemente se con 'ertir
en el estndar mundial que utilizarn los desarrolladores! los autores y los pro'eedores de herramientas de $8(E. Este libro no incluye todos los detalles de 673! un conjunto relati'amente amplio de notaciones. (e centra en los diagramas de uso frecuente y en las caracter"sticas que ms se utilizan dentro de ellos.
=ay por los menos AT notaciones diferentes de los elementos del anlisis y diseo orientados a objetos: ello dificulta una comunicaci#n
(i el lector desea un estudio e4hausti'o de la notaci#n 673 en sus 'ersiones iniciales! puede consultar la especificaci#n completa en el sitio de Ueb de 2ational $orporation5 .rational.com
eficaz y uniforme! la capacidad de aprender y las herramientas de $8(E. 3os autores del lenguaje 673 CDooch! &acobson y 2umbaugh C hicieron un e4celente ser'icio a la comunidad de la tecnolog"a de objetos al crear un lenguaje estandarizado de modelado que es elegante! e4presi'o y fle4ible.
En consecuencia! los metod#logos seguirn definiendo tcnicas!

El 673 es un lenguaje para construir modelos: no gu"a al desarrollador en la forma de reali(ar el anlisis y diseo orientados a objetos ni le indica cul proceso de desarrollo adoptar.
modelos y procesos de desarrollo para la creaci#n eficaz de sistemas de soft are: s#lo que ahora pueden hacerlo en un lenguaje com>n5 el 673.
23T45&6""273 - 63 '45"/.5 &/ &/.-445885

5<=/T2>5.
/9plicar el motivo del orden de los captulos posteriores, que siguen los pasos del proceso que se describen en este capitulo. .eguir un proceso simple de desarrollo desde los requerimientos hasta la implementacin.
INT !"U##I$N%
6n proceso de desarro o de so!"#are es un m)todo de organizar las actividades re1acionadas con la creacin, presentacin y mantenimiento de los sistemas de soft,are. /n este captulo se da una muy breve introduccin a las actividades fundamentales de un proceso, ofreciendo una gua de los pasos principales. Hemos incluido aqu esta e9p1icacin por dos motivos% /n los captulos subsecuentes se abordan el an lisis y el dise*o orientados a ob(etos a partir de esas actividades. -l seguir un proceso similar a1 que presentamos aqu, se sientan las bases para crear un proyecto de desarrollo mane(able, reproducible y e9itoso. /n el captu1o :; encontrar el lector mas temas concernientes a1 proceso.
$.1.1 'roceso y modelos que se recomiendan
/l lengua(e 6+8 no define un proceso est ndar. .us creadores admiten la importancia de contar con un lengua(e y un proceso muy s1idos para la construccin de modelos. 5frecen su recomendacin de lo que constituye un proceso adecuado en publicaciones aparte de las dedicadas al 6+8, porque la estandarizacin del proceso rebasaba entonces el mbito de la definicin del lengua(e. Tampoco se prescribe en este libro un est ndar o proceso nuevo. + s importante que seguir un proceso o m)todo oficiales es que el desarrollador adquiera habilidades que le permitan crear un buen dise*o, y que las organizaciones favorezcan este tipo de desarrollo de destrezas. /sto se logra dominando varios principios y heursticos que permiten identificar y abstraer los ob(etos idneos, asign ndoles despu)s responsabilidades.
/n este libro se ofrece una visin bastante representativa de los me(ores m)todos, de las actividades y modelos b sicos en un proceso de desarrollo para sistemas orientados a ob(etos que se funden en un enfoque iterativo e incremental de los casos de uso. 8os pasos y modelos recomendados constituyen, m s que una frmula, un recorrido por el panorama de desarrollo de soft,are por medio de la tecnologa de ob(etos. /stas actividades se incluyen como punto de partida para e9poner, e9perimentar y crear un proceso adecuado a las necesidades concretas de la empresa del lector.
?usin
55./ +odelos y proceso recomendados 0+'41 <ooch
+artn@ 5dell
&ise*o orientado a responsabilidades
5+T
/l 6+8
?igura $.1 ?actores que influyen en el proceso y los modelos recomendados en el libro. 3o se trata de un m)todo nuevo, sino la descripcin de un proceso y de modelos
generalmente recomendados 0+'41 que utilizan los profesionales y que, con diversos nombres y ligeras modificaciones, se incluyen en otros m)todos del an lisis y dise*o orientado a ob(etos A4umbaughB;C. 'ara simplificar la e9plicacin, en ocasiones uti@ lizaremos las siglas &' 0modelos y proceso recomendados1 y tambi)n para recalcar la naturaleza cclica del desarrollo iterativo. 8os factores que m s han influido en los +'4 aqu descritos 0figura $.11 son la e9periencia personal del autor en el desarrollo, el traba(o dedicado a 5b(ect.pace, el propio 6+8, ?usion A"olemanBDC, +artin@5dell A+5BEC, 4esponsability@&riven &esign AFirfs@ <rocGBHC, 55./ 05b(ectory1 A=acobsonB$C, 5+T A4umbaughB1C y <ooch A<oochBDC.
$.1.$ Alcance
8a descripcin de un proceso incluye fundamentalmente las actividades que abarcan desde los requerimientos hasta la presentacin o entrega. -dem s un proceso completo aborda puntos m s amplios relacionados con la industria1izacin del desarrollo de soft,are% ciclo de vida de un producto a largo p1azo, documentacin, soporte y capacitacin, traba(o en para1elo y coordinaciones entre los participantes.1 /n esta introduccin se ponen de relieve slo las actividades b sicas, sin entrar en muchos detalles. /n nuestro e9amen, se prescindir de algunos pasos y aspectos esencia1es del proceso% concepcin, p1aneacin, interaccin de equipos en paralelo, administracin del proyecto, documentacin y realizacin de pruebas. 5mitiremos los pasos anteriores porque son a(enos a1 propsito fundamental del libro @@aprender y aplicar habilidades en el an lisis y dise*o orientados a ob(etos@ o porque los temas son demasiado e9tensos como para investigarlos de manera satisfactoria.
$.$ /l lengua(e 6+8 y los procesos de desarrollo

/l lengua(e 6+8 estandariza los artefactos y la notacin, pero no define un proceso oficial de desarrollo. He aqu algunas de las razones que e9plican esto% 1. -umentar las probabilidades de una aceptacin generalizada de la notacin est ndar del modelado, sin la obligacin de adoptar un proceso oficial.
$. 8a esencia
de un proceso apropiado admite mucha variacin y depende de las habilidades del personal, de la razn investigacin@desarrollo, de la naturaleza del problema, de las herramientas y de muchos otros factores. 6na vez aclaradas estas razones, procedemos a aplicar los principios generales y los pasos
=acobson distingue entre m(todo) que abarca los pasos individuales y secuenciales del desarrollo, y proceso) que ampla el m)todo para aplicarlo a cuestiones mas amplias de industrializacin y de desarrollo en equipo A=acobsonB$C. -unque esta es una distincin importante, no subrayar) la distincin para no complicar aIn m s un rea ya saturada de tecnicismos.
1
normales que guan un proceso eficaz.
$.%
&asos de 'acro(i)e
/n un nivel a1to, los pasos principales en la presentacin de una aplicacin son los siguientes 0figura $.$1 % 1. & a(eaci*( + e a,oraci*(% planear, definir los requerimientos, construir prototipos, etc. $. -o(s"rucci*(% la creacin del sistema. :. Ap icaci*(% la transicin de la implementacin del sistema a su uso.
'laneacin y elaboracin
"onstruccin
-plicacin
Figura $.$ &asos de 'acro(i)e e( e desarro o
$..
Desarro o i"era"i)o
6n ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento secuencia1 de un sistema a trav)s de m*ltiples ciclos de desarrollo de an lisis, dise*o, implementacin y pruebas. /l sistema crece a1 incorporar nuevas funciones en cada ciclo de desarrollo. Tras una fase pre1iminar de planeacin y especificacin, el desarrollo pasa a la fase de construccin a trav)s de una serie de ciclos de desarrollo. /n cada ciclo se aborda un con(unto relativamente peque*o de requerimientos, pasando por el an lisis. el dise*o, la construccin y las pruebas 0figura $.:1 . /l sistema va creciendo con cada ciclo que concluye. /sto contrasta con el ciclo cl sico de la vida en cascada, en el cua1 las actividades 0an 1isis y dise*o, entre otras1 se llevan a cabo una vez con todos los requerimientos del sistema. /ntre las venta(as del desarrollo iterativo figuran las siguientes% 8a comple(idad nunca resulta abrumadora. .e produce retroa1imentacin en una etapa temprana. 'orque la implementacin se efectIa r pidamente con una parte peque*a del sistema.
"onstruccin
-plicacin
"iclo de desarrollo 1
...
'erfeccionar el plan
.incronizacin de artefactos
-n lisis
&ise*o
"onstruccin
'rueba
FI/0RA $.% -ic os i"era"i)os de desarro o $...1 Fi1aci*( de a duraci*( de u( cic o de desarro o 2Ti'e3,o4i(g5
6na estrategia muy Itil en los ciclos de desarrollo consiste en limitarlo a un marco temporal, esto es, un lapso rgidamente fi(o. &igamos cuatro semanas. Todo el traba(o ha de concluirse en ese lapso. 6n periodo entre dos semanas y dos meses suele ser conveniente. /n un periodo menor seria muy difcil terminar las actividadesJ en un perodo mayor la comple(idad se torna abrumadora y la retroalimentacin se retrasa 0figura $.D1.
'erfeccio namiento del plan
.incroniz acin
-n lisis
&ise*o
"onstruccin
'rueba
&e $ semanas a $ meses ?igura $.D ?i(acin de la duracin de un ciclo de desarrollo.
'ara tener )9ito con un programa de duracin fi(a es necesario escoger los requerimientos con mucho cuidado y asignarle la seleccin al equipo del desarrollo% son ellos los responsables de cumplir con el plazo establecido.
#asos de uso y los ciclos iterativos del desarrollo

6n caso de uso es una descripcin narrativa de un proceso de dominioJ por e(emplo, !btener libros prestados en una biblioteca. 8os ciclos iterativos de desarrollo se organizan a partir de los requerimientos del caso de uso.
&icho de otra manera, se asigna un ciclo de desarrollo para implementar uno o m s casos de uso o bien sus versiones simplificadas 0por cierto muy comunes cuando el caso completo sera demasiado comple(o de abordar en un ciclo1 0figura $.E1.
"iclos de desarrollo 1
"iclo de desarrollo $
"iclo de desarrollo :
...............
"aso de uso -% versin simplificada ....... ...... .......
"aso de uso -% versin integra ....... ...... .......
"aso de uso <% ......... ......... .........
"aso de uso "% ......... ......... .........
FI/0RA $.6 -ic os de desarro o orie("ados a casos

-dem s de los requerimientos de uso re1ativamente evidentes que es preciso tener presentes, algunos ciclos @@ especia1mente los primeros @@ han de centrarse en requerimientos poco evidentesJ por e(emplo, 1a creacin de servicios de soporte 0persistencia, seguridad y otros1.
$.D.:
"lasificacin de los casos de uso
&eberan clasificarse 1os casos de uso, y 1os que ocupen 1os niveles m s altos habran de abordarse en los ciclos iniciales de desarrollo. 8a estrategia general consiste en se1eccionar 1os casos que influyen profundamente en la arquitectura b sica, dando soporte al dominio y a las capas de servicios de alto nivel o los que presentan el m 9imo riesgo.
$.6 La !ase de a p a(eaci*( + de a e a,oraci*(

/sta fase del proyecto incluye la concepcin inicial, la investigacin de alternativas, la planeacin, la especificacin de requerimientos y otras actividades. NOTA: 'laneacin y elaboracin "onstruccin -plicacin
A constante B opcional C aplazable D orden variable
1. &efinir el plan preliminar
$. /laborar el informe preliminar de investigacin E. 2mplementar el prototipo B, D L. &efinir la arquitectura preliminar del sistema A, B, C
:. &efinir requerimientos
D. 4egistrar los t)rminos en el glosario A ;. &efinir el modelo conceptual preliminar C
. &efinir los casos de uso 0de alto nivel esenciales1 B. 'erfeccionar el plan
FI/0RA $.* E1e'p o de ac"i)idades de a !ase de p a(eaci*( + e a,oraci*( /n la figura $.K observamos algunas actividades de esta fase. /ntre los artefactos generados aqu podemos citar los siguientes% 'lan % programa, recursos, presupuesto, etc. Informe preliminar de investigacin % motivos, alternativas, necesidades de la empresa +specificacin de re,uerimientos% declaracin de los requerimientos. -losario% diccionario 0nombre de conceptos, por e(emplo1 y toda la
informacin afn, como las restricciones y las reglas. 'rototipo% sistema de prototipos cuyo fin es facilitar la comprensin del problema, los problemas de alto riesgo y los requerimientos. #asos de uso% descripciones narrativas de los procesos de dominio. "iagramas de casos de uso% descripcin gr fica de todos los casos y de sus relaciones. .os,uejo del modelo conceptual% modelo conceptual preliminar cuya finalidad es facilitar el conocimiento del vocabulario del dominio, especialmente en su relacin con los casos de uso y con las especificaciones de los requerimientos.
2.5.1 Orden de creacin de los artefactos o ele entos del desarrollo

-unque la gua que se muestra en la figura $. puede sugerir un orden lineal en la creacin de los artefactos, no es estrictamente as. 'odemos preparar en paralelo algunos de ellos, por e(emplo. /sto se aplica especialmente al modelo conceptual, al glosario, a los casos de uso y a los diagramas de los casos. 8os casos de uso que son sometidos a e9amen y, en cambio, el resto de los artefactos tienen por ob(eto presentar la informacin proveniente de los casos. /n captulos subsecuentes, los describiremos en orden lineal para ofrecer una e9posicin sencilla. 'ero en la practica se observa mucha mayor interaccin. FI/0RA $.7 E1e'p o de as ac"i)idades e( a !ase de a(8 isis
.............
NOTAS9 A9 si "oda):a (o se rea i;a B9 co(s"a("e -9 opcio(a "onstruccin 'rueba
'erfeccio namiento del plan
.incroniz acin de artefactos
-n lisis
&ise*o
1. &efinir los casos esenciales -
$. 'erfeccionar los diagramas de casos de uso K. &efinir los contratos de operaciones
:. 'erfeccionar el modelo conceptual
D 'erfeccionar el glosario
E. &efinir los diagramas de secuencia de los sistemas
;. &efinir los diagramas de estado
Figura $.7 /(emplo de las actividades en la fase de an lisis.
$.K 8a fase de construccin% ciclos del desarrollo

8a fase de construccin de un proyecto requiere varios ciclos de desarrollo Mprobablemente con plazos fi(os1 a lo largo de los cuales se e9tiende el sistema. /l ob(etivo final es obtener un sistema funcional de soft,are que atienda debidamente los requerimientos. /n un ciclo individual de desarrollo, los principales pasos se analizan y dise*an, como se se*ala en 1as figuras $.; y $.L. 8os detalles de los pasos se comentan de manera pormenorizada en los siguientes captulos y en el capitulo :;, donde e9aminaremos otros aspectos del proceso. NOTAS9 A. e( para e o co( os diagra'as de i("eracci*( B. orde( )aria, e
.............
'erfeccionam iento del plan
.incronizac in de las actividades
-n lisis
&ise*o
"onstruccin
'rueba
1. &efinir los casos reales de uso
$. &efinir los reportes, la interfaz del usuario y la secuencia de las pantallas E. &efinir los diagramas de dise*o de base A
:. 'erfeccionar la arquitectura del sistema B K. &efinir el esquema de la base de datos
D. &efinir los diagramas de interaccin
FI/0RA $.< E1e'p o de as ac"i)idades de a !ase de dise=o
2.!.1 Orden de creacin de los artefactos en el ciclo de desarrollo

"omo en el caso de los artefactos en la fase de requerimientos, el orden lineal deducible de la figura $.; no es el que se sigue rigurosamente. -lgunos artefactos pueden elaborarse en paraleloJ por e(emplo% "rear en paralelo un modelo conceptual y un glosario.
"rear en paralelo los diagramas de interaccin y los de dise*o de clases.
$.7
Decidir cua(do crear ar"e!ac"os
/n la fase inicial de planeacin y elaboracin pueden crearse ciertos artefactos, entre ellos un modelo conceptual preliminar 0un modelo de conceptos del mundo real1 y casos e9pandidos de uso 0descripciones narrativas detalladas de procesos1. /n la presente seccin se e9amina el momento de su creacin.
2.".1
C#ando crear el
odelo concept#al
/l 'ode o co(cep"ua es una representacin de conceptos u ob(etos en el dominio del problema, como Libros y .iblioteca. &ebe controlarse el esfuerzo que se aplique a la produccin del modelo conceptual preliminar durante la fase de planeacin y elaboracin. 8a meta es lograr un conocimiento b sico del vocabulario y de los conceptos que se incluyen en los requerimientos. 'or ello, no hace falta una investigacin e9haustiva, pues se correra el riesgo de saturar demasiado la investigacin desde el principio% e9ceso de comple(idad. /n los dominios de problemas amplios @@por e(emplo, un sistema de reservaciones para las lneas a)reas@@, un modelo conceptual muy completo resultara e9cesivamente complicado. 8a estrategia intermedia que recomendamos es generar r pidamente un modelo conceptual que se centre en identificar los conceptos obvios e9presados en los requerimientos y posponer para mas tarde una investigacin con detenimiento. + s adelante, en cada ciclo de desarrollo, iremos refinando el modelo conceptual y ampliando 1os requerimientos referentes al ciclo. 5tra estrategia consiste en suspender definitivamente la creacin del modelo basta el inicio de los ciclos de desarrolloJ comenzar desde cero en el ciclo de desarrollo y luego ir ampli ndolo en carla ciclo. .e obtiene as la venta(a de aplazar la comple(idad, pero tambi)n hay una desventa(a% se dispone menos informacin inicial, que pudiera haber sido de gran utilidad para comprender los aspectos generales, para entender el glosario, al realizar un e9amen meticuloso y al efectuar estimaciones. /n el estudio de casos importantes se adopta este enfoque de posposicin en la creacin del modelo conceptual, no porque sea nuestro favorito sino parque favorece la e9plicacin gradual de cmo producirlos.
/.0./
#uando crear los casos e1pandidos de uso
8os casos de uso de a "o (i)e son muy breves, generalmente descripciones de un proceso en dos o tres oraciones. 8os casos e4pa(didos de uso son descripciones e9tensas que pueden contener cientos de oraciones con las cuales se realiza la descripcin. &urante la fase de planeacin y elaboracin, le aconse(amos crear todos los casos de uso de alto nivel, pero escribir slo 1os m s importantes en un formato e9pandido 0largo1, posponiendo el resto hasta el ciclo de desarrollo en que se estudian.
2gual que con el modelo conceptual, la adquisicin temprana de informacin no esta e9enta de desventa(as, pues puede originar una enorme comple(idad. 2nvestigar y escribir detalladamente en la fase de planeacin y elaboracin los casos de uso e9pandidos ofrece la venta(a de suministrar m s informacinJ esta puede facilitar la compresin, la administracin del riesgo, el e9amen meticuloso y las estimaciones. 'ero tambi)n ofrece la desventa(a de una e9cesiva comple(idad inicial% la investigacin producir miles de detalles nimios. + s aIn, los casos e9pandidos tal vez no sean muy confiables porque la informacin es incompleta o errnea y porque los requerimientos pueden cambiar constantemente. 'or tanto, la estrategia intermedia que recomendamos es investigar detenidamente, durante la fase de planeacin y elaboracin, solo 1os casos de uso m s importantes.
E
1EF@;@$@V; 1E 7/1E3/(
W 82<EF8$</(
Objetivos
Definir los modelos de anlisis y de diseo. Explicar con ejemplos las dependencias entre los artefactos de anlisis y diseo.
E.A
@ntroducci#n
/n este captulo se e9ponen e(emplos de modelos en el an lisis y dise*o orientados a ob(etos, as como de la relacin de subordinacin entre los artefactos en los modelos. /l propsito es ofrecer al lector un panorama generalJ en captulos posteriores profundizaremos en los detalles de los modelos y artefactos.
E.B
(istemas de construcci#n de modelos

6n sistema 0tanto en el mundo real como en el mundo del soft,are1 suele ser e9tremadamente intrincadoJ por ello es necesario dividir el sistema e n partes o fragmentos si queremos entender y administrar su comple(idad. /stas partes podemos representarlas como 'ode os que describan y abstraigan sus aspectos esenciales A4umbaughB;C. 'or tanto, un paso Itil en la construccin de un sistema de soft,are es el de crear modelos que organicen y comuniquen los detalles importantes del problema de la vida
real con que se relacionan y del sistema a construir. 8os modelos deben contener elementos cohesivos y estrechamente intercone9os.
6+8 son las siglas de 6nified &odeling 8anguage 08engua(e 6nificado de "onstruccin de +odelos1, porque su finalidad es describir modelos de sistemas 0del mundo real y del mundo del soft,are1, basados en los conceptos de ob(etos. 8os modelos se componen de otros modelos o ar"e!ac"os> de diagramas y documentos que describen cosas. /l 6+8 especifica varios diagramas, entre ellos los diagramas de casos de uso y los diagramas de interaccin, que son los artefactos concretos a partir de los cuales creamos los modelos. /stos se visualizan por medio de las vistas @proyecciones visuales del modelo@J los diagramas de 6+8, entre ellos los de interaccin, abarcan las vistas de un modelo. .i queremos caracterizar los modelos, podemos poner de manifiesto la informacin es"8"ica o di(8'ica de un sistema. 6n 'ode o es"8"ico describe las propiedades estructurales del sistemaJ en cambio, un 'ode o di(8'ico describe las propiedades de comportamiento de un sistema.
3.3
Modelos muestra
/l 6+8 es un lengua(e fle9ible de modelado que permite definir modelos arbitrarios. /n esta seccin presentaremos e(emplos de modelos de an lisis y de dise*o que e9plican la pertenencia de artefactos concretos a los modelos.
Se trata de modelos muestra; no se pretende en absoluto que sean definitivos.

+odelo de sistemas
+odelo de an lisis
+odelo de dise*o
Figura %.1 /l modelo de sistemas
3.3.1 El modelo del sistema

/n este e(emplo el modelo global del sistema 0figura :.11 est constituido por el%
Modelo de anlisis: el que se relaciona con una investigacin del dominio y del mbito del problema, pero no con la solucin. Modelo de diseo: el que se relaciona con la solucin
lgica. En cap tulos subsecuentes se estudian estos modelos !figura 3."# con mayor detalle.
3. $
%elacin entre los artefactos

Sin importar cmo los artefactos se organicen para construir modelos, se dan dependencias muy importantes entre ellos. &or ejemplo, un diagrama de casos de uso que muestre todos los casos depende de las definiciones de los casos. 'onviene entender la dependencia y la influencia entre los artefactos para poder efectuar comprobaciones de consistencia y de rastreabilidad y para poder utili(ar efica(mente los artefactos dependientes como punto de partida para crear otros." &or ejemplo, en la figura 3.) se observan grficamente las dependencias entre artefactos generados durante la fase de planeacin y elaboracin. En los siguientes cap tulos trataremos ms a fondo del significado de los artefactos y sus dependencias.
2nforme preliminar de investigacin 'rototipos "asos de uso% a. todos de alto nivel b. algunos esenciales e9pandidos /specificaciones de requerimientos
'resupuesto, programa
&iagramas de casos de uso
&ependencia respecto a
+odelo conceptual preliminar
Nlosario
Figura %.$ 2nfluencia de los artefactos en la fase de planeacin y elaboracin.

Si se crea un artefacto que no tenga otros dependientes y si no se usa como entrada de otra cosa, *abr que poner en tela de juicio su valor y el tiempo que se dedic a su creacin.
"
982<E @@ F8(E
1E 938;E8$@V; W E38D/28$@V;
$8(/ 1E E(<61@/5 E3 96;</ 1E GE;<8

/bjeti'os
1efinir el caso de estudio que se emplea en el libro.
I.A
El sistema del punto de 'enta
3uestro principal caso de estudio es el sistema de una terminal 0'5.T1 de punto de venta. t /sta terminal es un sistema computarizado con el que se registran las ventas y se realizan los pagosJ normalmente se utiliza en las tiendas al detalle. -barca componentes de hard,are 0una computadora y un lector de cdigo de barras1 y soft,are para correr el sistema .uponga que se nos ha pedido crear un programa para una terminal de punto de venta. "on una estrategia de desarrollo de incremento iterativo, vamos a realizar las fases de requerimientos, an lisis y dise*o orientados a ob(etos e implementacin.
1 6n problema tambi)n e9aminado en A"oadBEC, aunque este traba(o se llev acabo de manera independiente y mucho antes
que el otro.
D @ "-.5 &/ /.T6&25% /8 '63T5 &/ >/3T-
!'or qu) escogimos este problema# 'or ser representativo de muchos sistemas de informacin y porque toca problemas comunes que puede encontrar un desarrollador. -hondaremos lo suficiente en el an lisis y en el dise*o, para que el lector vea en forma detallada cmo se abordan estos problemas y pueda aplicar el m)todo a otros proyectos.
I.B
$apas arquitect#nicas y el nfasis en el caso de estudio

6n sistema tpico de informacin que incluya una interfaz gr fica del usuario y acceso a la base de datos suele presentar un dise*o arquitectnico de varios niveles o capas 0figura D.$1 como las siguientes% &rese("aci*(9 interfaz gr ficaJ ventanas. L*gica de ap icaci*( 3 O,1e"os de do'i(io de pro, e'a9 ob(etos que representan conceptos del dominio 0los ob(etos de ventas, por e(emplo1 que cumplen con los requisitos de aplicacin. L*gica de ap icaci*( 3 O,1e"os de ser)icio9 ob(etos de dominio no relacionados con el problema que prestan servicios de soporteJ por e(emplo, interfaz con una base de datos. A 'ace(a'ie("o9 un mecanismo persistente de almacenamientoJ por e(emplo una base de datos relacional u orientada a ob(etos.
El anlisis y diseo orientados a objetos generalmente son ms tiles para modelar los niveles lgicos de la aplicacin.
/studiaremos en el captulo $$ el tema de una arquitectura de capas 0o niveles1. /l caso de estudio del punto de venta destaca principalmente los ob(etos del dominio del problema, asign ndoles responsabilidades para cumplir con los requisitos de la aplicacin. /n el captulo :L nos serviremos del dise*o orientado a ob(etos para crear un con(unto de ob(etos del nivel de servicio para conectarnos con una base de datos. /n este m)todo de dise*o, la capa de presentacin tiene muy poca responsabilidadJ se dice que es delgada. 8as ventanas no contienen un cdigo que se encargue de la lgica o procesamiento de la aplicacin. 'or el contrario, las solicitudes de tarea se envan al dominio del problema y a las capas de servicio.
I.E
;uestra estrategia5 aprendizaje y desarrollo iterati'os
/ste libro est organizado para seguir una estrategia de desarrollo iterativo. /l an lisis y el dise*o orientados a ob(etos se aplican al sistema del punto de venta en dos ciclos de desarrollo iterativo en que el primer ciclo se destina a una simple aplicacin de las funciones b sicas. /l segundo ampla la funcionalidad del sistema 0v)ase la figura D.:1.
?igura D.: 4uta de aprendiza(e que siguen los ciclos de desarrollo.
$ + "-.5 &/ /.T6&25% /8 '63T5 &/ >/3T-
,dems del desarrollo iterativo, tambi-n se e.pone de manera iterativa la presentacin de los temas del anlisis y el dise/o orientados a objetos, la notacin de 0M1 y los patrones. En el primer ciclo de desarrollo del sistema del punto de venta, se describe un grupo bsico de temas de anlisis y de dise/o, as como la notacin. El segundo ciclo se e.pande y ofrece nuevas ideas, la notacin de 0M1 y los patrones. Esta estrategia tiene por objeto proponer un modelo de aprendi(aje 2justo a tiempo2. El modelo procura e.plicar primero las ideas de mayor uso, lo ms cerca posible del momento en que el lector perciba la necesidad de aprenderlos para poder continuar. ,l principio, el libro se centra en las ideas y *abilidades fundamentales, sin saturarlo con nueva informacin que no pueda aplicar de inmediato. 3espu-s se e.plican las *abilidades e ideas que se utili(an ms raramente.
"535"2+2/3T5 &/ 85. 4/O6/42+2/3T5.

O,1e"i)os
2 2 2 #rear los artefactos de la fase de re,uerimientos3 por ejemplo) las especificaciones de funciones. Identificar y clasificar las funciones del sistema. Identificar y clasificar los atributos del sistema y relacionarlos con las funciones.
5.1 $ntrod#ccin
6n proyecto no puede ser e4itoso sin una especificaci#n correcta y e4hausti'a de los requerimientos. 9ara ello se necesitan muchas habilidades: un e4amen riguroso de ellas rebasa el mbito de este libro! pues nuestro objeti'o es que el lector domine el anlisis y el diseo orientados a objetos. 9ero se ofrece una introducci#n a los requerimientos
de la aplicaci#n punto de 'enta! porque en la prctica es un paso decisi'o! y se mencionan otros artefactos relacionados con la fase de requerimientos. ;o dudamos en recomendar E0ploring 1e,uirements: 2uality &e"ore Design R?UOPS! obra que se centra en las habilidades necesarias para dilucidar los requerimientos importantes. Este capitulo se propone lograr que el lector pueda e4presar los requerimientos! no en con'ertirlo en un e4perto en el dominio de los sistemas de terminales para tiendas y puntos de 'enta. 9or eso! la lista de las funciones y atributos del sistema no es e4hausti'a! sino representati'a.
'laneacin y elaboracin "onstruccin -plicacin
1. &efinir el plan preliminar D. 4egistrar los t)rminos en el glosario. a ;. &efinir el modelo conceptual preliminar. c Notas% a. constante b. opcional c. aplazable d. orden variable
$. /laborar el informe preliminar de investigacin E. 2mplementar el prototipo.

b, d
:. &efinir los requerimientos K. &efinir los casos de uso 0de alto nivel y esenciales1. B. 'erfeccionar el plan.
L. &efinir la arquitectura preliminar del sistema. a, c, d
-ctividades de la fase de planeacin y elaboracin. . 2nforme 'reliminar de 2nvestigacin /specificaciones de 4equerimientos
'rototipos
"asos de 6so% Todos de alto nivel. b. -lgunos esenciales e9pandidos. a.
&iagramas de "asos de 6so
'resupuesto, programa +odelo "onceptual preliminar &ependencia respecto a Nlosario
&ependencias de los artefactos respecto a la fase de planeacin y elaboracin.
;inguno de los artefactos que se describen en la presente secci#n son propios del lenguaje 673: se trata simplemente de documentos comunes de la fase de requerimientos.
5.2 %os re&#eri ientos

3os &e:ue&i3ien'%# son una descripci#n de las necesidades o deseos de un producto. 3a meta primaria de la fase de requerimientos es identificar y documentar lo que en realidad se necesita! en una forma que claramente se lo comunique al cliente y a los miembros del equipo de desarrollo. El reto consiste en definirlos de manera inequ"'oca! de modo que se detecten los riesgos y no se presenten sorpresas al momento de entregar el producto. (e recomiendan los siguientes artefactos en la fase de requerimientos5 X X X X X panorama general clientes metas funciones del sistema atributos del sistema
/tros documentos pertinentes! que por cierto no e4aminaremos en el libro! se mencionan al final del cap"tulo. 5.2.1 *ntegraci"n de las pie!as del rompeca$e!as En nuestro caso de estudio! la definici#n de los requerimientos aparece muy clara y tajante5 la realidad dista mucho de serlo. 9or lo regular hay que reunir y asimilar muchos estudios y documentos electr#nicos! analizar los resultados de las entre'istas! celebrar reuniones para definir los requerimientos en grupo! etctera. 5.3 +resentaci"n general
Este proyecto tiene por objeto crear un sistema de terminal para el punto de 'enta que se utilizar en las 'entas al menudeo. 4.0 Clientes *bject .tore, 3nc.! detallista multinacional de objetos. 5.5 Metas En trminos generales! la meta es una mayor automatizaci#n del pago en las cajas registradoras! dar soporte a ser'icios ms rpidos! ms baratos y mejores y a los procesos de negocios. 7s concretamente! la meta incluye5 X 9ago rpido de los clientes. X 8nlisis rpido y e4acto de las 'entas. X $ontrol automtico del in'entario. 5.% ,unciones del sistema 3as )unci%ne# del #i#'e3a son lo que ste habr de hacer4 por ejemplo autorizar los pagos a crdito. =ay que identificarlas y listarlas en grupos cohesi'os y l#gicos.
Con el ob'eto de verificar &#e al()n * es de verdad #na f#ncin del siste a, la si(#iente oracin deber+ tener sentido: ,l siste a deber+ -acer .*/.
9or ejemplo: El sistema deber autori(ar los pagos a cr5dito. En cambio! los a'&i(u'%# del #i#'e3a son cualidades no funcionales C entre ellas la facilidad de usoC que a menudo se confunden con las funciones. ;#tese que *facilidad de uso+ no encaja en la oraci#n de 'erificaci#n5 El sistema deber hacer la "acilidad de uso. 3os atributos no deben formar parte del documento de las especificaciones funcionales del sistema! sino de un documento independiente que especifica sus atributos. 5.%.1 Categor-as de las unciones 3as funciones! como autori(ar pagos a cr5dito, han de clasificarse a fin de establecer prioridades entre ellas e identificar las que de lo contrario pasar"an inad'ertidas ,pero que consumen tiempo y otros recursos-. 3as categor"as son5
8a'eg%&5a de la )uncin E'idente
Signi)icad% 1ebe realizarse! y el usuario deber"a saber que se ha realizado 1ebe realizarse! aunque no es 'isible para los usuarios. Esto se aplica a muchos ser'icios tcnicos subyacentes! como guardar informaci#n en un mecanismo persistente de almacenamiento. 3as funciones ocultas a menudo se omiten ,err#neamente- durante el proceso de obtenci#n de los requerimientos. /pcionales: su inclusi#n no repercute significati'amente en el costo ni en otras funciones.
/culta
(uperflua
5.!.2 0#nciones b+sicas

3as siguientes funciones del sistema en la aplicaci#n de la terminal del punto de 'enta son una muestra representati'a: no pretenden en absoluto ser e4hausti'as. ;uestro objeti'o es entender los detalles del anlisis y del diseo! no el funcionamiento de una tienda.
Re) D 2A.A
1uncin 2egistra la 'enta en proceso ,actual-5 los productos comprados. $alcula el total de la 'enta actual: se incluyen el impuesto y los clculos de cup#n. $aptura la informaci#n sobre el objeto comprado usando su c#digo de barras y un lector o usando una captura manual de un c#digo del producto: por ejemplo! un c#digo uni'ersal de producto ,69$-.
8a'eg%&5a E'idente
2A.B
E'idente
2A.E
E'idente
2A.I
2educe las cantidades del in'entario cuando se realiza una 'enta. (e registran las 'entas efectuadas. El cajero debe introducir una identificaci#n y una contrasea para poder utilizar el sistema. /frece un mecanismo de almacenamiento persistente. /frece mecanismos de comunicaci#n entre los procesos y entre los sistemas. 7uestra la descripci#n y el precio del producto registrado.
/culta
2A.K 2A.L
/culta E'idente
2A.N 2A.O
/culta /culta
2A.P
E'idente
4.56 7unciones de 'ago

Re) D 2B.A 1uncin 8a'eg%&5a
7aneja los pagos en efecti'o! capturando la cantidad ofrecida E'idente y calculando el saldo deudor. 7aneja los pagos a crdito! capturando la informaci#n E'idente crediticia a partir de una lectora de tarjetas o mediante captura manual! y autorizando los pagos con el ser'icio de autorizaci#n ,e4terna- de crditos de la tienda a tra's de una cone4i#n por m#dem. 7aneja los pagos con cheque! capturando la licencia de conducir mediante captura manual! y autorizando los pagos con el ser'icio de autorizaci#n ,e4terna- de cheques de la tienda a tra's de la cone4i#n por m#dem. 2egistra los pagos en el sistema de cuentas por cobrar! pues el ser'icio de autorizaci#n de crdito debe a la tienda el monto del pago. E'idente
2B.B
2B.E
2B.I
/culta
5." Atrib#tos del siste a

3os atributos del sistema son sus caracter"sticas o dimensiones: no son funciones. 9or ejemplo5 facilidad de uso tolerancia a las fallas tiempo de respuesta
metfora de interfaz
costo al detalle
plataformas
3os atributos del sistema pueden abarcar todas las funciones ,por ejemplo! la plataforma del sistema operati'o- o ser espec"ficos de una funci#n o grupo de funciones.
3os atributos tienen un posible conjunto de de'alle# de a'&i(u'%#! los cuales tienden a ser 'alores discretos! confusos o simb#licos: por ejemplo5 tiempo de respuesta M ,psicol#gicamente correctometfora de interfaz M ,grfico! colorido! basado en formas8lgunos atributos del (istema tambin pueden tener &e#'&icci%ne# de )&%n'e&a del a'&i(u'%! que son condiciones obligatorias de frontera! generalmente en un rango numrico de los 'alores de un atributo: por ejemplo5 tiempo de respuesta ,cinco segundos como m4imo=e aqu" algunos ejemplos ms5
A'&i(u'% <iempo de respuesta
De'alle# ! &e#'&icci%ne# de )&%n'e&a
,restriccin de "rontera6 $uando se registre un producto 'endido! la descripci#n y el precio aparecern en cinco segundos.
,detalle6 Gentanas orientadas a la metfora de una forma y cuadros de dilogo. ,detalle6 ma4imiza una na'egaci#n fcil con teclado y no con apuntadores.
7etfora de interfaz
<olerancia a fallas
,restriccin de "rontera6 debe registrar los pagos a crdito autorizados que se hagan a las cuentas por cobrar en un plazo de BI horas! aun cuando se produzcan fallas de energ"a o del equipo ,detalle6 7icrosoft Uindo s PK y ;<.
9lataformas del sistema operati'o
7.8.9 Atributos del sistema en las especi"icaciones de "unciones $on'iene describir todos los atributos del sistema que se relacionen claramente con las funciones dentro de la lista en que se especifican estas >ltimas. 8dems! los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales.9 A 6na restricci#n de frontera suele ser obligatoria! pues de lo contrario significar"a que no era solid.
Re) D 2A.P 1uncin 7ostrar la descripci#n y el precio del producto registrado. 8a'. E'idente A'&i(u'% <iempo de respuesta 7etfora de interfaz De'alle# ! &e#'&icci%ne# K segundos como m4imo 9antallas basadas en formas $olorido 2B.I 2egistrar los pagos a crdito en el sistema de cuentas por cobrar! pues el ser'icio de autorizaci#n de crdito debe a la tienda el importe del pago. /culto <olerancia a fallas 1ebe registrar en las cuentas por cobrar en un plazo de BI horas! aun cuando se produzcan fallas de energ"a o del equipo. AT segundos como m4imo 8a'. /bliga. torio /bliga. torio /pcional /bliga. torio
<iempo de respuesta
/bliga. torio
5.. /tros arte actos en la ase de los re0uerimientos En este libro se da una introducci#n muy sucinta a los requerimientos: es un tema que bien podr"a abarcar libros enteros. 3as funciones y los atributos del sistema son los documentos m"nimos de los requerimientos! de modo que se necesitan otros artefactos importantes para atenuar el riesgo y entender el problema! a saber5 : 1e,uerimientos y e,uipos de enlace: lista de los que deber"an participar en la especificaci#n de las funciones y atributos del sistema! en la realizaci#n de entre'istas! de pruebas! de negociaciones y de otras acti'idades. : /rupos a"ectados: los que reciben el impacto del desarrollo o aplicaci#n del (istema. : .uposiciones: las cosas cuya 'erdad se supone. : 1iesgos: las cosas que pueden ocasionar el fracaso o retraso. : Dependencias: otras personas! sistemas y productos de los cuales no puede prescindir el proyecto para su terminaci#n
: /losario: definici#n de los trminos pertinentes: tema que se estudiar en cap"tulos subsecuentes : ;asos de uso: descripciones narrati'as de los procesos del dominio: tema que se 'er en cap"tulos posteriores : %odelo conceptual preliminar: modelo de conceptos importantes y de sus relaciones: tema que se tratar en cap"tulos posteriores.
$8(/( 1E 6(/5 1E($2@9$@V; 1E 92/$E(/(
/$)eti1os : : : : 3denti"icar y escribir casos de uso. Disear diagramas de casos de uso. ;ontrastar los casos de uso de alto nivel con los e0pandidos. ;ontrastar los casos de uso esenciales con los reales.
%.1 *ntroducci"n 6na tcnica e4celente que permite mejorar la comprensi#n de los requerimientos es la creaci#n de casos de uso! es decir! descripciones narrati'as de los procesos del dominio. En este capitulo se e4ponen los conceptos bsicos de esta tcnica y se dan ejemplos para aplicarlos a la terminal de punto de 'enta. En el siguiente cap"tulo clasificaremos los casos de uso y escogeremos los que utilizaremos en el primer ciclo de desarrollo. El 673 incluye formalmente el concepto de casos de uso y sus diagramas de uso.
'laneacin y elaboracin "onstruccin -plicacin
1. &efinir el plan preliminar D. 4egistrar los t)rminos en el glosario. a ;. &efinir el modelo conceptual preliminar. c Notas% a. constante b. opcional c. aplazable d. orden variable
$. /laborar el informe preliminar de investigacin E. 2mplementar el prototipo.

b, d
:. &efinir los requerimientos K. &efinir los casos de uso 0de alto nivel y esenciales1. B. 'erfeccionar el plan.
L. &efinir la arquitectura preliminar del sistema. a, c, d
-ctividades de la fase de planeacin y elaboracin. . 2nforme 'reliminar de 2nvestigacin 'rototipos a.
/specificaciones de "asos de 6so%

Todos de -lto 3ivel. b. -lgunos esenciales
&iagramas de "asos de 6so
+odelo "onceptual preliminar &ependencia respecto a Nlosario
1ependencias de los artefactos respecto a la fase de planeaci#n y elaboraci#n.
%.2
2cti1idades 3 dependencias 3os casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema! en teor"a e4presados en el documento donde se especifican.
%.3
Casos de uso El caso de uso es un documento narrati'o que describe la secuencia de e'entos de un actor ,agente e4terno- que utiliza un sistema para completar un proceso R&acobsonPBS. 3os casos de uso son historias o casos de utilizaci#n de un sistema: no son e4actamente los requerimientos ni las especificaciones funcionales! sino que ejemplifican e incluyen tcitamente los requerimientos en las historias que narran.
$omprar productos
1igu&a ;.1 @cono del lenguaje 673 para un caso de uso. %.3.1 4)emplo de un caso de uso de alto ni1el: comprar productos El siguiente caso de uso de alto ni'el describe clara y concisamente el proceso de comprar art"culos en una tienda cuando se emplea una terminal en el punto de 'enta. 8a#% de u#%6 Ac'%&e#6 Tip%6 De#c&ipcin6 $omprar productos $liente! $ajero. 9rimario ,que se e4plicar luego-. 6n $liente llega a la caja registradora con los art"culos que comprar. El $ajero registra los art"culos y cobra el
importe. 8l terminar la operaci#n! el $liente se marcha con los productos. 3os encabezados y la estructura de este caso de uso son representati'os. (in embargo! el 673 no especifica un formato r"gido: puede modificarse para atender las necesidades y ajustarse al esp"ritu de la documentaci#n ante todo! una comunicaci#n clara. $on'iene comenzar con los casos de uso de alto ni'el para lograr rpidamente entenderlos principales procesos globales. %.3.2 4)emplo de un caso e5pandido de uso: comprar productos con e ecti1o 6n ca#% eEpandid% de u#% muestra ms detalles que uno de alto ni'el: este tipo de casos suelen ser >tiles para alcanzar un conocimiento ms profundo de los procesos y de los requerimientos. 8 menudo se lle'an a cabo en un estilo *coloquial+ entre los actores y el sistema RUirfs.Droc)PES. 1amos en seguida un ejemplo de un caso e4pandido de ;omprar productos que ha sido simplificado para manejar >nicamente los pagos en efecti'o y e4cluir la administraci#n del in'entario ,lo hemos hecho para simplificar la e4plicaci#n en este primer ejemplo-. 8a#% de u#%6 Ac'%&e#6 <&%p#i'%6 Re#u3en6 8%3p&a& p&%duc'%# en e)ec'i?% $liente ,iniciador-! $ajero. $apturar una 'enta y su pago en efecti'o. 6n $liente llega a la caja registradora con art"culos que desea comprar. El $ajero registra los productos y recibe un pago en efecti'o. 8l terminar la operaci#n! el $liente se marcha con los productos comprados. 9rimario y esencial. <unciones: 2A.A. 2A.B. 2A.E. 2A.N! 2A.P! 2B.l.
Tip%6 Re)e&encia# c&u7ada#6
-urso (or'a de os e)e("os Acci*( de ac"or 1. /ste caso de uso comienza cuando un "liente llega a una ca(a de T'&> 0Terminal 'unto de >enta1 con productos que desea comprar. %. &etermina el precio del producto e incorpora a la transaccin actual la informacin correspondiente. Respues"a de sis"e'a
$. /l "a(ero registra el identificador de cada producto. .i hay varios productos de una
1 ANLISIS Y DISEO ORIENTADOS A OBJETOS misma categora, el "a(ero tambi)n puede introducir la cantidad. .. -l terminar de introducir el producto, el "a(ero indica a T'&> que se concluy la captura del producto. /l "a(ero le indica el total al "liente. /l "liente efectIa un pago en efectivo Pel Qefectivo ofrecidoRP posiblemente mayor que el total de la venta. @. +uestra al cliente la diferencia Nenera un recibo. .e presentan la descripcin y el precio del producto actual.
6. "alcula y presenta el total de la venta.
?.
7.
<. /l "a(ero registra la cantidad de efectivo recibida. 1A. /l "a(ero deposita el efectivo recibido y e9trae el cambio del pago /l "a(ero da al "liente el cambio y el recibo impreso. 1$. /l "liente se marcha con los artculos comprados.
11. 4egistra la venta concluida.
Cursos alternos X 3"nea B5 introducci#n de identificador in'lido. @ndicar error. X 3"nea N5 el cliente no ten"a suficiente dinero. $ancelar la transacci#n de 'enta.
%.3.3
45plicaci"n del ormato e5pandido 3a parte superior de la forma e4pandida es informaci#n muy sucinta. 8a#% de u#%6 N%3(&e del ca#% de u#% Ac'%&e#6 3ista de actores ,agentes e4ternos-! en la cual se indica quin inicia el caso de uso. <&%p#i'%6 @ntenci#n del caso de uso. Re#u3en6 2epetici#n del caso de uso de alto ni'el o alguna s"ntesis
similar. Tip%6 1. 9rimario! secundario u opcional ,a e4plicar-. *. Esencial o real ,a e4plicar-. Re)e&encia# $asos relacionados de uso y funciones tambin relacionadas c&u7ada#6 del sistema.
3a secci#n intermedia! curso normal de los eventos, es la parte medular del formato e4pandido: describe los detalles de la con'ersi#n interacti'a entre los actores y el sistema. 6n aspecto esencial de la secci#n es que e4plica la secuencia ms com>n de los e'entos5 la historia normal de las acti'idades y la terminaci#n e4itosa de un proceso. =o incluye situaciones alternas.
Curso normal de los e1entos Accin del ac'%& Re#pue#'a del #i#'e3a 1escripciones numeradas de las respuestas del sistema.
8cciones numeradas de los actores.
3a >ltima secci#n! curso alterno de los eventos, describe importantes opciones o e4cepciones que pueden presentarse en relaci#n con el curso normal. (i son complejas! podemos e4pandirlas y con'ertirlas en nuestros casos de uso. $ursos alternos X 8lternati'as que pueden ocurrir en el n>mero de l"nea. 1escripci#n de e4cepciones. %.# 2ctores El actor es una entidad e4terna del sistema que de alguna manera participa en la historia del caso de uso. 9or lo regular estimula el sistema con e'entos de entrada o recibe algo de l. 3os actores estn representados por el papel que desempean en el caso5 $liente! $ajero u otro. $on'iene escribir su nombre con may>scula en la narrati'a del caso para facilitar la identificaci#n.
$liente 1igu&a ;.* @cono del lenguaje 673 que representa un actor de casos de uso.A A 8unque el icono estndar es una figura humana estilizada! hay quienes prefieren utilizar un icono con figura de computadora para designar los actores que son sistemas de c#mputo y no seres humanos.
En un caso de uso hay un actor iniciador ,ue produce la estimulacin inicial y, posiblemente, otros actores participantes4 tal ve( convenga indicar ,ui5n es el iniciador. 3os actores suelen ser los papeles representados por seres humanos! pero pueden ser cualquier tipo de sistema! como un sistema computarizado e4terno de bancos. =e aqu" algunos tipos5 X papeles que desempean las personas X sistemas de c#mputo X aparatos elctricos o mecnicos
%.5
6n error com7n en los casos de uso 6n error com>n en la identificaci#n de los casos de uso consiste en representar los pasos! las operaciones o las transacciones indi'iduales como casos. 9or ejemplo! en el dominio de la terminal del punto de 'enta! podemos definir ,incorrectamente- un caso denominado *@mprimir el recibo+! cuando en realidad esta operaci#n no es ms que un paso de un proceso ms amplio del caso ;omprar productos.
6n caso de uso es una descripci#n de un proceso de principio a fin relati'amente amplia! descripci#n que suele abarcar muchos pasos o transacciones: normalmente no es un paso ni una acti'idad indi'idual del proceso. Es posible di'idir las acti'idades o parte del caso en subcasos ,denominados ca#%# a(#'&ac'%# de u#%-! incluso en pasos indi'iduales5 pero esto no es lo habitual y lo 'eremos en el cap"tulo BL.
%.%
*denti icaci"n de los casos de uso 3os siguientes pasos de la identificaci#n de los casos de uso requieren
una llu'ia de ideas y re'isar los documentos actuales sobre la especificaci#n de los requerimientos.
6n mtodo con que se identifican los casos de uso se basa en los actores. 1. (e identifican los actores relacionados con un sistema o empresa. *. En cada actor! se identifican los procesos que inician o en que participan. 6n segundo mtodo de identificaci#n de los casos de uso se basa en e'entos. 1. (e identifican los e'entos e4ternos a los que un sistema ha de responder. *. (e relacionan los e'entos con los actores y con los casos de uso.
En la aplicaci#n del punto de 'enta! algunos actores posiblemente rele'antes y los procesos que inician son5
-a1ero 4egistra /ntrega efectivo "ompra productos 'aga los productos
- ie("e
%.8
Caso de uso 3 procesos del dominio >n caso de uso describe un proceso! un proceso de negocios por ejemplo. 6n p&%ce#% describe! de comienzo a fin! una secuencia de los e'entos! de las acciones y las transacciones que se requieren para producir u
obtener algo de 'alor para una empresa o actor. 8 continuaci#n se mencionan algunos procesos5 @ @ @ @ @ %.. 2etira efecti'o en un cajero automtico /rdena un producto 2egistra los cursos que se imparten en una escuela Gerifica la ortograf"a de un documento con un procesador de palabras 2ealiza una llamada telef#nica
Casos de uso9 unciones del sistema 3 rastrea$ilidad 3as funciones del sistema identificadas durante la especificaci#n pre'ia de requerimientos deben asignarse a los casos de uso. 8dems! debe ser posible 'erificar! mediante la secci#n 1e"erencias cru(adas, que todas las funciones hayan sido asignadas. $on ello se logra un '"nculo importante respecto a la rastreabilidad entre los artefactos. En definiti'a! todas las funciones y casos de uso del sistema deber"an poder rastrearse hasta la implementaci#n y la aplicaci#n de pruebas.
%.: &iagramas de los casos de uso En la figura L.E se muestra un diagrama de casos de uso para el sistema del punto de 'enta.
T'&> "ompra 'roductos "a(ero 4egistra los &atos /ntrega el cambio de los productos comprados "liente
1igu&a ;.+
1iagrama parcial de casos de uso.
6n diag&a3a de ca#%# de u#% e4plica grficamente un conjunto de casos de uso de un sistema! los actores y la relaci#n entre stos y los casos de uso. Estos >ltimos se muestran en #'alos y los actores son figuras estilizadas. =ay l"neas de comunicaciones entre los casos y los actores: las flechas indican el flujo de la informaci#n o el estimulo. El diagrama tiene por objeto ofrecer una clase de diagrama conte4tual que nos permite conocer rpidamente los actores e4ternos de un sistema y las formas bsicas en que lo utilizan.
%.1; ,ormatos de los casos de uso En la prctica! los casos de uso pueden e4presarse con di'erso grado de detalle y de aceptaci#n de las decisiones concernientes al diseo. En otras palabras! un mismo
caso de uso pueden escribirse en diferentes formatos y con di'ersos ni'eles de detalle. 7s adelante estudiaremos otras formas de clasificarlos y e4presarlos en formatos: pero por ahora nos concentraremos en una di'isi#n fundamental5 casos con formato de alto ni?el ! eEpandid%. %.1;.1 ,ormato de alto ni1el 6n ca#% de u#% de al'% ni?el describe un proceso muy bre'emente! casi siempre en dos o tres enunciados. $on'iene ser'irse de este tipo de caso durante el e4amen inicial de los requerimientos y del proyecto! a fin de entender rpidamente el grado de complejidad y de funcionalidad del sistema. Estos casos son muy sucintos y 'agos en las decisiones de diseo. %.1;.2 ,ormato e5pandido 6n ca#% de u#% eEpandid% describe un proceso ms a fondo que el de alto ni'el. 3a diferencia bsica con el caso de uso de alto ni'el consiste en que tiene una secci#n destinada al curso normal de los eventos, que los describe paso por paso. 1urante la fase de especificaci#n de requerimientos! con'iene escribir en el formato e4pandido los casos ms importantes y de mayor influencia: en cambio! los menos importantes pueden posponerse hasta el ciclo de desarrollo en el cual 'an a ser abordados. %.11 <os =istemas 3 sus ronteras 6n caso de uso describe la interacci#n con un *sistema+. 3as fronteras ordinarias del sistema son5 X la frontera hard are Q soft are de un dispositi'o o sistema de c#mputo X el departamento de una organizaci#n X la organizaci#n entera
"aso de uso
-ctor
1igu&a ;.0 Frontera de un caso de uso. Es importante definir la frontera del sistema para identificar lo que es interno o e4terno! as" como las responsabilidades del sistema. El ambiente e4terno est representada >nicamente por actores.
Estudiaremos un ejemplo de la influencia que tiene seleccionar la frontera del sistema5 los pagos en la terminal del punto de 'enta y la tienda. (i elegimos como *el sistema+ la tienda entera o el negocio ,figura L.L-! el >nico actor es el cliente y no el cajero! porque este >ltimo es un recurso del sistema del negocio que realiza las funciones. 9ero si escogemos como sistema el hard are y el soft are de la terminal del punto de 'enta ,figura L.K-! se trata como actores al cliente y al cajero.
T'&> "ompra 'roductos "a(ero 4egistra los 'roductos /ntrega el cambio de los productos comprados Figura ?.6 "asos de uso y actores cuando el sistema T&DB es la frontera Tienda "ompra 'roductos "liente "liente
/ntrega el cambio de los productos comprados Figura ?.? "asos de uso y actores cuando "ie(da es la frontera
En la selecci#n de una frontera del sistema influyen las necesidades de la in'estigaci#n. (i estamos desarrollando un soft are de aplicaci#n o un
dispositi'o! ser razonable establecer la frontera del sistema en la del hard are y en la del soft are: por ejemplo! la terminal del punto de 'enta y sus programas constituye *el sistema+! y el cliente y el cajero son los actores ,agentes- e4ternos. (i estamos efectuando la &eingenie&5a de p&%ce#%# de la e3p&e#a C reorganizando los procesos o la empresa para mejorar la competiti'idad o la calidadC! la selecci#n
de la compa"a o de la tienda entera como el sistema es importante. En el sistema <91G! definiremos *el sistema+ como la terminal de punto de 'enta y su soft are. %.12 Casos de uso primarios9 secundarios 3 opcionales 3os casos deber"an clasificarse en primarios! secundarios u opcionales. 7s adelante! a partir de estas designaciones clasificaremos nuestro conjunto de casos de uso para establecer prioridades en su desarrollo. 3os ca#%# p&i3a&i%# de u#% representan los procesos comunes ms importantes! como ;omprar productos. 3os ca#%# #ecunda&i%# de u#% representan procesos menores o raros: por ejemplo! .olicitud de surtir el nuevo producto. 3os ca#%# %pci%nale# de u#% representan procesos que pueden no abordarse.
%.13
Casos esenciales de uso comparados con los casos reales de uso
Nrado de la aceptacin del dise*o en un caso de uso
#aso esencial &uy abstracto
#aso real muy concreto
1igu&a ;.= 3os casos esenciales y reales de uso e4isten a lo largo de un continuo. %.13.1 Casos esenciales de uso 3os ca#%# e#enciale# de u#% R$onstantinePNS son casos e4pandidos que se e4presan en una forma te#rica que contiene poca tecnolog"a y pocos detalles de implementaci#n: las decisiones de diseo se posponen y se
abstraen de la realidad! especialmente las concernientes a la interfaz para el usuario. 6n caso de este tipo describe el proceso a partir de sus acti'idades y moti'os esenciales. El grado de abstracci#n con que se describe e4iste en un continuo5 la descripci#n puede ser ms o menos esencial. 3os casos de alto ni'el siempre son de carcter esencial! debido a su bre'edad y abstracci#n. En seguida se incluye un ejemplo de un caso de 1etiro de e"ectivo en un cajero automtico! que se e4presa en una forma relati'amente esencial.
Ese(cia Acci*( de os ac"ores 1. /l "liente se identifica. %. S as sucesivamente. Respues"a de sis"e'a $. 'resenta opciones. .. S as sucesivamente.
3a manera en que un cliente se identifica cambia con el tiempo Ces una decisi#n de diseoC! pero forma parte del proceso esencial de que la identificaci#n se realice de alguna manera. $on'iene crear casos esenciales de uso al comenzar a in'estigar los requerimientos! con el prop#sito de entender mejor el alcance del problema y las funciones necesarias. Este tipo de casos son de gran utilidad porque permiten captar la esencia del proceso y sus moti'os fundamentales! sin 'erse abrumado con detalles de diseo. (uelen tambin ser correctos durante largo tiempo! ya que e4cluye las decisiones de diseo y! por lo mismo! su creaci#n fa'orece la comprensi#n y el registro de los factores que dan 'ida a los procesos de un negocio. 6na empresa puede recuperar y releer los casos esenciales de uso mucho tiempo despus! aplicndolos e4itosamente a un nue'o proyecto de desarrollo. %.13.2 Casos reales de uso En cambio! un ca#% &eal de u#% describe concretamente el proceso a partir de su diseo concreto actual! sujeto a las tecnolog"as especificas de entrada y de salida! etc. $uando se trata de la interfaz para el usuario! a menudo ofrece presentaciones de pantalla y e4plica la interacci#n con los artefactos. 8 continuaci#n se incluye el caso 1etiro de e"ectivo e4presado en una forma relati'amente real.
Rea Acci*( de os ac"ores 1. /l "liente introduce su tar(eta $. Respues"a de sis"e'a 'ide el identificacin nImero de personal
1 ANLISIS Y DISEO ORIENTADOS A OBJETOS 032'1. %. 2ntroduce el 32' con un teclado num)rico. 6. S as sucesivamente. .. +uestra el menI de opciones.
?. S as sucesivamente.
;#tese que la acci#n esencial del *$liente se identifica a s" mismo+ del caso de uso se realiz# ahora concretamente en la serie de acciones comenzando con *El $liente introduce su tarjeta+. En teor"a! los casos reales de uso se crean durante la fase de diseo en un ciclo de desarrollo! por ser un artefacto del diseo. En algunos proyectos se pre'n las primeras decisiones de diseo concernientes a la interfaz para el usuario: de ah" la necesidad de crear casos reales en la fase inicial de elaboraci#n. (e recomienda hacerlo en la fase de planeaci#n y elaboraci#n por la aceptaci#n prematura de un diseo y la abrumadora complejidad. ;o obstante! algunas compa"as aceptan un contrato de desarrollo! basndose en las especificaciones de la interfaz para el usuario. En el cap"tulo AP se e4aminan los casos reales en la aplicaci#n al punto de 'enta. %.13.3 4l caso esencial de uso de la compra de productos El caso ampliado de uso ;omprar productos que ya mencionamos tiende a ser un caso esencial. /bsr'ese que la descripci#n no es muy espec"fica respecto a la realizaci#n tcnica. El caso est escrito de manera que casi podemos imaginar su aplicabilidad despus de cien aos o hace cien aos! lo cual manifiesta que es esencial.
Ese(cia Acci*( de os ac"ores 1. /l ca(ero registra el identificador en cada producto. .i hay m s de un producto igual, el "a(ero puede introducir de igual manera la cantidad %. S as sucesivamente. Respues"a de sis"e'a $. &etermina el precio del producto y agrega la informacin sobre )l a la actual transaccin de venta. -parecen la descripcin y el precio del producto actual. .. S as sucesivamente.
%.13.# 4l caso real de uso de la compra de productos 8 diferencia de una 'ersi#n esencial del caso de uso! una 'ersi#n real se compromete con el diseo: una 'ersi#n completa de ella se e4plicar en un capitulo posterior. En el siguiente ejemplo de la 'ersi#n real! n#tese la
decisi#n de utilizar un c#digo uni'ersal de producto ,$69- con el identificador del producto A y una interfaz grfica para el usuario. A En una fase temprana del anlisis no con'iene tomar algunas decisiones! como la de utilizar un c#digo uni'ersal de producto ,$69- en el caso esencial de uso. El anlisis y diseo esencial y real son trminos a lo largo de un continuo de abstracci#n ms que e4tremos. =e aqu" lo ms importante5 siempre que se adopta un compromiso durante la fase de anlisis! e4iste la posibilidad de un error prematuro de diseo! sobrecarga de informaci#n y menor fle4ibilidad.
Rea Acci*( de os ac"ores 1. /n cada producto, el "a(ero teclea el "digo 6niversal de 'roductos 0"6'1, en el campo de entrada del "6' de la >entanal. &espu)s oprime el botn Qintroducir productoR con el ratn u oprimiendo la tecla T/nterU. $. Respues"a de sis"e'a +uestra el precio del producto y agrega la informacin sobre )l a la actual transaccin de venta.. 8a descripcin y el precio del producto actual se muestran en el cuadro de Te9to $ de la >entanal. .. etc)tera
%. etc)tera.
!.11 2obre la notacin

?.9@.9 Asignacin de nombre a los casos de uso 8l caso de uso se le asigna un nombre que comience con un 'erbo para subrayar que se trata de un proceso. 9or ejemplo5 X $omprar productos X @ntroducir un pedido ?.9@.A 3nicio de un caso e0pandido de uso $omience un caso e4pandido con el siguiente esquema5 1. Este caso comienza cuando Y8ctorZ Yinicia un e'entoZ 9or ejemplo5 1. Este caso de uso comienza cuando un $liente llega a un <91G con productos que desea comprar. 1e este modo se estimula una identificaci#n clara del actor y del e'ento
iniciadores. ?.9@.B Cuntos sobre la decisin de notacin y sobre la rami"icacin 6n caso de uso puede contener puntos de decisi#n. 9or ejemplo! en ;omprar productos, el cliente puede optar por pagar con efecti'o! a crdito o con cheque en el momento del pago. (i una de estas trayectorias de decisi#n es un caso muy representati'o y si las otras alternati'as son raras! inusuales o e4cepcionales! el caso t"pico
deber ser el >nico acerca del cual se escribe en el ;urso normal de los eventos y las opciones han de escribirse en la secci#n titulada Alternativas. 9ero en ocasiones el punto de decisi#n representa opciones cuya probabilidad es relati'amente igual y normal: esto sucede con los tipos de pago en efecti'o! con tarjeta de crdito y con cheque. En este caso se utiliza la siguiente estructura notacional5 1. En la secci#n principal ;urso normal de los eventos, indique las ramas de las subsecciones. *. Escriba una subsecci#n en cada rama! utilizando otra 'ez un ;urso normal de los eventos. @nicie el e'ento numerando en A cada secci#n. +. (i las subsecciones tienen opciones! escr"balas en una secci#n de alternati'as de cada subsecci#n. Secci*(9 pri(cipa
-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /ste caso de uso comienza cuando un "liente llega a la ca(a T'&> con los productos que comprar . 0/9cluidos los pasos intermedios1... /l "liente escoge el tipo de pago% a. .i paga en efectivo, consIltese la seccin 'ago en efectivo. b. .i paga a cr)dito, consIltese la seccin 'ago con tarjeta de cr(dito. c. .i paga con cheque, consIltese la seccin 'ago con c8e,ue. .. 6. 4egistra la venta terminada. 2mprime un recibo. Respues"a de sis"e'a
$. %.
?. /l "a(ero le entrega el recibo al "liente. 7. /l "liente se marcha con los productos comprados.
Secci*(9 &ago e( e!ec"i)o

-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /l "liente da un pago en efectivo Vel Qefectivo ofrecidoR@, posiblemente mayor que el total de la venta. /l "a(ero registra el efectivo ofrecido. /l "a(ero entrega el efectivo ofrecido. /l "a(ero entrega al cliente el cambio del pago. %. +uestra al "liente la diferencia. Respues"a de sis"e'a
$. ..
C#rsos alternativos
W 8nea D% efectivo insuficiente en la ca(a para pagar la diferencia. .e pide efectivo al supervisor o se pide al "liente un pago m s cercano al total de la venta.
Secci*(9 pago co( "ar1e"a de crCdi"o

"ursos normales y alternos de la historia de pago con tar(eta de cr)dito.
Secci*(9 pago co( cDeEue

"ursos normales y alternos de la historia de pago con cheque.
!.15 Casos de #so dentro de #n proceso de desarrollo

5.94.9'asos de la fase de planeacin y elaboracin
1. &espu)s de haber listado las funciones del sistema, defina la frontera de )ste y luego identifique los actores y los casos de uso.
$. /scriba todos los casos de uso en el formato de alto nivel. "lasifquelos en primarios, secundarios u opcionales. %. &ibu(e un diagrama de caso de uso. .. 4elacione los casos de uso y d) e(emplo de las relaciones en el diagrama correspondiente 0m s adelante se e9plican las relaciones de los casos1. 6. /scriba en el formato esencial e1pandido los casos de uso m s importantes, influyentes y riesgosos, a fin de entender y estimar me(or la naturaleza y las dimensiones del problema. 'ara evitar an lisis comple(os posponga la escritura de la forma esencial e9pandida de los casos de uso menos importantes hasta los ciclos de desarrollo en que ser n abordados. ?. /n teora, los casos reales deberan posponerse hasta una fase de dise*o en el ciclo de desarrollo, porque su creacin conlleva decisiones de dise*o. 'ese a ello, a veces es necesario crear casos reales de uso durante la etapa inicial de los requerimientos si% @ @ 8as descripciones concretas facilitan notablemente la comprensin. 8os "lientes e9igen especificar sus procesos en esta forma.
7. "lasifique los casos de uso 0que se e9pondr n en el siguiente capitulo1.
5.94./ 'asos de la fase del ciclo de desarrollo iterativo

1. $. ?ase de an lisis% escriba casos esenciales de uso e9pandidos para los que se han abordado, si todava no se llevan a cabo. ?ase de dise*o% escriba casos reales de uso para los que est n siendo abordados, en caso de que todava no se realicen.
!.1! Casos del proceso en #n siste a del p#nto de venta

/9plicaremos algunas de las siguientes actividades en captulos posteriores, ya que requieren una e9posicin amplia o pueden aplazarse para evitar una sobrecarga de informacin. "omo nuestra meta es adquirir la habilidad de aplicar los casos y no convertirnos en e9pertos en tiendas, no escribiremos los detalles de todos los casos.
5.95.9 Identifi,ue los actores y los casos de uso

/n la aplicacin del punto de venta, defina la frontera del sistema que ser el sistema de hard,are X soft,are, el caso habitual. 6n e(emplo de lista de los actores y procesos relevantes a que dan inicio Pque no pretende en absoluto ser completaP incluye%
"a(ero
4egistra los productos /ntrega el cambio
"liente
"ompra productos 'aga los productos
Nerente -dministrador del sistema
2nicia "ierra 2ncorpora nuevos usuarios
5.95./ +scriba casos de uso en el formato de alto nivel

6na muestra de casos de uso de alto nivel comprende% -aso de uso9 Ac"ores9 Tipo9 Descripci*(9 -o'prar produc"os "liente 0iniciador1, "a(ero. 'rimario. 6n "liente llega a una ca(a con productos que desea comprar. /l "a(ero registra los productos y obtiene el pago. -l terminar la transaccin, el "liente se marcha con los productos.
-aso de uso9 Ac"ores9 Tipo9 Descripci*(9
I(icio de operacio(es Nerente. 'rimario. 6n gerente activa una T'&> a fin de prepararla para que la usen los "a(eros. /l Nerente comprueba que la fecha y la hora sean correctosJ hecho esto, el sistema est listo para que lo utilice el "a(ero.
5.95.6 "ibuje un diagrama de casos de uso
T'&> "ompra 'roductos "a(ero 4egistra los 'roductos 'aga o entrega el cambio del pago de los productos comprados Nerente "liente
2nicia -dministra a los usuarios etc)tera
-dministrador del .istema
Figura ?.< &iagrama parcial de caso de uso, que representa la aplicacin T'&>.
5.95.: elacione los casos de uso

/ste tema lo trataremos en un captulo posterior.
5.95.4 +scriba algunos casos esenciales e1pandidos de uso

/ntre los casos primarios de uso realmente significativos figuran% W W "omprar productos 'agar los productos comprados
/scribir lo anterior en una forma esencial e9pandida suministrar una mayor informacin y esclarecimiento de los requerimientos. - continuacin se presenta el caso de uso #omprar productos en su forma esencial e9pandida completa%
-asos de uso9 co'prar produc"os Secci*(9 pri(cipa
-aso de uso9 Ac"ores9 &rop*si"o9 Resu'e(9
"omprar productos "liente 0iniciador1, "a(ero. "apturar una venta y su pago. 6n "liente llega a la ca(a con productos que desea comprar. /l "a(ero registra los productos y recibe el pago, que puede ser autorizado. -l terminar la transaccin, el "liente se marcha con los productos. 'rimario y esencial. 7unciones% 41.1, 41.$, 41.:. 41.;, 41.B, 4$.1, 4$.$, 4$.:, 4$.D.
Tipo9 Re!ere(cias -ru;adas9
#asos de uso% el "a(ero debe haber terminado el caso de uso% egistrar.
-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /ste caso de uso comienza cuando un "liente llega a la ca(a T'&> con los productos que desea comprar. /l "a(ero registra los productos. .i hay m s de un producto, tambi)n puede introducir la cantidad. %. &etermina el precio del producto y agrega la informacin sobre )l a la actual transaccin de venta. .e muestran la descripcin y el precio del producto actual. Respues"a de sis"e'a
$.
1 ANLISIS Y DISEO ORIENTADOS A OBJETOS .. -l terminar la captura de los productos, el "a(ero indica a T'&> que termin la captura de los productos. /l "a(ero le indica el total al "liente. /l "liente escoge la forma de pago% a. .i paga en efectivo, v(ase la seccin 'agar en +fectivo. b. .i paga con tar(eta v(ase la seccin 'agar con tarjeta de cr(dito. c. .i paga con cheque, v)ase la seccin 'agar con c8e,ue. <. 4egistra la >enta terminada. @. -ctualiza los niveles de inventario. 1A. Nenera un recibo. 11. /l "a(ero entrega el recibo al cliente. 1$. /l "liente se marcha con los productos comprados. 6. "alcula y presenta el total de la venta.
?. 7.
C#rsos alternos
8nea $% se introduce un identificador inv lido del producto. 2ndique el error. 8nea ;% el "liente no pudo pagan "ancele la transaccin de venta.
Secci*(9 pagar e( e!ec"i)o
-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /l "liente da un pago en efectivo Vel Qefectivo ofrecidoR@, posiblemente mayor que el total de la venta. /l "a(ero registra el efectivo ofrecido. /l "a(ero deposita el efectivo ofrecido y e9trae la diferencia. /l "a(ero le entrega el cambio al cliente. %. 'resenta la diferencia al "liente. Respues"a de sis"e'a
$. ..
C#rsos alternos
8nea 1% el "liente no tiene suficiente efectivo. 'uede cancelar o iniciar otro m)todo de pago. 8nea D% la ca(a no contiene suficiente efectivo para pagar la diferencia. /l "a(ero pide m s efectivo al supervisor o le pide al "liente otro billete de menor denominacin u otra forma de pago.
Secci*(9 pago co( "ar1e"a de crCdi"o

-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /l "liente comunica su informacin de cr)dito para pagar con tar(eta. $. Respues"a de sis"e'a Nenera una solicitud de pago con tar(eta de cr)dito y la enva a un .ervicio e9terno de autorizacin de cr)dito.
%.
/l .ervicio de autorizacin de cr)dito autoriza el pago.
.. 4ecibe una respuesta aprobatoria de cr)dito del .ervicio de autorizacin de cr)dito. 6. /n el sistema de "uentas por cobrar registra la informacin sobre el pago con tar(eta de cr)dito y la respuesta de aprobacin. /l .ervicio de autorizacin de cr)dito debe dinero a la TiendaJ por lo tanto, "uentas por cobrar debe darle seguimiento. +uestra el mensa(e aprobatorio de autorizacin.
?.
C#rsos alternos
8nea :% solicitud de cr)dito negada por el .ervicio de autorizacin de cr)dito. 'roponer otro m)todo de pago.
Secci*(9 pago co( cDeEue

-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /l "liente e9tiende un cheque y se identifica. /l "a(ero registra la informacin sobre la identificacin y solicita la autorizacin del pago con cheque. >erifica que el pago haya sido autorizado por el .ervicio de autorizacin de cheques. %. Nenera una solicitud de pago con cheque y la enva a un .ervicio e9terno de autorizacin de cheques. 4ecibe una respuesta aprobatoria del .ervicio de autorizacin de "heques. Respues"a de sis"e'a
$.
..
6.
?. 2ndica la obtencin de la autorizacin.
C#rsos alternos
8nea D% verificar solicitud negada por el .ervicio de autorizacin de cheques. 'roponer otra forma de pago.
5.95.5 ;i es necesario) escriba algunos casos reales de uso

3o conviene o no es necesario crear casos de uso real en este momentoJ este traba(o se realizar durante los ciclos de desarrollo.
5.95.0 #lasifi,ue los casos de uso

/ste tema se estudiar en el siguiente capitulo.
!.1" 3odelos
#estra
8os casos esenciales de alto nivel y los diagramas de casos de uso son miembros del modelo de casos de uso del an lisis 0figuraK.B1.
+odelo de ?igura K.B -n lisis
+odelo de casos de uso del an lisis b
+odelo conceptual
+odelo del comportamiento del sistema b
+odelo de estado del an lisis b
"asos de 6so% @de alto nivel @esenciales &iagramas de casos de uso
&iagramas de estructura est tica para los conceptos del dominio
&iagramas de secuencia del sistema
&iagramas de /stado para conceptos y casos de uso
"ontratos para operaciones del sistema
a. modelo est tico ,. modelo din mico
Figura ?.@ +odelo de -n lisis
-LASIFI-A-IFN Y &RO/RAGA-IFN DE &RO-ESOS
5b(etivos
Y "lasificar los casos de usos. Y "uando sea necesario, preparar versiones simplificadas de los casos de usos. Y -signar los casos de usos a los ciclos de desarrollo.
7.1
INTROD0--IFN 8as especificaciones de los requerimientos y los casos de uso se definen en la ?ase de 'laneacin y /laboracin. -dem s, puede crearse un +odelo conceptual preliminar y dise*ar una arquitectura tambi)n preliminar del y dise*ar una arquitectura tambi)n preliminar del sistema, aunque estas actividades se pospondr n en nuestro estudio de casos para ofrecer una introduccin mas gradual a los temas. .uponiendo que todos los artefactos deseados hayan sido generados 0por e(emplo, la especificacin de los requerimientos y los casos de uso1, el siguiente paso es iniciar la fase de "onstruccin en el ciclo de desarrollo iterativo y comenzar a implementar el sistema. /n un ciclo de vida de desarrollo iterativo, la tarea de llenar los casos de uso se distribuye entre varios ciclos.
/n el presente captulo se estudia la clasificacin y la programacin o calendarizacin de los casos de usos. 6na vez concluida esta etapa, estaremos listos para comenzar el primer ciclo de desarrollo y e9aminar a fondo el an lisis y dise*o orientados a ob(etos.
"onstruccin
-plicacin
1.@ &efinir plan preliminar
$.@ /laborar el informe preliminar de investigacin E.@ 2mplementar el prototipo ,b, d
:.@ &efinir los requerimientos
D.@ 4egistrar los t)rminos en el glosario ,a ;.@ &efinir el modelo conceptual preliminar ,c
K.@ &efinir los casos de uso 0de alto nivel y esenciales1 B.@ 'erfeccionar el plan
3otas a. constante b. opcional c. aplazable d. orden variable
L.@ &efinir la arquitectura preliminar del sistema. ,a, c, d
-ctividades de la fase de planificacin y elaboracin. 2nforme preliminar de investigacin /specificaciones de requerimientos
'rototipos
"asos de uso% a. todos de alto nivel b. algunos esenciales e9pandidos
&iagramas de casos de uso
+odelo conceptual preliminar
Nlosario
&ependencias de los artefactos respecta a la fase de planeacin y elaboracin. 7.$ &RO/RAGA-IFN DE LOS -ASOS DE 0SO EN LOS -I-LOS DE DESARROLLO -ASOS DE 0SO DE LOS -I-LOS DE DESARROLLO 8os ciclos de desarrollo se organizan en torno a los requerimientos de los casos de uso. /n otras palabras, se asigna un ciclo para implementar uno o m s casos de uso o sus versiones simplificadas, cuando el caso ntegro resulta demasiado comple(o para abordarlo en un ciclo 0figura ;.11.
7.$.1
"iclo de desarrollo
"aso de uso -% >ersin simplificada
"iclo de desarrollo
"aso de uso -% versin ntegra
"iclo de desarrollo
"aso de uso <%
@@@@ @@@@ @@@@
@@@@ @@@@ @@@@
@@@@ @@@@ @@@@

"aso de uso "%
@@@@ @@@@ Figura 7.1 -signacin de los casos de uso a los ciclos de desarrollo. 7.$.$ -LASIFI-A-IFN DE LOS -ASOS DE 0SO
/s necesario clasificar los casos de uso, y los casos de alto rango han de tratarse al inicio de los ciclos de desarrollo. 8a estrategia general consiste en escoger primero los casos que influyen profundamente en la arquitectura b sica. He aqu algunas de las cualidades que aumenta la clasificacin de un caso% a. Tener una fuerte repercusin en el dise*o arquitectnicoJ por e(emplo, incorporar muchas clases a la capa del dominio o requerir servicios de persistencia. b. "on relativamente poco esfuerzo obtener informacin e ideas importantes sobre el dise*o. c. 2ncluir funciones riesgosas, urgentes o comple(as.
d. 4equerir una investigacin a fondo o tecnologa nueva y riesgosa. e. 4epresentar procesos primarios de la lnea de negocios. f. -poyar directamente el aumento de ingresos o la reduccin de costos /l esquema ta9onmico puede servirse de una clasificacin simple y poco rigurosa% alto@ mediano@ba(o. /l esquema tambi)n puede aplicar puntuaciones 0posiblemente incrementadas con ponderacin1, bas ndose en las cualidades que inciden en la clasificacinJ por e(emplo. -aso de uso "omprar productos y as sucesivamente a E , : c $ d H e E ! : Su'a 1<
7.%
-LASIFI-A-IFN DE LOS -ASOS DE 0SO EN LA A&LI-A-IFN AL &0NTO DE BENTA "on base en los criterios anteriores de clasificacin, a continuacin se incluye una clasificacin informal y poco rigurosa de los casos de uso de aplicacin al punto de venta. &e ninguna manera pretendemos dar una lista e9haustiva.
- asi!icaci*( -lto +ediano
-aso de uso "omprar productos 2ncorpora nuevos usuarios 4egistra los productos comprados 'aga los productos comprados 'agar 2niciar "errar
Jus"i!icaci*( "orresponde a los criterios de clasificacin m s altos. -fecta al subdominio de la seguridad. -fecta al subdominio de la seguridad. 'roceso importanteJ afecta la contabilidad. /fecto mnimo en la arquitectura. 8a definicin depende de otros casos de uso. /fecto mnimo en la arquitectura.
<a(o
7..
EL -ASO DE 0SO DE ARRANH0E
'r cticamente todos los sistemas cuentan con un #aso de uso de inicio o arran,ue. -unque tal vez no ocupe un nivel alto conforme a otros criterios, es preciso estudiar al menos una versin simplificada de )l, al principiar el ciclo de desarrollo, )ste se realiz incrementalmente para satisfacer las necesidades de arranque de otros casos. 3o vamos a presentar de manera e9plcita la programacin de los pasos de este caso de uso y supondremos que siempre se desarrolla en forma implcita como se necesita. 7.6 &RO/RAGA-IFN DE LOS -ASOS DE 0SO EN LA A&LI-A-IFN DEL &0NTO BENTA - partir de la clasificacin, el caso #omprar productos debera incluirse en el primer ciclo de desarrollo. "omo hemos visto, tambi)n puede abordarse una versin simple de Inicio para soportar los otros casos de uso. 7.6.1 -REA-IFN DE BERSIONES GILTI&LES DE LOS -ASOS DE 0SOS -OG&LEJOS
.iempre que se asigne un caso de uso, es necesario estimar si es posible resolverlo ntegramente en el lapso limitado de un ciclo 0cuatro semanas, por e(emplo1 o si el traba(o ha de ser distribuido en varios ciclos. /n este caso, #omprar productos es e9tremadamente comple(o y quiz requiere cinco o m s ciclos, suponiendo que cada uno tendr una duracin de cuatro semanas e9actamente. .e supone una estrategia de programacin de duraci*( o "ie'po !i1o, en la cual al ciclo de desarrollo se le establece un plazo fi(o. /n esta situacin el caso se redefine a partir de varias versiones de )l, que van abarcando requerimientos cada vez m s e9haustivos. "ada versin se limita a incluir lo que se estima una cantidad razonable de traba(o dentro de los confines de la duracin fi(a del ciclo 0digamos cuatro semanas1. 'or e(emplo% Y "omprar productos% versin 1 0pagos en efectivo, sin actualizaciones de inventario,Z1 Y "omprar productos% versin $ 0permitir cualquier tipo de pago1 Y "omprar productos% versin : 0versin completa, incluyendo entre otras cosas las actualizaciones del inventario,Z1 8as versiones anteriores se distribuyen despu)s a lo largo de una serie de ciclos de desarrollo, (unto con otros casos de uso.
7.6.$
ASI/NA-IFN DE LOS -ASOS DE 0SO
.i nos basamos en la clasificacin de los casos y de varias versiones de #omprar productos, podramos asignar algunos casos de uso al ciclo de desarrollo de la figura ;.$
"iclo de desarrollo 1 "omprar productos versin 1 @@@@ @@@@ @@@@
"iclo de desarrollo $ "omprar productos versin $ @@@@ @@@@ @@@@
"iclo de desarrollo: "omprar productos versin $ @@@@ @@@@ @@@@
"iclo de desarrollo D 4egistrar productos comprados @@@@ @@@@ @@@@ 'agar los productos comprados @@@@ @@@@ @@@@
Figura 7.$ -signacin de los casos de uso a los ciclos de desarrollo. 7.? BERSIONES DEL -ASO DE 0SO J-OG&RAR &ROD0-TOSK
6na vez que se ha decidido simplificar el caso y e9presarlo, hay que escribir versiones cada vez m s comple(as. Tambi)n hay que estipular las simplificaciones, las metas y las suposiciones de cada versin. 8as siguientes secciones ofrecen sugerencias valiosas al respecto. 7.?.1 BERSIFN 1 DE -OG&RAR &ROD0-TOS SIG&LIFI-A-IONES> GETAS Y S0&OSI-IONES L L L L L L L L L L 'agos /n efectivo e9clusivamente. .in mantenimiento de inventario. /s una tienda independiente, que no forma parte de una organizacin m s grande. "aptura manual del cdigo universal de producto 0"6'1J sin lector de cdigo de barras 3o se calculan los impuestos. .in cupones. /l ca(ero no tiene que registrar las ventasJ no se controla el acceso. 3o se lleva un registro de los clientes individuales ni de sus h bitos de compra. 3o se controla la ca(a de efectivo. /n el recibo aparecen el nombre y la direccin de la tienda, la fecha y la hora de la venta.
L 3i la identificacin del ca(ero ni la de T'&> aparecen en el recibo. L 8as ventas realizadas se registran en un documento histrico.
-aso de uso9 Ac"ores9 &rop*si"o9 Resu'e(9
Tipo Re!ere(cias -ru;adas9
-o'prar produc"os> )ersi*( 1 "liente 0iniciador1, ca(ero. "apturar una venta y su pago en efectivo. 6n "liente llega a la ca(a con productos que desea comprar. /l "a(ero registra los productos comprados y recibe el pago en efectivo. -l terminar la transaccin, el "liente se marcha con los productos. 'rimario y esencial. 7unciones% 41.1, 41.$, 41.:, 41.E, 41.;, 41.B, 4$.1
-urso (or'a de os e)e("os Acci*( de os ac"ores 1. /ste caso de uso comienza cuando un "liente llega a una ca(a de T'&> con productos que desea comprar. $. /l "a(ero registra el cdigo universal de producto 0"6'1 en cada producto. .i un producto se repite, el "a(ero tambi)n puede introducir la cantidad. .. -l terminar de capturar los productos, el "a(ero indica ala T'&> que ya concluy la captura. ?. /l "a(ero le indica al "liente el total. 7. /l "liente da un pago en efectivo Vel efectivo QofrecidoR@, posiblemente mayor que el total de la venta. <. /l "a(ero registra el efectivo recibido @. +uestra al "liente la diferencia. Nenera un recibo. 1A. /l "a(ero deposita el efectivo recibido y e9trae la diferencia. /l "a(ero entrega al "liente el cambio y 11. 4egistra la venta terminada. Respues"a de sis"e'a
%. &etermina el precio del producto y agrega la informacin correspondiente a la transaccin actual. 'resenta la descripcin y el precio del producto en cuestin. 6. "alcula el total de la venta y se lo presenta al "liente.
el recibo impreso. 1$. /l "liente se marcha con los productos comprados. 7.?.$ -OG&RAR &ROD0-TOS9 BERSIFN $
Si'p i!icacio(es> 'e"as + suposicio(es 8as simplificaciones de la versin 1 se aplican tambi)n a esta versin, salvo que el pago puede efectuarse en efectivo, con la tar(eta de cr)dito o con cheque. 8as dos segundas formas de pago requieren autorizacin . -aso de uso9 Ac"ores9 &rop*si"o9 Resu'e(9 -o'prar produc"os> )ersi*( $ "liente 0iniciador1, "a(ero. "apturar una venta y su pago. 6n "liente llega a la ca(a con productos que desea comprar. /l "a(ero registra los productos comprados y recibe un pago> que debe recibir autorizacin. -l terminar la transaccin, el "liente se marcha con los productos comprados, y as sucesivamente.
7.7
RES0GEN
Sa estamos para hacer la transicin a la fase de desarrollo iterativo. /n el primer ciclo nos serviremos del caso del uso #omprar productos% versin 9.
INI-IO DE 0N -I-LO DE DESARROLLO

OBJETIBOS Y 4esumir la transicin de la fase de planeacin y elaboracin de la construccin iterativa.
<.1 INI-IO DE 0N -I-LO DE DESARROLLO .uponga la fase de planeacin y elaboracin ha concluido y que los casos de uso han sido identificados, clasificados y programados, por lo menos en la primera pare(a de ciclos. .e presenta entonces una transicin muy importante% comienza la fase de construccin en la cual se cumplen los ciclos del desarrollo iterativo 0figura L.11. /n el primer ciclo se ha decidido e9aminar una versin simplificada de #omprar productos que incluye solamente los pagos en efectivo y no el control de inventario. 8as actividades iniciales del ciclo se relacionan con la administracin del proyecto. /n el caso general, viene despu)s 0o, m s probablemente, ocurre en paralelo1 una sincronizacin de la documentacin 0por e(emplo, los diagramas1 a partir del Iltimo ciclo con el estado real del cdigo, por que los artefactos de dise*o y los cdigos difieren invariablemente durante la fase de codificacin del ultimo ciclo.
/ntonces se inicia la fase de analizar 0o de an lisis1, en el cual se investigan a fondo los problemas del ciclo actual. /n esta fase, una de las primeras actividades consiste en desarrollar un modelo conceptual, tema que trataremos en el siguiente captulo.
"onstruccin
-plicacin
'erfeccionar el plan
.incronizacin de artefactos
-n lisis
&ise*o
"onstruccin
'rueba
Figura <.1 6n ciclo de desarrollo.
&ARTE III
FASE DE ANLISIS
215
-o(s"rucci*( de u( 'ode o co(cep"ua
O,1e"i)os
L 2dentificar los conceptos relacionados con los requerimientos del ciclo actual de desarrollo. L "rear un modelo conceptual preliminar. L &istinguir entre los atributos correctos y los incorrecto. L 2ncorporar conceptos de especificacin cuando convenga. L "omparar los t)rminos% conceptos, tipo, interfaz y clase. @.1 I("roducci*(
@.1 INTROD0--IFN 6n modelo conceptual e9plica 0a sus creadores1 los conceptos significativos en un dominio del problemaJ es el artefacto m s importante a crear durante el an lisis orientado a ob(etos 1. /n este captulo estudiaremos los conocimientos preliminares en la creacin de modelos conceptuales. /n los dos siguientes e9aminaremos m s detenidamente las
habilidades relacionadas con la construccin de modelos conceptuales% observar atentamente los atributos y las asociaciones. 1. 8os casos de uso son un importante artefacto del an lisis de requerimientos, pero realmente no est n orientados a objetos. 'onen de relieve la vista del dominio a partir de un proceso. "iclo de desarrollo a.@ si todava no se realiza 'erfecciona@ .incronizacin -n lisis "onstruccin 'rueba &ise*o b.@ actual miento del plan de artefactos c.@ opcional
1. &efinir los casos esenciales de usos E. &efinir los diagramas de secuencia de los sistemas
$. 'erfeccionar los diagramas de los casos de usos K. &efinir los contratos de operaciones
:. 'erfeccionar el modelo conceptual ;. &efinir los diagramas de estados
D. 'erfeccionar el glosario
-ctividades de la fase de an lisis dentro de un ciclo de desarrollo.

"asos de uso% @e9pandidos @esenciales &iagramas de casos de usos "aso de uso% @reales >entanas y reportes "asos de prueba
&iagramas de interaccin
+)todos
+odelo conceptual Nlosario &iagrama de secuencia del sistema &iagramas de clase de dise*o &iagramas de clase de dise*o &efiniciones de clase y de interfaz
"ontratos de operacin
&iagramas de estado
/squema de base de datos
.O8
&ependencias de los artefactos durante la fase de construccin. 2dentificar muchos ob(etos o conceptos constituye la esencia del an lisis orientado a ob(etos y al esfuerzo se compensa con los resultados concebidos durante la fase de dise*o e implementacin. 8a identificacin de conceptos forma parte de una investigacin del dominio del problema. /l lengua(e 6+8 contiene la notacin en diagrama la notacin de estructura est tica que e9plican gr ficamente los modelos conceptuales. 6na cualidad esencial que debe ofrecer un modelo conceptual es que representa cosas del mundo real, no componentes del soft,are.
@.$ A-TIBIDADES Y DE&ENDEN-IAS 6na de las primeras actividades centrales de un ciclo de desarrollo consiste en crear un modelo conceptual para los casos de uso del ciclo actual. /sto no puede hacerse si no cuentan con los casos y con otros documentos que permitan identificar los conceptos 0ob(etos1. 8a creacin no siempre es linealJ por e(emplo, el modelo conceptual puede formularse en paralelo con el desarrollo de los casos. @.% GODELOS -ON-E&T0ALES /l paso esencial de un an lisis o investigacin orientado a objetos es descomponer el problema en conceptos u ob(etos individuales% las cosas que sabemos. 6n 'ode o co(cep"ua es una representacin de conceptos en un dominio del problema A+5BE, ?o,lerBKC. /n el 6+8, lo ilustramos con un grupo de diagra'as de es"ruc"ura es"8"ica donde no se define ninguna operacin. 8a designacin de modelo conceptual ofrece la venta(a de subrayar fuertemente una concentracin en los conceptos del dominio, no en las entidades del soft,are. 'uede mostrarnos% Y "onceptos Y -sociaciones entre conceptos Y -tributos de conceptos 'or e(emplo, en la figura B.1 vemos un modelo conceptual parcial del dominio de la tienda y las ventas. /9plica gr ficamente que le concepto de 'ago y <enta son importantes en este
dominio del problema, que 'ago se relaciona con <enta en una forma que conviene se*alar y que venta tiene fecha y hora. 'or ahora no son importantes los detalles de la notacin.
"oncepto
>entas 8ineade'roductos cantidad
4egistra @ venta V de
'roducto
1 H.1 [
-lmacenada @en Tienda &ireccin 3ombre
-sociacin
"ontenida Ven
1Z[
1
>enta
-tributos
?echa Hora
1 1
1
-lo(a 1Z[
'agada@por
1
'ago +onto
"apturada @en
T'&>
Figura @.1 +odelo conceptual parcial. 8os nImeros en los e9tremos de la lnea indican multiplicidad, la cual se describe en el captulo subsecuente. @.%.1 -ONO-IGIENTO DE LA NOGEN-LAT0RA DEL DOGINIO -dem s de descomponer el espacio del problema en unidades comprensibles 0conceptos1, la creacin de un modelo conceptual contribuye a esclarecer la terminologa o nomenclatura del dominio. 'odemos verlo como un modelo que comunica 0a los interesados como pueden serlo los desarrolladores1 cuales son los t)rminos importantes y como se relacionan entre s. @.%.$ LOS GODELOS -ON-E&T0ALES NO SON GODELOS DE DISEO DE SOFTMARE 6n modelo conceptual, como se advierte en la figura B.$, es una descripcin del dominio de un problema real, no es una descripcin del dise*o del soft,are, como una clase de =ava o de "\\ 0figura B.:1. 'or ello los siguientes elementos no son adecuados en )l%
Y 8os artefactos de soft,are como una ventana o una base de datos, salvo que le domino a modelar se refiera a conceptos de soft,areJ por e(emplo, un modelo de interfaces gr ficas parar el usuario.
Y 8a responsabilidades o m)todos.011 >enta ?echa hora
"oncepto del mundo real, no una clase de soft,are
Figura @.$ 6n modelo conceptual muestra conceptos del mundo real. /vitar
<ase de datos >entas -rtefacto del soft,areJ no forma parte de un modelo conceptual
>enta
/vitar
?echa Hora 2mprimir 0 1
"lase de soft,areJ no forma parte de un modelo conceptual
Figura @.% 6n modelo conceptual no muestra los artefactos o clases del soft,are. @.%.% -ON-E&TOS /n t)rminos informales el concepto es una idea, cosa u ob(eto. /n un lengua(e m s formal podemos considerarlo a partir de sus smbolo, intencin 0$1 y e9tensin A+5BEC 0figura B.D1. Y S:',o o9 'alabras o im genes que representan un concepto. Y I("e(si*(9 8a definicin del concepto. Y E4"e(si*(9 /l con(unto de e(emplos al que se aplica el concepto. "onsideremos, por e(emplo, el concepto del evento de una transaccin de compra. 'odemos optar por designarlo con el smbolo <enta. 8a intencin de una <enta puede afirmar que Qrepresenta el evento de una transaccin de compra y tiene fecha y horaR. 8a e9tensin de <enta son todos los e(emplos de ventaJ en otra palabra el con(unto de todas las ventas.
011 8as responsabilidades normalmente se relacionan con entidades del soft,are y los m)todos siempre lo hacenJ pero el modelo conceptual describe conceptos reales, no entidades del soft,are. &urante la fase de diseo es muy importante tener en cuenta las responsabilidadesJ ya que no slo forman parte de este modelo. 0$1 2ntensin% en oposicin a e9tensin, designa el grado de cualidad.
>enta ?echa hora
smbolo del concepto
Quna venta representa el evento de una transaccin de compra. Tiene fecha y hora.R
intensin del concepto
>enta >enta 1 >enta : >enta D >enta $ e9tensin del concepto
Figura @.. /l concepto tiene un smbolo, intensin y e9tensin. "uando se crea un modelo conceptual, por lo regular la vista del smbolo y de la intensin de un concepto es el aspecto de mayor inter)s pr ctico.
@.%.. LOS GODELOS -ON-E&T0ALES Y LA DES-OG&OSI-IFN 8os problemas de soft,are a veces son comple(osJ la descomposicin Vdivide y vencer s@ es una estrategia que suele utilizarse para resolver la comple(idad dividiendo el espacio del problema en unidad comprensible. /n el a(8 isis es"ruc"urado la dimensin de la descomposicin se realiza mediante procesos o funciones. /n cambio, en el an lisis orientado a ob(etos, se lleva a cabo fundamentalmente con conceptos.
6na distincin fundamental entre el an lisis orientado a ob(etos y el an lisis estructurado% divisin por conceptos 0ob(eto1 y no por funciones. 'or tanto, una tarea primordial de la fase de an lisis consiste en identificar varios conceptos en el dominio del problema y documentar los resultados en un modelo conceptual. @.%.6 -ON-E&TOS EN EL DOGINIO DEL &0NTO DE BENTA 'or e(emplo, en el dominio del problema real de comprar productos en una tienda en una terminal de punto de venta 0T'&>1 intervienen los conceptos de Tienda, T'&> y una <enta. 'or tanto, nuestro modelo conceptual 0figura B.E1 puede incluir una Tienda) T'"< y una <enta. Tienda T'&> >enta
Figura @.6 +odelo conceptual parcial en el dominio de la tienda. @... Es"ra"egias para ide("i!icar os co(cep"os 3uestra meta es crear un modelo conceptual de conceptos interesantes o significativos del dominio en cuestin. /n este caso, ello significa conceptos relacionados con el caso de uso #omprar productos, versin 9. 8a tarea fundamental ser , pues, identificar los conceptosJ se proponen dos estrategias. 8a siguiente es una directriz de gran utilidad en la identificacin de conceptos% Es 'e1or e4agerar + especi!icar u( 'ode o co(cep"ua co( 'ucDos co(cep"os re!i(ados Eue (o especi!icar o ca,a 'e("e. 3o piense que un modelo conceptual es m s adecuado si tiene menos conceptosJ generalmente suele suceder lo contrario. /s frecuente omitir conceptos durante la fase inicial de identificacin y descubrirlos m s tarde cuando se e9aminen los atributos o asociaciones o durante la fase de dise*o. "uando se detecten, habr que incorporarlos al modelo conceptual. 3o se e9cluya un concepto simplemente porque los requerimientos no indiquen una necesidad evidente que permita recordar la informacin acerca de ella 0criterio comIn de la construccin de modelos de datos para dise*ar una base de datos relacional, pero no pertinente a la creacin de modelos conceptuales1 o porque el concepto carezca de atributos. /s perfectamente v lido tener conceptos sin atributos o conceptos con un papel puramente de comportamientos en el dominio en vez de un papel informacional.
@...1. O,"e(ci*( de co(cep"os a par"ir de u(a is"a de ca"egor:as de co(cep"os. 8a creacin de un modelo conceptual se comienza preparando una lista de conceptos idneos a partir de la siguiente lista. "ontiene muchas categoras comunes que vale la pena tener en cuenta, sin que importe el orden de importancia. 8os e(emplos se tomaron de los dominios de la tienda y de las reservaciones de lneas a)reas.
-a"egor:a de co(cep"o 5b(etos fsicos o tangibles T'&> -vin
E1e'p os
/specificaciones, dise*o o descripciones de cosas 8ugares
/specificacionde'roducto &escripcionde>uelo Tienda -eropuerto >enta, 'ago 4eservacin >entas8ineade'roducto
Transacciones
8nea o rengln de elemento de transacciones 'apel de las personas
"a(ero 'iloto Tienda, "esto -vion 'roducto
"ontenedores de otras cosas
"osas dentro de un contenedor
'asa(ero 5tros sistemas de cmputo o electromec nicos e9ternos al sistema "onceptos de nombres abstractos .istemade-utorizaciondeTar(etade"redito "ontroldeTrafico-ereo
Hambre -crofobia &epartamentode>entas 5b(eto8inea-erea >enta, 4obo, =unta >uelo, -ccidente, -terriza(e >enta6n'roducto 4eservacion-siento
5rganizaciones
/ventos
'rocesos 0a menudo no est n representados como conceptos, pero pueden estarlo1 4eglas y polticas
'oliticade4eembolso 'oliticade"ancelaciones "atalogode'roducto "atalogode'artes 4ecibo, +ayor, "ontratode/mpleo <itacorade+antenimiento
"at logos
4egistros de finanzas, de traba(o, de contratos de asuntos legales
2nstrumentos financieros
servicios 8ineade"redito /9istencia +anualde'ersonal +anualde4eparaciones
+anuales, libros
@...$ O,"e(ci*( de co(cep"os a par"ir de a ide("i!icaci*( de !rases (o'i(a es. 5tra t)cnica muy Itil 0por su simplicidad1 propuesta en A-bbotL:C consiste en identificar las frases nominales en las descripciones te9tuales del dominio de un problema y considerarlas conceptos o atributos idneos.
Es"e 'C"odo Da+ Eue u"i i;ar o co( 'ucDa prude(ciaN (o es posi, e e(co("rar 'ec8(ica'e("e correspo(de(cias e("re sus"a("i)o + co(cep"o> + ade'8s as pa a,ras de e(gua1e (a"ura so( a',iguas.
'ese a ello, esta t)cnica es fuente de inspiracin. 8os casos e9pandidos de uso son una e9celente descripcin que puede conseguirse con este an lisis. 'or e(emplo, puede usarse el caso de uso #omprar productos, versin 9.
Acci*( de os ac"ores 1. /ste caso de uso comienza cuando un - ie("e llega a una ca1a de T&DB con produc"os que desea comprar. $. /l -a1ero registra el c*digo u(i)ersa de produc"os 0"6'1
Respues"a de sis"e'a
%. &etermina el precio de produc"o y a la "ra(sacci*(
en cada produc"o. .i hay m s de un produc"o, el -a1ero puede introducir tambi)n la ca("idad.
de )e("as le agrega la informacin sobre el producto. .e muestran la descripci*( y el precio del produc"o actual.
-lgunas de las frases nominales anteriores son conceptos idneosJ algunas pueden ser atributos de conceptos. 'or favor, consulte el lector la seccin siguiente y el captulo dedicado a los atributos% en ellos encontrar sugerencias para distinguirlos. 6na debilidad de este enfoque es la imprecisin del lengua(e naturalJ varias frases nominales pueden designar el mismo concepto o atributo, entre otras ambig]edades que pueden presentarse. 'ese a ello, no dudamos en recomendar usarlo en combinacin con el m)todo de Lista de categor=a de conceptos.
@.6 -o(cep"os id*(eos para e do'i(io de pu("o de )e("a

- partir de la Lista de categor=a de conceptos y del an lisis de frases nominales generamos una lista de conceptos adecuados para incluirlos en la aplicacin del punto de venta. 8a lista est su(eta a la restriccin de los requerimientos y simplificaciones que se consideren en el momento% los casos simplificados de uso de #omprar productos) versin 9. T'"< 'roducto Tienda <enta 'ago +specificacionde'roduct o <entasLineade'roducto #ajero #liente -erente
#atalogode'roductos
@.6.1. O,1e"os de i(!or'e9 Ose i(c u+e e reci,o e( e 'ode oP /l recibo es un registro de una venta y de un pago, as como un concepto relativamente prominente en el dominio de ventasJ !debe, pues, mostrarse en el modelo# /n seguida se mencionan algunos factores que han de tenerse presentes% /l recibo es un informe de una venta. /n general, no conviene incluirlo en un modelo conceptual, ya que toda su informacin proviene de otras fuentes. ^ste es un buen motivo para e9cluirlo. /l recibo cumple un papel especial respecto a las reglas de la empresa% al portador le confiere el derecho de devolver los productos adquiridos. /sta es una razn para incorporarlo al modelo. /l recibo se e9cluir , porque las devoluciones de productos no se incluyen en este ciclo de desarrollo. .e (ustificar su inclusin durante el ciclo que aborde el caso "evolver productos. @.6.$. E 'ode o co(cep"ua de pu("o de )e("a 2s* o co(cep"os5 8a lista anterior de los nombres de conceptos puede representarse gr ficamente 0figura B.K1 en la notacin del diagrama de estructura est tica de 6+8, a fin de mostrar la g)nesis del modelo conceptual. T'&> >entas8inea de'roducto 'roducto "a(ero Tienda "liente >enta Nerente
'ago
"atalogode 'roductos
/specificacion de'roducto
Figura @.?. +odelo conceptual inicial del dominio del punto de venta.
/n captulos posteriores trataremos de los atributos y asociaciones del modelo conceptual.
@.?. Direc"rices para co(s"ruir 'ode os co(cep"ua es

@.?.1. -*'o co(s"ruir u( 'ode o co(cep"ua
-plique los siguientes pasos para crear un modelo conceptual% &ara co(s"ruir u( 'ode o co(cep"ua 9 1. Lis"e os co(cep"os id*(eos usa(do a %ista de cate(or4as de conceptos + a ide("i!icaci*( de a !rase (o'i(a re acio(adas co( os reEueri'ie("os e( cues"i*(. $. Di,Q1e os e( u( 'ode o co(cep"ua . %. I(corpore as asociacio(es (ecesarias para regis"rar as re acio(es para as cua es de,e reser)ar u( espacio e( a 'e'oria 2"e'a Eue se e4po(dr8 e( u( cap:"u o pos"erior5. .. Agregue os a"ri,u"os (ecesarios para cu'p ir co( as (ecesidades de i(!or'aci*( 2"e'a Eue se "ra"ar8 e( u( cap:"u o pos"erior5.
@.?.$. La asig(aci*( de (o',res + e 'ode ado de as cosas9 e car"*gra!o

8a estrategia del cartgrafo se aplica a los mapas y a los modelos conceptuales. &repare u( 'ode o co(cep"ua i(spir8(dose e( a 'e"odo og:a de car"*gra!o9 0"i ice os (o',res e4is"e("es e( e "erri"orio. E4c u+a as carac"er:s"icas irre e)a("es. No agregue cosas Eue (o e4is"a(.
/l modelo conceptual es una especie de mapa de conceptos o cosas de un dominio. /ste enfoque pone de relieve el papel analtico de un modelo conceptual y sugiere lo siguiente% 8os cartgrafos se sirven de nombres del territorio Vno cambian los nombres de ciudades en sus mapas@. /n el caso de un modelo conceptual, ello significa utilizar el vocabulario del dominio cuando se asignan nombres a los conceptos y a los atributos. 'or e(emplo, al desarrollar el modelo de una biblioteca, al cliente se le designar con los nombres que utilice el personal% <isitante) Lector, u otro seme(ante. 6n cartgrafo elimina cosas en el mapa en caso de que no las (uzgue pertinentes para el propsito que persigueJ as, no es necesario que muestre la topografa ni las poblaciones. &e modo an logo, un modelo conceptual puede e9cluir en el dominio del problema los conceptos que no se relacionen con los requerimientos. 'or e(emplo, podemos omitir 'luma y .olsade'apel en nuestro modelo conceptual 0con el con(unto actual de requerimientos1, por no tener una funcin importante que sea obvia. 6n cartgrafo no muestra cosas que no e9istanJ por e(emplo, una monta*a ine9istente. /n forma parecida, el modelo conceptual ha de e9cluir las cosas que no se encuentren en el dominio del problema en cuestin.
@.?.%. 0( error Eue se co'e"e !recue("e'e("e a ide("i!icar os co(cep"os

Tal vez el error m s frecuente cuando se crea un modelo conceptual es el de representar algo como atributo, cuando debi haber sido un concepto. 6na regla pr ctica para no caer en )l es%
Si e( e 'u(do rea (o co(sidera'os a gQ( co(cep"o R co'o u( (Q'ero o "e4"o> pro,a, e'e("e R sea u( co(cep"o + (o u( a"ri,u"o. 'or e(emplo, pongamos el caso del dominio de las reservaciones en lneas a)reas. !&ebera "estino ser un atributo de <uelo o un concepto aparte >eropuerto# >uelo OoSP &estino 3ombre >uelo -eropuerto
/n el mundo real, un aeropuerto de destino no se considera nImero ni te9to% es una cosa masiva que ocupa espacio. 'or tanto, -eropuerto debera ser un concepto. E( caso de duda> co()ier"a e a"ri,u"o e( u( co(cep"o i(depe(die("e.
@.7 So uci*( de os co(cep"os si'i ares9 co'paraci*( e("re T&DB + Regis"ro

-nta*o, mucho antes del advenimiento de las terminales instaladas en el punto de venta, una tienda llevaba un registro% un libro donde asentaba las ventas y los pagos. "on el tiempo fue automatizado en un registro mec nico de efectivo. Hoy esa terminal desempe*a el papel del registro 0figura B.;1
conceptos semejantes con distinto nombre
<91G A 2egistra [ Genta o?
2egistro A 2egistra [ Genta
Figura @.7. T'&> y registro son conceptos similares. 6n registro es una cosa que asienta las ventas y los pagos, pero tambi)n lo es la terminal instalada en el punto de ventas. 3o obstante, el t)rmino registro parece tener un significado m s abstracto y denota una implementacin menos orientada que T'&>. 'ues bien, !en el modelo conceptual deberamos utilizar el smbolo egistro en vez de T'"<# &ri'ero> u(a reg a pr8c"ica co(sis"e e( Eue u( 'ode o co(cep"ua (o es a,so u"a'e("e correc"o (i err*(eo> si(o de 'a+or o 'e(or u"i idadN es u(a Derra'ie("a de a co'u(icaci*(. "onforme al principio del cartgrafo, T'"< es un t)rmino usual en el territorio, por lo cual es un smbolo Itil desde el punto de vista del conocimiento y la comunicacin. egistro es atractivo y Itil, segIn la meta de crear modelos que representen abstracciones y que no dependan de la implementacin. 011 -mbas opciones tienen sus bondades. /n este caso de estudio hemos escogido T'"< de modo un tanto arbitrarioJ tambi)n pudimos haber escogido egistro.
@.<. -o(s"rucci*( de u( 'ode o de 'u(do irreal
-lgunos sistemas de soft,are est n destinados a dominios que presentan muy poca seme(anza con los dominios naturales o con los de las empresas, un e(emplo lo constituye el soft,are de las telecomunicaciones. Todava es posible crear un modelo conceptual en esos dominios, pero se requiere un alto grado de abstraccin y abandonar los dise*os comunes. 011 3tese que anta*o un registro era simplemente una implementacin posible de la manera de registrar ventas. "on el tiempo, su significado ha ido generaliz ndose. /numeramos algunos conceptos adecuados que se relacionan con un intercambio de telecomunicaciones% &ensaje) #one1in) "ilogo) uta) 'rotocolo.
@.@. Especi!icaci*( o descripci*( de co(cep"os

.uponga lo siguiente% 8a instancia de +lemento representa una entidad fsica de una tiendaJ puede ser incluso un nImero serial. 6n +lemento tiene una descripcin, precio y cdigo universal de producto, los cuales no est n registrados en ninguna otra parte. Todos los que traba(an en la tienda sufren amnesia. "ada vez que se vende un elemento fsico, en Qterreno del soft,areR se elimina una instancia del soft,are correspondiente a +lemento.
"on estas suposiciones, preguntamos% !qu) sucede en el siguiente escenario# /9iste gran demanda de una nueva hamburguesa% 5b(etoHamburguesa. 8a tienda vende todas sus e9istencias, lo cual significa que todas las instancias de +lemento de 5b(etoHamburguesa se cancelan en la memoria de la computadora. -hora bien, )sta es la esencia del problema% si alguien pregunta% Q!"u nto cuesta el 5b(etoHamburguesa#R, nadie podr contestarle porque la memoria de su precio se ane9 a las instancias inventariadas, que fueron elimin ndose conforme se vendan. 3tese asimismo que el modelo actual, si se implementa en el soft,are tal como se describe, posee datos duplicados y mane(a ineficientemente el espacio, porque la descripcin, el precio y el cdigo universal de producto se duplica en cada instancia de +lemento del mismo producto.
@.@.1. Necesidad de as especi!icacio(es
/l problema anterior demuestra la necesidad de un concepto de ob(etos que son especificaciones o descripciones de otras cosas. 'ara resolver el problema del +lemento lo que se necesita es una +specificacionde'roducto 0o +specificacionde+lemento) "escripcionde'roducto, Z1 concepto que registra la informacin sobre los elementos. 6na +specificacionde'roducto no representa un +lemento, sino una descripcin acerca de ellos. 3tese que, aunque todos los elementos inventariados se vendan y se eliminen sus instancias correspondientes de soft,are, se conserva la +specificacionde'roducto. 8a descripcin o especificacin de ob(etos se relacionan bastante con aquella que describen. /n un modelo conceptual, se acostumbra estipular que una +specificacion? describe una ?.
Producto descripcion precio numero de serie $69
Ga
Es pecificacionde9roducto descripcion precio $69 A
1escribe [
9roducto num ero de serie
Bie(
Figura @.<. /specificaciones de otras cosas. /l signo Q[R significa una multiplicidad de QmuchosR. 2ndica que una +specificacionde'roducto puede describir muchos 0[1 'roductos. 8a necesidad de especificar los conceptos es frecuente en los dominios de ventas y productos. Tambi)n lo es en la manufactura, donde se requiere una descripcin de lo manufacturado que se distingue de la cosa manufacturada. /l tiempo y el espacio han sido incluidos al e9plicar la causa de la especificacin de conceptos, por ser muy comunesJ no se trata de un concepto poco usual de la construccin de modelos.
@.@.$. O-u8(do se reEuiere especi!icar os co(cep"osP

8as siguientes directrices indican cu ndo emplear las especificaciones.
I(corpore u(a especi!icaci*( o ,specificacionde5rod#cto6 cua(do9
descripci*(
de
co(cep"os
2por
e1e'p o>
La e i'i(aci*( de as i(s"a(cias de as cosas Eue descri,e( ,le ento> por e1e'p o> da por resu "ado u(a pCrdida de a i(!or'aci*( Eue Da de co(ser)arse> de,ido a a asociaci*( i(correc"a de a i(!or'aci*( co( o e i'i(ado.
Reduce i(!or'aci*( redu(da("e o dup icada.
@.@.%. O"ro e1e'p o de especi!icaci*(

He aqu un Iltimo e(emplo% imagine que una compa*a a)rea sufre el accidente fatal de uno de sus aviones. .uponga que todos los vuelos quedan cancelados por seis meses, mientras se lleva a cabo la investigacin. .uponga adem s que, cuando se cancelan los vuelos, sus correspondientes ob(etos de soft,are <uelo se eliminan en la memoria de la computadora. -s, todos los ob(etos <uelo se eliminan en la memoria de la computadora. -s, todos los ob(etos <uelo quedan eliminados tras el accidente. .i el Inico registro del aeropuerto al cual se dirige un vuelo est en las instancias <uelo, que representan vuelos especficos en determinado da y hora, ya no habr un registro de qu) rutas tiene la lnea a)rea. 'ara resolver este problema, se requiere una "escripcionde<uelo 0o +specificacionde<uelo1 que describa un vuelo y su ruta, aun cuando no est) programado un vuelo determinado 0figura B.B1.
Vuelo fecha numero [ hora Guela.a A 8eropuerto nom bre
Ga
Guelo fecha hora [
1escrito .por A
1escripciondeGuelo numero [ 1escribe.'uelos.a A 8eropuerto nombre
Bie(
Figura /specificaciones de otros elementos.
@.@.
@.1A De!i(ici*( de "Cr'i(os e( e e(gua1e 0GL

/n 6+8, se emplean los t)rminos QclaseR y QtipoR, no as QconceptoR. 3o e9iste consenso un nime respecto al significado de clase y tipoJ as que para evitar ambig]edades el 6+8 define rigurosamente ambos t)rminos tal como se utilizan en su metamodelo 0el modelo de 6+81, aunque otros autores y profesionales usan definiciones alternas y antagnicas.
"ualquiera que sea la definicin, lo importante es su utilidad para distinguir entre la perspectiva de un analista de dominios que observa conceptos reales, como venta, y los dise*adores de soft,are que especifican entidades de programasJ por e(emplo, la clase <enta en =ava. /l 6+8 sirve, entre otras cosas, para e9plicar concretamente las perspectivas de notacin y terminologa muy afinesJ de ah la importancia de tener presente qu) perspectiva va a adoptarse 0un an lisis, un dise*o o una vista de la implementacin1.
&ara si'p i!icar (ues"ra e4posici*(> e( es"e i,ro co( e "Cr'i(o Jco(cep"oK desig(are'os cosas de 'u(do rea + co( e de Jc aseK> as especi!icacio(es e i'p e'e("acio(es de so!"#are.
8a definicin de c ase en 6+8 es Quna descripcin de un con(unto de ob(etos que comparten los mismos atributos, operaciones, m)todos, relaciones y sem nticaR A<=4B;C. -lgunos autores limitan la definicin de clase a una implementacin concreta de soft,are, digamos una clase en =ava A?o,lerBKC. 'ero, en el 6+8, este vocablo tiene una acepcin m s general% abarca especificaciones que anteceden a la implementacin. /n ese lengua(e, a una clase implementada de soft,are se le llama m s concretamente c ase de i'p e'e("aci*(. /n 6+8, una operaci*( es Qun servicio que puede solicitarse a un ob(eto para que realice un comportamientoR A<=4B;C, y 'C"odo es la implementacin de una operacin que especifica el algoritmo o procedimiento de esta Iltima. 8a definicin de "ipo en 6+8 se aseme(a a la de clase Vdescribe un con(unto de ob(etos parecidos con atributos y operaciones@, pero no puede incluir m)todos. &e ello se deduce que un tipo es una especificacin de una entidad de soft,are y no una implementacin. /llo significa tambi)n que un tipo de 6+8 es independiente del lengua(e. -unque no sea estrictamente e9acto dentro del conte9to del lengua(e 6+8, este libro a veces utiliza los vocablos QconceptoR y QtipoR indistintamente, porque en el uso coloquial el vocablo QtipoR a menudo se define como sinnimo de un concepto del mundo real A+5BEC. /l t)rmino i("er!a; se define como un con(unto de operaciones visibles en el e9terior. /n el 6+8, puede estar asociada a tipos y clases 0y tambi)n a paquetes que agrupan elementos1. -unque los conceptos reales pueden tener una interfaz 0la de un tel)fono, por e(emplo1, el t)rmino suele emplearse dentro del conte9to de una interfaz para entidades de soft,are, como la interfaz unnable de =ava.
@.11 Gode os &a"r*(

/l modelo "onceptual se compone de diagramas est ticos de estructura 6+8 que ilustran conceptos en el dominio, como se muestra en la figura B.1H.
+odelo de ?igura K.B -n lisis
+odelo de casos de uso del an lisis b
+odelo conceptual
+odelo del comportamiento del sistema b
+odelo de estado del an lisis b
"asos de 6so% @de alto nivel @esenciales &iagramas de casos de uso
&iagramas de estructura est tica para los conceptos del dominio
&iagramas de secuencia del sistema
&iagramas de /stado para conceptos y casos de uso
"ontratos para operaciones del sistema
a. modelo est tico ,. modelo din mico
Figura @.1A /l modelo de an lisis
1H
Gode o co(cep"ua 9 A/RE/A-IFN DE LAS ASO-IA-IONES

O,1e"i)os
2dentificar las asociaciones de un modelo conceptual. &istinguir entre las asociaciones que es necesario conocer y las que se requieren slo para la comprensin.
1A.1 I("roducci*(
/s necesario identificar las asociaciones de los conceptos que se requieren para satisfacer los requerimientos de informacin de los casos de uso en cuestin y los que contribuyen a entender el modelo conceptual. /n el presente captulo e9aminaremos la identificacin de las asociaciones adecuadas y las incorporaremos al modelo conceptual del sistema del punto de venta.
1A.$ Asociacio(es
8a asociaci*( es una relacin entre dos conceptos que indica alguna cone9in significativa e interesante entre ellos 0figura 1H.11.
asociacion
2egistra TPDV
Figura 1A.1 -sociaciones
Genta actual
/n el lengua(e 6+8 se describen como Qrelaciones estructurales entre los ob(etos de diversos tiposR.
1A.$.1-ri"erios de as asociacio(es Q"i es

8as asociaciones que vale la pena mencionar suelen incluir el conocimiento de una relacin que ha de preservarse durante algIn tiempo% puede tratarse de milisegundos o a*os segIn el conte9to. /n otras palabras, !entre qu) ob(etos hemos de tener algIn recuerdo de una relacin# 'or e(emplo, !debemos recordar cu les instancias de <entasLineade'roducto est n asociadas a la instancia <enta# "laro que s, porque de lo contrario no sera posible reconstruir la venta, imprimir el recibo ni calcular el total de la venta. E4a'i(e a co()e(ie(cia de i(c uir as siguie("es asociacio(es e( u( 'ode o co(cep"ua 9 Las asociacio(es e( Eue e co(oci'ie("o de a re aci*( Da de ser preser)ado dura("e a gQ( "ie'po 2asociacio(es Eue Jde,e( co(ocerseK5. Las asociacio(es pro)e(ie("es de a %ista de asociaciones co #nes.
/n cambio, !necesitamos recordar una relacin entre una <enta actual y un -erente# 8a respuesta es negativa% los requerimientos no indican que haga falta ese tipo de relacin. Tal vez no sea incorrecto mostrar una relacin entre una <enta y -erente, pero no es indispensable ni Itil dentro del conte9to de nuestros requerimientos.
1A.%TNo"aci*( de as asociacio(es e( e 0GL

6na asociacin se representa como una lnea entre conceptos con el nombre de la asociacin. ^sta es intrnsecamente bidireccional, o sea es posible un ne9o lgico entre los ob(etos de un tipo y los del otro. /ste vnculo es totalmente abstractoJ no es una afirmacin sobre las cone9iones entre las entidades del soft,are.
.Jflecha de direcci#n de la lecturaJ .no tiene otro significado que el de indicar la direcci#n en que debe leerse el nom bre de la asociaci#n .a menudo se e4cluye
TPDV A
2egistra Z A
Genta actual
nombre de la asociaci#n
multiplicidad
Figura 1A.$ 3otacin de las asociaciones en el lengua(e 6+8. 8os e9tremos de una asociacin pueden contener una e9presin de multiplicidad que indique la relacin num)rica entre las instancias de los conceptos. 6na flecha opcional de la direccin de la lectura 0o Qflecha de la direccin del nombreR1 indica la direccin en que debe leerse el nombre de la asociacinJ no denota la direccin de visibilidad o de navegacin. /n su ausencia, por convencin la asociacin se lee de izquierda a derecha o de arriba hacia aba(o, aunque el 6+8 no hace esto una regla 0figura 1H.$1.
La ! ecDa de direcci*( de a ec"ura (o "ie(e u( )a or se'8("icoN "a( s* o es u(a a+uda para eer e diagra'a.
1A.. Ide("i!icaci*( de as asociacio(es9 is"a de asociacio(es co'u(es

"omience a agregar las asociaciones utilizando la lista ane9a. "ontiene categoras comunes que normalmente vale la pena incluir. 8os e(emplos est n tomados de los dominios de la tienda y de la reservacin de las lneas a)reas.
"ategora - es una parte fsica de <
/(emplos "a(a@T'&> -la@-vin >entas8ineade'roducto@>enta Tramode>uelo@4utade>uelo T'&>@Tienda, 'roducto@/stante 'asa(ero@-vion &escripcionde'roducto@"atalogo >uelo@'rogramade>uelo &escripcionde'roducto@'roducto &escripcionde>uelo@>uelo
- es una parte lgica de <
- est fsicamente contenido en <
- est contenido lgicamente en <
- es una descripcin de <
- es un elemento de lnea en una >entas8ineade'roducto@>enta transaccin o reporte de < Traba(ode+antenimiento@ +antenimiento - se conoceXintroduceXregistraX presentaXcaptura en < >enta@T'&> 4eservacin@8istade'asa(eros
- es miembro de <
"a(ero@Tienda 'iloto@-vion
- es una subunidad organizacional de &epartamento@Tienda < +antenimiento@8inea-erea - usa o dirige a < "a(ero@T'&> 'iloto@-vion "liente@"a(ero -gentede4eservaciones@'asa(ero 'ago@>enta 'asa(ero@<oleto
- se comunica con <
- se relaciona con una transaccin <
- es una transaccin relacionada con 'ago@>enta otra transaccin < 4eservacin@"ancelacion - est contiguo a < T'&>@T'&> "iudad@"iudad T'&>@Tienda -vion@8inea aerea
- es propiedad de <
1A...1 Asociacio(es de a "a prioridad

- continuacin se enumeran algunas categoras de alta prioridad que siempre conviene incluir en un modelo conceptual%
- es una parte f=sica o lgica de <. - est f=sica o lgicamente contenido en <. - est registrado en <.
1A.6 OHuC grado de de"a e de,er:a( "e(er as asociacio(esP

8as asociaciones son importantes, pero una falla habitual al crear modelos conceptuales es el e9cesivo tiempo que, durante la investigacin, se dedica al intento de descubrirlas. /s indispensable convencerse de lo siguiente%
Es 'ucDo '8s i'por"a("e ide("i!icar os conceptos Eue as asociacio(es. E "ie'po co(sagrado a a creaci*( de 'ode o co(cep"ua de,er:a des"i(arse a ide("i!icar os co(cep"os> (o as asociacio(es .
1A.? Direc"rices de as asociacio(es

Direc"rices de as asociacio(es9 -o(ce("rarse e( as asociacio(es e( Eue e co(oci'ie("o de a re aci*( Da de preser)arse dura("e a gQ( "ie'po 2asociacio(es Eue Jes (ecesario co(ocerK5. Es '8s i'por"a("e ide("i!icar os conceptos Eue as asociacio(es. GucDas asociacio(es "ie(de( a co(!u(dir e 'ode o co(cep"ua e( )e; de ac arar o. A )eces se reEuiere 'ucDo "ie'po para descu,rir as> + os ,e(e!icios so( escasos. No i(c uir as asociacio(es redu(da("es (i as deri)a, es.
1A.7 &ape es
- los e9tremos de una asociacin se les llama pape es. ^stos pueden tener% nombre e9presin de multiplicidad navegabilidad
/n este momento se investiga la multiplicidad, pero las dos caractersticas restantes se estudiar n en captulos posteriores.
1A.7.1 Gu "ip icidad

8a 'u "ip icidad define cu ntas instancias de un tipo - pueden asociarse a una instancia del tipo < en determinado momento 0figura 1H.:1.
Tienda A
8lmacena [
9roducto
multiplicidad del papel
Figura 1A.% +ultiplicidad en una asociacin 'or e(emplo, una instancia individual de una Tienda puede asociarse a QmuchasR instancias 0cero o m s marcadas con [1 de 'roducto. /n la figura 1H.D se ofrecen algunos e(emplos de las e9presiones de multiplicad.
[ T cero o ms: JmuchosJ
A.. [
<
uno o ms
A..IT
<
de uno a cuarenta
<
e4actamente K
E! K! O
<
e4actamente tres! cinco u ocho
Figura 1A.. >alores de la multiplicidad. /n el 6+8, el valor de la multiplicidad depende del conte9to. 4umbaugh A4umbaughB1C da un e9celente e(emplo de 'ersona y #ompa=a en la asociacin Trabaja@para. &el conte9to del modelo depender indicar si una instancia de 'ersona se aplica a una o varias instancias de #ompa=aJ al departamento de impuestos le interesan muc8asJ a un sindicato probablemente le interese slo una. 1A.< Asig(aci*( de (o',re a as asociacio(es
Se asig(a (o',re a u(a asociaci*( ,as8(dose e( e !or'a"o No',redeTipo3 FraseNo'i(a 3No',redeTipo> do(de a !rase (o'i(a ge(era u(a secue(cia Eue es egi, e + sig(i!ica"i)a de("ro de co("e4"o de 'ode o.
8os nombres de las asociaciones comienzan con una mayIscula. 6na frase nominal debe construirse con guiones. /n la figura 1H.E, la direccin por omisin en que debe leerse el nombre de una asociacin es de izquierda a derecha o de arriba hacia aba(o. 3o es as en la direccin por omisin de 6+8, aunque se trata de una convencin relativamente usual.
Tienda A $ontiene A..[ <91G A
'agada@por
$aptura A..[ Genta
'ago
3inea aerea A Emplea A..[ 9ers ona A [ A 8signada.a [ Y 8signado.a [ A
Guelo
8'ion
(uper'is a
Figura 1A.6 3ombres de las asociaciones.
1A.@ Asociacio(es 'Q "ip es e("re dos "ipos

&os tipos pueden tener varias asociaciones entre ellosJ esto sucede con frecuencia. 3o hay un e(emplo sobresaliente en nuestro sistema T'&>, pero en el dominio de la lnea a)rea encontramos uno en las relaciones entre >uelo y -eropuerto 0figura 1H.K1. 8as asociaciones volar@hacia y volar@de son relaciones netamente diferentes que han de mostrarse por separado. -dvi)rtase asimismo que _no se garantiza que todos los vuelos aterricen en un aeropuerto`
Vuelo
[ [
Guela.a
T..A A
8eropuerto
Guela.de
Figura 1A.? -sociaciones mIltiples
1A.1A Asociacio(es e i'p e'e("aci*(

&urante la fase de an lisis, una asociacin no es una proposicin sobre los flu(os de datos, variables de instancia ni cone9iones de ob(etos en una solucin de soft,areJ es una proposicin de que una relacin es significativa en un sentido puramente analticoJ en el mundo real. /n la pr ctica, muchas de estas relaciones suelen implementarse en los programas como trayectorias de navegacin y visibilidadJ pero su presencia en una vista investigadora o analtica de un modo conceptual no requiere la implementacin.
"uando se crea un modelo conceptual, podemos definir asociaciones que no se necesitan en la construccin. S a la inversa% podemos descubrir asociaciones que han de ser implementadas pero que se omitieron durante la fase de an lisis. /n tal caso, habra que actualizar el modelo para que incluyan esos descubrimientos. + s adelante e9plicaremos las formas de implementar las asociaciones en un lengua(e de programacin orientado a ob(etos 0lo usual es servirse de un atributo que apunte a una instancia de la clase asociada1, pero por ahora conviene verlas como meras e9presiones analticas, no como proposiciones acerca de una solucin de base de datos ni de soft,are. "omo de costumbre, posponemos las consideraciones de dise*o y as nos liberamos de informacin y decisiones prematuras en el modelo de an lisis, a la vez que aumentamos al m 9imo nuestras opciones para despu)s.
1A.11 Asociacio(es de do'i(io de pu("o de )e("a

-hora podemos agregar asociaciones a nuestro modelo conceptual del sistema del punto de venta. &eberamos incorporar las que indican los requerimientos 0los casos de uso, por e(emplo1, las que conllevan la necesidad de recordar o que de alguna otra manera nos sugiere nuestra percepcin del dominio del problema. "uando acometamos un nuevo problema, hay que repasar y estudiar las categoras comunes de las asociaciones mencionadas en p ginas anteriores, pues representan muchas de las asociaciones pertinentes que generalmente es preciso registrar.
1A.11.1 Re acio(es i(o )ida, es e( a "ie(da

8a siguiente muestra de asociaciones se (ustifica por la necesidad de conocerlas. .e funda en los casos de uso que hemos venido e9aminando. T'"< #aptura <enta <enta pagada en efectivo 'ara conocer la venta actual genera un total, e imprime un recibo. 'ara saber si se pag la venta, relaciona la cantidad ofrecida con el total de la venta e imprime un recibo. 'ara recuperar una /specificacionde'roducto, con un cdigo universal de producto.
#atalogode'roductos registra +specificacionde'roducto
1A.11.$ Ap icaci*( de a ca"egor:a de a is"a de co'pro,aci*( de as asociacio(es 4ecorreremos la lista de comprobacin, bas ndonos en los tipos anteriormente identificados y teniendo presentes los requerimientos actuales del caso de uso.
-a"egor:a - es una parte fsica de < - es una parte lgica de < - est fsicamente contenido en <
Sis"e'a T&DB No aplicable <entasLineade'roducto@<enta T'"<@Tienda 'roducto@Tienda +specificacionde'roducto@ #atalogode'roductos #atalogode'roductos@Tienda +specificacionde'roducto@'roducto
- est contenido lgicamente en <
- es una descripcin de <
- es una lnea de una transaccin o <entasLineade'roducto@<enta reporte de < - se introduceXregistraX presentaXcaptura en < - es miembro de < <entasAterminadasB@Tienda <entaAactualB@T'"< #ajero@Tienda
- es una subunidad organizacional No aplicable de < - usa o dirige a < #ajero@T'"< -erente@T'"< -erente@#ajero) pero probablemente no aplicable #liente@#ajero #liente@'ago #ajero@'ago
- se comunica con < - se relaciona con una transaccin <
- es una transaccin relacionada con 'ago@<enta otra transaccin < - sigue a < T'"<@T'"<) pero probablemente no aplicable T'"<@Tienda
- es propiedad de <
1A.1$ Gode o co(cep"ua de pu("o de )e("a

/l modelo conceptual de la figura 1H.; muestra un con(unto de conceptos y asociaciones idneos para nuestra aplicacin al punto de venta. 8as asociaciones se tomaron principalmente de la lista de comprobacin de asociaciones adecuada.
1A.1$.1 OSe co(ser)a( s* o as asociacio(es Eue de,e( co(ocerseP
/l con(unto de asociaciones que se incluye en el modelo conceptual de la figura 1H.; se obtuvo de manera bastante mec nica a partir de la lista de comprobacin. 'ero tal vez hay que ser m s selectivos con las asociaciones que contendr nuestro modelo conceptual. &esde el punto de vista de la comunicacin, no conviene saturar el modelo con asociaciones que no sean indispensables y que no me(oren nuestro conocimiento. /l e9ceso de ellas no aclara, sino que oscurece la situacin. "omo se*alamos con anterioridad, recomendamos los siguientes criterios para presentar las asociaciones% -o(ce("rarse e( as asociacio(es e( Eue e co(oci'ie("o de a re aci*( Da de ser preser)ado dura("e a gQ( "ie'po 2asociacio(es JEue de,e( co(ocerseK5. No i(c uir as asociacio(es redu(da("es (i as deri)a, es. 2egistra.'enta.de 1escritas.por A $atalogode9roductos A 6sado.por T..[ $ontiene 1escribe A Especificacion de los 9rod A..[ A
[ [ [ 8lmacena 9roducto Gentas3ineade9roductos <ienda A A A [ A A..[ $apturas 8loja terminadas $ontenidas.en A A..[ 9agado.por A Genta [ @nciado.por ?erente <91G A $apturadas.en A A A A A A Y 2egistra.'entas.en @niciado.por A 9ago A $liente A @niciada.por A $ajero
Figura 1A.7 +odelo conceptual aplicado al punto de venta.
"onforme a nuestra recomendacin, no son indispensables todas las asociaciones que se muestran en cierto momento. /studie detenidamente la tabla ane9a% Asociaci*( <enta capturada@por #ajero E4p icaci*( 8os requerimientos no indican la necesidad de conocer ni de registrar al ca(ero actual. -dem s, es derivable si e9iste la asociacin T'"< Usado@por #ajero 8os requerimientos no indican la necesidad de conocer ni de registrar al ca(ero actual 8os requerimientos no indican la necesidad de conocer ni de registrar al gerente que inici un T'&> 8os requerimientos no indican la necesidad de conocer ni de registrar al "liente actual que inici una venta. 8os requerimientos no indican la necesidad de conocer o mantener la informacin del inventario. 8os requerimientos no indican la necesidad de mantener la informacin de inventario.
T'"< Usado@por cajero
T'"< Iniciado@por -erente
<enta Iniciada@por #liente
Tienda >lmacena 'roducto
<entasLineade'roducto 'roducto
egistra@venta@de@
3tese que la capacidad de (ustificar una asociacin atendiendo a la necesidad de conocerla depende de los requerimientosJ un cambio de ellos Vpor e(emplo, e9igir que la identificacin del ca(ero aparezca en un recibo@ altera la necesidad de recordar una relacin. - partir del an lisis anterior, tal vez se (ustifique suprimir las asociaciones en cuestin.
1A.1$.$ Las asociacio(es Eue (ecesi"a( co(ocerse + as Eue !aci i"a( a co'pre(si*(
6n criterio estricto de la necesidad de conocer aplicado a la conservacin de asociaciones dar origen a un Qmodelo mnimo de informacinR sobre lo que se requiere para construir un modelo del dominio del problema, modelo que estar acotado por los requerimientos en cuestin. 'ero este procedimiento puede producir un modelo que no facilite 0ni a los dise*adores ni a terceros1 la comprensin cabal del dominio. -lgunas veces vemos el modelo conceptual no como un modelo riguroso de informacin, sino como una herramienta de la comunicacin, con la cual intentamos entender los conceptos importantes y sus relaciones. &esde esta perspectiva, eliminar algunas asociaciones que no reclamen estrictamente el criterio de la necesidad de conocer puede originar un modelo inadecuado% no comunica las ideas ni las relaciones m s importantes. /sto lo vemos, por e(emplo, en la aplicacin al punto de venta% aunque conforme al criterio estricto de la necesidad de conocer, quiz no sea preciso registrar >enta 2niciada@por "liente, su ausencia omite un aspecto importante para comprender el dominio% el hecho de que un cliente genera ventas. /n lo tocante a las asociaciones, un buen modelo ocupa un punto intermedio de un modelo basado en la necesidad mnima de conocimiento y otro que contenga todas las relaciones posibles. !"u l es el criterio b sico para (uzgar su valor# 6no podra ser% !cumple con todos los requerimientos de la necesidad de conocer y adem s comunica claramente una comprensin esencial de los conceptos importantes en el dominio del problema#
E(!a"ice as asociacio(es Eue de,e( co(ocerse> pero i(corpore "a',iC( as opcio(a es Eue se reEuiere( s* o para a co'pre(si*(> co( e !i( de e(riEuecer e co(oci'ie("o ,8sico de do'i(io.
11
GODELO -ON-E&T0AL9
A/RE/A-IFN DE LOS ATRIB0TOS
O,1e"i)os
2dentificar los atributos en un modelo conceptual. &istinguir entre atributos correctos e incorrectos.
11.1 I("roducci*(
/s necesario identificar los atributos de los conceptos que se necesitan para satisfacer los requerimientos de informacin de los casos de uso en cuestin. /n este captulo e9aminaremos la identificacin de los atributos idneos y le agregaremos atributos al modelo conceptual del dominio, que hemos aplicado al punto de venta. RecuCrdese Eue e 'ode o co(cep"ua es u(a represe("aci*( de cosas rea es> (o de co'po(e("es so!"#are. -ua Euier a!ir'aci*( co(cer(ie("e a os a"ri,u"os Da de i("erpre"arse de("ro de co("e4"o de e("idades de 'u(do rea .
11.$ A"ri,u"os
6n a"ri,u"o es un valor lgico de un dato de un ob(eto. I(c u+a os siguie("es a"ri,u"os e( u( 'ode o co(cep"ua 9 AEue os e( Eue os reEueri'ie("os 2por e1e'p o> os casos de uso5 i(dica( o co( e)a( a (ecesidad de recordar i(!or'aci*(. 'or e(emplo, un recibo de ventas normalmente incluye la fecha y la hora. /n consecuencia, el concepto <enta requiere los atributos fec8a y 8ora.
11.$ No"aci*( de os a"ri,u"os e( e 0GL

8os atributos se muestran en la segunda seccin de la seccin de conceptos 0?igura 11.11. /s opcional indicar su tipo.
Genta fecha =orade@nicio 5 =ora atributos
Figura 11.1 "oncepto y atributos
11.. Tipos de a"ri,u"os )8 idos

Hay algunas cosas que no deberan representarse como atributos, sino m s bien como asociaciones. /n esta seccin trataremos de los atributos v lidos.
11...1 -o(ser)e si'p es os a"ri,u"os

8os tipos m s simples de atributos son los que, en la pr ctica, suelen considerarse los tipos primitivos de datos. 'or lo regular el tipo de un atributo no debera ser un concepto comple(o del dominio, como <enta o >eropuerto. 'or e(emplo, el siguiente atributo actual de T'"< en el tipo #ajero de la figura 11.$ no es idneo porque con su tipo se indica una T'"<, que no es un tipo de atributo simple 0digamos N*mero o #adena1. 8a forma m s conveniente de e9presar que un #ajero utiliza una T'"< es recurrir a una asociacin, no a un atributo.
/n un modelo conceptual, es preferible que los atributos sean a"ri,u"os si'p es o )a ores puros de da"os. /ntre los tipos comunes de atributos simples m s frecuentes se cuentan% <ooleano, ?echa, 3umero, "adena 0Te9to1, Hora He aqu otros tipos comunes% &ireccin, "olor, Neometra 0'unto, 4ectangulo, Z1, 3umero telefonico, 3umero del .eguro .ocial, "odigo 6niversal de 'roducto 0"6'1, .a6, "' o codigos postales, tipos enumerados.
Cajero
no atributo JsimpleJ
Ga
nom bre <91Gactual
Bie(
Cajero nombre
6sa
<91G numero
Figura 11.$ 4elacione con asociaciones, no con atributos
Ga
Guelo destino
destino es un concepto complejo
Bie(
V uelo A
Guela.a A
8eropuerto
Figura 11.% 3o represente como atributos los conceptos comple(os de dominioJ use asociaciones. 4epetiremos un e(emplo anterior% una confusin frecuente consiste en modelar como atributo un concepto comple(o del dominio. -s, un aeropuerto de destino no es una cadena de caracteres en realidad% es una realidad comple(a que ocupa muchos Gilmetros cuadrados de espacio. 'or tanto, deberamos relacionar <uelo con >eropuerto a trav)s de una asociacin y no con un atributo, como se indica en la figura 11.: Re acio(e co(cep"os co( u(a asociaci*(> (o co( u( a"ri,u"o
11...$ -o'paraci*( e("re a(8 isis + dise=o9 OEuC decir de os a"ri,u"os e( c*digoP
8a restriccin de que los atributos del modelo conceptual sean Inicamente tipos de datos simples no significa que los de "\\, =ava o .malltalG 0miembros de datos, variables de instancias1 deban ser slo de tipos primitivos de datos simples. /l modelo conceptual se centra en afirmaciones analticas puras sobre un dominio del problema, no en entidades de soft,are. + s adelante, durante las fases del dise*o y construccin, veremos que las asociaciones entre los ob(etos e9presados en el modelo conceptual a menudo se implementar n como atributos que apuntan a otros tipos comple(os. 'ero )sta no es m s que una de muchas posibles soluciones de dise*o para implementar una asociacinJ por tanto, la decisin habr de aplazarse durante la fase de an lisis. 8a etapa de an lisis no es el momento de tomar prematuramente decisiones concernientes al dise*o.
11...% Ba ores puros de da"os

/n t)rminos m s generales, los atributos deberan ser )a ores puros de da"os 0o TiposdeDa"os, en el lengua(e 6+81, en los cuales la identidad Inica no es significativa
0dentro del conte9to de nuestro modelo o sistema1 A4umbaughB1C. 'or e(emplo, no es 0generalmente1 significativo distinguir entre% 2nstancias aisladas del Numero E. 2nstancias aisladas de la #adena QgatoR. 2nstancias aisladas de NumeroTelefonico que contengan el mismo nImero 2nstancias aisladas de "ireccion que contengan la misma direccin. /n cambio, s es significativo distinguir 0por identidad1 entre dos instancias asiladas de una 'ersona cuyos nombres sean Q=ill .mithR, porque ambas instancias pueden representar diferentes individuos con un mismo nombre. 'or lo que respecta al soft,are, hay pocas situaciones donde compararamos la direccin de memoria de las instancias de Numero) #adena) NumeroTelefonico o "ireccionJ slo las comparaciones basadas en valores son relevantes. /n cambio, es posible comparar las direcciones de memoria de las instancias 'ersona y distinguirlas, aun cuando tuvieran los mismos valores de atributos, por ser importante su identidad Inica. 0( e e'e("o de u( "ipo puro de da"os puede e1e'p i!icarse e( a secci*( de o"ro co(cep"o des"i(ada a os a"ri,u"os> au(Eue "a',iC( es acep"a, e 'ode ar o co'o u( co(cep"o di!ere("e. 8os valores puros de datos tambi)n se denominan o,1e"os de )a or. /l concepto de valor puro es sutil. 6na regla pr ctica consiste en aplicar la prueba b sica de los tipos de atributos QsimplesR% convertirlos en atributo si espont neamente los concebimos como nImero, cadena, booleano, fecha u hora 0y as sucesivamente1J de lo contrario, representarlos como un concepto aparte. E( caso de duda> de!i(a a go co'o co(cep"o ais ado + (o co'o a"ri,u"o.
11....
De"erioro de dise=o9 (i(gQ( a"ri,u"o de,e i(c uirse co'o a)e !or8(ea.
8os atributos no deberan servir para relacionar conceptos en el modelo conceptual. 8a violacin m s frecuente de esta regla consiste en agregar un tipo de a"ri,u"o de a)e !or8(ea, lo cual suele hacerse con los dise*os de bases de datos relacionales, a fin de asociar dos tipos. 'or e(emplo, en la figura 11.D el atributo 3umeroT'&> actual en el tipo #ajero no es conveniente, porque su propsito es relacionar #ajero con un ob(eto T'"<. 8a me(or manera de e9presar que un #ajero usa una T'"< consiste en recurrir a la asociacin, no a un atributo de llave for nea. 6na vez m s, recuerde el lector relacionar los tipos a trav)s de una asociacin y no con un atributo.
Hay muchas formas de relacionar los ob(etos Vlas llaves for neas son una de tantas@J adem s para evitar el de"erioro del dise*o, deberamos posponer hasta la fase del dise*o cmo vamos a implementar la relacin.
$ajero
Ga
nombre ;umero<91Gactual
un atributo "simple", pero que se usa como clave extraa para relacionarlo con otro objeto
Bie(
Cajero nombre A
6sa A
<91G numero
Figura 11.. 3o utilice los atributos como claves e9tra*as.
11.6 Tipos de a"ri,u"os (o pri'i"i)os

/n el modelo conceptual el tipo de un atributo puede e9presarse como no primitivo por s mismo. -s, en el sistema del punto de venta hay un "digo universal de producto 0"6'1. .uele consider rsele como un nImero. !&ebera entonces representarse como un tipo no primitivo# -plique la siguiente directriz% Represe("e co'o "ipo (o pri'i"i)o o Eue i(icia 'e("e puede co(siderarse u( "ipo pri'i"i)o de da"os 2u( (Q'ero o u(a cade(a> por e1e'p o5> si9 Se co'po(e de seccio(es i(depe(die("es. 3 (Q'ero "e e!*(ico> (o',re de perso(a. Nor'a 'e("e se asocia( a C operacio(es co'o e a(8 isis o a )a idaci*(. 3 (Q'ero de seguro socia . &osee o"ros a"ri,u"os. 3 e precio pro'ocio(a podr:a "e(er !ecDa de i(icio + de "er'i(aci*(. Es u(a ca("idad co( u(a u(idad. 3 e i'por"e de pago "ie(e u(a u(idad 'o(e"aria.
-l aplicar las directrices anteriores a los atributos del modelo conceptual del punto de venta, se obtiene el siguiente an lisis% /l cdigo cup debera ser un tipo "6' no primitivo, porque puede ser validado verificando la suma y porque puede poseer otros atributos 0por e(emplo, el fabricante que lo asign1.
8os atributos de precio y cantidad deberan ser los tipos no primitivos #antidad, por ser cantidades en una unidad monetaria. /l atributo direccion debera ser un tipo no primitivo "ireccion, porque consta de secciones independientes.
8os tipos #U') "ireccion y #antidad son valores puros de datos 0la identidad Inica no es significativa1J as que podemos mostrarlos en la seccin de la casilla dedicada a los atributos en vez de relacionarse con una lnea de asociacin.
11.6.1
OD*(de 'os"rar os "ipos (o pri'i"i)os de a"ri,u"os + os )a ores purosP
!&eberamos mostrar el tipo de #U' como concepto aparte en un modelo conceptual# 8a respuesta es% depende de lo que queremos destacar en el diagrama. 'or ser el "6' un valor puro de datos 0la identidad Inica no es importante1, podra presentarse en la seccin dedicada a atributos en la casilla de conceptos, como se advierte en la figura 11.E. 'ero por no ser un tipo primitivo con sus propios atributos y asociaciones, tal vez sera interesante mostrarlo como concepto en su propia ca(a. 3o e9iste en este caso una respuesta correctaJ depender de la manera en que vamos a utilizar el modelo conceptual como herramienta de comunicacin y tambi)n depender de la importancia del concepto en el dominio.
Bie(
Especificacion de producto
$69 [ A
<ienda [ A
1ireccion
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
Bie(
Especificacion de prod cup 5 $69
<ienda direccion 5 1ireccion
Figura 11.6 .i el tipo de atributo es un valor puro de datos, puede mostrarse en la seccin de atributos.
0( 'ode o co(cep"ua es u(a Derra'ie("a de a co'u(icaci*(N as decisio(es so,re o Eue de,er:a 'os"rarse Da( de "o'arse "e(ie(do prese("e eso.
11.? Gode ado de ca("idades + u(idades de os a"ri,u"os
/n t)rminos informales, el importe de un 'ago puede ser representado como un N*mero. 'ero, en general, )ste no es un esquema robusto ni fle9ible porque las unidades de un nImero a menudo son importantes. "onsidere% moneda velocidad
'or e(emplo suele requerirse convertir las unidades 0por e(emplo, las conversiones del sistema ingl)s al sistema m)trico1. .uponiendo que el soft,are del punto de venta est) destinado al mercado internacional, habra que conocer la unidad monetaria de los pagos. 8a solucin consiste en representar #antidad como un concepto distinto, con una Unidad asociada. S como se supone que las cantidades son valores puros de datos 0la identidad Inica carece de importancia1, es aceptable limitarse a presentarlas en la seccin de la casilla destinada a los tipos 0v)ase la figura 11.K1.
utilizable! pero no fle4ible ni robusto Pago monto 5 ;umero
bbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbb
9ago <iene.cantidadZ $antidad Esta.en Z
6nidad
monto 5 ;umero
[
'ago
..
mejor
monto% cantidad
8as cantidades son valores puros de datos, adecuados por eso para mostrarlos en la seccin de atributos
Figura 11.? +odelado de cantidades
11.7 A"ri,u"os de sis"e'a de pu("o de )e("a

/s necesario producir una lista de atributos para los conceptos del dominio del punto de venta. &ebera estar reservada primordialmente a los requerimientos y a las simplificaciones en cuestin% los casos simplificados #omprar 'roductos% versin 9.
8a lectura llama claramente algunos atributos% especificacin de los requerimientos casos de uso en cuestin documentos de simplificaciones, clarificaciones y suposiciones
'or e(emplo, normalmente es necesario registrar la fecha y la hora de una venta. &e ah que el concepto <enta requiera los atributos fec8a y 8ora. 5tros atributos no son evidentes y posiblemente no se los identifique en el an lisis. /sto es aceptable% durante las fases de dise*o y construccin descubriremos e iremos incorporando el resto de los atributos. /n la siguiente seccin se resumen las opciones de atributos indicadas por los casos actuales de uso.
11.< A"ri,u"os e( e 'ode o de pu("o de )e("a

TPDV 9roducto <ienda direccion 5 1ireccion nombre 5 <e4to Genta fecha 5 Fecha hora5 =ora
Gentas3inea9roducto cantidad 5 Entero
$ajero
$liente
?erente
'ago +onto% "antidad
Especificacion de 9roducto $atalogode9roductos descripcion 5 <e4to precio 5 $antidad cup 5 $69
"antidad
Figura 11.7 +odelo conceptual que muestra los atributos.
11.<.1 E4p icaci*( de os a"ri,u"os T&DB
'ago
importe% hay que capturar un monto 0llamado tambi)n Qimporte ofrecidoR1 para determinar si se dio un pago suficiente y calcular el cambio. descripcion% para incluir descripcin en un despliegue. una
+specificacionde'roducto
"6'% 'ara consultar /specificacionde'roducto, una vez capturado un "6', es necesario relacionarlos con un "6'. precio% para calcular el total de las ventas y mostrar el precio de la lnea del producto. <enta 7ec8a) 8ora% el recibo es un informe escrito de una venta. 3ormalmente contiene la fecha y la hora de la venta. cantidad% para registrar la cantidad capturada, cuando hay m s de un elemento en la lnea del producto 0por e(emplo, cinco paquetes de pa*uelos desechables1. direccin) nombre% el recibo requiere el nombre y la direccin de la tienda.
<entasLineade'roducto
Tienda
11.@ Gu "ip icidad e("re Be("asLi(eade&roduc"o + &roduc"o

/s posible que un ca(ero reciba un grupo de productos afines 0seis paquetes de pa*uelos desechables, por e(emplo1, que introduzca una vez el cdigo universal de producto y luego una cantidad 0seis, por e(emplo1. /n consecuencia, un <entas L=nea de 'roducto puede estar asociado a m s de una instancia de cada producto. 8a cantidad que captura el ca(ero puede quedar registrada como atributo de <entasLineade'roducto 0figura 11.L1. .in embargo, tambi)n puede calcularla a partir del valor real de multiplicidad de la relacinJ as que puede caracterizarse como un a"ri,u"o deri)ado, el cual puede ser deducido de otra informacin. /n el lengua(e 6+8, un atributo de esta clase se denota con el smbolo QXR.
>entas8ineade'roducto
H.. 1
4egistra@venta@de
'roducto
"ada lnea de producto registra la venta de un producto individualJ por e(emplo, 1 paquete de pa*uelos desechables
>entas8ineade'roducto
H.. 1
4egistra@venta@de 1..[
'roducto
"ada lnea de productos registra un grupo de la misma clase de productosJ por e(emplo, K paquetes de pa*uelos desechables
>entas8ineade'roducto Xcantidad
H.. 1
4egistra@venta@de 1..[
'roducto
-tributo derivado del valor de multiplicidad
11.1A Gode o co(cep"ua de pu("o de )e("a

-l combinar los conceptos, asociaciones y atributos que descubrimos en la investigacin anterior, obtenemos el modelo de la figura 11.B.
1 ANLISIS Y DISEO ORIENTADOS A OBJETOS 2egistra.'enta.de 1escritas por
A Especificacionde9roducto
descripcion precio "6'
$atalogode9roductos
$ontiene
A..[ A
A 6sado.por
T..A cantidad
Gentas3ineade9roductos
1escribe [
9roducto
[
<ienda
8lmacena
A..[ $apturas
$ontenidas.en 9agado.por terminadas
1ireccion nombre
8loja @nciado.por
A A Genta [
fecha hora
A..[
<91G
$apturadas.en A
?erente
A @niciada.por A 'ago monto

"liente
Y 2egistra.'entas.en
A A $ajero
Figura 11.@ +odelo conceptual del dominio del punto de venta.
11.11.3 -o(c usi*(

Hemos creado un modelo conceptual relativamente Itil del dominio de la aplicacin al punto de venta. 3o e9iste un modelo apropiado para todos los casos o circunstancias. Todos ellos no son m s que apro9imaciones al dominio que intentamos entender. 6n buen modelo conceptual capta las abstracciones esenciales y la informacin indispensable para comprender el dominio dentro del conte9to de los requerimientos actualesJ nos facilita adem s conocer el dominio% sus conceptos, su terminologa y sus relaciones.
1$
RE/ISTRO DE LOS TURGINOS EN EL /LOSARIO
/bjeti'os E4presar trminos en un glosario.
1$.1 I("roducci*(
/l glosario es un documento simple en el cual se definen t)rminos. /n el presente captulo ofrecemos un e(emplo de glosario aplicado al dominio del punto de venta.
1$.$ / osario
/l g osario o diccio(ario 'ode o 0seme(ante a un diccionario de datos1 incluye y define todos los t)rminos que requieren e9plicacin para me(orar la comunicacin y aminorar el riesgo de malos entendidos. 6n significado uniforme y compartido resulta e9tremadamente importante durante el desarrollo de las aplicaciones, sobre todo cuando muchos miembros del equipo intervienen en el proyecto.
1$.% Ac"i)idades + depe(de(cias

/l glosario se crea originalmente durante la fase de 'laneacin y /laboracin conforme vayan gener ndose los t)rminosJ despu)s va perfeccion ndose continuamente en cada ciclo de desarrollo al aparecer nuevos vocablos. 'or lo regular se realiza (unto con la especificacin de requerimientos, los casos de uso y el
modelo conceptual. &arle mantenimiento es una actividad permanente a lo largo de todo el proyecto.
1$.%.1Reg as + res"riccio(es de do'i(io

/l glosario es un documento muy Itil donde se registran las reglas del dominio de la empresa, las restricciones y otros puntos, aunque aqu no e9aminaremos este aspecto. He aqu otros artefactos en que se registra esta clase de informacin% los casos de uso, los contratos 0que veremos en un captulo subsecuente1 y la incorporacin de notas de restriccin a los elementos 0los conceptos, entre ellos1 a los que se aplica la regla o la restriccin.
1$.. E1e'p o de g osario ap icado a sis"e'a de pu("o de )e("a

3o e9iste un formato oficial de este tipo de glosario. -ne9amos aqu una muestra%
T.&3in% $omprar productos
8a'eg%&5a caso de uso
Especificacionde9roducto. atributo descripci#n5 <e4to 9roducto tipo
9ago tipo Especificacionde9roducto. atributo precio5 $antidad Genta3ineasde9roducto. $antidad5 Entero Genta Gentas3ineade9roducto <ienda Genta.total5 $antidad 9ago.monto5 $antidad atributo tipo tipo tipo atributo atributo
Especificacionde9roducto. atributo
8%3en'a&i%# 1escripci#n del proceso de un cliente que compra productos en una tienda. 1escripci#n bre'e de un producto en una 'enta! junto con su Especi"iciondeCroducto asociada. 6n producto para 'enderse en una +ienda. 6n pago en efecti'o. El precio de un producto en una 'enta! junto con su Especi"icacindeCroducto asociada. 3a cantidad comprada de un tipo de 9roducto. 6na transacci#n de 'entas. 6na l"nea de productos de un producto particular comprado en una Denta El lugar donde se realiza la 'enta de productos. El gran total de la Denta. El monto que el cliente ofrece o presenta para el pago. El c#digo uni'ersal de producto del
cup5 $69
9roducto y su Especi"icaciondeCroducto.
1:
8O <ORTA IENTO DE LOS SISTE AS6 DIAFRA A DE LA SE8UEN8IA DEL SISTE A

O(je'i?%# @dentificar los e'entos y las operaciones del sistema. $rear el diagrama de la secuencia del sistema para los casos de uso.
1%.1 I("roducci*(
/l diagrama de la secuencia de un sistema muestra gr ficamente los eventos que fluyen de los actores al sistema. /n este captulo describiremos la forma de elaborarlos. 8a creacin de los diagramas de la secuencia de un sistema forma parte de la investigacin para conocer el sistemaJ se incluye, pues, dentro del modelo de an lisis. /l 6+8 ofrece una notacin con los diagramas de la secuencia que muestran gr ficamente los eventos que pasan de los actores al sistema.
1%.$ Ac"i)idades + depe(de(cias
8os diagramas de la secuencia de un sistema se preparan durante la fase de an lisis de un ciclo de desarrollo. .u creacin depende de la formulacin previa de los casos de uso. "iclo de desarrollo
9erfeccio namiento del plan (incronizac i#n de artefactos 8nlisis 1iseo $onstruc ci#n 9rueba
a.si todava no se realiza b. actual c.opcional
A.1efinir los casos esenciales de usoa
B.9erfeccionar los diagramas de casos de uso L.1efinir los contratos de operaciones
E. 9erfeccionar el modelo conceptual
I. 9erfeccionar el glosariob
K.1efinir los diagramas de secuencia de los sistemas
7.1efinir los dia. gramas de estadoc
-ctividades de la fase de an lisis dentro de un ciclo de desarrollo.
$asos de uso5 . e4pandidos . esenciales
$asos de uso5 .reales
Gentas y reportes
$asos de prueba
1iagramas de casos de uso 7odelo conceptual
1iagramas de interacci#n
7todos
?losario
1iagramas de clase de diseo
1efiniciones de clase y de interfaz
1iagrama de secuencia del sistema
1iagramas de paquete de arquitectura
1ependencia respecto a
$ontratos de operaci#n
1iagramas 1e estado
Esquema de base de datos
(Q3
&ependencias de los artefactos durante la fase de construccin.
1%.% -o'por"a'ie("o de sis"e'a

-ntes de iniciar el dise*o lgico de cmo funcionar una aplicacin de soft,are, es necesario investigar y definir su comportamiento como una Qca(a negraR. /l co'por"a'ie("o de sis"e'a es una descripcin de lo ,ue hace, sin e9plicar la
manera en que lo hace. 6na parte de la descripcin es un diagrama de la secuencia del sistema.
1%.. Diagra'as de a secue(cia de sis"e'a

8os casos de uso indican cmo los actores interactIan con el sistema de soft,are que es lo que en realidad deseamos crear. &urante la interaccin un actor genera eventos dirigidos a un sistema, solicitando alguna operacin a cambio. 'or e(emplo, cuando un ca(ero introduce un cdigo universal de producto de un artculo, est pidiendo al sistema T'&> registrar la compra. "on el evento de esa peticin se inicia una operacin del sistema. "onviene aislar y e9plicar gr ficamente las operaciones que un actor solicita a un sistema porque contribuyen de manera importante a entender el comportamiento del sistema. /l 6+8 incluye entre su notacin los diagra'as de a secue(cia que dan una descripcin gr fica de las interacciones del actor y de las operaciones a que da origen. /l diagra'a de a secue(cia de u( sis"e'a es un representacin que muestra, en determinado escenario de un caso de uso,1 los eventos generados por actores e9ternos, su orden y los eventos internos del sistema. - todos los sistemas se les trata como una ca(a negraJ los diagramas se centran en los eventos que trascienden las fronteras del sistema y que fluyen de los actores a los sistemas. El diagrama de la secuencia de un sistema deber"a prepararse para el curso normal de los e'entos de un caso de uso \ y posiblemente tambin de otros.! teniendo en cuenta los cursos opcionales ms interesantes.
1%.6 E1e'p o de u( diagra'a de a secue(cia de u( sis"e'a

/l diagra'a de a secue(cia de u( sis"e'a describe, en el curso particular de los eventos de un caso de uso, los actores e9ternos que interactIan directamente con el sistema 0como ca(a negra1 y con los eventos del sistema generados por los actores 0figura 1:.11. /n el diagrama el tiempo avanza hacia aba(o, y el ordenamiento de los eventos debera seguir el orden indicado en el caso de uso.
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1
/l escenario de un caso de uso es una instancia o trayectoria realizada por medio del uso% un e(emplo real de su e(ecucin.
8os eventos del sistema pueden incluir par metros. /l e(emplo ad(unto se refiere al curso normal de los eventos en el caso #omprar productos. 2ndica que el ca(ero es el Inico actor en el sistema T'&> y que genera los eventos del sistema introducir'roducto) terminar<enta y efectuar'ago.
(istema como $aja negra 8ctor ;omprar productos: versin 9
$ajero
%(istema
2epetir hasta que no hay ms productos
introducir9roducto,$69! cantidad-
terminarGenta,-
efectuar9ago ,monto<e4to que aclara el control! la l#gica! la iteraci#n! etctera. 9uede tomarse del caso de uso. E'ento del sistema @nicia una operaci#n del sistema
1igu&a 1+.1 1iagrama de la secuencia del sistema para el caso de uso ;omprar Croductos
1%.? E)e("os + operacio(es de u( sis"e'a

/l e)e("o de u( sis"e'a es un hecho e9terno de entrada que un actor produce en un sistema. /l evento da origen a una operacin de respuesta. 8a operaci*( de u( sis"e'a es una accin que )ste e(ecuta en respuesta a un evento del sistema 0figura 1:.$1. 'or e(emplo, cuando el ca(ero genera el evento introducir'roducto) causa la e(ecucin de la operacin introducir'roducto3 el nombre del evento y de la operacin son id)nticosJ la distincin reside en que el evento es el estmulo nombrado y la operacin es la respuesta. 1
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] 1
8o mismo sucede con los mensa(es y m)todos.
;omprar productos: versin 9
$ajero introducir9roducto,$69! cantidad-
%(istema
E'ento del sistema *introducir9roducto+ @nicia una operaci#n del sistema del mismo nombre *introducir9roducto+ 1igu&a 1+.* 3os e'entos del sistema inician las operaciones de l.
1%.?.1Regis"ro de a operacio(es de u( sis"e'a

'ara determinar el con(unto de las operaciones requeridas del sistema se identifican sus eventos. "uando se utilizan par metros, las operaciones son las siguientes% introd#cir5rod#cto 7C85, cantidad6 ter inar9enta76 efect#ar5a(o7 onto6
!&nde deberan registrarse estas operaciones# /l lengua(e 6+8 ofrece una notacin para registrar las operaciones de un tipo, como se aprecia en la figura 1:.:.
<ipo^ /peracionA,/peracionB,/peraciones del tipo
1igu&a 1+.+ ;otaci#n de las operaciones en el 673.
"on esta notacin, las operaciones del sistema pueden agruparse como operaciones del ;istema 0figura 1:.D1. 8os par metros son opcionales% pueden incluirse o no.
(istema terminarGenta ,introducir9roducto,efectuar9ago,-
1igu&a 1+.+ ;otaci#n de las operaciones en el 673.
/ste esquema tambi)n funciona satisfactoriamente cuando registra las operaciones del sistema de varios sistemas o procesos en una aplicacin distribuidaJ a cada sistema se le asigna un nombre especial 0;istema9) ;istema/)C1 y tambi)n sus operaciones propias. 5bserve que la representacin del tipo ;istema es muy diferente a lo que se e9pres en el modelo conceptual. 8os elementos de )ste representan conceptos del mundo realJ en cambio, el tipo ;istema es un concepto artificial. S adem s muestra las operaciones, cosa totalmente nueva. /llo se debe a que V a diferencia del modelo conceptual, que presenta informacin est tica V estamos describiendo el comportamiento del sistema, que es informacin din mica.
1%.7 -*'o e a,orar u( diagra'a de a secue(cia de u( sis"e'a

9ara elaborar diagramas de la secuencia de un sistema que describan el curso normal de los e'entos en un caso de uso5 1 * + 0 <race una l"nea que represente el sistema como una caja negra. @dentifique los actores que operan directamente sobre el sistema. <race un l"nea para cada uno de ellos. 8 partir del curso normal de los e'entos del caso de uso identifique los e'entos ,*e4ternos+del sistema que son generados por los actores. 7ustrelos grficamente en el diagrama. 8 la izquierda del diagrama puede incluir o no el te4to del caso de uso.
1%.< Diagra'as de a secue(cia de u( sis"e'a + o"ros ar"e!ac"os

8a identificacin y ordenamiento de los eventos de un sistema para incluirlos en los diagramas de secuencia 0figura 1:.E1 se logran de la revisin de los casos de uso.
$8(/ 1E 6(/5 $/79282 92/16$</(. $urso normal de los e'entos Este caso de uso comienza cuando un cliente llega a una caja de <91G con productos que desea comprar. El cajero registra el c#digo uni'ersal del producto ,$69- de cada producto. (i hay ms de uno del mismo producto! tambin se puede capturar la cantidad. El sistema determina el precio del producto y agrega la informaci#n sobre el producto a la transacci#n actual de 'entas. (e muestran la descripci#n y el precio del producto actual. y as" sucesi'amente.
%(istema
$ajero introducir9roducto,$69! cantidadterminarGenta,efectuar9ago ,monto-
1igu&a 1+.4 3os diagramas de la secuencia de un sistema se dedujeron de los casos de uso.
1%.@ E)e("os + !ro("eras de u( sis"e'a

'ara identificar los eventos de un sistema es necesario tener un idea clara de lo que se quiere al escoger su frontera, segIn vimos en el captulo anterior dedicado a los casos de uso. 'or lo que respecta al desarrollo de soft,are 0y, posiblemente, del hard,are1J dentro de este conte9to, un evento del sistema es un hecho e9terno que estimula directamente el soft,are 0figura 1:.K1. /n la reingeniera de empresas, la frontera del sistema V y, por lo tanto, sus eventos@ pueden ampliarse para que abarquen los procesos manuales, pero esto rebasa el mbito de nuestro libro. "onsideremos ahora el caso de uso #omprar 'roductos a fin de identificar los eventos del sistema. 'rimero debemos determinar los actores que interactIan directamente con el sistema de soft,are. /l cliente interactIa con el ca(ero, pero no directamente con el soft,are T'&>J esto slo lo hace el ca(ero. 'or lo tanto, el cliente no es un generador de eventos del sistemaJ slo el ca(ero lo es.
$ajero
%(istema
introducir9roducto ,$69! cantidad-
terminarGenta,-
efectuar9ago ,monto-
Frontera del sistema
1igu&a 1+.; 1efinici#n de la frontera del sistema.
1%.1A Asig(aci*( de (o',re a os e)e("os + a as operacio(es de u( sis"e'a

8os eventos de un sistema 0y sus operaciones asociadas1 deberan e9presarse en el nivel de propsito y no el medio fsico de entrada o en el nivel de elementos de la interfaz. Tambi)n me(ora la claridad si el nombre de un evento del sistema comienza con un verbo 0agregarZ, introducirZ, terminarZ, efectuarZ,1, como en la figura 1:.;, porque recalca que los eventos est n orientados a comandos.
%(istema
$ajero ;ombre ms id#neo introducir9roducto,$69! cantidadintroducir<ecla/primida ,$69! cantidad;ombre menos id#neo
1igu&a 1+.= Escoja los nombres de los e'entos y de las operaciones en un ni'el abstracto.
-s, Qterminar>entaR es preferible a QintroducirTecla5primidaR porque capta me(or el propsito de la operacin% mantiene un car cter abstracto y no se pronuncia respecto a las decisiones de dise*o sobre cu l interfaz sirve para capturar el evento del sistema. /n cuanto a e9presar las operaciones en el nivel de propsito, procure alcanzar el nivel m s alto o la meta final de asignar nombre a la operacin. 'or e(emplo, respecto a la operacin de captura el pago% introducirImporte!frecidoAmontoB introducir'agoAmontoB introducir'agoAmontoB deficiente me(or quiz me(or aIn
1%.11 &rese("aci*( de "e4"o de caso de uso

/n ocasiones conviene mostrar al menos fragmentos del te9to del caso de uso dentro del diagrama de la secuencia, con el fin de describir gr ficamente se estrecha relacin con el caso de uso 0figura 1:.L1.
%(istema
$ajero En todos los productos! el $ajero registra el $#digo uni'ersal de producto ,$69- y la cantidad. 8l terminar de capturar el producto! el $ajero indica a la <91G que la 'enta concluy#. El $ajero le indica el total al $liente! y ste le da un pago. El $ajero registra el importe recibido en efecti'o. 1igu&a 1+.> 1iagrama de la secuencia de un sistema con te4to del caso de uso. introducir9roducto,$69! cantidadterminarGenta,-
efectuar9ago ,monto-
1%.1$ Gode os 'ues"ra

8os diagramas de la secuencia de un sistema forman parte del modelo del comportamiento del sistema, como se advierte en la figura 1:.B, la cual especifica a qu) eventos responde un sistema y qu) responsabilidades y poscondiciones tiene sus operaciones correspondientes.
7odelo de anlisis
a.modelo est tico b.modelo din mico
7odelo de casos de uso del anlisisb
7odelo conceptuala
7odelo del comporta. 7iento del sistemab
7odelo de estado del anlisisb
$asos de uso . de alto ni'el . esenciales

1iagramas de casos de uso
1iagramas de estructura esttica para los conceptos del dominio
1iagramas de secuencias del sistema $ontratos para operaciones del sistema
1iagramas de estado para conceptos y casos de uso
1igu&a 1+.B 7odelo del anlisis.
1D 8O <ORTA IENTO DE LOS SISTE AS6 8ONTRATOS
O(je'i?%# $rear contratos para las operaciones de un sistema.
10.1 In'&%duccin
3os contratos contribuyen a definir el comportamiento de un sistema: describen el efecto que sobre l tienen las operaciones. En este cap"tulo estudiaremos su utilizaci#n. El lenguaje 673 ofrece un soporte para definir los contratos! ya que permite definir las precondiciones y las poscondiciones de las operaciones. A
10.* Ac'i?idade# ! dependencia#

3os contratos de operaci#n del sistema se elaboran durante la fase de anlisis en un ciclo de desarrollo. (u preparaci#n depende del desarrollo pre'io del modelo conceptual! de los diagramas de la secuencia del sistema y la identificaci#n de sus operaciones. ]]]]]]]]]]]]]]]]]]

A
En la definici#n formal del 673 \ o metamodelo .! las operaciones tienen un conjunto de propiedades predefinidas que incluye sus precondiciones y poscondiciones. "iclo de desarrollo
9erfeccio namiento del plan (incronizac i#n de artefactos 8nlisis 1iseo $onstruc ci#n 9rueba
a. si todava no se realiza b. actual c. opcional
A.1efinir los casos esenciales de usoa
B.9erfeccionar los diagramas de casos de uso L.1efinir los contratos de operaciones
E. 9erfeccionar el modelo conceptual
I. 9erfeccionar el glosariob
K.1efinir los diagramas de secuencia de los sistemas
7.1efinir los diagramas de estadoc
8cti'idades de la fase de anlisis dentro de un ciclo de desarrollo.

$asos de uso5 . e4pandidos . esenciales $asos de uso5 .reales Gentas y reportes $asos de prueba
1iagramas de casos de uso 7odelo conceptual
1iagramas de interacci#n
7todos
?losario
1iagramas de clase de diseo
1efiniciones de clase y de interfaz
1iagrama de secuencia del sistema
1iagramas de paquete de arquitectura
1ependencia respecto a
$ontratos de operaci#n
1iagramas 1e estado
Esquema de base de datos
(Q3
&ependencias de los artefactos durante la fase de construccin.
1..% -o'por"a'ie("o de u( sis"e'a

-ntes de emprender el dise*o lgico de cmo funcionar una aplicacin de soft,are, es necesario investigar y definir su comportamiento como Qca(a negraR. /l co'por"a'ie("o de u( sis"e'a es una descripcin de lo ,ue hace, sin e9plicar cmo lo hace. 8os contratos son documentos muy Itiles que describen el comportamiento de un sistema a partir de cmo cambia el estado un sistema cuando se llama una operacin suya.
1... -o("ra"os
/n la figura 1D.1, el diagrama de la secuencia de un sistema muestra los eventos generados por un actor e9terno, pero no profundiza en los detalles de la funcionalidad asociada con las operaciones invocadas. 3o contiene los detalles necesarios para entender la respuesta del sistema, o sea su comportamiento. /n t)rminos generales, un co("ra"o1 es un documento que describe lo que una operacin se propone lograr. .uele redactarse en un estilo declarativo, enfatizando
lo ,ue suceder y no cmo se conseguir . 8os contratos suelen e9presarse a partir de los cambios de estado de las precondiciones y de las poscondiciones. 'uede elaborarse un contrato para un m)todo de una clase de soft,are o para una operacin m s global del sistema. /l co("ra"o de operaci*( de sis"e'a describe los cambios del estado del sistema total cuando se llama de sus operaciones
(istema terminaGenta,introducir9roducto,efectuar9ago,-
(e redactan contratos para cada operaci#n del sistema con el fin de describir su comportamiento
1igu&a 10.1 3as operaciones del sistema requieren las descripciones del contrato.
4epetimos% un contrato puede emplearse con una operacin de alto nivel que se aplica al sistema entero o con un m)todo de ba(o nivel de una clase particular. 'or ahora nos centraremos en su uso en las operaciones del sistema.
1..6 E1e'p o de co("ra"o9 i("roducir&roduc"o

/n el siguiente e(emplo se describe un contrato de la operacin introducir'roducto del sistema. bbbbbbbbbb 1 <ertrand +eyer fue el primero en difundir el t)rmino.
-o("ra"o
No',re9 Respo(sa,i idades9 Tipo9 Re!ere(cias cru;adas9 No"as9 E4cepcio(es9 Sa ida9 &reco(dicio(es9 &osco(dicio(es9 introducir'roducto 0cup% nImero, cantidad% entero1. "apturar 0registrar1 la venta de un producto y agregarla a la venta. &esplegar la descripcin y el precio del producto. .istema. ?unciones del sistema% 41.1, 41.:, 41.B. "asos de uso% "omprar productos 6tilizar el acceso superr pido a la base de datos. .i el "6' no es v lido, indicar que se cometi un error. /l sistema conoce el "6'.
.i se trata de una nueva venta, se crea una <enta Acreacin de instanciaB. .i se trata de una nueva venta, la nueva <enta fue asociada a T'&> 0asociacin formada1. .e cre una instancia <entasLineade'roducto Acreacin de instanciaB. .e asoci una instancia <entasLineade'roducto a la venta 0asociacin formadaB. .e asign cantidad a <entasLineade'roducto.cantidad Amodificacin de atributoB. .e asoci una instancia <entasLineade'roducto a la instancia +specificionde'roducto) basado eso en la correspondencia del "6' 0asociacin formadaB.
1..? Seccio(es de co("ra"o

6na descripcin de las secciones de un contrato se da en el siguiente esquema. 3o todas las secciones son necesariasJ nosotros recomendamos las de esponsabilidades y 'oscondiciones.
-o("ra"o
No',re9 Respo(sa,i idades9 Tipo9 Re!ere(cias cru;adas9 No"as9 E4cepcio(es9 Sa ida9 &reco(dicio(es9 &osco(dicio(es9 /l estado del sistema despu)s de la operacin. /sto se e9plica a fondo en la siguiente seccin. 3ombre de la operacin y par metros. &escripcin informal de las responsabilidades que debe cumplir la operacin. 3ombre del tipo 0concepto, clase de soft,are, interfaz1. 3Imeros de referencias de las funciones del sistema, casos de uso, etc)tera. 3otas de dise*o, algoritmos e informacin afn. "asos e9cepcionales. 3o salidas de la interfaz de 6suarioJ por e(emplo, mensa(es o registros que se envan afuera del sistema. .uposiciones acerca del estado del sistema antes de e(ecutar la operacin.
1..7 -*'o preparar u( co("ra"o

-plique la siguiente sugerencia para elaborar contratos.
9ara preparar un contrato en los casos de uso5 1 @dentifique las operaciones del sistema a partir de los diagramas de su secuencia. * Elabore un contrato en cada operaci#n del sistema. + $omience redactando la secci#n de 2esponsabilidades: despus describa informalmente el prop#sito de la operaci#n. 0 $omplete luego la secci#n de 9oscondiciones! describiendo en forma declarati'a los cambios de estado de los objetos en el modelo conceptual. 4 9ara describir las poscondiciones utilice las siguientes categor"as5 $reaci#n y eliminaci#n de las instancias. 7odificaci#n de los atributos. 8sociaciones formadas y canceladas.
1..7.1-o("ra"os + o"ros ar"e!ac"os

8os casos de uso sugieren los diagramas de los eventos y de la secuencia del sistema. &espu)s se identifican las operaciones del sistema. /l efecto de las operaciones del sistema se describe en los contratos.
/peraci#n5 introducir9roducto $8(/ 1E 6(/5 $/79282 92/16$</(. $urso normal de los e'entos A. Este caso de uso comienza_ $ajero introducir9roducto ,$69! cantidad(istema (istema terminaGenta,introducir9roducto,efectuar9ago,9oscondiciones5 A. (i se trata de una nue'a 'enta! fue creada una nue'a Genta_
terminarGenta,efectuar9ago ,monto-
/peraci#n5 terminarGenta 9oscondiciones5 A. _
8a#% de u#%
Diag&a3a de la #ecuencia del #i#'e3a
Ope&aci%ne# del #i#'e3a
8%n'&a'%#
1igu&a 10.* $ontratos y otros artefactos.
1..< &osco(dicio(es
3tese que las poscondiciones en el e(emplo introducir'roducto incluyen una clasificacinJ por e(emplo, creacin de instancias o asociacin formada. &espu)s de la seccin de esponsabilidades) la parte m s importante del contrato son las poscondiciones, que estipulan cmo cambi el sistema tras esta operacin. 3o son acciones que deben efectuarse durante la operacinJ m s bien son declaraciones sobre el estado del sistema que se aplican una vez concluida la operacin, es decir, una vez ,ue el 8umo se 8a disipado. /l 6+8 no impone lmites a la manera de e9presar las poscondicionesJ pero las siguientes categoras de cambio de estado han resultado de gran utilidad en la pr ctica. 8e aconse(amos e9presar sus poscondiciones de una manera similar. $ategor"as >tiles referentes a las poscondiciones del contrato5 $reaci#n y eliminaci#n de las instancias. 7odificaci#n de los atributos. 8sociaciones formadas y canceladas.
/l 6+8 no define cmo e9presar las poscondicionesJ as que puede usted escoger el formato que m s le agrade. 8o importante es que adopte una actitud declarativa, orientada al cambio de estado y no a la accin, porque las poscondiciones deberan
ser declaraciones sobre los estados o resultado, no una descripcin de acciones a realizar.
1..<.1Las posco(dicio(es se re acio(a( co( e 'ode o co(cep"ua

8as poscondiciones se e9presan dentro del conte9to del modelo conceptual, !Ou) instancias es posible crear# 8a respuesta es% las provenientes de ese modelo. !Ou) asociaciones es posible formar# 8a respuesta es% las que est n en el modelo conceptual. S as podramos ir formulando y contestando m s preguntas. "uando se elaboran contratos, generalmente el lector se percatar de la necesidad de registrar en el modelo conceptual nuevos conceptos, atributos o asociaciones. 3o se limite usted a la definicin precedente del modelo conceptual% me(relo conforme vaya haciendo m s descubrimientos, mientras refle9iona sobre los contratos de las operaciones.
1..<.$La )e("a1a de as posco(dicio(es

/9presando en una forma declarativa de cambios de estado, el contrato constituye una e9celente herramienta de investigacin, pues permite describir los cambios necesarios para que el sistema funcione sin necesidad de describir cmo se logran. /n otras palabras, podemos posponer el dise*o y la solucin del soft,are y concentrarnos analticamente en lo ,ue debe suceder, no en la manera de conseguirlo.
1..@ E esp:ri"u de as posco(dicio(es9 e esce(ario + e "e *(

8as poscondiciones deberan describir el estado de un sistema, no las acciones a realizar. /9pr)selas en tiempo pasado para enfatizar que se trata de declaraciones sobre un cambio pret)rito de estado. 'or e(emplo% .e cre* una instancia <entasLineade'roducto 0me(or1J /n lugar de "rear una instancia <entasLineade'roducto 0peor1. 4efle9ione sobre las poscondiciones sirvi)ndose de la siguiente imagen% +l sistema y sus objetos se presentan en el escenario de un teatro. 1. Tome una fotografa del escenario antes de la operacin. $. "orra el teln del escenario y aplique la operacin del sistema 0 ruido de fondo con sonidos metlicos) gritos) c8illidosCB. :. corra el teln y tome una segunda fotografa. D. "ompare las fotografas de antes y despu)s, y e9prese como poscondiciones los cambios del estado del escenario 0;e cre la instancia <entasLineade'roductoCB.
1..1A E4p icaci*(9 posco(dicio(es de introd#cir5rod#cto

/n la siguiente seccin analizaremos por qu) se utilizan las poscondiciones de la operacin del sistema de introducir'roducto.
1..1A.1 -reaci*( + e i'i(aci*( de i(s"a(cias

6na vez que el ca(ero captur el cdigo universal del producto 0"6'1 y la cantidad de un producto, !qu) nuevos ob(etos han de crearse# .i se trata de una nueva venta, habra que crear una instancia para una nueva <enta. 6na instancia <entasLineade'roducto debera ser creada de modo incondicional. 'or tanto% .i se trata de una nueva venta, se cre una <enta 0creacin de instancia1. .e cre una instancia <entasLineade'roducto 0creacin de instancia1.
1..1A.$ Godi!icaci*( de a"ri,u"os

6na vez que la ca(era captur el cdigo universal de producto y la cantidad de un producto, !qu) atributos de los ob(etos nuevos o actuales deberan ser modificados# Habra que establecer la cantidad de <entasLineade'roducto. 'or tanto% .e defini para <entasLineade'roducto.cantidad el valor de cantidad 0modificacin del atributo1.
1..1A.% Asociacio(es !or'adas + ca(ce adas

6na vez que el ca(ero captur el cdigo universal de producto y la cantidad de un producto !qu) asociaciones entre los ob(etos nuevos y actuales debieron haber sido formadas o canceladas# Habra que haber relacionado la nueva instancia >entas8ineade'roducto con sus >entas y con su 'roducto. .i se trataba de una nueva venta, la >enta debi haber sido relacionada con la T'&> dentro de la cual es registrada. 'or tanto% .i se trata de una venta nueva, la nueva >enta fue asociada a la T'"< 0asociacin formada1. 6na instancia <entasLineade'roducto fue asociada a la <enta 0asociacin formada1. 6na instancia <entasLineade'roducto fue asociada a una +specificacinde'roducto) con base en la correspondencia del "6' 0asociacin formada1.
1..11 O-u8( co'p e"as de,e( ser as posco(dicio(esP
/n la fase de an lisis no es probable V ni siquiera necesario V generar un grupo de poscondiciones completas y e9actas de la operacin del sistema. -conse(amos ver en su elaboracin la con(etura inicial m s acertada, a sabiendas de que los contratos estar n incompletos. /sta creacin temprana V aunque incompleta V sin duda es preferible a posponer la investigacin hasta la fase de dise*o, cuando los creadores se concentrar n en el dise*o de una solucin m s que en averiguar lo ,ue debe hacerse. -lgunos de los detalles finos V y quiz hasta los m s generales V se descubrir n durante la fase de dise*o. 3o es algo necesariamente maloJ en la fase de investigacin se debilitan el esfuerzo y la dedicacin si se prolongan demasiado tiempo. /n la fase de dise*o se logran algunos descubrimientos que despu)s pueden guiar la fase de investigacin de un ciclo iterativo posterior. 6na de las venta(as del desarrollo iterativo es )sta% los descubrimientos hechos en la fase de dise*o de un ciclo pueden me(orar la calidad de la investigacin y el traba(o de an lisis en el siguiente ciclo.
1..1$ Descripci*( de os de"a es + a gori"'os de dise=o9 (o"as

8a seccin del contrato correspondiente a 3otas es el lugar donde pueden hacerse las declaraciones del dise*o referentes a la operacin. 'or e(emplo, si se sabe que se prefiere un algoritmo en particular para mane(ar la operacin, esa seccin es el sitio idneo para su documentacin.
1..1% &reco(dicio(es
8as precondiciones definen las suposiciones sobre el estado del sistema al iniciarse la operacin. Hay muchas precondiciones que pueden declararse en una operacin, pero la e9periencia revela que vale la pena mencionar las siguientes% "osas que son importantes probar en el soft,are en algIn momento de la e(ecucin de la operacin. "osas que no ser n sometidas a prueba, pero de las cuales depende el )9ito de la operacin. Oueremos compartir esta suposicin con los futuros lectores del contrato, a fin de subrayar su importancia y de que los lectores se percaten de ella.
1..1. Reco'e(daci*( so,re c*'o redac"ar co("ra"os
6na vez anotado el nombre de la operacin, llene primero la seccin de esponsabilidades y luego la de 'oscondiciones) de(ando al final la de 'recondiciones. .on las tres secciones m s importantes del proyecto en cuanto a su uso ulterior. &esde luego, si a un desarrollador no le resulta Itil llenar una seccin, no lo har y nada pasar . 6se la seccin de Notas para e9plicar los detalles del dise*oJ por e(emplo, los algoritmos y los pasos secuenciales de alto nivel. 6se la seccin de +1cepciones para e9plicar la reaccin ante situaciones raras o especiales. 6se la siguiente categoras de los cambios de estado en las poscondiciones% o "reacin y eliminacin de instancias. o +odificacin de atributos. o -sociaciones formadas y canceladas. /9prese las poscondiciones en forma pasiva declarativa, en pret)rito 0 fue registradoZ1 para destacar la declaracin de un cambio de estado en vez del dise*o de cmo iba a obtenerse. 'or e(emplo%
Fue creada una instancia <entasLineade'roducto 0bien1. /s me(or que .e cre una instancia <entasLineade'roducto 0mal1. o 8a diferencia entre ambas oraciones puede parecer meramente acad)mica y superficialJ pero si se emplea la construccin activa en vez de la pasiva, sabemos por e9periencia que los desarrolladores r pidamente adoptan la actitud de dise*ar la forma en que van a resolver la operacin del soft,are. /l espritu del contrato es poner de relieve una declaracin de los cambios de estado, absteni)ndose de ofrecer los medios de una solucin. 3o olvide establecer una memoria entre los ob(etos actuales y los de creacin reciente, definiendo para ello la formacin de una asociacin. 'or e(emplo, si no es suficiente que una nueva instancia <entasLineade'roducto se genere cuando ocurre la operacin introducir'roducto. 6na vez finalizada la operacin, deber ser verdad que la instancia reci)n creada fue asociada a <entaJ por tanto, o 8a instancia <entaLineade'roducto fue asociada a la <enta 0asociacin formada1.
1..1..1 E error '8s !recue("e e( a preparaci*( de co("ra"os

/l problema m s comIn consiste en olvidar incluir la formacin de asociaciones. .obre todo cuando se crean nuevas instancias, muy probablemente ser necesario haber establecido las asociaciones a varios ob(etos. 3o lo olvide.
1..16 -o("ra"os para e caso de uso -o'prar produc"os
1..16.1 -o("ra"o para i("roducir&roduc"o

8%n'&a'% N%3(&e6 Re#p%n#a(ilidade#6 Tip%6 Re)e&encia# c&u7ada#6 N%'a#6 EEcepci%ne#6 Salida6 <&ec%ndici%ne#6 <%#c%ndici%ne#6 introducir9roducto ,cup5 n>mero! cantidad5 entero-. $apturar ,registrar- la 'enta de un producto y agregarla a la 'enta. 1esplegar la descripci#n del producto y su precio. (istema. Funciones del sistema5 2A.A! 2A.E! 2A.P. $asos de uso5 $omprar productos 6tilice el acceso superrpido a la base de datos. (i el $69 no es 'lido! indique que se cometi# un error. El sistema conoce el $69.
(i se trata de una nue'a 'enta! una Denta fue creada )creacin de instancia6. (i se trata de una nue'a 'enta! la nue'a Denta fue asociada a <91G ,asociacin "ormada o "ormacin de asociaciones -. (e cre# una instancia DentasLineadeCroducto )creacin de instancia6. (e asoci# una instancia DentasLineadeCroducto a la Denta ,asociacin "ormada6. (e estableci# DentasLineadeCroducto.cantidad con el 'alor de cantidad )modi"icacin de atributo6. 3a instancia DentasLineadeCroducto fue asociada a una Especi"iciondeCroducto, basado esto en la correspondencia del c#digo uni'ersal ,asociacin "ormada6.
1..16.$ -o("ra"o para "er'i(arBe("a

8%n'&a'% N%3(&e6 Re#p%n#a(ilidade#6 Tip%6 Re)e&encia# c&u7ada#6 N%'a#6 EEcepci%ne#6 Salida6 <&ec%ndici%ne#6 <%#c%ndici%ne#6 terminarGenta,-. 2egistrar que es el final de la captura de los productos de la 'enta y desplegar el total de la 'enta. (istema. Funciones del sistema5 2A.B. $asos de uso5 $omprar productos (i no est realizndose una 'enta! indicar que se cometi# un error. El sistema conoce el $69.
Estableci# Denta.esta+erminada en verdadero )modificaci#n de atributo6.
1..16.% -o("ra"o para e!ec"uar&ago

8%n'&a'% N%3(&e6 Re#p%n#a(ilidade#6 Tip%6 Re)e&encia# c&u7ada#6 N%'a#6 EEcepci%ne#6 efectuar9ago ,monto5 ;>mero o $antidad-. 2egistrar el pago! calcular el saldo e imprimir el recibo. (istema. Funciones del sistema5 2B.A. $asos de uso5 $omprar productos (i la 'enta no est concluida! indicar un error. (i el monto es menor que la 'enta total! indicar que se cometi# un error. Salida6 <&ec%ndici%ne#6 <%#c%ndici%ne#6 (e cre# un Cago ,creaci#n de instancia-. (e asign# a Cago.monto*"recido el 'alor de monto ,modificaci#n de atributo-. (e asoci# el Cago a la Denta ,relaci#n formada-.
(e asoci# la Denta a la +ienda para agregarla al registro hist#rico de las 'entas terminadas ,relaci#n formada-.
1..1? -o("ra"os para e caso de uso I(icio 1..1?.1 -o("ra"o para I(icio
8%n'&a'% N%3(&e6 Re#p%n#a(ilidade#6 Tip%6 Re)e&encia# c&u7ada#6 N%'a#6 EEcepci%ne#6 Salida6 <&ec%ndici%ne#6 <%#c%ndici%ne#6 inicio,-. @nicializar el sistema. (istema.
(e cre# una instancia +ienda, +CDD, ;atalogodeCroductos y Especi"icacionesdeCroducto ,creaci#n de instancia-. (e asoci# ;atalogodeCroductos a Especi"icacionesdeCroducto ,asociaci#n formada-. (e asoci# +ienda a ;atalogodeCroductos ,asociaci#n formada-. (e asoci# +ienda a +CDD ,asociaci#n formada-. (e asoci# +CDD a ;atalogodeCroductos ,asociaci#n formada-.
1..17 -a',ios de 'ode o co(cep"ua /stos contratos sugieren la e9istencia de un dato que todava no ha figurado en el modelo conceptual% la terminacin de la captura del producto en la venta. 8o modifica la especificacin terminar<enta) y la especificacin efectuar'ago lo prueba como precondicin. 6na forma de representar esta informacin es e9presarla como un atributo estaTerminada 0o captura+staTerminadaB de la venta, por medio de un valor booleano%
Genta e#'aTe&3inada6 (%%lean% fecha hora
.e cuenta con otras soluciones alternas para representar el estado cambiante del sistema. 6n m)todo es el pa"r*( de es"ado, que estudiaremos en un captulo subsecuente.
1..1< Gode os 'ues"ra

8os contratos que rigen las operaciones del sistema forman parte del modelo del comportamiento del sistema, el cual describe la interfaz e9terna y el comportamiento de todo el sistema 0figura 1D.:1.
7odelo de anlisis
a.modelo est tico b.modelo din mico
7odelo de casos de uso del anlisisb
7odelo conceptuala
7odelo del comporta miento del sistemab
7odelo de estado del anlisisb
$asos de uso . de alto ni'el . esenciales

1iagramas de casos de uso
1iagramas de estructura esttica para los conceptos del dominio
1iagramas de secuencias del sistema $ontratos para operaciones del sistema
1iagramas de estado para conceptos y casos de uso
1igu&a 10.+ 7odelo de anlisis.

Grai Gum Ly Patrones Recor Regi Do

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Grai Gum Ly Patrones Recor Regi Do

Enviado por

Direitos autorais:

Formatos disponíveis

1

ANLISIS Y DISEO ORIENTADOS A OBJETOS

Aplicacin del lenguaje U L ! del an"li#i# ! el di#e$% %&ien'ad%# a %(je'%#

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

Figura 1.1 Temas y habilidades que se incluyen en el libro

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

<odo lo anterior lo ejemplificamos dentro del conte4to de un estudio de casos.

La asignacin de responsabilidades a los componentes es la habilidad ms importante del diseo.

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

,-u. #%n el an"li#i# ! el di#e$%/

,-u. #%n el an"li#i# ! el di#e$% %&ien'ad%# a %(je'%#/

Anlisis orientado a objetos: conceptos!

@n'estigaci#n del problema

1igu&a A.B (ignificado de las acti'idades de desarrollo.

$oncepto del dominio

2epresentaci#n en el anlisis de conceptos

2epresentaci#n en un lenguaje de programaci#n orientado a objetos

9ublic class 3ibro H public 'oid print,-: pri'ate (tring title:

1igu&a 1.+ 3a orientaci#n a objetos se centra en la representaci#n de objetos.

Una anal%g5a6 %&gani7acin de la e3p&e#a

La organizacin de una empresa y el anlisis y el diseo orientados a objetos guardan semejanzas.

MicroChaos est creciendo rpidamente...

1.5.2 Qu son los procesos de negocios?

1.5.3 Cules son los papeles o las unciones en la organi!aci"n?

1igu&a 1.0 $onceptos en la empresa.

8nlisis y diseo orientados a objetos 8nlisis de requerimientos

8nlisis del dominio

1.5.# Qu unciones cumple cada empleado? C"mo cola$ora el personal?

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

Un eje3pl% del an"li#i# ! del di#e$% %&ien'ad%# a %(je'%#

Un simple ejemplo nos permite ver todo el panorama.

1.%.1 &e inici"n de los casos de uso

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

1.%.2 &e inici"n de un modelo conceptual

De)ini& l%# ca#%# de u#%

De)ini& el 3%del% c%ncep'ual

De)ini& l%# diag&a3a# de c%la(%&acin

De)ini& l%# diag&a3a# de di#e$% de cla#e#

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

1.%.3 &e inici"n de los diagramas de cola$oraci"n

De)ini& l%# ca#%# de u#%

De)ini& el 3%del% c%ncep'ual

De)ini& l%# diag&a3a# de c%la(%&acin

De)ini& l%# diag&a3a# de di#e$% de cla#e#

1.%.# &e inici"n del dise'o de clases

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

De)ini& l%# ca#%# de u#%

De)ini& el 3%del% c%ncep'ual

De)ini& l%# diag&a3a# de c%la(%&acin

De)ini& l%# diag&a3a# de di#e$% de cla#e#

&ugador nombre jugar,A &uega A

1ado B 'alor7ostrado lanzar,B

1.%.5 (esumen del e)emplo del )uego de dados

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

(istema de informaci#n de la biblioteca

8Q1 orientados a objetos 1escomposici#n por objetos o conceptos $atlogo Dibliotecario

8Q1 estructurados 1escomposici#n por funciones o procesos (istema

Ad?e&'encia6 el @an"li#i#A ! el @di#e$%A pueden p&%?%ca& gue&&a# 'e&3in%lgica#

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

. qu . requerimientos . in'estigaci#n del dominio . c#mo . soluci#n l#gica

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

1 ANLISIS Y DISEO ORIENTADOS A OBJETOS

$.6 La !ase de a p a(eaci( + de a e a,oraci(