Módulo 1 Modelos y Proceso de desarrollo de Software.
1.1- Modelos, conceptos. ¿Qué es un modelo y por qué modelamos? Los proyectos de software que fracasan lo hacen por circunstancias propias, pero todos los proyectos con éxito se parecen en muchos aspectos. Entre todos los aspectos que hacen que un proyecto tenga éxito uno en común es el uso del modelado. El modelado es una técnica de Ingeniería proada y ien aceptada. !e construyen modelos arquitect"nicos de casas y edificios para ayudar a sus usuarios a #isuali$ar el producto final antes que el mismo esté construido. Incluso podemos elaorar modelos matem%ticos para anali$ar los efectos de #ientos o terremotos sore los edificios. &n modelo es una simplificaci"n de la realidad. &n modelo proporciona los planos de un sistema. 'ueden ser planos generales, que ofrecen una #isi"n gloal del sistema en consideraci"n, así como planos detallados. &n uen modelo incluye, para un ni#el de astracci"n dado, los elementos que tienen gran influencia y omite aquellos menores que no son rele#antes. (odo sistema puede ser caracteri$ado desde diferentes perspecti#as, utili$ando diferentes modelos. &n modelo puede p uede ser estructural resaltando la organi$aci"n del sistema o puede ser de comportamiento, destacando su din%mica. !e construyen modelos para comprender me)or el sistema que estamos desarrollando. * tra#és del modelado se persiguen los siguientes o)eti#os+ •
•
•
Los modelos ayudan a #isuali$ar c"mo es, o queremos que sea un sistema. Los modelos permiten especificar comportamiento de un sistema.
la
estructura
o
el
Los modelos proporcionan plantillas que sir#en de guía en la construcci"n de un programa. 1
•
Los modelos documentan las decisiones que se han adoptado.
-onstruimos modelos de sistemas comple)os porque es difícil comprender el sistema en su totalidad. El ser humano tiene una capacidad limitada para comprender y aordar la comple)idad, por ello a tra#és del modelado podemos reducir el prolema que se est% estudiando y enfocarnos en un aspecto a la #e$. En general, aún en el proyecto m%s simple, los desarrolladores siempre reali$an alguna acti#idad de modelado como un osque)o en ho)a de papel o en algún software graficador. !in emargo, estos modelos informales no proporcionan frecuentemente un lengua)e común que pueda compartirse entre todos los desarrolladores y no siempre queda deidamente documentado. *sí como existe un lengua)e común para reali$ar planos en la industria de la construcci"n, en la Ingeniería -i#il, Eléctrica, entre otros, tamién es eneficioso para una empresa de software que todos sus desarrolladores utilicen un lengua)e común para el modelado del software.
Principios !sicos de modelado -omo se plantea en el liro “El lenguaje Unificado de Modelado”, la experiencia en el uso del modelado sugiere los siguientes cuatro principios %sicos /ooch 0., umaugh 2. y 2acoson I., 1333, p%gs. 4,56+
•
“La elección de los modelos a crear tiene mucha influencia sobre cómo se aborda el problema y cómo de da forma a la solución.”
Esto quiere decir que hay que elegir ien los modelos. Los modelos adecuados pueden arro)ar mucha lu$ sore los prolemas de desarrollo m%s complicados, rindando una comprensi"n que no podríamos otener de otra manera. *hora ien, si se incurre en la utili$aci"n de modelos err"neos o inadecuados, éstos desorientar%n haciendo que uno se centre en cuestiones irrele#antes. •
“Todo modelo puede ser epresado a distintos ni!eles de precisión.”
Los me)ores tipos de modelos son aquellos que permiten elegir el grado de detalle dependiendo de quién est% #iendo el sistema y por qué necesita #erlo. Lo que un usuario final espera de un modelo del sistema no es lo mismo que necesita un dise7ador. &n analista o un usuario final se centrar%n en 8qué9 hace el sistema: un dise7ador;desarrollador se
centrar% en el 8c"mo9. (anto unos como otros querr%n #isuali$ar un sistema a diferentes ni#eles de detalle en diferentes momentos. •
“Los mejores modelos son los "ue est#n ligados a la realidad.”
(odos los modelos simplifican la realidad: lo importante es que esta simplificaci"n no enmascare ningún detalle importante. Es me)or tener modelos que tengan una clara conexi"n con la realidad y donde esta conexi"n sea déil saer concretamente c"mo se apartan estos modelos del mundo real. •
“$o es suficiente confeccionar un %nico modelo. Todo sistema no tri!ial se aborda mejor a tra!&s de un conjunto de modelos casi independientes.”
!i por e)emplo, se estu#iera reali$ando la construcci"n de una casa, no hay un único con)unto de planos que indiquen todos sus detalles sino que se necesitar%n planos de planta, de electricidad, de lo$as, de agua, entre otros. Lo mismo se aplica para los sistemas de software. 'ara comprender la arquitectura de tales sistemas se necesitan #arias #istas complementarias y entrela$adas. -uando se hala de modelos 8casi independientes9 se refiere a tener modelos que podemos construir y estudiar separadamente pero que est%n interrelacionados.
1."- #ipos de metodolo$%as &oncepto de Metodolo$%a. En principio podemos definir una metodología como 8... un conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de sistemas de información9 , según lo expresa 'iattini ==>, p%g. 436?
citando a @addison ? . Ae acuerdo a esta definici"n, una metodología es entonces un con)unto de componentes que especifican+ •
-"mo di#idir un proyecto en etapas.
•
Las tareas que se lle#an a cao en cada etapa. <
•
Las salidas que se producen y cu%ndo se deen producir.
•
Las restricciones se aplican.
•
Las herramientas que se #an a utili$ar.
•
-"mo se gestiona y controla un proyecto.
-onsiderando una definici"n m%s genérica, podemos decir que una metodología de desarrollo es un conjunto de procedimientos, t&cnicas, herramientas y un soporte documental "ue ayuda a los desarrolladores a reali'ar un nue!o soft(are . Bormalmente consistir% en una serie de fases
descompuestas en sufases m"dulos, etapas, pasos, entre otras formas de denominaci"n6. Esta descomposici"n del proceso de desarrollo guía a los desarrolladores en la elecci"n de las técnicas que dee elegir para cada estado del proyecto, así como facilita la planificaci"n, gesti"n, control y e#aluaci"n de los proyectos. Una metodolog)a, por lo tanto, representa el camino para desarrollar soft(are de manera sistem#tica.
!e mencionan a continuaci"n algunos conceptos relacionados con las metodologías+ Métodos: Indican c"mo construir técnicamente un sistema. *arcan un
amplio espectro de tareas que incluyen la comunicaci"n, el an%lisis de los requisitos, el modelado de dise7o, la construcci"n de programas, la reali$aci"n de prueas y el soporte. !e asan en un con)unto de principios %sicos que goiernan cada %rea de la tecnología e incluyen acti#idades de modelado y otras técnicas descripti#as. Técnica: Es un método estructurado y repetile para lograr una tarea
específica. Herramientas+ !uministran un soporte automati$ado o semiautomati$ado
para el proceso y los métodos. -uando se integran herramientas para que la informaci"n creada por una herramienta la pueda utili$ar otra, se estalece un sistema de soporte para el desarrollo del software llamada Ingeniería de !oftware *sistido por -omputadora -*!E6.
'(eti)os de las Metodolo$%as. !e pueden identificar, de forma general, tres necesidades principales que se intentan curir con una metodología+
>
•
•
•
@e)ores aplicaciones. Ae todos modos hay que tener en cuenta que el seguimiento de una metodología no asta para asegurar la calidad del producto, sino que esto depende de muchos peque7os factores. &n me)or proceso de desarrollo que identifica las salidas o productos intermedios de cada fase, lo que permite planificar y controlar el proyecto. &n proceso est%ndar en la organi$aci"n, lo que aporta entre otros eneficios una mayor integraci"n entre los proyectos de sistemas en marcha y una mayor facilidad en el camio de personal de un proyecto a otro.
Entre los o)eti#os que pueden tener las metodologías, podemos mencionar+ •
•
•
•
•
•
egistrar los requisitos de un sistema de informaci"n de manera apropiada. 'roporcionar un método sistem%tico de desarrollo de forma que se pueda controlar su progreso. -onstruir un sistema de informaci"n dentro de un tiempo apropiado y costos aceptales. -onstruir un sistema ien documentado y que sea f%cil de mantener. *yudar a identificar lo m%s pronto posile cualquier camio que sea necesario a reali$ar dentro del proceso de desarrollo. 'roporcionar un sistema que satisfaga a todas las personas afectadas por el mismo, ya sean clientes, directi#os, auditores, usuarios.
&aracter%sticas deseales en una uena Metodolo$%a. Entre las características deseales que deería incluir una metodología se pueden destacar las siguientes+
C
•
Existencia de reglas predefinidas+ La metodología deería indicar
formalmente reglas que definan sus fases, las tareas, productos intermedios, técnicas y herramientas a utili$ar. •
Coertura total del ciclo de desarrollo: Aee indicar los pasos a
seguir para curir desde el planteamiento de un sistema hasta su mantenimiento. •
!erificaciones intermedias: Aee contemplar la reali$aci"n de
#erificaciones sore los productos generados en cada fase para comproar su correcci"n. •
Enlace con procesos de gestión: Aee proporcionar una forma de
desarrollar software de manera planificada, controlada y de calidad. •
Comunicación efecti"a: Aeería proporcionar un medio de
comunicaci"n efecti#a entre los desarrolladores para facilitar el traa)o en grupo y con los usuarios. •
#tili$ación sore un aanico amplio de proyectos+ Aee ser
flexile para poder emplearse en proyectos de di#erso tama7o, #ariedad y entorno. •
%&cil formación+ La organi$aci"n dee formar a su personal en
todos los procedimientos y técnicas definidos por la metodología. •
#so de herramientas C'(E + La metodología dee ser soportada por
herramientas automati$adas que me)oren la producti#idad del equipo de desarrollo y la calidad de los productos otenidos. •
Contener acti"idades )ue mejoren el proceso de desarrollo+ Es
necesario definir mediciones que indiquen la calidad y el costo asociado a cada etapa del proceso. Estos datos se utili$ar%n para anali$ar y modificar el proceso para su me)ora. •
(oporte al mantenimiento+ El campo de la e#oluci"n del software
deería ser tenido en cuenta por las metodologías para facilitar las modificaciones sore los sistemas existentes. •
(oporte de la reutili$ación de soft*are: !e deerían incluir
procedimientos para la creaci"n, mantenimiento y recuperaci"n de componentes reutili$ales que no se limiten s"lo al c"digo. La aplicaci"n de patrones de software en las distintas etapas del proceso de desarrollo ayuda a la reutili$aci"n de soluciones de an%lisis y dise7o.
D
#ipos de Modelos de Proceso -omo ya se mencion" anteriormente, una metodología dee curir todo el ciclo de desarrollo de un sistema de software desde su planteamiento hasta su e#oluci"n. Aentro de este ciclo de #ida una porci"n muy importante lo constituye el desarrollo del sistema de software. -ualquier organi$aci"n de ingeniería de software dee descriir un con)unto único de acti#idades para el proceso de software que adopte para el desarrollo del sistema. (amién dee completar cada acti#idad con un con)unto de acciones de ingeniería de software y definir cada acci"n en cuanto a un con)unto de tareas que identifique el traa)o y los productos del traa)o que deen completarse para alcan$ar las metas de desarrollo. Aespués, la organi$aci"n dee adaptar el modelo de proceso resultante y a)ustarlo a la naturale$a específica de cada proyecto, a las personas que lo reali$ar%n y el amiente en el que se e)ecutar% el traa)o. !e mencionan a continuaci"n algunos de los modelos prescripti#os de proceso que consideramos m%s representati#os tal como los presenta oger 'ressman ==D6 en su liro 8Ingeniería de !oftware9 #er /iliografía6, sin que esta enumeraci"n sea exhausti#a ni la única manera de clasificar los mismos. Luego en la &nidad se presentar% el 'roceso &nificado de Aesarrollo.
El ciclo de "ida cl&sico o en cascada+
El modelo en cascada, llamado tamién el ciclo de #ida cl%sico, sugiere un enfoque sistem%tico, secuencial hacia el desarrollo de software tal como se #isuali$a en la siguiente figura+
uente+ Liro 8Ingeniería del !oftware9 F oger 'ressman ==D6, '%g. C=.
4
El modelo en cascada es el m%s antiguo para la Ingeniería de software, sin emargo las críticas reali$adas a este modelo durante las décadas precedentes ocasionaron que aún sus m%s fer#ientes seguidores se hayan cuestionado su eficacia. Entre los prolemas que presenta el modelo en cascada podemos enunciar+ •
•
•
Los proyectos reales rara #e$ siguen el flu)o secuencial que propone el modelo. recuentemente es difícil para el cliente definir todos los requisitos de manera explícita en el inicio del proyecto. &na #ersi"n funcional de los programas s"lo estar% disponile cuando el proyecto esté astante a#an$ado, por lo que el cliente deer% tener paciencia.
La naturale$a lineal del modelo en cascada conduce a situaciones en las cuales algunos miemros del equipo de traa)o deen esperar a otros para terminar tareas dependientes, lo cual 8loquea9 el a#ance del proyecto. !in emargo, este modelo de proceso puede resultar útil en casos donde los requerimientos est%n fi)os y donde el traa)o se realice en forma lineal hasta su conclusi"n. Modelos de procesos incrementales+
@uchas #eces los requisitos iniciales del software est%n ien definidos de manera ra$onale, pero el enfoque gloal del esfuer$o de desarrollo excluye un proceso puramente lineal. *dem%s, es proale que sea necesario proporcionar de manera r%pida un con)unto limitado de funcionalidad para el usuario y luego refinarla y expandirla en las entregas posteriores del software. En estos casos es con#eniente elegir un modelo de proceso dise7ado para producir el software de manera incremental. !e presentan a continuaci"n dos modelos de proceso de este tipo. a El modelo incremental+
El modelo incremental comina elementos del modelo en cascada aplicado en forma iterati#a. -omo se muestra en la siguiente figura, este modelo aplica secuencias lineales de manera escalonada conforme a#an$a el tiempo en el calendario.
5
uente+ Liro 8Ingeniería del !oftware9 F oger 'ressman ==D6, p%g. C.
-ada secuencia lineal produce incrementos en el software. -on frecuencia, el primer incremento es un producto esencial, es decir se consideran los requisitos %sicos pero muchas características complementarias aún no se incorporan. El producto producido se muestra al cliente y como resultado de la e#aluaci"n se desarrolla un plan para el incremento siguiente que afronta la modificaci"n del producto esencial a fin de satisfacer me)or las necesidades del cliente e incorporar características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento hasta producir el producto completo. El desarrollo incremental es útil cuando el personal necesario para una implementaci"n completa no est% disponile: si el producto esencial es ien reciido se agrega el personal necesario para implementar el incremento siguiente. *dem%s los incrementos se pueden planear para mane)ar los riesgos técnicos: por e)emplo, cierta funcionalidad puede requerir el uso de un hardware nue#o que aún no est% disponile entonces se planean los primeros incrementos de manera que se e#ite el uso de este hardware. El modelo -.'+
El desarrollo r%pido de aplicaciones A*6 es un modelo de proceso incremental que resalta un ciclo de desarrollo corto. El modelo A* es una adaptaci"n a 8alta #elocidad9 del modelo en cascada en el que se logra el desarrollo r%pido mediante un enfoque de construcci"n asado en componentes. -on una uena comprensi"n de los requisitos y se limita el %mito del proyecto, el proceso A* permite que un equipo de desarrollo
3
otenga el producto de software completamente funcional dentro de un período muy corto, por e)emplo entre D= y 3= días. En la siguiente figura se ilustra el proceso A*+
uente+ Liro 8Ingeniería del !oftware9 F oger 'ressman ==D6, p%g. C>.
!i una aplicaci"n de negocios se puede modular de modo que cada gran funci"n se pueda completar en menos de tres meses es una candidata para aplicar A*. -ada gran funci"n se puede aordar por un equipo separado aplicando A*, luego se integran y se forma el todo. -omo todos los modelos de proceso, este enfoque presenta algunos incon#enientes+ •
•
•
•
'ara proyectos grandes escalales se necesitan suficientes recursos humanos para crear el número correcto de equipos A*. Los proyectos A* pueden fracasar si los desarrolladores y clientes no se comprometen con las acti#idades r%pidas necesarias para completar el sistema en tiempo re#e. Es prolem%tica la construcci"n de los componentes necesarios para el A* si el sistema no se puede modular en forma apropiada. !i el alto rendimiento es un aspecto importante y se alcan$ar% al con#ertir interfaces en componentes del sistema, este enfoque puede no funcionar.
1=
•
El modelo A* no es apropiado cuando los riesgos técnicos son altos, por e)emplo cuando la nue#a aplicaci"n requerir% muchas nue#as tecnologías.
Modelos de procesos e"oluti"os+
*l igual que todos los sistemas comple)os, el software e#oluciona con el tiempo. Los requisitos del negocio y productos frecuentemente camian durante el proceso de desarrollo: en estos casos una ruta lineal que condu$ca al producto final no ser% real. En estas situaciones los ingenieros de software necesitan un modelo de proceso que haya sido dise7ado de manera explícita para incluir un producto que e#olucione con el tiempo. Los modelos e#oluti#os son iterati#os y se caracteri$an por la forma en que permiten que se desarrollen #ersiones cada #e$ m%s completas del software. !e presentan a continuaci"n dos modelos de proceso de este tipo+ a Construcción de prototipos+
recuentemente los clientes definen un con)unto de o)eti#os generales para el software pero no identifican los requisitos detallados de entrada, proceso o salida. En estos casos y en muchas otras situaciones un modelo de construcci"n de prototipos puede ser de utilidad. En este modelo el proceso se inicia con la comunicaci"n, en la cual el ingeniero de software y el cliente encuentran y definen los o)eti#os gloales para el software, identifican los requisitos conocidos y las %reas del esquema en las que se necesita m%s definici"n. !e plantea entonces con rapide$ una iteraci"n de construcci"n de prototipos y se presenta el modelado en forma de un dise7o r%pido. Este dise7o r%pido se centra en una representaci"n de los aspectos del software que ser%n #isile para el usuario final y conduce a la construcci"n de un prototipo. El cliente;usuario e#alúa el prototipo y con la retroalimentaci"n se refinan los requisitos del software que se desarrollar%. La iteraci"n ocurre cuando el prototipo se a)usta para satisfacer las necesidades del cliente.
11
uente+ Liro 8Ingeniería del !oftware9 F oger 'ressman ==D6, p%g. CC.
!i ien la construcci"n de prototipos se puede utili$ar como un modelo de proceso independiente, se emplea m%s comúnmente como una técnica que puede implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos. La construcci"n de prototipos tamién plantea algunos incon#enientes+ •
•
El cliente #e lo que parece una #ersi"n en funcionamiento del software sin saer que por la prisa de hacer funcionar el prototipo no se ha considerado la calidad del software gloal o la facilidad de mantenimiento a futuro y le cuesta comprender que dee construirse otra #e$ para mantener los altos ni#eles de calidad. @uchas #eces el desarrollador estalece compromisos de implementaci"n para lograr que el prototipo funcione con rapide$ y luego se familiari$a con las selecciones reali$adas y se ol#idan las ra$ones por las que son inapropiadas. El modelo en espiral
El modelo en espiral que fue propuesto originalmente por /. /oehm es un modelo de proceso de software e#oluti#o que comina la naturale$a iterati#a de la construcci"n de prototipos con los aspectos controlados y sistem%ticos del modelo en cascada. -uando se aplica este modelo el software se desarrolla en una serie de entregas e#oluti#as. Aurante las primeras iteraciones la entrega tal #e$ consista en un documento del modelo del sistema o un prototipo, luego
1
durante las últimas iteraciones se otienen #ersiones cada #e$ m%s completas del producto de software. El modelo en espiral que se expone a continuaci"n es una #ariaci"n del modelo original, presentada en el liro 8Ingeniería de !oftware9 de oger 'ressman ==D6 #er /iliografía6.
uente+ Liro 8Ingeniería del !oftware9 F oger 'ressman ==D6, p%g. C5.
En el primer circuito del espiral qui$% se genere la especificaci"n del producto y los pasos siguientes alrededor del espiral producir%n el desarrollo de un prototipo y luego progresi#amente, #ersiones m%s elaoradas del software. En cada paso sore la regi"n de planeaci"n se producen a)ustes al plan del proyecto. * diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de todo el ciclo de #ida del producto de software siguiendo la e#oluci"n del mismo. El modelo en espiral mantiene el enfoque sistem%tico de los pasos que sugiere el modelo en cascada pero lo incorpora al marco de traa)o iterati#o que se adapta menor al mundo real. *simismo, permite a los desarrolladores aplicar la construcci"n de prototipos como un mecanismo para reducir riesgos y en general en cualquier etapa e#oluti#a del producto. Ae todos modos este modelo, al igual que otros, no est% lire de incon#enientes. Es difícil con#encer a los clientes de que el enfoque e#oluti#o es controlale: si un riesgo importante no se descure y administra apropiadamente, surgir%n prolemas.
1<
1.*- &aracter%sticas de los Modelos 'rientados a '(etos +l Paradi$ma 'rientado a '(etos En los @odelos Grientados a G)etos, el sistema se puede !er en términos de percepci"n6 como una colecci"n de o)etos que colaoran entre sí para otener un o)eti#o común. Las operaciones que modifican el estado de los o)etos son sencillas: los o)etos se construyen a partir de otros o)etos lo que lle#a a que los sistemas se puedan construir a partir de componentes proados. 'or lo enunciado anteriormente, las técnicas orientadas a o)etos se pueden utili$ar como medios para el dise7o sencillo de sistemas comple)os. La orientaci"n a o)etos es muy poderosa cuando se cominan #arias tecnologías+ metodologías de *n%lisis y Aise7o Grientado a G)etos, herramientas -*!E Ingeniería de !oftware *sistida por -omputadora6, 'rogramaci"n Hisual, 0eneradores de -"digo, entre otras. El an%lisis y dise7o orientado a o)etos tiene algunas características importantes+ •
•
•
-amian nuestra forma de pensar sore los sistemas. 'ara la mayoría de las personas la forma de pensar GG es m%s natural. -omen$amos a aprender sore ellos desde la infancia por e)emplo, al agitar un sona)ero éste hace ruido6. Aesde una etapa muy temprana categori$amos los o)etos y descurimos su comportamiento. Los sistemas suelen construirse a partir de o)etos ya existentes. Esto lle#a a un alto grado de reutili$aci"n, a una disminuci"n de costos, un menor tiempo de desarrollo y una mayor confiailidad del sistema. La comple)idad de los o)etos que podemos utili$ar sigue en aumento, puesto que nue#os o)etos se construyen a partir de
1>
otros, que a su #e$ est%n constituidos por otros o)etos, y así sucesi#amente. •
*yuda a explotar la potencia expresi#a de los lengua)es de programaci"n asados en o)etos y orientados a o)etos.
+lementos del Modelo de '(etos 'ara todo lo que se considere “orientado a objetos9 un lengua)e de programaci"n, un herramienta -*!E, técnicas de modelado, un proceso de desarrollo, por e)emplo6 el marco de referencia conceptual es el modelo de ojetos. ay cuatro elementos fundamentales en este modelo+ •
*stracci"n
•
Encapsulamiento
•
@odularidad
•
2erarquía
*l decir fundamentales se quiere significar que cualquier modelo que care$ca de alguno de estos elementos no se considera 8orientado a o)etos9. Aesarrollamos a continuaci"n el concepto de cada uno de los elementos fundamentales.
•
'stracción
-omo la define 0rady /ooch, la astracci"n 8denota las características esenciales de un o)eto que lo distinguen de todos los dem%s tipos de o)eto y proporciona así fronteras conceptuales nítidamente definidas respecto a la perspecti#a del oser#ador9. /ooch 0rady, 133D, p%g. >D6. &na astracci"n se centra en la !isión eterna de un o)eto y sir#e para separar el comportamiento esencial de un o)eto de su forma de implementaci"n. En el desarrollo del modelo de o)etos de un sistema se tratar% de construir astracciones de entidades que imiten directamente el #ocaulario de un determinado dominio de prolema.
1C
!e puede caracteri$ar el comportamiento de un o)eto considerando los ser#icios que presta a otros o)etos, así como las operaciones que puede reali$ar sore otros o)etos. Este punto de #ista nos lle#a a concentrarnos en la #isi"n exterior del o)eto, lo que algunos llaman el modelo contractual : la #ista exterior de cada o)eto define un contrato del que pueden depender otros o)etos y que a su #e$ es lle#ado a cao por la #ista interior del propio o)eto a menudo en colaoraci"n con otros o)etos6. Este contrato aarca las responsabilidades de un o)eto, es decir el comportamiento del que se le considera responsale. 'or e)emplo, en un anco uno de los ser#icios ofrecidos es del de -a)a de *horro. Aesde una #ista externa una ca)a de ahorro en un o)eto que sae cu%l es su número de cuenta, a quién pertenece y cu%l es su saldo de manera simplificada6. JKué es su número de cuenta &n #alor numérico de ocho dígitos y su saldo ser% un #alor que represente el monto de dinero actualmente depositado en ella. !us responsailidades ser%n, entre otras+
-onocer su saldo actual
-onocer su número
Incrementar su saldo por un dep"sito
Aisminuir su saldo por una extracci"n
-onocer quién es su titular
@ostrar sus dato
-onocer su fecha de cierre
•
Encapsulamiento
La astracci"n y el encapsulamiento son conceptos complementarios+ la astracci"n se centra en el comportamiento oser#ale de un o)eto, mientras el encapsulamiento se centra en la implementaci"n que da lugar a este comportamiento. El encapsulamiento se consigue mediante la ocultación de información, por el cual se ocultan todos los aspectos de un o)eto que no contriuyen a sus características esenciales. Bormalmente lo que se oculta es la estructura de datos de un o)eto así como la implementaci"n o codificaci"n de sus métodos. 0rady /ooch define el encapsulamiento como 8el proceso de almacenar en un mismo compartimiento los elementos de una astracci"n que constituyen su estructura y su comportamiento: sir#e para separar la
1D
interfa$ contractual de una astracci"n y su implantaci"n9. /ooch 0rady, 133D, p%g. C>,CD6. En nuestro e)emplo de la ca)a de ahorro, por e)emplo, la propiedad saldo podría estar internamente almacenada como+ •
!aldo+ campo de tipo real con dos decimales
G podría estar almacenada de la siguiente manera+ •
•
Importe entero+ campo entero que almacena la cantidad entera del saldo Importe decimal+ campo entero que almacena la cantidad decimal del saldo
-ualquier o)eto 8titular9 que solicite a 8ca)a de ahorro9 que muestre su saldo reciir% como respuesta, por e)emplo, M 1==,C= y nunca se enterar% de qué manera est% internamente guardado este dato, así como tampoco sar% c"mo operan los métodos de ca)a de ahorro para mostrar este saldo. Ae igual manera, cuando a un o)eto 8titular9 le llega una solicitud de ser#icio mensa)e6 por el cual se le pide mostrar su nomre, éste retornar% una cadena de caracteres en la que figuran su apellido, primer nomre y segundo nomre, si lo tu#iera. El o)eto que hi$o la solicitud no sae si el o)eto titular tiene+ &n atriuto 8apellidoNBomre9 Aos atriutos+ apellido nomre (res atriutos+ apellido primerBomre segundoBomre Ae este modo el encapsulamiento permite que se pueda camiar la implementaci"n de un o)eto y que ninguna otra parte del sistema dea ser modificada siempre que no modifique su interfa$ astracci"n6, que es lo que los otros o)etos conocen para poder comunicarse con este o)eto.
•
Modularidad
-omo afirma /ooch Fcitando a LisOo#F 8la modulari$aci"n consiste en di#idir un programa en m"dulos que pueden compilarse separadamente, pero que tienen conexiones con otros m"dulos9. /ooch 0rady, 133D, p%g. D16.
14
En algunos lengua)es las clases y o)etos forman la estructura l"gica de un sistema: se sitúan, entonces, estas astracciones en m"dulos para producir la arquitectura física del sistema. Los m"dulos sir#en como contenedores físicos en los que se declaran las clases y o)etos del dise7o l"gico reali$ado. Especialmente para aplicaciones grandes en las que puede haer #arios cientos de clases el uso de m"dulos es esencial para ayudar a mane)ar la comple)idad. 'ara prolemas muy peque7os el desarrollador podría decidir declarar todas las clases en el mismo paquete. 'ara cualquier situaci"n que se salga de lo tri#ial, es me)or soluci"n agrupar las clases que se relacionan l"gicamente en el mismo m"dulo. Aesde nuestra perspecti#a, concluye /ooch, 8la modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un con)unto de m"dulos cohesi#os y déilmente acoplados9. /ooch 0rady, 133D, p%g. D16.
•
/erar)uía
La )erarquía es una forma de clasificar u ordenar las astracciones. recuentemente un con)unto de astracciones forma una )erarquía y la identificaci"n de estas )erarquías en el an%lisis y dise7o simplifica en gran medida la comprensi"n del prolema. Las dos )erarquías m%s importantes son+ •
•
!u estructura de clases+ la 8)erarquía de clases9 est% dada por la herencia. !u estructura de o)etos+ la 8)erarquía de o)etos9 est% dada por la agregaci"n.
Bo desarrollamos aquí estos conceptos porque se #er%n m%s adelante en las secciones 8elaciones entre -lases9 y 8elaciones entre G)etos9.
'(etos y &lases 01/ET0+ •
*oncepto
-omo lo plantea /ooch, desde la 8perspecti#a de la cognici"n humana8 un o)eto puede ser+
15
? &na cosa tangile y;o #isile. ? *lgo que puede comprenderse intelectualmente. ? *lgo hacia lo que se dirige un pensamiento o acci"n9. /ooch 0rady, 133D, p%g. 3D6. * esta definici"n informal podemos agregar que un o)eto modela alguna parte de la realidad y es por lo tanto algo que existe en el tiempo y en el espacio. *hora ien, los o)etos del mundo real no son el único tipo de o)eto de interés en el desarrollo de software. Existen otros tipos importantes de o)etos que son in#enciones del proceso de dise7o cuyas colaoraciones con o)etos seme)antes sir#en como mecanismos para desempe7ar algún comportamiento de ni#el superior. Esto nos lle#a a una definici"n me)orada según la cual 8un o)eto representa un elemento, unidad o entidad indi#idual e identificale, ya sea real o astracta, con un papel ien definido en el dominio del prolema9. &n o)eto tiene estado, comportamiento e identidad: la estructura y comportamiento de o)etos similares est%n definidos en su clase común.
•
Estado+
/ooch nos proporciona la siguiente definici"n “el estado de un objeto abarca todas las propiedades normalmente est#ticas- del mismo m#s los !alores actuales normalmente din#micos- de cada una de esas propiedades”. /ooch 0rady, 133D, p%g. 356.
&na propiedad es una característica inherente o distinti#a, un rasgo o cualidad que hace que ese o)eto sea ese y no otro. Las propiedades suelen ser est%ticas porque estos atriutos suelen ser inmutales y fundamentales para la naturale$a del o)eto. (odas las propiedades tienen algún #alor. Este #alor puede ser una mera cantidad o puede denotar otro o)eto. !e dice que los #alores son 8normalmente9 din%micos porque en algunos casos los #alores son est%ticos, como en nuestro e)emplo de 8-a)a de *horro9 la propiedad o atriuto6 n%mero no camia, #a a camiar seguramente el #alor del atriuto saldo y proalemente el del atriuto fechae*ierre... !iguiendo con este e)emplo el estado de un o)eto ca)a de ahorro estar% dado por los #alores que adopte la propiedad saldo y fechae*ierre. *sí los estados posiles ser%n+
13
•
-on saldo+ si el #alor de saldo es mayor a cero
•
!in saldo+ si el #alor de saldo es igual a cero
•
-errada+ si el #alor de fechae*ierre es distinto a #acío.
•
*omportamiento+
Bingún o)eto existe de forma aislada. Los o)etos recien acciones y ellos mismos actúan sore otros o)etos. 8El comportamiento es c"mo actúa y reacciona un o)eto, en términos de sus camios de estado y paso de mensa)es9 /ooch 0rady, 133D, p%g. 1=16. es decir, el comportamiento de un o)eto representa su acti#idad #isile y comproale exteriormente. &na operaci"n representa un ser#icio que todos los o)etos de una clase ofrecen a sus clientes. !e reconocen cinco tipos de operaciones sore un o)eto. Los tres tipos m%s comunes de operaciones son los siguientes+
@odificador+ &na operaci"n que altera el estado de un o)eto modifica el #alor de alguno;s de sus atriutos. 'or e)emplo+ depositar, extraer, transferir para un o)eto cajae/horro.
!elector+ &na operaci"n que accede al estado de un o)eto a alguno;s de sus atriutos6 pero no altera ese estado. 'or e)emplo+ mostrarTitular, mostrar0aldo, mostrar$umero*uenta.
Iterador+ &na operaci"n que permite acceder a todas las partes de un o)eto en algún orden perfectamente estalecido. 'or e)emplo, si un o)eto Titular tiene una propiedad nroTel&fono con múltiples #alores para el teléfono particular, laoral, celular6 la operaci"n mostrarTel&fono ser% una operaci"n iteradota.
ay otros dos tipos de operaciones haituales, que representan la infraestructura necesaria para crear y destruir o)etos instancias de una clase6+
-onstructor+ &na operaci"n que crea un o)eto y;o iniciali$a su estado.
Aestructor+ &na operaci"n que liera el estado de un o)eto y;o destruye el propio o)eto.
&nificando las definiciones de estado y comportamiento, eecca Pirfs? /rocO defini" las responsailidades de un o)eto de manera que éstas incluyen el conocimiento que un o)eto mantiene y las acciones que puede lle#ar a cao. =
Las responsailidades de un o)eto son todos los ser#icios que éste proporciona.
•
1dentidad+
En el paradigma orientado a o)etos, la identidad es la propiedad que tiene un o)eto que le permite distinguirse de todos los dem%s o)etos. La mayoría de los sistemas de ases de datos utili$an cla#es de identificaci"n para distinguir o)etos persistentes, me$clando el #alor de un dato con la identidad. En el mundo de los o)etos podemos tener dos de ellos con #alores iguales en todas sus propiedades y seguir siendo dos o)etos distintos cada uno con su propia identidad. 'or e)emplo, puede haer dos o)etos 2ersona que tengan exactamente el mismo nomre, apellido, direcci"n y teléfono, pero eso no significa que sean la misma persona tenemos muchos casos conocidos de padres e hi)os con los mismos nomres y mientras #i#an en la misma casa tamién la misma direcci"n6: en el paradigma orientado a o)etos cada uno de esos o)etos tiene su propia 8identidad9 y son perfectamente identificales. Los sistemas de ases de datos relacionales son incapaces de distinguir entre dos o)etos o instancias con #alores iguales, por ello se hace indispensale contar con una cla#e identificatoria, que en nuestro e)emplo de padre e hi)o sería por e)emplo el número de documento. Esta ser% una cuesti"n importante a considerar si llegado el momento de decidir la forma de persistencia de nuestro modelo orientado a o)etos la elegida es una ase de datos relacional. En este momento har% que disponer de un mecanismo que sal#e las diferencias de amos esquemas de representaci"n.
C2'(E •
*oncepto+
Los conceptos de clase y o)eto est%n estrechamente relacionados, porque no puede halarse de un o)eto sin atenci"n a su clase. !in emargo, existen diferencias entre amos términos. @ientras que un o)eto es una entidad concreta que existe en el tiempo y en el espacio, una clase representa s"lo una astracci"n, la 8esencia9 de un o)eto. En el contexto del an%lisis y dise7o orientado a o)etos, /ooch define una clase como 8un con)unto de o)etos que comparten una estructura común y un comportamiento común9 /ooch 0rady, 133D6. Esto significa que una 1
clase es una descripción de un conjunto de objetos "ue comparten los mismos atributos, operaciones, relaciones y sem#ntica.
Las clases son los loques de construcci"n m%s importantes de cualquier sistema orientado a o)etos. !e pueden utili$ar para capturar el #ocaulario del sistema que se est% desarrollando. Estas clases pueden incluir astracciones que formen parte del dominio del prolema, así como clases que constituyen el dominio de una determinada soluci"n tecnol"gica. !e pueden utili$ar clases para representar cosas que sean software, hardware o puramente conceptuales.
•
3esponsabilidades de una clase+
&na responsailidad es un contrato o una oligaci"n de una clase. *l crear una clase, se est% expresando que todos los o)etos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento. * un ni#el m%s astracto, estos atriutos y operaciones son simplemente las características por medio de las cuales se lle#an a cao las responsailidades de una clase. *l modelar clases, un uen comien$o consiste en especificar las responsailidades de los elementos del #ocaulario. &na clase puede tener cualquier número de responsailidades, aunque en la pr%ctica cada clase ien estructurada tiene al menos una responsailidad y a lo sumo unas pocas. *l ir refinando el modelo se traducir%n estas responsailidades en el con)unto de atriutos y operaciones que me)or satisfagan las responsailidades de la clase. Las responsailidades se enuncian como texto lire+ una frase, una sentencia o, como mucho, un p%rrafo corto.
•
4istas de una clase+
Aeemos distinguir entre la #isi"n externa interfa'6, y la #isi"n interna, implementación6, de una clase. La interfa' de una clase proporciona su #isi"n externa y por lo tanto enfati$a la astracci"n a la #e$ que oculta su estructura y su comportamiento. Esta interfa$ se compone principalmente de las declaraciones de todas las operaciones aplicales a instancias de esta clase o)etos6, pero tamién puede incluir la declaraci"n de constantes, #ariales y excepciones que se necesiten para completar la astracci"n.
'or otro lado, la implementación de una clase es su #isi"n interna, que engloa los secretos de su comportamiento. La implementaci"n de una clase se compone de la implementaci"n de todas las operaciones definidas en la interfa$ de la misma. !e puede especificar la interfa$ de una clase con cualquiera de los tres ni#eles de #isiilidad disponiles+
2%blica+ &na declaraci"n accesile a todos los clientes de esa clase.
2rotegida+ &na declaraci"n accesile s"lo a la propia clase, sus
suclases y clases amigas.
2ri!ada+ &na declaraci"n accesile s"lo a la propia clase y sus clases
amigas. * lo que nos indica la iliografía cl%sica podemos agregar un tipo m%s de #isiilidad generalmente soportado por los lengua)es orientados a o)etos y las herramientas automati$adas de modelado que es la 8 !isibilidad de pa"uete” , esto significa que el elemento el púlico dentro del paquete o susistema en el que se encuentre alo)ado. La implementaci"n de estas características depender% de c"mo lo mane)e el lengua)e de programaci"n elegido. * continuaci"n se muestra una forma de representaci"n gr%fica para una clase, utili$ada en &@L Lengua)e &nificado de @odelado, #er &nidad de este m"dulo6
Nombre+ -ada clase ha de tener un nomre que la distinga de otras
clases. &na clase puede diu)arse mostrando s"lo su nomre, como se muestra a continuaci"n+
<
Atributos: &n atriuto es una propiedad de una clase identificada
con un nomre, que descrie un rango de #alores que pueden tomar las instancias de la propiedad. &na clase puede tener cualquier número de atriutos o no tener ninguno. &n atriuto representa alguna propiedad del elemento que se est% modelando que es compartida por todos los o)etos de esa clase. &n atriuto es una astracci"n de un tipo de dato o estado que puede incluir un o)eto de la clase.
Operaciones+ &na operaci"n es la implementaci"n de un ser#icio
que puede ser requerido a cualquier o)eto de la clase para que muestre su comportamiento, es decir, una operaci"n es una astracci"n de algo que se puede hacer a un o)eto y que es compartido por todos los o)etos de la clase. &na clase puede tener cualquier número de operaciones y por lo menos una operaci"n. * menudo, pero no necesariamente, la in#ocaci"n de una operaci"n sore un o)eto camia los datos o el estado del o)eto. En nuestro e)emplo sería el caso de las operaciones 8depositar69 y 8extraer69. Aependiendo del ni#el de astracci"n en que se esté modelando nos referiremos a responsailidades a ni#el modelado de requisitos y an%lisis6, operaciones en general a ni#el dise7o6 y métodos normalmente durante la etapa de implementaci"n;codificaci"n6, para referirnos a los ser#icios que prestan los o)etos de una clase.
.E2'C304E( E4T.E 01/ET0(
&n o)eto por sí mismo no es demasiado interesante. Los o)etos contriuyen al comportamiento de un sistema colaorando con otros. ay dos tipos de relaciones que se pueden dar entre o)etos+ enlaces y agregaci"n.
•
Enlaces+
-omo nos cita /ooch 8Q el término enlace es definido por umaugh como una conexi"n física o conceptual entre o)etos9. /ooch 0rady, 133D6. &n o)eto colaora con otros a tra#és de sus enlaces con éstos. Esto quiere decir que un enlace denota la asociaci"n específica por la cual un
>
o)eto el cliente6 utili$a los ser#icios de otro o)eto el ser#idor6 o a tra#és de la cual un o)eto puede comunicarse con otro. &n concepto esencial en el paradigma orientado a o)etos, es el hecho de que los o)etos 8colaoran9 entre sí para lle#ar a cao un comportamiento superior. &na colaboración representa la solicitud de un ser#icio desde un o)eto cliente a un o)eto ser!idor para cumplir una responsailidad del cliente. Los o)etos de una clase pueden cumplir una responsailidad por sí solos o pueden requerir la asistencia de otros o)etos de otras clases6. !e dice que un o)eto ! colaora con otro o)eto -, si el o)eto - para cumplir con una responsailidad, necesita en#iar algún mensa)e a ! solicit%ndole un ser#icio. Aesde el punto de #ista del cliente, 8-9, cada una de sus colaoraciones est%n asociadas con una responsailidad particular implementada por el ser#idor, 8!9. &n mensa)e en#iado de un o)eto a otro representa la existencia de un enlace entre amos. Los mensa)es se muestran como líneas dirigidas, que representan su direcci"n, con una etiqueta que nomra al propio mensa)e. *unque el paso de mensa)es es iniciado por el cliente y dirigido hacia el ser#idor los datos pueden fluir en amas direcciones a tra#és de un enlace+
del cliente al ser#idor+ par%metros
del ser#idor al cliente+ respuesta
!upongamos que el o)eto 8ca)aAe*horro9, que conoce quién es su 8titular9, como parte de su responsailidad de mostrar sus datos completos dee mostrar el nomre del titular. Entonces necesita pedirle al o)eto (itular que le retorne su nomre, para ello le en#iar% un mensa)e indic%ndole tal solicitud. El o)eto (itular responder% retorn%ndole su nomre. *sí se manifiesta el enlace entre amos o)etos. Esto puede representarse gr%ficamente de la siguiente manera+
El gr%fico donde se muestran los enlaces entre o)etos se denomina 8iagrama de *olaboraciones” y en general se utili$a durante el modelado de an%lisis.
C
•
/gregación+
La agregaci"n denota una )erarquía todo;parte, en la cual un o)eto del todo tiene o contiene o)etos de la parte. La agregaci"n puede o no denotar contenci"n física. 'or e)emplo, un aeroplano se compone de alas, motores, tren de aterri$a)e+ es un caso de contenci"n física. En otro e)emplo, un accionista tiene acciones, pero las acciones no son de ninguna manera parte física del accionista. Esta última relaci"n todo;parte es m%s conceptual y por lo tanto menos directa que la agregaci"n física de las partes que forman un aeroplano. !e desarrolla este tema con m%s detalle en el punto siguiente, 8elaciones entre -lases9.
.E2'C304E( E4T.E C2'(E(
Las clases, al igual que los o)etos, no existen aisladamente. *ntes ien, para un dominio de prolema específico las astracciones cla#e suelen estar relacionadas por #ías muy di#ersas e interesantes, formando la estructura de clases. Existen tres tipos %sicos de relaciones entre clases, en &@L+
0enerali$aci"n;Especiali$aci"n, que denota una relaci"n del tipo 8es un9, 8padre;hi)o9, conocida como herencia.
*sociaci"n, que denota alguna dependencia sem%ntica entre clases de otro modo independientes.
Aependencia, es una relaci"n de uso, se usar%n cuando se quiera indicar que un elemento utili$a a otro. &no de los usos m%s frecuentes de la dependencia es para modelar una #isiilidad temporal desde los o)etos de una clase hacia los o)etos de otra.
•
5erencia+
La herencia es una implantaci"n de la generali$aci"n. La generali$aci"n estalece que las propiedades de un tipo se aplican a sus sutipos. La herencia hace que la estructura de datos y operaciones de una clase padre6 estén disponiles para su reutili$aci"n por parte de sus suclases
D
hi)os6. La herencia de las operaciones de una superclase permite que las clases compartan el c"digo en #e$ de #ol#erlo a definir6. La herencia de estructura de datos permite la reutili$aci"n de la estructura. En términos sencillos, la herencia es una relaci"n entre clases en la que una clase comparte la estructura y;o el comportamiento definidos en una herencia simple6 o m%s clases herencia múltiple6. La clase de la que otras heredan se denomina superclase o clase padre y la clase que hereda de otra o m%s clases se denomina subclase o clase hija. * menudo, una suclase a7ade atriutos y operaciones a los que hereda de sus padres, pero tamién puede redefinir el comportamiento heredado. &na operaci"n de un hi)o con la misma signatura nomre, par%metros y #alor de retorno6 que una operaci"n del padre, redefine la operaci"n heredada del padre: esto se conoce como polimorfismo, haciendo alusi"n a una operaci"n que adopta #arias formas de implementaci"n según haya sido redefinida en las clases hi)as. &na clase puede tener uno o m%s padres o ien no tener ninguno. &na clase sin padres y uno o m%s hi)os se denomina ra)' o clase base . &na clase sin hi)os se denomina clase hoja. &na clase con un único padre se dice que utili$a herencia simple: una clase con m%s de un padre se dice que utili$a herencia múltiple. Las clases ho)as son de las que se espera que existan instancias, es decir o)etos, por ello se las denomina tamién clases concretas. Las clases sin instancias se llaman clases abstractas. &na clase astracta se redacta con la idea de que las suclases a7adan elementos a su estructura y comportamiento, usualmente completando la implementaci"n de sus métodos. Ae modo que nunca existir%n o)etos de una clase astracta. 0r%ficamente, la generali$aci"n se representa como una línea dirigida continua, con una punta de flecha #acía apuntando al padre, como se muestra en el siguiente e)emplo+
4
Observación: La simología que se est% utili$ando para graficar las relaciones entre clases es
la estalecida por
[email protected]
•
/sociación+
&na asociaci"n es una relaci"n estructural que especifica que los o)etos de una clase est%n conectados con los o)etos de otra. &na asociaci"n s"lo denota una dependencia sem%ntica entre dos clases pero no estalece la forma exacta en que una clase se relaciona con la otra: s"lo puede denotarse esa sem%ntica nomrando el papel que desempe7a cada clase en relaci"n con la otra. Aada una asociaci"n entre dos clases se puede na#egar desde un o)eto de una clase hasta un o)eto de la otra. 0r%ficamente, una asociaci"n se representa como una línea continua que conecta la misma o diferentes clases+
5
&n concepto importante a modelar respecto de una asociaci"n es la na#egaci"n. La na"egación de una asociaci"n específica que dado un o)eto perteneciente a la clase de un extremo se puede llegar f%cil y directamente a los o)etos de la clase del otro extremo, normalmente deido a que el o)eto inicial almacena algunas referencias a los o)etos en el destino. La direcci"n de la na"egación indica qué clase es la que contiene la referencia hacia la otra determina 8quién conoce a quién96.
'uede ocurrir que en algunos casos la asociaci"n necesite ser na#egale en amos sentidos. 'or e)emplo+
'ara mostrar los datos completos de una factura es necesario que factura cono$ca al cliente al que corresponde.
'ara mostrar un resumen de cuenta de un cliente es necesario que cliente cono$ca las facturas que le corresponden.
Esta situaci"n se modela de la siguiente manera+
3
G tamién se puede modelar así+
Es legal que amos extremos de una asociaci"n estén conectados a la misma clase. Esto significa que, dado un o)eto de una clase, se puede conectar con otro;s o)eto;s de la misma clase. * este tipo de asociaciones se les denomina reflei!as. 'or e)emplo+
En este e)emplo se recurri" a otro elemento con el que podemos 8adornar9 una asociaci"n+ la definici"n de un rol+ -uando una clase participa en una asociaci"n, tiene un rol específico que )uega en la asociaci"n: un rol es simplemente la cara que la clase de un extremo de la asociaci"n presenta a la clase del otro extremo. En muchas situaciones de modelado, es importante se7alar cu%ntos o)etos pueden conectarse a tra#és de una instancia de la asociaci"n. Este 8cu%ntos9 se denomina multiplicidad de la asociaci"n y se escrie como una expresi"n que se e#alúa a un rango de #alores o a un #alor explícito. -uando se indica una multiplicidad en un extremo de una asociaci"n se est% especificando que para cada o)eto de la clase en el extremo opuesto
<=
dee haer tantos o)etos en este extremo. !e puede indicar una multiplicidad de exactamente uno 16, cero =6, muchos S6, uno o m%s 1..S6 o un #alor exacto por e)emplo, C6. La multiplicidad se indica en el extremo que corresponde a la na#egaci"n.
•
/gregación+
La agregaci"n es un tipo especial de asociación. Las relaciones de agregaci"n entre clases tienen un paralelismo directo con las relaciones de agregaci"n entre los o)etos correspondientes a esas clases. La agregaci"n es una relaci"n 8todo;parte9 en la cual una clase representa una cosa grande el 8todo96, que consta de elementos m%s peque7os las 8partes96. epresenta una relaci"n del tipo 8tiene un9, o sea, un o)eto del todo tiene o)etos de la parte. 0r%ficamente la agregaci"n se representa como se muestra a continuaci"n+
La agregaci"n puede o no denotar contenci"n física. (enemos entonces dos posiilidades en cuanto a la relaci"n de agregaci"n+
<1
Agregación por Valor+ Es un tipo de relaci"n, en la que el tiempo de
#ida del o)eto incluido est% condicionado por el tiempo de #ida del que lo incluye. Este tipo de relaci"n es tamién llamada Composición el G)eto ase se construye a partir del o)eto incluido, es decir, es Tparte;todoT6. En este tipo de relaci"n el o)eto 8parte9 no existe independientemente del o)eto 8todo9 que lo contiene. Esto significa que el tiempo de #ida de amos o)etos est% íntimamente relacionado+ cuando se crea una instancia del todo, se crea tamién por lo menos una instancia de la parte: cuando se destruye el o)eto 8todo9 esto implica la destrucci"n de todos los o)etos 8parte9 relacionados a él. En el e)emplo, cuando se crea una instancia de 'edido un o)eto pedido6 es porque existe al menos una instancia o)eto6 de la clase Aetalle'edido.
Agregación por Referencia: Es un tipo de relaci"n, en donde el
tiempo de #ida del o)eto incluido es independiente del que lo incluye. Este tipo de relaci"n es comúnmente llamada *gregaci"n el o)eto ase utili$a al incluido para su funcionamiento6. *lgunos autores llaman tamién a esta forma de agregaci"n 8compartida9 porque es posile que un o)eto 8parte o contenido9 corresponda a m%s de un o)eto 8todo o contenedor9 'or e)emplo+ Esta forma de graficar la agregaci"n es opcional. Bo es oligatorio determinar el tipo de agregaci"n sore todo durante el modelado de requerimientos o an%lisis, pero es útil comprender el significado de amas y es m%s útil determinar concretamente el tipo de agregaci"n en la acti#idad de dise7o.
<
•
ependencia+
Este tipo de relaci"n se define en el liro de &@L como 8una relaci"n de uso que declara que un camio en la especificaci"n de un elemento puede afectar a otro elemento que la utili$a9, esto representa la dependencia que tiene una clase de otra. /ooch, umaugh y 2acoson, 13336 0eneralmente las dependencias se utili$an para indicar que una clase utili$a a otra como argumento en la signatura de una operaci"n, esto significa que la clase dependiente otiene #isiilidad de la otra clase porque recie un o)eto como par%metro de alguna operaci"n. Esto es claramente una relaci"n de uso+ si la clase utili$ada camia, la operaci"n de la otra clase puede #erse tamién afectada, porque la clase utili$ada puede presentar ahora una interfa$ o comportamientos diferentes. 0r%ficamente estas relaciones se representan con una línea discontinua dirigida hacia la clase de la cual se depende, como se muestra a continuaci"n+
La dependencia se utili$a para representar la #isiilidad de par%metro. En nuestro e)emplo *ondicion2ago se hace #isile para *uota porque un o)eto de esta última clase reciir% como par%metro de entrada para su operaci"n 8calcular3ecargo9, un o)eto de la clase *ondicion2ago.
-3'5.'M' -E C2'(E(
Los diagramas de clases son los m%s utili$ados en el modelado de sistemas orientados a o)etos. &n diagrama de clases muestra un conjunto de clases as) como sus relaciones.
Los diagramas de clases se utili$an para modelar la #ista de dise7o est%tica de un sistema #er el punto .1 Histas de &@L en este mismo m"dulo6. 'rincipalmente esto incluye modelar el #ocaulario del sistema. &n
<<
diagrama de clases se puede utili$ar para modelar las clases l"gicas, que son típicamente la clase de cosas de las que hala la gente de negocios de una organi$aci"n los usuarios6. En este caso se usa el diagrama de clases para modelar el 8dominio del prolema9 pero tamién se utili$a el diagrama de clases para mostrar las clases de implementaci"n, que son las 8cosas9 con las que traa)an los programadores. Este enfoque se aplica a partir de la acti#idad de Aise7o de un sistema. En un diagrama de clases podemos encontrar+
-lases
elaciones+ herencia, asociaci"n su #ariante+ agregaci"n6, dependencia.
Indicadores de multiplicidad y na#egailidad
Bomre de ol
En este diagrama podemos representar las clases indicando s"lo su nomre en este caso sería un diagrama are#iado6 o mostrando tamién los atriutos y;o operaciones. * continuaci"n se muestra un fragmento de un diagrama de clases uniendo algunos de los e)emplos indi#iduales ya #istos+
•
0imbolog)a del iagrama de *lases
En el gr%fico que figura a continuaci"n, se resumen todos los elementos que pueden estar presentes en un diagrama de clases+
<>
1.- Metodolo$%as estructuradas )s. Metodolo$%as 'rientadas a '(etos El tema del car%cter del software es tratado por 0rady /ooch entre otros autores, al explicar que la 8comple)idad innata9 del software se deri#a de+
•
La comple)idad del dominio del prolema.
•
La dificultad de gestionar el proceso de desarrollo.
•
La flexiilidad que se puede alcan$ar a tra#és del software.
•
Los prolemas de caracteri$ar el comportamiento de sistemas discretos.
La técnica para dominar la comple)idad de un sistema es descomponerlo en partes m%s y m%s peque7as, cada una de las cuales se puede refinar en forma independiente. (enemos dos formas de descomponer un sistema comple)o+ •
Descomposición algorítmica: Es la forma de descomposici"n
sustentada por el an%lisis y dise7o estructurado. En este caso se di#ide el sistema en elementos funcionales relacionados estructuralmente entre sí. Esta #isi"n enfati$a el orden de los e#entos. •
En este caso la descomposici"n consiste en determinar un con)unto de agentes aut"nomos o)etos6 que colaoran para lle#ar a cao algún comportamiento de ni#el superior. Esta #isi"n resalta los agentes que causan acciones o son su)etos de estas acciones. Descomposición
orientada
a
objetos+
En el liro 8Lengua)e &nificado de @odelado9 #er iliografía6 se plantea que una de las deilidades de las técnicas de an%lisis y dise7o estructurado es el hecho de que hay una desconexi"n %sica entre el modelo de an%lisis y el modelo de dise7o del sistema: no poder sal#ar este aismo genera que el sistema conceido y el sistema construido difieran a medida que transcurre el tiempo. En los sistemas orientados a o)etos, es posile conectar todas las #istas casi independientes de un sistema en un todo sem%ntico. Los métodos de dise7o estructurado surgieron para guiar a los desarrolladores que intentaan construir sistemas comple)os utili$ando los algoritmos como loques fundamentales para su construcci"n. El dise7o estructurado tiene un enfoque descendente+ la unidad fundamental de descomposici"n es el suprograma y se #a modelando en forma de un %rol de modo que cada suprograma reali$a su funci"n llamando a otros suprogramas. 'or otro lado, el dise7o estructurado no contempla los prolemas de astracci"n de datos y ocultaci"n de informaci"n, tampoco responde ien al camio de tama7o cuando se aplica a sistemas muy comple)os.
Los métodos de dise7o orientado a o)etos surgieron para ayudar a los desarrolladores a apro#echar la potencialidad de la programaci"n orientada a o)etos que utili$a las clases y o)etos como loques %sicos de construcci"n. La descomposici"n orientada a o)etos produce sistemas m%s peque7os a tra#és de la reutili$aci"n de mecanismos comunes: a su #e$ los sistemas orientados a o)etos son tamién m%s resistentes al camio y por lo tanto est%n me)or preparados para e#olucionar en el tiempo ya que su dise7o est% asado en formas intermedias estales.
".1- istas de M/ ¿Qué es M/? -omo lo presentan sus creadores, 0rady /ooch, 2ames umaugh e I#ar 2acoson, el Lengua)e &nificado de @odelado &nified @odeling Langua)e, &@L6 es un lengua)e est%ndar para escriir 8planos9 de software. &@L puede utili$arse para #isuali$ar, especificar, construir y documentar los artefactos de un sistema que in#olucra una gran cantidad de software. &@L, como lo estalecen sus autores, es apropiado para modelar desde sistemas de informaci"n en empresas hasta aplicaciones distriuidas asadas en la Pe. &@L, es s"lo un lenguaje no es una metodolog)a- y, por lo tanto, es s"lo una parte de un método de desarrollo de software: fue dise7ado de forma independiente del modelo de proceso de software a aplicar, aunque para utili$arlo "ptimamente, sus autores aconse)an utili$ar un proceso que sea+ dirigido por los casos de uso, centrado en la arquitectura, iterati#o e incremental. -uando decimos que &@L es un lengua)e nos referimos a que un lengua)e proporciona un #ocaulario y las reglas para cominar palaras de ese #ocaulario con el o)eti#o de posiilitar la comunicaci"n. &n lengua)e de modelado es un lengua)e cuyo #ocaulario y reglas se centran en la representaci"n conceptual y física de un sistema. El modelado proporciona una comprensi"n de un sistema. Bunca es suficiente con un único modelo, a menudo se necesitan múltiples modelos conectados entre sí. El #ocaulario y las reglas de &@L indican c"mo crear y leer modelos ien formados, pero no dicen qué modelos se deen crear ni cu%ndo se deerían crear. Usta es la tarea del proceso de desarrollo de software. &n
<4
proceso ien definido guiar% a los desarrolladores a decidir qué artefactos producir, qué acti#idades y qué personal se emplea para crearlos y gestionarlos. &@L es un lengua)e que permite+ •
Visualizar: &n modelo explícito facilita la comunicaci"n. *lgunas
cosas se modelan me)or textualmente, otras se modelan me)or de forma gr%fica. En todos los sistemas hay estructuras que trascienden lo que puede ser representado en un lengua)e de programaci"n. &@L es uno de estos lengua)es gr%ficos, es algo m%s que un con)unto de símolos gr%ficos. Aetr%s de cada símolo en la notaci"n &@L hay una sem%ntica ien definida. *sí, un desarrollador puede construir un modelo en &@L y otro desarrollador o incluso otra herramienta, puede interpretar ese modelo sin amigVedad. •
Especificar+ En este contexto especificar significa construir modelos
precisos, no amiguos y completos. &@L cure la especificaci"n de todas las decisiones de an%lisis, dise7o e implementaci"n que deen reali$arse al desarrollar y desplegar un sistema con gran cantidad de software. •
onstruir: &@L no es un lengua)e de programaci"n #isual, pero sus
modelos pueden conectarse de forma directa a una gran #ariedad de lengua)es de programaci"n. Esto significa que es posile hacer correspondencias desde un modelo &@L a un lengua)e de programaci"n como 2a#a, -WW o Hisual /asic, incluso a talas en una ase de datos relacional o al almacenamiento persistente de una ase de datos orientada a o)etos. Esta correspondencia permite ingeniería directa+ la generaci"n de c"digo a partir de un modelo &@L en un lengua)e de programaci"n. •
Documentar: &na organi$aci"n de software que traa)e ien
produce toda clase de artefactos adem%s de c"digo e)ecutale. Estos artefactos incluyen, entre otros+ requisitos, arquitectura, dise7o, c"digo fuente, planificaci"n de proyectos, prueas, prototipos, #ersiones. 8*rtefacto9 es un término general para cualquier tipo de informaci"n creada, camiada o utili$ada por los traa)adores en el desarrollo del sistema.
<5
Principales elementos del len$ua(e Los tres elementos principales de &@L son+ los loques %sicos de construcci"n de &@L, las reglas que dictan c"mo pueden cominarse esos loques y algunos mecanismos comunes que se aplican a lo largo del lengua)e. En los siguientes cuadros se resumen los elementos principales de &@L.
Los elementos estructurales, en su mayoría, son las partes est%ticas de un modelo y representan cosas que son conceptuales o materiales+
<3
>=
Los elementos de comportamiento son las partes din%micas de los modelos &@L, representan comportamiento en el tiempo y el espacio+
Los elementos de agrupación, son las partes organi$ati#as de los modelos &@L, representan las ca)as en las que puede descomponerse un modelo. ay un elemento de agrupaci"n principal+ los paquetes, que representan un mecanismo de prop"sito general para organi$ar elementos en grupos. &n pa"uete es puramente conceptual, s"lo existe en tiempo de desarrollo. 0r%ficamente se #isuali$a como una carpeta+
Los elementos de anotación, son las partes explicati#as de los modelos &@L, son comentarios que se pueden aplicar para hacer oser#aciones sore cualquier elemento del modelo. ay un tipo principal de elemento de anotaci"n llamado nota, que se grafica de la siguiente manera+
En el siguiente cuadro se explica re#emente el concepto de cada uno de los tipos de relaciones en &@L+
>1
* continuaci"n se explica re#emente el concepto de cada uno de los tipos de diagramas en &@L+
>
istas de un sistema con M/ -ada uno de los in#olucrados en el proyecto de desarrollo usuarios finales, analistas, desarrolladores, integradores de sistemas, encargados de las prueas, encargados de la documentaci"n, )efes de proyecto, entre otros6 reali$an diferentes acti#idades a lo largo del proyecto y cada uno mira al sistema de formas diferentes. La arquitectura de un sistema es el artefacto m%s importante que se puede emplear para mane)ar estos distintos puntos de #ista. (al como se plantea en el liro de &@L, entendemos por arquitectura el con)unto de decisiones significati#as sore+ •
La organi$aci"n de un sistema de software.
•
La selecci"n de elementos estructurales y sus interfaces.
•
!u comportamiento colaoraciones entre esos elementos6.
•
La composici"n de los elementos estructurales comportamiento en susistemas cada #e$ m%s grandes.
y
de
><
•
El estilo arquitect"nico que guía esta organi$aci"n los elementos est%ticos y din%micos y sus interfaces, colaoraciones y su composici"n6.
La ar)uitectura de un sistema se puede descriir a tra#és de cinco #istas relacionadas entre sí, como se muestra en el siguiente gr%fico+
0r%fico de las #istas >W1 F uente+ Liro 8El Lengua)e &nificado de @odelado9 0rady /ooch y otros 13336, '%g. 4.
>>
"."- +l proceso unificado de desarrollo &n proceso es un con)unto de pasos ordenados para alcan$ar un o)eti#o. En la ingeniería de software el o)eti#o es construir un producto de software o me)orar uno existente de modo que satisfaga las necesidades del usuario de forma eficiente y predecile. !n proceso de desarrollo de soft*are es el conjunto de actividades necesarias para transformar los re"uisitos de un usuario en un sistema soft#are$
uente+ Liro 8El 'roceso &nificado de Aesarrollo de !oftware9 I#ar 2acoson y otros ===6, p%g.>.
La comunidad de desarrolladores necesita una forma coordinada de traa)ar. Becesita un proceso que integre las múltiples facetas del desarrollo. Becesita un método común, un proceso que+ •
•
•
•
'roporcione una guía para ordenar las acti#idades de un equipo. Airi)a las tareas de cada desarrollador por separado y del equipo como un todo. Especifique los artefactos que deen desarrollarse. Gfre$ca criterios para el control y la medici"n de los productos y acti#idades del proyecto.
El 6roceso #nificado es un proceso de desarrollo de soft#are "ue utiliza el %enguaje !nificado de &odelado '!&%( para preparar todos los es"uemas de un sistema de soft#are ) fue propuesto por los mismos creadores de !&%: *rad) +ooc,- .ames Rumbaug/ e 0var .acobson$
&@L, como ya se ha mencionado es astante independiente del proceso, lo que significa que se puede utili$ar con diferentes procesos de ingeniería de
>C
software. El 'roceso &nificado es uno de los procesos de desarrollo que se adapta especialmente ien a &@L. Los aspectos definitorios del 'roceso &nificado se resumen en tres frases cla#es+ est% dirigido por casos de uso, centrado en la arquitectura y es un proceso iterati#o e incremental. Estas son las características esenciales de este proceso y son los puntos que se desarrollan a continuaci"n.
".".1- 0iri$ido por caso de uso &n caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales del sistema para cada usuario. Los casos de uso, adem%s de especificar los requisitos de un sistema, guían su dise7o, implementaci"n y pruea: es decir, guían el proceso de desarrollo. Esto es así porque as%ndose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de dise7o e implementaci"n que lle#an a cao los casos de uso. Los ingenieros de pruea pruean la implementaci"n para garanti$ar que se han implementado correctamente los casos de uso. Ae esta manera, los casos de uso adem%s de iniciar el proceso constituyen el hilo conductor del mismo. !in emargo, los casos de uso no se desarrollan aisladamente, sino a la par de la arquitectura del sistema.
"."."- &entrado en la arquitectura 'ara comprender me)or el papel que )uega la arquitectura en la construcci"n de un sistema de software, comparémosla con la arquitectura en la construcci"n de una casa. &na casa contempla distintos puntos de #ista+ la estructura, los conductos de gas, electricidad, agua, fontanería, entre otros aspectos. Esto permite al constructor tener una imagen completa de la casa antes de comen$ar la edificaci"n. Ae la misma manera la arquitectura de un sistema de software se descrie mediante distintas #istas, que incluyen los aspectos est%ticos y din%micos m%s significati#os del sistema. Las distintas #istas y el con)unto de decisiones significati#as que aarca la arquitectura se trataron ya en el punto 8Histas de un !istema con &@L9 p%g.D=6. El concepto de arquitectura software incluye los aspectos est%ticos y din%micos m%s significati#os del sistema.
>D
La arquitectura del sistema surge de las necesidades de la empresa, como las percien los usuarios y los in#ersores, y se refle)a en los casos de uso. !in emargo, tamién se #e influida por muchos otros factores, como la plataforma en que tiene que funcionar el software arquitectura de hardware, sistema operati#o, sistema de gesti"n de ase de datos, protocolos para comunicaci"n en red6, los loques de construcci"n reutili$ales de los que se dispone, consideraciones de implantaci"n, sistemas heredados y requisitos no funcionales por e)emplo, rendimiento, fiailidad, seguridad6. !e necesita una arquitectura para+ •
-omprender el sistema.
•
Grgani$ar el desarrollo.
•
omentar la reutili$aci"n.
•
acer e#olucionar el sistema.
!i nos preguntamos c"mo relacionar los casos de uso con la arquitectura, deemos recordar que cada producto tiene tanto una funci"n como una forma. !e trata de dos fuer$as que deen estar equiliradas para otener un producto con éxito. En este contexto la funci"n corresponde a los casos de uso y la forma a la arquitectura. Los casos de uso deen enca)ar en la arquitectura cuando se lle#en a cao y, a su #e$, la arquitectura dee permitir el desarrollo de todos los casos de uso requeridos. 'odemos resumir el traa)o de un 8arquitecto9 de un sistema el que desarrolla la arquitectura6, en los siguientes pasos+ 1. -rear un esquema en orrador de la arquitectura, comen$ando por la parte que no es específica de los casos de uso por e)emplo, la plataforma6. *unque esta parte de la arquitectura es independiente de los casos de uso, el arquitecto dee poseer una comprensi"n general de los casos de uso antes de comen$ar la creaci"n del esquema arquitect"nico. . (raa)ar con un sucon)unto de los casos de uso especificados, aquellos que representen las funciones cla#e del sistema. -ada caso de uso se especifica detalladamente en términos de susistemas, clases y componentes. <. * medida que se especifican y maduran los casos de uso, se descure m%s de la arquitectura: esto a su #e$ lle#a a la maduraci"n de m%s casos de uso. >. !e dee continuar este proceso hasta que la arquitectura sea estale.
>4
".".*- terati)o e ncremental El desarrollo de un producto de software puede demandar un tiempo considerale. Es pr%ctico di#idir el traa)o en partes m%s peque7as o miniproyectos. -ada miniproyecto es una iteraci"n que resulta en un incremento. Las iteraciones se refieren a pasos en el flu)o de traa)o y los incrementos, al crecimiento del producto. 'ara lograr efecti#idad, las iteraciones deen estar controladas, es decir deen seleccionarse y e)ecutarse en forma planificada. Lo que se implementar% en una iteraci"n se selecciona en ase a dos factores+ 1. La iteraci"n trata un grupo de casos de uso que amplían la utilidad de lo desarrollado hasta el momento. . La iteraci"n trata los riesgos m%s importantes. En cada iteraci"n se identifican y especifican los casos de uso rele#antes, se crea un dise7o utili$ando la arquitectura seleccionada como guía, se implementa el dise7o mediante componentes y se #erifica que los componentes satisfacen los casos de uso es decir, que en cada iteraci"n se hace an%lisis, dise7o, implementaci"n y pruea6. !i una iteraci"n cumple con sus o)eti#os, se continúa con la siguiente: de lo contrario los desarrolladores deen hacer una re#isi"n y proar nue#os enfoques.
".*- 2ases dentro de un ciclo El 'roceso &nificado se repite a lo largo de una serie de ciclos que constituyen la #ida de un sistema. -ada ciclo concluye con una #ersi"n del producto para los clientes. -ada ciclo consta de cuatro fases+ inicio, elaoraci"n, construcci"n y transici"n. -ada fase a su #e$ puede tener #arias iteraciones+
>5
uente+ Liro 8El 'roceso &nificado de Aesarrollo de !oftware9 I#ar 2acoson y otros ===6, '%g.5.
-ada ciclo produce una nue#a #ersi"n del sistema, que es un producto preparado para su entrega. -onsta de c"digo fuente incluido en componentes que puede compilarse y e)ecutarse, manuales y otros productos asociados. 'ara llegar a ese producto, deer%n desarrollarse los siguientes modelos+
uente+ Liro 8El 'roceso &nificado de Aesarrollo de !oftware9 I#ar 2acoson y otros ===6, p%g. 3.
>3
2ases del Proceso nificado -ada ciclo del 'roceso &nificado se di#ide en cuatro fases, cada una de las cuales puede tener #arias iteraciones, como ya #imos. Estas fases son las siguientes+ •
%ase de 3nicio
'rincipalmente esta fase responde a las preguntas sore cu%les son las principales funciones del sistema para sus usuarios m%s importantes, c"mo podría ser la arquitectura del sistema y cu%l es el plan del proyecto, adem%s de cu%nto costar% desarrollar el sistema. !e reali$a un modelo de casos de uso simplificado, con los m%s críticos: la arquitectura es un eso$o que muestra los principales susistemas, se identifican y priori$an los riesgos, se planifica en detalle la fase de elaoraci"n y se estima el proyecto. •
%ase de elaoración
!e especifican en detalle la mayoría de los casos de uso del producto y se dise7a la arquitectura del sistema. La arquitectura se expresa en forma de #istas de todos los modelos del sistema decimos #ista de los modelos porque no son los modelos completos, ya que faltan incorporar casos de uso6. !e crea una línea ase de la arquitectura. •
%ase de construcción
*quí la línea ase de la arquitectura crece hasta con#ertirse en el sistema completo, oteniendo así un producto preparado para ser entregado a los usuarios. •
%ase de transición
En esta fase el producto se con#ierte en una #ersi"n eta. &n número reducido de usuarios, con experiencia, pruea el sistema e informa defectos y deficiencias. •
Los desarrolladores corrigen los prolemas e incorporan las me)oras sugeridas. Esta fase incluye adem%s las tareas de formaci"n del cliente, ayuda en línea y asistencia.
C=
&onceptos !sicos del Proceso Los términos que se definen a continuaci"n se utili$ar%n a lo largo de todo el desarrollo del proceso unificado. •
%lujo de Traajo 78or9flo*
Es un con)unto de acti#idades. &n flu)o de traa)o determina c"mo fluye el traa)o de un traa)ador a otro. 'ara ello se ha identificado primero qué tipos de traa)adores participan en el proceso. Luego se identifica qué artefactos se necesitan crear durante el proceso por cada tipo de traa)ador. Entonces se puede descriir c"mo fluye el proceso a tra#és de los distintos traa)adores y c"mo ellos crean, producen y utili$an los artefactos de los dem%s. &n e)emplo de un flu)o de traa)o es el flu)o de traa)o de los requisitos. Incluye a los siguientes traa)adores+ analista de sistemas, arquitecto, especificador de casos de uso y dise7ador de interfa$ del usuario. !e producen los siguientes artefactos+ modelos de casos de uso, prototipo de interfa$, modelo del dominio, entre otros. •
'rtefacto
Es un término general para cualquier tipo de informaci"n creada, producida, camiada o utili$ada por los traa)adores en el desarrollo del sistema. 'or e)emplo, los diagramas &@L y su texto asociado, los ocetos de la interfa$ del usuario, componentes de c"digo fuente, componentes e)ecutales, entre otros.
•
Traajador
!e denomina así a los puestos de traa)o a los cuales se pueden asignar personas dentro del proyecto. &n tipo de traa)ador es un papel que una persona puede desempe7ar en el desarrollo de software. 'uede ser un especificador de casos de uso, un arquitecto, un ingeniero de componentes, un ingeniero de prueas, por mencionar algunos. -ada traa)ador es responsale de un con)unto completo de acti#idades y de producir un número determinado de artefactos. C1
•
'cti"idades
!on traa)os significati#os para una persona que actúa como traa)ador.
2lu(os de traa(o fundamentales En cada una de las iteraciones del ciclo de #ida del 'roceso &nificado se recorre cada uno de los flu)os de traa)o fundamentales que son+ •
equisitos
•
*n%lisis
•
Aise7o
•
Implementaci"n
•
'ruea
!ore estos flu)os de traa)o, las acti#idades que se reali$an en ellos, los traa)adores que inter#ienen y los artefactos que se producen, tratan las unidades que siguen. En la figura que se muestra a continuaci"n se #isuali$a c"mo se cominan los flu)os de traa)os por cada iteraci"n en cada una de las fases.
C
uente+ Liro 8El 'roceso &nificado de Aesarrollo de !oftware9 I#ar 2acoson y otros ===6, p%g. 11.
C<
