Mdulo 2 Captura y Modelado de Requerimientos.

1

3.1- Captura de requisitos, objetivo de la captura de requisitos Conceptos Bsicos: Requerimiento:

Unrequerimientoesunacaractersticadelsistemaounadescripcindealgo que el sistema es capaz de hacer con el objeto de satisfacer elpropsitodelmismo.

Analizarrequerimientosesmuchomsquedejarescritomeramenteloquequieren los clientes. Es difcil saber exactamente lo que el sistema debehacer.

Los requerimientos son caractersticas que deben incluirse en un nuevosistemaconsiderando:

descripcionesdeserviciosodeaquelloqueelsistemaescapazdehacer,

restricciones que el sistema deba considerar, contemplando lasnecesidadesocondicionesestablecidasporelusuario,

los problemas observados y las mejoras posibles en relacin alsistemaactual.

PropsitosdelosRequerimientos:

1.Permitenquelosdesarrolladoresexpliquencmohanentendidoloqueelclientepretendedelsistema.

2.Indicanalosdiseadoresqufuncionalidadycaractersticasvaatenerelsistemaresultante.

2

3. Indicanalequipodepruebasqudemostraciones llevaracaboparaconvenceralclientequeelsistemaqueseleentregaesloquehabaordenado.

CaractersticasdelosRequerimientos:

Como plantea Shari Pleeger en su libro Ingeniera de Software (verbibliografa), para asegurar que los desarrolladores y los clientescomprendan y utilicen correctamente los requerimientos es importantequeestosltimosseandealtacalidad.

Con este objetivo debe comprobarse que los requerimientos posean lassiguientescaractersticas:

Correcto:Tanto losclientescomo losdesarrolladoresdeben revisar losrequerimientosdefinidosparaasegurarsequenocontenganerrores.

Consistente:Unrequerimientoesconsistentesinoescontradictorioconotrorequerimiento.PorejemplosiunrequerimientodicequeHabrunmximo de 10 puestos de trabajo simultneos y otro requerimientoexpresaque Paraprocesar lospagosenfechadevencimientosepodrtrabajar con 12 puestos simultneos, estos requerimientos soninconsistentes.

Completo: Un requerimiento est completo si no necesita ampliardetalles en su redaccin para su comprensin. Un conjunto derequerimientos es completo si todos los estados posibles, cambios deestado,entradas,productosyrestriccionesestndescriptosenalgunodelosrequerimientos.

Realista:Debecomprobarsequeelsistemapuedahacerloqueelclienteestpidiendo.Aveces,cuandoeltiempodedesarrolloes largo,elclienteintenta anticiparse a las mejoras en tecnologas disponibles e imponerequerimientossobreelestadodelarte.Todos los requerimientosdebenserrevisadosparaasegurarquesonposibles.

Necesario: Un requerimiento es necesario si su omisin provoca unadeficiencia en el sistema a construir. En ocasiones, un requerimientorestringe innecesariamentea losdesarrolladoreso incluye funcionesquenoestndirectamenterelacionadasconelproblemaqueseesttratando.

Verificable: Un requerimiento es verificable cuando puede sercuantificado demanera que permita hacer uso de distintosmtodos deverificacin.Debemospoderprepararpruebasquedemuestrenquesehancumplimentadolosrequerimientos.

3

Rastreable:Debeserposible rastrearcada funcindelsistemahastaelconjuntoderequerimientosquelaestablece.

Tipos de Requerimientos: Unaclasificacintpicadelosrequerimientosdeunsistemadesoftwareeslasiguiente:

1.RequerimientosFuncionales

2.RequerimientosNoFuncionales

1.RequerimientosFuncionales

Definen las funciones que el sistema ser capaz de realizar y describencmodebecomportarseelsistemaantedeterminadoestmulo.

Describen la funcionalidad o los servicios que se espera que el sistemaprovea, detallando las transformaciones que el sistema realiza sobre lasentradasparaproducirsalidas.

Ejemplos:

a)ParaunSistemadeProcesamientodeTransacciones

Elsistemadeber:

Registrarlospedidosdelosclientes.

Administrardatosdelosclientes.

Generarfacturasdeventa.

EmitirReportesdeVentasenunrangodefechadado.

Administrardatosdelosproductosquesecomercializanysustockactual.

Registrarmovimientosdestockdecadaproducto.

4

b) Para un Sistema de un Videojuego: (Basado en el ejemplodesarrollado en libro Ingeniera de Software, una perspectivaorientadaaObjetosdeEricBraude,2003).

Elsistemadeber:

Generar dos tipos de personajes: los que estn bajo elcontroldel jugadorypersonajes extraosbajoel controldelaaplicacin.

Permitiraljugadordefinirunpersonajeprincipal.

Mantener cualidades para cada personaje: fuerza,velocidad,paciencia.

Mantenerunvalorparacadacualidaddecadapersonaje.

Permitirque lospersonajespuedaninteractuarcuandoestnenlamismarea.

2.RequerimientosNoFuncionales:

Sonrestriccionesdelosserviciosofuncionessobreelsistemaquelimitalaeleccindealternativasenlaetapadediseoyconstruccindelsistema.

Los requerimientosno funcionales son caractersticasquedeunauotraforma pueden limitar el sistema, como por ejemplo, el rendimiento (entiempoyespacio), interfacesdeusuario, fiabilidad (robustezdel sistema,disponibilidad de equipo), mantenimiento, seguridad, portabilidad,estndares,entreotras.

Ejemplos:

a)ParaunSistemadeProcesamientodeTransacciones

Elsistemadeber:

Operarenunentornodered.

Definirdistintosnivelesdeusuarioyasignarpermisosdeaccesosegnelniveldelosmismos.

AlmacenarlosdatosenunabasededatosRelacional.

b)ParaunSistemadeunVideojuego:1

Elsistemadeber:

5

OperarenunacomputadoraconsistemaoperativoWindows98osuperior.

Operarenunequipoconunmnimode512Kbdememoria.

EllenguajedeimplementacindeberserJAVA.

Clasificacin de Requerimientos No Funcionales La figuraquesemuestraacontinuacincontieneunaclasificacinde losrequerimientosno funcionalespresentadapor IanSommerville (2002)ensulibroIngenieradeSoftware(verbibliografa).

Fuente:LibroIngenieradeSoftwareIanSommerville(2002),Pg.102

Comentamosacontinuacinlascaractersticasgeneralesdelosprincipalestiposderequerimientosnofuncionales:

6

RequerimientosdelProducto:Estos requerimientos especificanel comportamientodelproducto, comoporejemplo:

Requerimientos de desempeo en la rapidez de ejecucin. Porejemplo: La consulta de disponibilidad de habitaciones deberrealizarseenuntiempomenorde20segundos

Requerimientos de tamao de memoria requerida, tamao endisconecesario

Requerimientosdefiabilidadquefijanlatasadefallasparaqueelsistemaseaconsideradoaceptable.

Requerimientos de portabilidad, como por ejemplo: Laaplicacin deber poder accederse desde navegadores WebInternetExplorer6.0osuperiores,ynavegadoresMozillaFirefoxapartirdelaversin4.0

Requerimientosorganizacionales:Sederivande laspolticasyprocedimientosexistentesen laorganizacindelclienteyenladeldesarrollador.Algunosejemplosson:

Estndaresenlosprocesosquedebenutilizarse.

Requerimientos de implementacin como el lenguaje deprogramacinoelmtododediseoautilizar.Porejemplo: ElmotordebasededatosautilizardeberserSQLServer2008,queeselutilizadoparalosotrosaplicativosdelaorganizacin

Requerimientosdeentregaqueespecificancundoseentregarelproductoysudocumentacin.

Requerimientosexternos:Este apartado cubre todos los requerimientos que se derivan de losfactoresexternosalsistemaydesuprocesodedesarrollo.stosincluyen:

Requerimientos de interoperabilidad que definen la manera enque el sistema interacta con otros sistemas. Por ejemplo: Sedebergenerarunarchivoconlainformacindelasacreditacionesde sueldos respetando el formato establecido por el BancoProvinciadeCrdoba.

7

Requerimientos legalesquedebenseguirseparaasegurarqueelsistema opere dentro de la Ley. Por ejemplo: Las facturasgeneradas e impresas deben cumplimentar todas lasreglamentaciones definas a tal efecto por laAFIP (AdministracinFederaldeIngresosPblicos)ylaLeydeFacturacinvigente.

Requerimientos ticos para asegurar que ser aceptado por elusuarioyporelpblicoengeneral.

Categoras de los Requerimientos: Engeneral,planteaShariPleeger,estilsepararlosrequerimientosentrescategoras:

1.Requerimientosquedebenserabsolutamentesatisfechos

2.Requerimientosquesonmuydeseables,peronoindispensables.

3.Requerimientosquesonposibles,peroquepodraneliminarse

Dependiendo del tiempo asignado al proyecto, los recursos, los costos,envergadura del proyecto, entre otros aspectos, el sistema a desarrollardebe considerar obligatoriamente los requerimientos de la categora 1.Dependiendo de cunto debe ajustarse el proyecto a las limitacionespuedenanalizarse losdecategora2parasupostergacinoeliminacinylos requerimientos de categora 3 son los primeros a eliminarse delproyectosegnlanecesidadrequerida.

En anlisis de requerimientos por categora es til para que todos losparticipantescomprendanloquerealmentesenecesita.

Los problemas con los Requerimientos: Paul Bramble, uno de los autores del libro Patrones de Casos deUso,plantea que existen una serie de problemas cuando trabajamos en ladefinicindelosrequerimientos:

Los requerimientos pueden ser tediosos (una extensa lista y/odocumentos)

Losrequerimientospuedenestardesorganizados

8

Los requerimientos, como lo expresan los usuarios, pueden serimprecisos,ambiguosoerrneos

La captura de requisitos es un proceso continuo (mientras msestudiamoselsistema,msaprendemosdelymscambia).

Losclientesnosiempreconocensusverdaderasnecesidades,enmuchoscasoscreenestarsegurosdelasmismas.Esnuestrotrabajoencontrarlas.

Un Analista/Desarrollador puede afirmar Yo entiendo losrequerimientos,peroQuhacerealmenteelSistema?

Se necesita un proceso ordenado y sistemtico para trabajar con losrequerimientos, porque stos son la base de todo proyecto y en granmedidalosresponsablesdesuxitoofracaso.

Ingeniera de Requerimientos Concepto

Eselprocesodedescubrir,analizar,documentaryverificarlosserviciosyrestricciones que debe considerar el sistema a desarrollar. En otraspalabras, la ingenieraderequerimientosesunprocesoquecomprendetodaslasactividadesrequeridasparacrearymantenerundocumentoderequerimientosdelsistema.

Permiteunaespecificacinde losrequerimientoscompleta,consistenteynoambigua,lacualservircomobaseparaacuerdoscomunesentretodaslaspartesinvolucradasyendondesedescribenlasfuncionesquerealizarelsistema.

La siguiente figura ilustra el esquema de procesos comprendidos por laIngenieradeRequerimientos.

9

Fuente:PginaWebdelSIU(ConsorciodeUniversidades),artculodeRicardoWilliams(CoordinadorgeneraldelSIU,LicenciadoenSistemas,EspecialistaenIngenieradeSoftware)http://www.siu.edu.ar/infosiu/&edicion=12&nota=75(fechavisitadelsitio:20092013)

ELICITACIN

Concepto:Procesoendondeseadquiereelconocimientodeltrabajodelcliente /usuario, sebusca comprender susnecesidades y sedetallan lasrestriccionesmedioambientales.

Resultado: el conjunto de los requerimientos de todas las partesinvolucradas.

Tcnicas: Entrevistas, cuestionarios, observacin, anlisis dedocumentos,torbellinodeideas,JAD,entrelasprincipales.

ESPECIFICACIN

Concepto: Esta etapa es un proceso de descripcin del requerimientodurante el cual se producir el documento de especificacin derequerimientosdelsoftware(ERS).

Resultado:Una formadecontratoentreusuariosydesarrolladoresquedefine el comportamiento funcional deseado del software (y otraspropiedades como performance, confiabilidad, seguridad.) sin mostrarcmoseralcanzadatal funcionalidad.Existeunanormaestndarpara la

10

escrituradeldocumentodeespecificacinderequerimientos(ERS)queesla: IEEE Std. 830 (1998) ( IEEE = Institute of Electrical and ElectronicsEngineersInstitutodeIngenierosenElectricidadyElectrnica)

Tcnicas:LatcnicamsutilizadaenelmomentoesladeCasosdeUso,conotrasherramientasgrficascomplementarias.

VALIDACIN

Concepto:Eselprocesoquecertificaqueseatacaelproblemacorrecto.Este proceso final se nutre de los anteriores y realiza la integracin yvalidacinfinaldeloobtenidoencadaunadelasetapasanteriores.

Resultado:Modeloderequerimientosenlneaconlasexpectativasdelosusuarios.

Tcnicas:Revisionesderequerimientos,prototipos,generacindecasosdeprueba,anlisisdeconsistenciaautomtico.

La captura de requisitos en el PUD EnelProcesoUnificadodeDesarrollo,elpropsito fundamentaldel flujode trabajo de requisitos es guiar el desarrollo hacia el sistema correcto.Estoseconsiguemedianteunadescripcin,suficientementebuena,delosrequisitos del sistema como para que los desarrolladores lleguen a unacuerdo con el cliente sobre qu debe hacer y qu no debe hacer elsistema.

Ms all de cul sea el punto de partida para el descubrimiento de losrequisitos(modeladodelnegocio,deldominio,especificacinderequisitoshechaporelcliente),hayunaseriedepasosqueestnsiemprepresentes:

Enumerarlosrequisitoscandidatos. Comprenderelcontextodelsistema. Encontrarrequisitosfuncionales Encontrarrequisitosnofuncionales

11

Enumerarlosrequisitoscandidatos

Durante el desarrollo del sistema todos los involucrados en el proyecto(clientes, usuarios, analistas, desarrolladores y otros) presentan buenasideasquepuedenconvertirseenrequisitosverdaderos.

Conviene entonces confeccionar una lista de caractersticas con estasideasa lasqueconsideramosrequisitoscandidatos.Esta listaseaumentacon la aparicin de nuevas ideas y disminuye cuando algunascaractersticasseconviertenenverdaderosrequisitosypasanamodelarsecomocasosdeuso.

Elrestodelospasossetratarnconmsdetalleenlospuntosquesiguen.

3.2- Comprensin del contexto del sistema mediante un modelo de negocio Comprender el contexto del sistema Paracapturarlosrequisitoscorrectos,quenosllevenaconstruirelsistemacorrecto, se requiere un firme conocimiento del contexto en el que seemplazaelsistema.

Hay,por lomenos,dos formasdeexpresarelcontextodeunsistemaenuna forma que sea de utilidad para los desarrolladores del sistema: elmodeladodeldominioyelmodeladodelnegocio.

Unmodelodedominio (tambinconocidocomoModelodeObjetosdelDominiodelProblema)describe losconceptos importantesdelcontextocomo objetos del dominio y enlaza estos objetos entre s. Este tema sedesarrollaacontinuacinenestaunidad.

12

Elmodeladodelnegocioserealizaparadescribirlosprocesosdelnegocio,conunavisinorientadaaobjetos, conelobjetivode comprenderlos.Elmodeladodenegocio espartede la IngenieradeNegocios,que esunatcnica que tiene por objetivo mejorar los procesos de negocio de laorganizacin.

Modelo de Negocio Unmodelodecasosdeusodelnegociodescribeprocesosdeunnegocioysus interaccionesconelexterior.Supropsitoprincipalesdescribircmoesusadoelnegocioporsususuarios,enestecasosusclientesysocios.

Para nosotros, la principal motivacin para confeccionar un modelo denegocio ser la posibilidad de derivar, a partir de dicho modelo, losrequerimientosdelsistemadesoftwarequedarsoporteaesesistemadenegocio.

ElmodeladodenegocioestsoportadopordostiposdemodelosdeUML(definidosenlaextensindeUMLrelativaalNegocio):

ModelodeCasosdeUsodeNegocio:Presentauna vistaexternadelnegocio lacualdefine loqueesesencialqueelnegociorealicepara entregar el resultado deseado a sus clientes (actores delnegocio).

ModelodeObjetosdelNegocio:Esunavista internadelnegocioquedescribecmocadacasodeusodenegocioes llevadoacaboporpartedeunconjuntode trabajadoresdenegocioqueutilizanunconjuntodeentidadesdenegocio.

Notacin y elementos bsicos del Modelado de Negocio Los elementos bsicos que estn presentes en elModelado deNegocioson:

ActordeNegocio(usuariosdelnegocio)

CasodeUsodeNegocio(procesosdelnegocio)

TrabajadordeNegocio(engeneral:rolesquejuegan laspersonasenunaorganizacin)

13

Entidad de Negocio (las cosas que un negocio administra,producey/outiliza)

Actor De Negocio: Representa un rol en relacin al negocio,desempeado por algo o alguien en el entorno del negocio. Unactor normalmente corresponde a un ser humano pero haycircunstanciasenqueunsistemadeinformacinjuegaelroldeunactor.

Simbologa:

CasoDeUsoDeNegocio:EsunasecuenciadeaccionesquerealizaunnegocioparaproducirunresultadoobservabledevalorparaunactorindividualdelNegocio.Loscasosdeusodenegociocapturaymodelanlosprocesosdenegocio.

Simbologa:

TrabajadorDeNegocio:Representaunroloconjuntoderolesenelnegocio. Un trabajador de negocio interacta con otrostrabajadoresymanipulaentidadesdenegociomientrasparticipaenlasrealizacionesdeloscasosdeusodenegocio.Puederepresentar:

Una abstraccin de un humano que acta dentro delnegocio.

Unaabstraccindel sistemade softwarequemodelamoscomo trabajador automatizado cuando el Actor en vez decomunicarseconun trabajadordenegociohumanoaccededirectamentealsistema.

14

Simbologa:

EntidadDeNegocio:Representa una abstraccin de algo que lostrabajadoresdenegocio toman, inspeccionan,producenoutilizancuandoejecutanuncasodeusodenegocio.Puederepresentar:

a)Undocumento

b)Unaparteesencialdeunproducto

c) Algo menos tangible como el conocimiento oinformacin acerca de un cliente, proveedor,artculosyotrasabstraccionesclave.(*1)

Cuandoelobjetivoderealizarunmodelodenegocioesfundamentalmentederivar el sistema de informacin de soporte nos concentraremos enmodelar entidades de negocio del tipo c) y dejaremos de lado las querepresentan cosas ms bien fsicas. De esta manera las entidades denegocioseutilizanpararepresentarlosmismostiposdeconceptosquelasclasesdeldominio(quepodemosmodelarmedianteundiagramadeclasescomoyasevioenlaUnidad1)

Simbologa:

15

EjemplodeModelodeCasosdeUsodeNegocio

EjemplosdeModelodeObjetosdelNegocioa)Diagramadecolaboracindenegocio:

Muestraunarealizacindecasodeusodelnegocio.

EjemplodediagramadecolaboracindenegocioparaelcasodeusodenegocioAtenderCompradediscografa

16

b)Diagramadeentidadesdenegocio:

Esundiagramadeclasesquemodelalasentidadesdenegocio.

EnestediagramapuedenbosquejarselosatributosyresponsabilidadesdelasentidadesdenegociocomoclasesdelDominiodeProblema.

c)Diagramadetrabajadoresdenegocio:

Es un diagrama de clases que modela los trabajadores de negocio,indicandosusatributosyresponsabilidades.

17

Derivacin del sistema de informacin a partir del sistema de negocio Un buen entendimiento de los procesos de negocio es importante parapoder construirel sistemade soportecorrecto.Esen lavista internadelnegocio,capturadaporelmodelodeobjetos,quesepuedeverlaconexinmsestrechaconrespectoacmodeberanverselosmodelosdelsistemadeinformacin.

Losmodelosdenegociopodranservircomoentradaalavistadecasosdeuso y a la vista lgica. (Recordar vistas de la arquitectura conUML quetratamosenlaUnidad2).

Modelo de Negocio y Modelo de casos de uso del sistema de informacin. Lasreglasqueenunciamosacontinuacinnosservirnparapoderderivarlosactoresycasosdeusodelsistemade informacinapartirdelModelodeNegociorealizado.

1.ParacadaTrabajadordelNegociosedeberdeterminarsivaautilizarelsistemadeinformacin.Silarespuestaess,entonces:

a)Seidentificarunactordelsistemadeinformacinconelmismonombredelactordenegocio.

18

b) Analizar sus responsabilidades: determinar cules implican el uso delsistemade informacine identificaruncasodeusodelsistemaporcadaunadeellas

2. Si en el modelo de negocio tenemos Trabajadores de Negocioautomatizados,entonces:

a)Elactordenegociopasaraseractordelsistemadeinformacin.

b)Lasresponsabilidadesdeltrabajadordenegocioautomatizadopasarnasercasosdeusodelsistemadeinformacin.

19

Modelo de Negocio y clases del Modelo de dominio y Modelo de anlisis. Las reglas que enunciamos a continuacin nos servirn para poderencontrar clases del Modelo de Dominio y del Modelo de Anlisis delsistemadeinformacinapartirdelasentidadesdenegocio.

1.Para cadaEntidaddeNegociodeterminar sivaa ser soportadaporelsistemadeinformacin.Enestecaso:

a)Se identificarunaclasedelModelodeObjetosdelDominiodeProblemaconelmismonombrequelaentidaddeNegocio

b)SeidentificarunaclasedeentidaddelModelodeAnlisis.

2. Las relaciones entre Entidad deNegocio que sern soportadas por elsistemade informacinpasarnaserrelacionesentreclasesdelDominiodeProblemaydelModelodeAnlisis.

Modelo de Dominio Otro de los elementos tiles a la hora de comprender el contexto delsistema, adems del Modelo de Negocio, es contar con un modelo dedominio.

ElModelodeDominio (tambin llamadoModelodeObjetosdelDominiodeProblemay frecuentementeencontradopor las siglasMODP) captura

20

los tipos de objetos ms importantes en el contexto del sistema. Losobjetosdeldominio representan las cosasqueexisteno los eventosquesucedenenelentornoenelquesedesenvuelveelsistema.

Muchosde las clasesdeldominiodelproblema,puedendeducirsede laespecificacinde requisitosomediante laentrevistacon losexpertosdeldominio,odelModelodeObjetosdelNegocio(entidadesdenegocio)sisecuentacondichomodelo.Lasclasesdeldominioaparecencomo:

Entidadesdelnegocioquerepresentancosasquesemanipulanenelnegociocomopedidos,cuentas,contratos.

Entidadesdelmundo realyconceptosde losqueelsistemadebehacerunseguimiento,comoartculos,vehculos.

Sucesosqueocurrirnohanocurrido,como lapartiday/o llegadadeunavin,unsiniestroenunacompaadeseguros.

El principal diagrama UML para describir el dominio es el Diagrama declases.

Utilidaddelmodelodedominio

Elmodeladodeldominiodebecontribuira lacomprensindelproblemaquesesuponequeelsistemaresuelve.Paradesarrollarestemodelodebeconformarseunequipoenelqueestnpresentes tanto losexpertosdeldominio (usuarios)comogenteconexperienciaenmodelado,coordinadoporlosanalistasdeldominio.

El modelo de dominio ayuda a los usuarios, clientes, desarrolladores yotros participantes del proyecto a utilizar un vocabulario comn. Laterminologa comnesnecesariapara compartirelconocimiento con losotros.

Lasclasesdeldominioqueaquseencuentrenseutilizarnaldescribirloscasosdeusoydisearelprototipodeinterfazdeusuario(dentrodelflujode trabajo de Requisitos) y para sugerir clases internas al sistema endesarrolloduranteelAnlisis.

21

Diagrama de Clases del dominio de problema Como ya vimos en laUnidad 1, un diagrama de clases (enUML) es undiagrama que muestra un conjunto de clases, interfaces, suscolaboracionesyrelaciones.

Seutilizanparamodelarlavistadediseoestticadeunsistema.ConUMLlosdiagramasdeclasesseempleanparavisualizarelaspectoestticodelos bloques de construccin bsicos del sistema y sus relaciones, y paraespecificarlosdetallesparaconstruirlos.

Los componentes y simbologa del diagrama de clases se trataron en laUnidad1.

Pautasparasuconstruccin

Seenumeranacontinuacinalgunaspautas,enformadeconsejosaseguircuandoseestconfeccionandoundiagramadeclases:

Debe comunicar un aspecto de la vista de diseo esttica de unsistema.

Debecontenerslo loselementosesencialesparacomprendereseaspecto.

Debe proporcionar detalles en forma consistente con el nivel deabstraccin,mostrandosloaquellosadornosqueseanesencialesendichonivel.

Sedebendistribuirsuselementosdemododeminimizarloscrucesdelneas.

Organizar los elementos de modo que los que seansemnticamentecercanosloestntambinfsicamente.

Usar notas y colores sobre aspectos importantes que se quierandestacar.

SemuestraacontinuacinelModelodeObjetosdelDominiodeProblemade una empresa de venta de discografa, que se est utilizando paradiversosejemplos.

22

23

3.3- Captura de requerimientos Siguiendoconelprocesodecapturaderequerimientos,habiendorealizadoya laenumeracinde requisitos candidatosyobtenidouna comprensindelcontextodelsistema(medianteunmodelodenegocioy/ounmodelodedominio),continuamoscon la identificacinderequisitosfuncionalesynofuncionales,principalmentemediantelatcnicadecasosdeuso.

Encontrar requisitos funcionales Latcnicaespecficapara identificar losrequisitosfuncionalesdelsistemasebasaenloscasosdeuso.Loscasosdeusocapturantantolosrequisitosfuncionalescomolosnofuncionales,especficosdecadacasodeuso.

Cadausuarioquierequeelsistemahagaalgoparal,esdecirquetendrdistintosmodosdeutilizarelsistema.Cadaunadeestasformasdeutilizarel sistema es un caso de uso. Entonces si se pueden describir todos loscasosdeusoquenecesitaelusuario,sepodrsaber loquedebehacerelsistema.

Encontrar requisitos no funcionales Los requisitos no funcionales especifican propiedades del sistema comorestricciones del entorno o de la implementacin, dependencias de laplataforma, consideraciones de rendimiento, seguridad, flexibilidad,facilidaddemantenimiento,entreotras.

Algunosrequisitosnofuncionalessernaplicablesatodosloscasosdeusoengeneralyalgunospuedenserespecficosparauncasodeusooslounnmerodeterminadodeellos.

Porejemplo,elrequisitonofuncional:LasfacturasgeneradaseimpresasdebencumplimentartodaslasreglamentacionesdefinasatalefectoporlaAFIPy laLeydeFacturacinvigente,afectarnicamentealcasodeusoGenerar facturacin,en cambio el siguiente requisitono funcional: Elsistemadeberfuncionalenunentornoderedcontemplandounmximo

24

de40puestosdetrabajosimultneos,esunrequerimientoqueafectaengeneralatodosloscasosdeusoyaningunoenparticular.

3.4- El modelo de caso de uso. Los casos de uso proporcionan un medio intuitivo y sistemtico paracapturar los requisitos funcionalesponiendonfasisenelvaloragregadoparacadausuarioindividualoparacadasistemaexterno.Lautilizacindelos casos de uso hace que los analistas deben pensar en trminos dequinessonlosusuariosyqunecesitaduobjetivosdelaempresapuedencumplir.

Elprincipalesfuerzodelaetapaderequisitosesdesarrollarunmodelodelsistemaque se va a construir y lautilizacinde los casosdeusoesunaforma adecuada para ello, debido a que los requisitos funcionales seestructuran naturalmentemediante los casos de uso y los requisitos nofuncionalessuelenserespecficosdeuncasodeusoypuedentratarseenesecontexto.

Flujo de trabajo del modelado de casos de uso Dentro del PUD (Proceso Unificado de Desarrollo), el primer flujo detrabajoeselderequisitos.Parapresentaresteflujodetrabajo,aligualquese ir haciendo con los restantes en las siguientes unidades,mencionaremos los artefactos que se crean en este flujo de trabajo, lostrabajadoresparticipantesylasactividadesarealizar:

Artefactos: Los artefactos fundamentales que se utilizan en lacapturaderequisitosson:

9 ModelodeCasosdeUso,queincluyeloscasosdeusoylosactores.

9 Descripcindelaarquitectura

25

9 Glosario9 Prototipodelainterfazdelusuario

Trabajadores:Lostrabajadoresresponsablesporlosartefactosqueseproducenenelmodeladodecasosdeusoson:

9 AnalistadeSistemas.9 Especificadordecasosdeuso.9 Diseadordeinterfazdeusuario.9 Arquitecto.

Actividades: Las actividades a realizar por los trabajadores paraproducirlosdistintosartefactosson:

9 Encontraractoresycasosdeuso.9 Priorizarcasosdeuso.9 Detallarloscasosdeuso.9 Prototiparlainterfazdelusuario.9 Estructurarelmodelodecasosdeuso.

Elsiguientegrficomuestralosartefactosdelmodeladodecasosdeusoylostrabajadoresresponsablesdecadauno:

Fuente:LibroElProcesoUnificadodeDesarrollodeSoftware,IvarJacobsonyotros,(2000),Pg.127

26

LasiguientefiguramuestraungrficoqueindicaelflujodetrabajoparalaactividadderequisitosenelPUD,incluyendolostrabajadoresparticipantesysusactividades:

Fuente:LibroElProcesoUnificadodeDesarrollodeSoftwareIvarJacobsonyotros,(2000)Pg.136

Acontinuacinserealizarunadescripcindecadaunode losartefactos,poniendonfasisen losprincipales y luego sedescribirn lasactividadescomprendidasenesteFlujodeTrabajodeRequisitos.

Artefactos del Flujo de Trabajo de Requisitos ModelodeCasosdeUso

Elmodelodecasosdeusopermiteque losdesarrolladoresy losclienteslleguen a un acuerdo sobre los requisitos, es decir, sobre lo que debe

27

cumplir el sistema y constituye la entrada principal para el anlisis, eldiseoylaspruebas.

Elmodelodecasosdeusoesunmodeloquecontieneactores,casosdeusoylasrelacionesentrestos.Sielmodelodecasosdeusoesgrande,esdecir, si el nmero de ellos es elevado es til introducir paquetes en elmodeloparatratarsutamao.Unpaquetereunirciertonmerodecasosde uso agrupados por algn criterio de homogeneidad (los quecorrespondenaunmismoactor, losqueserefierenaunmismoproceso,sonlosprincipalescriterios).

Actor

Unactoreselrolque juegaunusuarioenuncasodeuso.Normalmente,un actor representa un rol que es representado por una persona, undispositivodehardwareo inclusootrosistemaal interactuarconnuestrosistema.

Elmodelodecasosdeusodescribe loquehaceelsistemaparacadatipodeusuario.Cadausuariopuederepresentarseporunoomsactores.Delamisma forma cada sistema externo que interacta con el sistema endesarrollopuederepresentarseporunoomsactores.

Cadarol(actor)defineloquehaceuntrabajadordelnegocioenunprocesoconcreto.Cadavezqueunusuarioenconcreto(unhumanouotrosistema)interacta con el sistema, la instancia correspondiente del actor estdesarrollando ese papel.Una instancia de un actor es, por lo tanto, unusuarioconcretoqueinteractaconelsistema.

Podemosdistinguirlasiguienteclasificacindeactoressegnelobjetivoacumplirenrelacinaloscasosdeuso:

Actor Primario: Tiene un objetivo claro que debe ser tenido encuentayconcretadoconlaayudadelsistemadeinformacin.

Actor Secundario: Es de quin el sistema necesita ayuda paracumplirconelobjetivodelactorprimario.

Simbologa:

28

Glosario

Sepuedeutilizarun glosarioparadefinir trminos comunes importantesquelosanalistasyotrosdesarrolladoresutilizanaldescribirelsistema.Unglosario es muy til para lograr consenso en la definicin de distintosconceptosyparareducirelriesgodeconfusiones.

Descripcindelaarquitectura

Ladescripcindelaarquitecturacontieneunavistadelmodelodecasosdeuso,querepresentaloscasosdeusosignificativos.

Lavistade laarquitecturadelmodelodecasosdeusodebera incluir loscasos de uso que describan alguna funcionalidad importante y crtica, oque impliquenalgn requisito importantequedebadesarrollarsepronto,dentrodelciclodevidadelsoftware.

Estavistadelaarquitecturaseutilizacomoentradacuandosepriorizanloscasosdeusoparasudesarrollodentrodecadaiteracin.

Fuente:LibroElProcesoUnificadodeDesarrollodeSoftwareIvarJacobsonyotros,2000,Pg.133

29

CasodeUso

Uncasousorepresentacadaformaenquelosactoresusanelsistema.Loscasosdeusoson fragmentosde funcionalidadqueelsistemaofreceparaaportarunresultadodevalorparasusactores.Uncasodeusoespecificauna secuencia de acciones que el sistema puede llevar a cabointeractuandoconsusactores.

Por lo expresado, un caso de uso es una especificacin. Especifica elcomportamiento de elementos dinmicos, en este caso instancias decasosdeuso.Unainstanciadeuncasodeusoeslarealizacin(oejecucin)deuncasodeuso.

Podemosestablecerlacategoradeloscasosdeusocomo:

Esenciales:Describenlafuncionalidadprincipaloesencialquetieneque cumplirel sistema.Comprenden losprincipalesprocesosquedebeejecutarelsistemadeinformacin.

De Soporte: Comprenden la funcionalidad que surge a partir deanalizar aquello que se necesita para que puedan funcionar loscasosdeusoesenciales.Tambinaqu se consideran los casosdeusodelusuario,que comprenden la funcionalidad requeridaparaadministrar los datos de los usuarios del sistema y los permisosasignadosalosmismos.

Otraformadeclasificarloscasosdeusoeslasiguiente:

Concreto:Selellamaasalcasodeusoqueesiniciadoporunactoryqueconstituyeunflujodeeventoscompleto.

Abstracto:Eselcasodeusoquenoesiniciadonuncaporunactor,sinoquenicamenteesinstanciado(iniciado)porotrocasodeuso.Surgen a partir de relaciones de extensin, inclusin ogeneralizacin.

Ladescripcindeuncasodeusopuedeincluir:

Diagramasdeestados:Especificanelciclodevidadelasinstanciasdecasosdeuso.

30

Diagramasdeactividad:Describeelciclodevidaconmsdetalleindicando la secuencia temporal de acciones que tienen lugardentrodecadatransicin.

Diagramas de colaboraciones y de secuencia: Describen lasinteraccionesentreunainstanciatpicadeunactoryunainstanciatpicadeuncasodeuso.

EldiagramaUMLquemodela loscasosdeusoeseldiagramadecasosdeuso.

Prototipodeinterfazdelusuario

Los prototipos de interfaz del usuario nos ayudan a comprender yespecificarlasinteraccionesentreactoreshumanosyelsistemadurantelacapturaderequisitos.Noslonosayudaadesarrollaruna interfazgrficamejor,sinoacomprendermejorloscasosdeuso.

Paraespecificarlainterfazdeusuariopuedenutilizarsemodelosdeinterfazgrficayesquemasdepantallas.

El tema de los prototipos de interfaz se ampla en el punto 3.5 de estaunidad.

Diagrama de Casos de Uso Los diagramas de casos de uso son importantes para modelar elcomportamientodeunsistemaounsubsistema.Estosdiagramasfacilitanque los sistemas y subsistemas sean abordables y comprensibles, alpresentarunavistaexternadecmopuedenutilizarseestoselementosenuncontextodado.

Losdiagramasdecasosdeusocontienen:casosdeuso,actores,relacionesdedependencia,generalizacinyasociacin.

Losactoresseconectana loscasosdeusoa travsdeasociaciones.Unaasociacinentreunactoryuncasodeusoindicaqueelactoryelcasodeusosecomunicanentresycadaunopuedeenviaryrecibirmensajes.Larelacindeasociacinentreunactoryuncasodeuso segraficaparaelcasoenqueel actor seael responsablede instanciar (iniciar)el casodeuso.

31

SimbologadelDiagramadeCasosdeUso

Enlasiguientefigurasemuestranlosdistintoselementosquepuedenestarpresentesenundiagramadecasosdeuso.

Nombredecasodeuso

Cada caso de uso debe tener un nombre que lo distinga de los dems.Puedeserunnombresimple(unasimplecadenadetexto)ounnombredecamino(path)enelcasodequeestprecedidoporelnombredelpaqueteenqueestincluidoelcasodeuso.

Losnombresdecasosdeusosonexpresionesverbalesquedescribenalgncomportamiento del vocabulario del sistemaque se estmodelando. Seaconseja que el nombre del caso se uso comience con un verbo eninfinitivo.

Nombredeactor

El nombre del actor debe reflejar el rol que cumple un usuario alinteractuarconelcasodeusoalqueestconectadoynodebereflejaraunusuarioenparticular.

RelacindeGeneralizacinentreactores

Puedendefinirsecategorasgeneralesdeactoresyespecializarlosatravsderelacionesdegeneralizacin.Losactoresespecializados(hijos)heredanelcomportamientodelactorpadre.

32

Siuncasodeusoesinstanciadoporelactorpadrepuedeserinstanciadoporcualquieradesushijos.Ahorabienpodrahabercasosdeusoquesoninstanciadosporunodelosactoreshijoenparticular.

Relacionesentrecasosdeuso

Los casos de uso pueden organizarse especificando relaciones degeneralizacin,inclusinyextensinentreellos.Estasrelacionesseutilizanpara:

Factorizar el comportamiento comn (extrayendo esecomportamientodeloscasosdeusoenlosqueseincluye)

Factorizarvariantes(poniendoesecomportamientoenotroscasosdeusoqueloextienden).

Simplificar un caso de uso extrayendo una parte compleja yubicndolaenotrocasodeuso.

Relacindegeneralizacinentrecasosdeuso

La generalizacin entre casos de uso es como la generalizacin entreclases. En este contexto significa que el caso de uso hijo hereda elcomportamientodelcasodeusopadre.Elhijopuedemodificary/oagregarcomportamientoalheredado.

La generalizacin se emplea para simplificar la forma de trabajo y lacomprensin delmodelo de casos de uso y para reutilizar casos de uso

33

semifabricados.Un casodeuso semifabricadoexiste solamenteparaqueotrosloreutilicen.

Grficamenteseindica,aligualquelaherenciaentreclases,conunalneacontinua conpuntade flecha vacadirigidadel casodeusohijohaciaelpadre.

Ejemplos:

Relacindeinclusinentrecasosdeuso

Unarelacinde inclusinentrecasosdeusosignificaqueuncasodeusobase incorporaexplcitamenteelcomportamientodeotrocasodeusoenel lugar especificado en el caso base. El caso de uso incluido nunca esinstanciadoporunactor,sinoquees instanciadoporel/loscasosdeusoqueloincluyen.Porello,uncasodeusodeinclusinessiempreuncasodeusoabstracto.

Lasecuenciadecomportamientoylosatributosdelcasodeusoincluidoseencapsulan y no pueden modificarse o accederse, solamente puedeutilizarseelresultado (o funcin)delcasodeuso incluido.Elcasodeusobase llama al caso de uso incluido el cual se ejecuta y luego el controlvuelvealcasodeusobase.

34

Una caractersticade la relacinde inclusinesqueel casodeusobasesiempre deber invocar la ejecucin del caso de uso incluido paracompletarconsuobjetivo;esdecir,elcasodeusobasenoestcompletasinoseejecutalafuncionalidaddelcasodeusodeinclusin.

La relacin de inclusin se usa para abstraer el comportamiento comnentrecasosdeuso,evitandodescribirelmismoflujodeeventosrepetidasveces.Tambinseutilizaparaapartardelcasodeusobaseunaporcindefuncionalidadcomplejaoquecomplicalacompresindeste.

La inclusin se representa como una dependencia estereotipada con lapalabra include o en forma abreviada inc, dirigida desde el caso de usobasehaciaelcasodeusoincluido.

Relacindeextensinentrecasosdeuso

Unarelacindeextensinentrecasosdeusosignificaqueuncasodeusobase incorpora implcitamenteelcomportamientodeotrocasodeuso.Elcaso de uso base puede ejecutarse aisladamente, pero bajo ciertascondiciones su funcionalidad ser extendida por la del caso de uso deextensin.

Laextensinpuedeversecomoqueelcasodeusodeextensinincorporasucomportamientoenelcasodeusobase.Unarelacindeextensinseutilizaparamodelar lapartedeuncasodeusoqueelusuariopuedevercomo comportamiento opcional del sistema.De esta forma se separa elcomportamiento opcional del obligatorio. Tambin puede utilizarse para

35

modelar un subflujo separado que slo se ejecuta bajo ciertascircunstancias.

Elhechodeque la llamada al casodeusode extensin seaopcional sedebeaqueelcasodeusobaseescompletoensmismo,esdecirpuedecumplir con su objetivo sin necesidad de llamar al caso de uso deextensin; slo que a veces extender o ampliar su funcionalidadllamandoalaejecucindelotrocasodeuso.

El caso de uso de extensin puede en algunos casos ser instanciadodirectamente por un actor (en este caso se considera un caso de usoconcreto),ademsdeinstanciarseparaextenderelcomportamientodeuncaso de uso base. Si el caso de uso de extensin nunca es instanciadodirectamenteporunactor,entoncesesuncasodeusoabstracto.

La extensin se representa como una dependencia estereotipada con lapalabraextendoenformaabreviadaext,dirigidadesdeelcasodeusodeextensinhaciaelcasodeusobase.

ActividadesdelFlujodeTrabajodeRequisitos

Cuando los trabajadores ejecutan las actividades, crean y modificanartefactos. Describimos un flujo de trabajo como una secuencia deactividadesqueestnordenadas,demodoqueunaactividadproduceunasalidaquesirvedeentradaalasiguiente.Apesardeello,enelmundoreal

36

nosiempretrabajamosestrictamenteensecuencia.Sepuedetrabajarpormltiplesvasqueproducenunresultadofinalequivalente.

Una actividad puede ser retomada muchas veces (recordemos queestamosenunprocesodedesarrollo iterativo)ycadaunadestaspuedeacarrear la ejecucin de un solo fragmento de la actividad. Por ejemplocuando retomamos la actividad Encontrar actores y casos de uso, elnuevo resultado puede ser solamente una identificacin adicional de uncasodeuso.

Las distintas actividades en el modelado de casos de uso adoptandiferentesformasendiferentesfasesdelproyecto.Porejemplo,cuandounanalistadesistemasejecuta laactividaddeEncontraractoresycasosdeusodurante la fasede inicio, identificarmuchosactoresycasosdeusonuevos.Perocuandolaactividadserealicedurantelafasedeconstruccin,el analista har principalmente cambios secundarios en el conjunto deactoresycasosdeuso.

Sedescribenacontinuacin lasactividadesque se realizanenel flujodetrabajoderequisitos.

ENCONTRARACTORESYCASOSDEUSOLaidentificacindeactoresycasosdeusoeslaactividadmsdecisivaparaobteneradecuadamentelosrequisitosyesresponsabilidaddelanalistadesistemas.

Para realizar esta actividad, si se dispone de unmodelo de negocio, sepuedeobtenerunborradordelmodelodecasosdeusoenformabastantedirecta.Otrasvecessepuedepartirdelmodelodedominioosimplementedeunaespecificacindelascaractersticasqueserequierendelsistema.

Estaactividadpuededescomponerseencuatropasos:

1.Encontrarlosactores

2.Encontrarloscasosdeuso

3.Describirbrevementeloscasosdeuso

4.Describirelmodelodecasosdeusocompleto

1.Encontrarlosactores:

Haydoscriteriostilesalahoradeelegirloscandidatosaactores:

37

Primero debe ser posible identificar al menos un usuario quepuedarepresentaralactorcandidato.

Segundo,debeexistirunacoincidenciamnimaentrelosrolesquedesempean las instanciasde losdiferentesactores.Nodebemostenerdosoms actoresque cumplan losmismos roles.O sonelmismo actor o se realiza una generalizacin abstrayendo elcomportamientocomn.

Para encontrar actores, resulta til preguntarse por ejemplo quin va autilizarciertainformacin,quinvaausarunadeterminadafuncionalidad,quin actualizar algn dato en el sistema, con qu otros sistemas va ainteractuarelsistemaqueestamosmodelando.

Elanalistadesistemasdanombrealosactoresydescribebrevementelospapeles de cada actor. La descripcin de cada actor debe esbozar susnecesidadesyresponsabilidades.

2.Encontrarloscasosdeuso:

Elanalistadesistemasidentificarloscasosdeusoatravsdelostallerescon los clientes y los usuarios. El analista de sistemas va repasando losactoresdeaunoypiensaenqu formapuedenutilizarelsistemaoqunecesitandelsistema,proponiendoascasosdeuso,queseconsideranenprimerainstanciacandidatos.Algunosdeloscandidatosnollegarnasercasosdeusoporsmismos,sinoquesernpartesdeotro.

Comoyamencionamosalhablardelascategorasdecasosdeuso(pgina21 de estamaterial), habr casos de uso a los que llamamos esencialesporque involucran actividades que constituyen el ncleo del negocio ysuelenserlosprimerosenserdescubiertos;yotroscasosdeusoalosquellamamos secundarios o de soporte, que permiten realizar tareas talescomo: actualizar todas las clases que aparecieron en el dominio delproblema y las que irn apareciendo, ms adelante (en las ltimasiteraciones) pueden aparecer casos de uso para administrar usuarios,sesindeusuario,entreotros.

Seeligeunnombreporcadacasodeuso,querepresente lasecuenciadeaccionesconcretaqueaadevaloraunactor(producealgodevalorparael actor). El nombre del caso de uso comienza con un verbo(preferentementeeninfinitivo)ydebereflejarelobjetivodelainteraccinentreelactoryelsistema.

3.Describirbrevementecadacasodeuso:

Amedidaquesevandescubriendoloscasosdeusosesueleirregistrandoalgunas palabras explicndolos. Luego se procede a describir ms

38

formalmenteelcasodeuso,enprimera instanciaconunaspocasfrasesymsadelanteseharunadescripcindetallada.

4.Describirelmodelodecasosdeusocompleto:

Estatareaconsisteenelaborardiagramasydescripcionesparaexplicarelmodelodecasosdeusoentotalidad.

Nohayunareglaestrictaque indiquequsedebe incluirenundiagrama(considerandounsistemamedianamentecomplejoenelquenosepuedenincluirtodosloscasosdeusoensolodiagrama).Podemostenerdiagramasporcadaprocesodenegocio,o reunir todos loscasosdeusoen losqueintervieneunmismoactor.

Elmodelodecasosdeusopuedeorganizarseenconjuntosdecasosdeusoconformandopaquetesdecasosdeuso.

PRIORIZARCASOSDEUSOEl propsito de esta actividad es determinar cules casos de uso sonnecesariosparaeldesarrolloen lasprimeras iteracionesyculespuedendejarseparamsadelante.

Losresultadosdeestaactividadconforman lavistade laarquitecturadelmodelodecasosdeuso,queesrevisadaporeljefedeproyectoyseutilizacomobaseparalaplanificacindeunaiteracin.

DETALLARCASOSDEUSOEl objetivo de esta actividad es detallar el flujo de sucesos en detalle,incluyendocmocomienza,terminaeinteractanconlosactores.

Conelmodelodecasosdeusocomopuntodepartidaelespecificadordeuncasodeusoindividualpuedecomenzaradescribircadacasodeusoendetalle,especificandolasecuenciaprecisadeacciones.

Hay varias formas y herramientas con las que se puede realizar ladescripcindeun casodeuso. Independientementede la formaelegidaparadescribirelcasodeuso,debeverificarseque ladescripcinsiempreincluyalosiguiente:9 Elestadoinicial,comoprecondicin.9 Cmoycundocomienzaelcasodeuso(esdecir,laprimeraaccin

aejecutar).9 El orden requerido en el que las acciones de deben ejecutar

(determinadoenformadesecuencianumerada).

39

9 Cmoycundoterminanloscasosdeuso.9 Losposiblesestadosfinales,comopostcondiciones.9 Loscaminosdeejecucinquenoestnpermitidos.9 Lasdescripcionesdecaminosalternativosqueestnincluidosjunto

conladescripcindelcaminobsico.9 Lasdescripcionesdecaminosalternativosquehansidoextradosde

ladescripcindelcaminobsico.9 Lainteraccindelsistemaconlosactoresyqucambiosproducen.9 Lautilizacindeobjetos,valoresyrecursosdelsistema.9 La descripcin explcita de lo que hace el sistema, separando las

responsabilidadesdelsistemadelasaccionesdelosactores.

Acontinuacindemuestraunaplantillaquecubreestosaspectosyresultamuy til para realizar una descripcin detallada de un caso de uso,incluyendo lasreferenciasa loscasosdeusocon losquetienerelacionesdeextensin,inclusin,generalizacin.

Hay diferentes formatos que se pueden utilizar para una plantilladescriptiva de caso de uso, el siguiente es simplemente una propuesta;mientras se respeten los tems esenciales que deben incluirse en ladescripcin, tal como se enunciaron en el prrafo anterior, se puedenagregaroquitarseccionessegnlasnecesidadesopreferenciasdelequipodeespecificacin.

PlantillaparaladescripcindeCasosdeUso

40

41

Otrasherramientasquepuedenayudaramejorar la comprensinde loscasosdeusoson:

Diagramasdeestado:Paradescribirlosestadosdeloscasosdeusoylastransicionesentreesosestados.

Diagramas de actividad: Para describir las transiciones entreestadosconmsdetallecomosecuenciasdeacciones.

Diagramas de interaccin: Para describir cmo interacta unainstanciadecasodeusoconlainstanciadeunactor.Enestecasoeldiagramade interaccinmuestra sloel casodeuso yel actoroactoresparticipantes.

PROTOTIPARLAINTERFAZDELUSUARIOHastaaqu, sehadesarrolladoelmodelode casosdeusoqueespecificaqu usuarios hay y para qu necesitan usar el sistema. Ahora, hay quedisearlainterfazdeusuarioquelepermitallevaracaboloscasosdeusodemaneraeficiente.

Secomienzacon loscasosdeuso, intentandodeterminarqusenecesitadelasinterfacesdeusuarioparahabilitarloscasosdeuso.Estoeshacerundiseo lgico de la interfaz. Luego se realiza un diseo fsico y sedesarrollanprototipos.

Como ya mencionamos anteriormente, el tema de los prototipos deinterfazseamplaenelpunto3.5deestaunidad.

ESTRUCTURARELMODELODECASOSDEUSOElmodelodecasosdeusoseestructurapara:

42

Extraer descripciones de funcionalidades generales y compartidasquepuedenserutilizadaspordescripcionesmsespecficas(casosdeusodeinclusin).

Extraerdescripcionesdefuncionalidadadicionalesuopcionalesquepueden extender descripciones ms especficas (casos de uso deextensin).

Enestaactividadelanalistade sistemaspuede reestructurarel conjuntocompleto de casos de uso para hacer que el modelo sea ms fcil deentenderydetrabajarconl.

Elanalistadebebuscarcomportamientoscompartidosyextensiones.Estosereflejaen ladeterminacinderelacionesdegeneralizacin, inclusinyextensinentrecasosdeuso.

CuandosetrateltemadeRelacionesentrecasosdeusosepresentaronvariosejemplosdecadauna.Semuestraenlasiguientefiguraunejemplodeuncasodeusocuyafuncionalidadfueextradadeloscasosdeusobaseyesllamandoporextensinoporinclusinsegnseaelcasodeusobasellamador.

EjemplodediagramadecasosdeusodeunSistemadeComercializacindeDiscografa,delquesehanidodandoalgunosejemplossueltos.

43

44

3.5- Prototipos de Interfaz Concepto y propsito de los prototipos Unprototipoesunaversininicialdeunsistemadesoftwarequeseutilizapara demostrar los conceptos, probar opciones de diseo y, en general,conocermsacercadelproblemayopcionesdesolucin.

TalcomoloplanteaIanSommerville(2002),unprototipodesirvedeapoyoadosactividadesdentrodelprocesodeingenieraderequerimientos:

1. Obtencin de requerimientos: Los prototipos permiten a losusuarios experimentar para ver cmo el sistema ayudar a sutrabajo.Lespermiteadquirirnuevasideasparalosrequerimientosyproponernuevosrequerimientos.

2.Validacinderequerimientos:Unprototipopuederevelarerroresyomisionesen losrequerimientospropuestosyespecificados.Conel uso de prototipos los usuarios a menudo encuentran que suvisininicialfueincorrectaoincompleta,entonceslaespecificacindel sistema puede modificarse para reflejar el cambio en lacomprensindelosrequerimientos.

Adems de permitir a los usuarios mejorar la especificacin derequerimientos, el desarrollo de un prototipo del sistema tiene otrasventajas:

Al demostrar las funciones del sistema se identifican lasdiscrepanciasentrelosdesarrolladoresylosusuarios.

Durante el desarrollo del prototipo, el personal dedesarrollo puede darse cuenta de que los requerimientossoninconsistentesy/oestnincompletos.

Aunquelimitado,sedisponerpidamentedeunsistemaquefunciona y demuestra la factibilidad y usabilidad de laaplicacinaadministrar.

El prototipo de utiliza como base para escribir laespecificacinparalaproduccindeunsistemadecalidad.

45

Por lo general el desarrollo del prototipo conduce a mejorar laespecificacindel sistema,perounavezqueelprototipoestdisponibletambinseutilizaparaotrospropsitos:

1.Capacitaralusuario:Elprototiposepuedeutilizarparcapacitaralosusuariosantesqueelsistemafinalestterminado.

2.Probarelsistema:Losmismoscasosdepruebase introducenalprototipoyalsistemaenprueba.Siambossistemasdanlosmismosresultados el caso de prueba no detecta una falla. Pero si losresultadosdifierensignificaqueelsistemafallayhayqueinvestigarlasrazonesdelasdiferencias.

Construccin de prototipos de interfaz de usuario En la actualidad, las interfaces grficasdeusuario (GUIpor sus siglaseningls) sehanconvertidoen lasnormaspara los sistemas interactivos.Elesfuerzocomprendidoen laespecificacin,eldiseoy la implementacindeuna interfazdeusuariorepresentaunapartesignificativade loscostosdedesarrollodeunsistema.

IanSommerville (2002)nosplanteaque losdiseadoresnodebendarsuopininalosusuariosdeloquedeberaserunainterfazdeusuarioyqueelusuariodebetenerunaparticipacinactivaeneldiseodelamisma.

Desdeelpuntode vistade la Ingenierade software, la construccindeprototipos esunaparteesencialdelprocesodediseode la interfazdeusuario.La construccindeprototiposevolutivoscon laparticipacindelusuariofinaleslanicamanerasensibleparadesarrollarinterfacesgrficasdeusuarioparalossistemasdesoftware.

La siguiente figuranosmuestra elprocesodediseodeuna interfazdeusuario, tal como lopresenta Ian Sommervilleen su libro IngenieradeSoftware(verbibliografa).

46

Fuente:LibroIngenieradeSoftwareIanSommerville,2002,Pg.329.

Ventajas del uso de Interfaz Grfica de Usuario (GUI) Aunque las interfacesbasadasen textoanseutilizan,especialmenteenlos sistemas heredados, los usuarios actuales de sistemas informticosesperan que las aplicaciones tengan algn tipo de interfaz grfica deusuario.

Este tipo de interfaces se caracterizan por el uso de los siguienteselementos:

Ventanas: Las ventanas mltiples permiten que sedespliegue simultneamente informacin diversa en lapantalladelusuario.

conos: Los conos representan diferentes tipos deinformacin. En algunos sistemas los conos representanarchivosyenotrosrepresentanprocesos.

Mens:Loscomandosseseleccionandeunmenen lugardeteclearseenunlenguajederdenes.

Apuntador: Para seleccionar las opciones de un men,indicar elementos de inters en una ventana o dirigirse aalguna parte de la ventana se utiliza un dispositivoapuntadorcomoelmouse(ratn).

47

Grficos: Los elementos grficos se pueden mezclar contextoenelmismodespliegue.

Entre las ventajas del uso de interfaces grficas de usuario podemosmencionar:

Sonfcilesdeaprenderyutilizar. Para interactuar con el sistema losusuarios cuentan conpantalla

mltiples (ventanas)por lo tantoesposible irdeuna tareaaotrasinperderdevistalainformacingeneradadurantelaprimertarea.

Es posible interactuar rpidamente y tener acceso inmediato acualquierpuntodelapantalla.

Elementos de una interfaz grfica de usuario Los diseadores de interfaces de usuario deben tener en cuenta lascapacidades fsicas ymentales de la gente que utilizar el software. Laspersonasolvidan fcilmenteycometenvarioserrorescuando tienenquemanejar demasiada informacin o estn bajo presin, pero poseen unampliorangodecapacidadesfsicas.

Lashabilidadeshumanasson labasepara losprincipiosdediseoqueseenuncian a continuacin y que consisten en una serie de principiosgenerales que se pueden aplicar a todos los diseos de interfaces deusuario.

Familiaridad del usuario: La interfaz debe utilizar trminos yconceptos que se toman de la experiencia de las personas quemsutilizan el sistema. Por ejemplo, si en la organizacin utilizan eltrmino afiliado para referirse a los clientes mantener estadenominacinenlasinterfaces.

Consistencia:Lainterfazdebeserconsistenteenelsentidodequelasoperacionescomparablesseactivande lamisma forma.Porejemplotodas las ventanas de registro de datos son similares (ventana pararegistrarnuevodisco,nuevosello,nuevognero)

Mnima sorpresa: El comportamiento del sistema no debe provocarsorpresaa losusuarios.Utilizar recursos comomostrarunabarradeavanceparaindicaralusuarioqueelsistemaestprocesandoalgo,porejemplo,paraquenopiensequesehaclavadoelsistema.

48

Recuperabilidad:La interfazdebe incluirmecanismosparapermitiralos usuarios recuperarse de los errores, como confirmacin deaccionesdestructivas (siempre solicitarconfirmacinanteunaaccineliminar), proveer un recurso para deshacer (incluir la opcincancelarentodaslasventanas)

Guaalusuario:Cuando loserroresocurren, la interfazdebeproveerretroalimentacin significativa y caractersticas de ayuda sensible alcontexto.Mostrarmensajedeerrorsignificativoparaelusuarioqueleden indicacin sobre cul es el error y cmo subsanarlo o cmocontinuarcorrectamenteconlaaplicacin.

Diversidad de usuarios: La interfaz debe proveer caractersticas deinteraccinapropiadaparalosdiferentestiposdeusuariosdelsistema.Hayusuariosque tienenbuenamemoria y son giles con el tecladonumrico demodo que prefieren ingresar por estemedio los datos(comoporejemplo legajosdepersonalocdigodeartculos)envezque tener que trasladar la mano al mouse para hacer la seleccindesdeuncomboolista,locualsetraduceenmstiempoempleadoenlaoperacin sihayquehacermuchos cambiosdemovimientode lamano (del tecladoalmouseydesteal teclado sucesivamente).Demodoquelainterfazdeberapermitirambostiposdeacciones:ingresodedatososeleccindelosmismos.

Interaccin del usuario Los diseadores de interfaces de usuario deben decidir cmo se va aintroducir la informacin del usuario a la computadora y cmo sepresentaralusuariolainformacindelsistema.

La interaccin del usuario implica emitir comandos y datos asociados alsistema de software. En las primeras computadoras la nica forma dehacerestoeraatravsdeuna internade lneadecomandosen laqueseutilizaba un lenguaje de propsito especfico. Sin embargo este enfoqueslo lo utilizaban los expertos por lo que fueron surgiendo otrasposibilidadesquelesfacilitabanlastareas.

IanSommerville(2002)enel libroquehemosestadomencionando,citaaShneiderman,quienclasificlasdiversasformasdeinteraccindelusuariocon la computadora (es decir con la interfaz de usuario) en estos cincoestilosprimarios:

Manipulacin directa: Cmo arrastrar para mover o eliminar unarchivo. Es una interaccin rpida e intuitiva adems de fcil de

49

aprender pero puede ser difcil de implementar si no hay unarepresentacinvisualclaraparalastareasyobjetos.

Seleccin de mens: Seleccionar el archivo y luego seleccionar laaccinmoveroeliminardesdeunmen.Evitaerroresdelusuarioy requiere teclear poco, pero puede parecer lenta a usuariosexperimentados.

Llenado de formularios: El usuario llena campos de un formulario(ventanadecargadedatos),puede tenermensasociados,botones,conos, entre otros elementos grficos. Implica una forma deintroduccindedatos sencillay fcildeaprenderperoocupamuchoespacioenpantalla.

Lenguaje de comandos: El usuario indica un comando especial yparmetros necesarios (DEL nota.txt). Es una forma de interaccinpoderosayflexibleperopuederesultardifcildeaprender.

Lenguajenatural:Emitiruncomandoen lenguajenatural (borrarelarchivo nota.txt). Resulta accesible a usuarios casuales pero serequiereteclearmsademsquesedeberadisponerdesistemasdecomprensin de lenguaje natural los cuales no siempre resultanfiables.

Respectodelaformadepresentacindelainformacinalosusuariosenlainterfaz,podemosmencionarbrevemente.

Presentacin como texto: Utilizada generalmente cuando serequiere informacin numrica precisa y la informacin cambiarelativamentelento.

Presentacin como grfico: Utilizada generalmente cuando losdatoscambianrpidamenteosi lasrelacionesentre losdatossonsignificantes(usodegrficosdebarra,curva,torta,porejemplo).

Uso del color en el diseo de la interfaz de usuario En general, los sistemas interactivos permiten despliegues a color y losdiseadoresdeinterfacesdeusuarioutilizanelcolordediferentesformas.

Elusodelcolorenlasinterfacespuederesultardeutilidadayudandoalosusuariosacomprenderymanejar lacomplejidad.Sinembargo,sielcolor

50

es utilizado de manera errnea puede conducir a interfaces pocoatractivas,fatigosasparalavistaypropensasaerrores.

A continuacin se listan algunas recomendaciones respecto del uso delcolorenlasinterfaces:

9 Limitar el nmero de colores utilizados, ser conservador almomentodeutilizarlos.

9 Utilizaruncambiodecolorparamostraruncambioenelestadodelsistema (porejemploenun listadodepedidos identificarconazulloscancelados).

9 Utilizarelcdigodecoloresparaapoyar la tareaque losusuariosestn tratandode llevar a cabo (identificar instancias anmalasosimilitudes).

9 Utilizarelcdigodecoloresen formaconscienteyconsistente:Sienunapartesemuestranmensajesdeerrorencolorrojo,hacerloasentodaslasinterfaces.

9 Sercuidadosoalutilizarparesdecolores:Porlafisiologadelojolaspersonasnopuedenenfocarelrojoyelazulsimultneamente.Lavista cansada es consecuencia del despliegue de rojo sobre azul.Otrascombinacionestambinsonperturbadorasodifcilesde leer(comoamarillosobrenegroporejemplo).

9

Soporte al usuario Las interfacesdeusuariosiempredebenproveeralgunaformadesistemadeayudaenlnea,comomencionamosalenunciarlosprincipiosdediseodeinterfacesdeusuario.

Los sistemasde ayudaen lnea conuna facetadeunaparte generaldeldiseodeinterfacesdeusuario.Elsoportealusuariocubretresreas:

Losmensajesproducidosporelsistemaenrespuestaalasaccionesdelusuario

Ayudaenlnea Ladocumentacinsuministradaconelsistema

51

Mensajes de error Losmensajesdeerrordel sistema son laprimeramarcaque reciben losusuarios de un sistema de software. Al hacer su trabajo los usuariosinexpertospuedencometererroresydemanera inmediatadeberapodercomprenderelmensajedeerrorresultante.

Los mensajes de error deben tomar en cuenta el conocimiento y laexperienciadelosusuarios.Podemostener:

Mensajeorientadoal sistema:Comoporejemplo:Error#32enlnea410Esunmensajenegativo,noseajustaa lashabilidadesyniveldeexperienciadelusuario,tampocosugierecmorectificarlasituacin.

Mensaje orientado al usuario: Como por ejemplo Cliente noregistradoutilicelaopcin:RegistrarNuevoCliente.Estetipodemensajes son los que se deben utilizar. Deben ser amables,concisos,consistentesyconstructivos.

Diseo del sistema de ayuda Enelcasoqueelmensajedeerrornoseasuficienteparaelusuario,stesedirigirinmediatamentealsistemadeayudaenbuscademsinformacinparasolucionarelinconvenienteodudaqueselepresenta.

Hayalgunosaspectos interesantesaconsideraralmomentodedisear laayudaenlnea:

Niveles de entrada: Los sistema de ayuda proveen varios puntosdiferentesdeentradaalosusuarios.

Navegacinde laayuda:Losusuariospueden ingresaralsistemadeayudaenelpuntode la jerarquacorrespondientealmensajey luegonavegarpor laestructurade reddel sistemade ayuda.Puedepasarqueelusuariocomienceanavegarpor laayudayalpoco tiemposeencuentreperdido;desplegar la informacindeayudaenmltiplesventanaspuedealiviarestasituacin.

Contenido:Eltextodeunsistemadeayudasepreparaconlaayudadeespecialistas en la aplicacin. La ayuda en lnea no debe sersimplemente una reproduccin del manual del usuario ya que laspersonas leenenpapelyenpantallaen formadiferente.El texto,su

52

exposicinyestilotienenquedisearsecuidadosamenteparapermitirsudesplieguelegibleenunaventanageneralmentepequea.

Herramientas: Respecto de las herramientas que se pueden utilizarparaconfeccionarunsistemadeayudaenlneatenemos,

9 Conjunto de pginas vinculadas a Worl Wide Web que sernaccedidasmedianteunnavegador:Sonfcilesdeimplementarynonecesitan ningn software especial pero pueden ser difciles devincularconlasaplicaciones.

9 Sistema de hipertexto integrado con las aplicaciones, utilizandoherramientas como por ejemplo WinHelp que produce ayudassimilares a lasque estn ampliamentedifundidas en los sistemasoperativosyaplicativoscomerciales.

Documentacin del usuario Ladocumentacindelusuarionoesestrictamentepartedeldiseode lainterfazdeusuario,peroes recomendabledisearelapoyodeayudaenlneajuntoconladocumentacinenpapel.

Losmanualesdelsistemaproveen informacinmsdetalladade laayudaen lneaysediseadetalformaquepuedanserutilizadospordiferentestiposdeusuariosdelsistema.

Ian Sommerville (2002) nos recomienda al menos cinco documentos, ocaptulosdeunnicodocumento,paraentregar juntoconelproductodesoftware:

Descripcin funcional: Describe brevemente los servicios queproveeelsistema.

Documentode instalacin:Provee losdetallesdecmo instalarelsistema, losdiscosqueseentreganconelsistema, losarchivosdeestosdiscosylaconfiguracindehardwaremnimarequeridaparaquefuncionecorrectamenteelsistema.

ManualIntroductorio:Presentaunaintroduccinuntantoinformaldel sistema, describiendo su utilizacin normal. Describe comoiniciar, cerrar sesin de usuarios y cmo utilizar los recursoscomunesdelsistema.

53

Manual de referencia: Describe todos los recursos del sistema;proveeuna listade losmensajesdeerror,posiblescausasycmorecuperarsedelosmismos.

Guadeladministrador:Describe losmensajesquesegeneranporla interaccindelsistemaconotrossistemasycmoreaccionarenestas situaciones; tambin cuando el problema puede estarrelacionado con algn elemento de hardware, indicando cmoreconocer y reparar el problema, de ser posible para el usuario.Estetipodedocumentacinsloestpresenteenalgunostiposdesistemas, los que incluyen saturaciones como las que sedescribieron.

Evaluacin de la interfaz Laevaluacinde la interfazeselprocesode valorar la formaenqueesutilizadaunainterfazyverificarquecumplesusrequerimientos.

Idealmente, una evaluacin se compara con la especificacin de lausabilidadquesebasaenlossiguientesatributos:

Aprendizaje: Seevala cunto tiempo tardaunusuarionuevoenserproductivoconelsistema.

Velocidad de operacin: Se considera qu tan bien responde elsistemaalasoperacionesdetrabajodelusuario.

Robustez:Seevalaqutantoleranteeselsistemaaloserroresdelusuario.

Recuperacin:Seobservaqutanbienserecuperaelusuariodeloserroresdelusuario.

Adaptacin: Se evala qu tan atado est el sistema a un solomodelodetrabajo.

Para realizar laevaluacinde la interfazdeusuariosepuedenaplicarlassiguientestcnicas:

Cuestionarios,querecolectanlaopinindelosusuariosacercadelainterfaz.

Observacindelosusuariosalmomentodetrabajarconelsistema. Videosdesesionesdeusuario.

54

Cdigo incluido en el software que recolecte informacin sobreerroresmscomunesyrecursosmsutilizados.

Elementos de una interfaz grfica de usuario Se muestran a continuacin algunos elementos que estn presentes entodainterfazgrficadeusuario.

55

Bibliografa BoochGrady, Rumbaugh James, Jacobson Ivar, El lenguaje deModelado

Unificado,Espaa,EditorialAddisonWesleyIberoamericana,(1999).

Captulos:16y17

Bramble Paul, artculo Introduction to Patterns for Writing Effective UseCases.

Braude Eric, (2003), Ingeniera de Sofware, una perspectiva orientada aobjetos,AlfaomegaGrupoEditorSA.

Captulo3

DavisAlan,artculodelautorextradode SoftwareRequeriments:AnlisisandSpecification,PrenticeHall,(1990).

English, Arthur V., Senior Learning and Development Consultant, UnisysCorporation. Business modeling with UML: Understanding the similaritiesand differences between business use cases and system use cases. TheRationalEdge,artculodeAbril2007.

Jacobson Ivar, Booch Grady, Rumbaugh James, El Proceso Unificado deDesarrollodeSoftware,Espaa,EditorialAddisonWesley,(2000).

Captulos:6y7

Jacobson Ivar,TheObjectAdvantage.BusinessProcessReengineeringwithObjectTechnology,EditorialAddisonWesley,(1995).

PleegerShari,IngenieradeSoftware.TeorayPrctica,PrenticeHallCaptulo4

PressmanRoger,IngenieradeSoftware.Unenfoqueprctico6ta.edicin,Ed.McGrawHill,(2006).

Captulos8y15

Sommerville Ian, Ingeniera de Sofware (2002), Ed. Pearson Educacin,Mxico,(2002).

Captulos:5,6,8y15

www.uesiglo21.edu.ar

56