Modelado de los requerimientos concepto breve del análisis

1. MODELADO DE LOS REQUERIMIENTOS:
¿Qué es? El modelode requerimientostienemuchasdimensionesdiferentes.Eneste capítulo,el lector
aprenderáacerca de modelosorientadosal flujo,de modelosde comportamientoyde las
consideracionesespecialesdelanálisisde requerimientosque entranenjuegocuandose desarrollan
webapps.
¿Quiénlo hace?Un ingenierode software (avecesllamadoanalista) construyeel modeloconel usode
losrequerimientosrecabadosentre variosparticipantes.
¿Por qué es importante? La perspectivade losrequerimientosdel software crece enproporcióndirecta
al númerode dimensionesdistintasdel modeladode losrequerimientos.Aunque quizánose tengael
tiempo,losrecursosola inclinaciónparadesarrollarcadarepresentaciónsugeridaeneste capítuloyen
el anterior, debe reconocerseque cadaenfoque diferentede modeladoproporcionaunaformadistinta
de ver el problema.Enconsecuencia,el lector(yotrosparticipantes) estarámejorpreparadopara
evaluarsi ha especificadoenformaapropiadaaquelloque debe lograrse.
muchasdimensionesdiferentes.Eneste capítulo,el lectoraprenderáacercade modelosorientadosal
flujo,de modelosde comportamientoyde lasconsideracionesespecialesdelanálisisde requerimientos
que entranenjuegocuandose desarrollanwebapps.Cadaunade estasrepresentacionesde modelado
complementaloscasosde uso,modelosde datosymodelosbasadosenclasesque se estudiaronenel
capítulo6.
¿Quiénlo hace?Un ingenierode software (avecesllamadoanalista) construyeel modeloconel usode
losrequerimientosrecabadosentre variosparticipantes.¿Porqué esimportante?Laperspectivade los
requerimientosdel software crece enproporcióndirectaal númerode dimensionesdistintasdel
modeladode losrequerimientos.Aunquequizánose tengael tiempo,losrecursosolainclinaciónpara
desarrollarcadarepresentaciónsugeridaeneste capítuloyenel anterior,debe reconocerse que cada
enfoque diferente de modeladoproporcionaunaformadistintade verel problema.Enconsecuencia,el
lector(yotros participantes) estarámejorpreparadoparaevaluarsi haespecificadoenformaapropiada
aquelloque debe lograrse.¿Cuálessonlospasos?El modeladoorientadoal flujodaunaindicaciónde la
formaen laque las funcionesde procesamiento transformanlosobjetosde datos.El modeladodel
comportamientoilustralosestadosdel sistemaysusclases,así comoel efectoque tienenloseventos
sobre dichosestados.El modeladobasadoenpatronesutilizael conocimientodel dominioexistente
para facilitarel análisisde losrequerimientos.Losmodelosde requerimientosconwebappsestán
adaptadosespecialmentepararepresentarrequerimientosrelacionadosconcontenido,interacción,
funciónyconfiguración.
¿Cuál esel producto final? Para el modeladode losrequerimientos,esposible escogerunagran
variedadde formasbasadasentextoy diagramas.Cadauna de estas representacionesdauna
perspectivade unoomás de loselementosdel modelo.¿Cómome asegurode que lohice bien?Debe
revisarse si losproductosdel trabajodel modeladode losrequerimientossoncorrectos,completosy
congruentes.Debenreflejarlasnecesidadesde todoslosparticipantesyestablecerlosfundamentos
desde losque se llevaráacabo el diseño.

2. MODELADO ORIENTADOAL FLUJO Aunque algunosingenierosde softwarepercibenel modelado
orientadoal flujocomounatécnicaobsoleta,sigue siendounade lasnotacionesmásusadas
actualmente parahacerel análisisde losrequerimientos.1Si bienel diagramade flujode datos (DFD) y
la informaciónrelacionadanosonunaparte formal del UML, se utilizanparacomplementarlos
diagramasde éste y amplíanla perspectivade losrequerimientosydel flujodel sistema.El DFDadopta
un puntode vistadel tipoentrada-proceso-salidaparael sistema.Esdecir,losobjetosde datosentranal
sistema,sontransformadosporelementosde procesamientoylosobjetosde datosque resultande ello
salendel software.Losobjetosde datosse representanconflechasconleyendasylastransformaciones,
con círculos (tambiénllamadosburbujas).El DFDse presentaenformajerárquica.Es decir,el primer
modelode flujode datos(enocasionesllamadoDFDde nivel 0o diagramade contexto) representaal
sistemacomoun todo.Los diagramasposterioresde flujode datosmejoranel diagramade contextoy
dan cada vezmás detallesenlosnivelessiguientes.
Creaciónde un modelode flujode datosEl diagramade flujode datospermite desarrollarmodelosdel
dominiode lainformaciónydel dominiofuncional.A medidaque el DFDse mejoracon mayoresniveles
de detalle,se efectúaladescomposiciónfuncional implícitadel sistema.Al mismotiempo,lamejoradel
DFD da como resultadoel refinamientode losdatosconforme avanzanporlosprocesosque constituyen
la aplicación.
7.2.2 Creaciónde un modelode flujode control Paraciertostiposde aplicaciones,el modelode datosy
el diagramade flujode datosestodolo que se necesitaparaobtenerunavisiónsignificativade los
requerimientosdel software.Sinembargo,comoyase dijo,ungran númerode aplicacionesson
“motivadas”poreventosyno por datos,produceninformaciónde control enlugarde reporteso
pantallas,yprocesaninformaciónconmuchaatenciónenel tiempoyel desempeño.Talesaplicaciones
requierenel usodel modeladodelflujode control,ademásde modelarel flujode datos.Se dijoque un
eventooaspectodel control se implementacomovalorbooleano(porejemplo,verdaderoofalso,
encendidooapagado,1 o 0) o como una listadiscretade condiciones(vacío,bloqueado,lleno,etc.).Se
sugierenloslineamientossiguientesparaseleccionareventoscandidatospotenciales:•Enlistartodos
lossensoresque son“leídos”porel software.• Enlistartodaslascondicionesde interrupción. •Enlistar
todoslos“interruptores”que sonactivadosporun operador.• Enlistartodaslascondicionesde los
datos.• Revisartodoslos“aspectosde control”como posiblesentradasosalidasde especificacióndel
control,segúnel análisisgramatical de sustantivosyverbosque se aplicóala narracióndel
procesamiento.•Describirel comportamientode unsistemaconlaidentificaciónde susestados,
identificarcómose llegaa cada estadoy definirlastransicionesentreestados.•Centrarse enlas
posiblesomisiones,errormuycomúnal especificarel control;porejemplo,se debe preguntar:“¿hay
otro modode llegara este estadoo de salirde él?”
La especificaciónde control Unaespecificaciónde control (CSPEC) representade dosmanerasdistintas
el comportamientodel sistema(enel nivel desde el que se hizoreferenciaaél).3La CSPECcontiene un
diagramade estadoque esunaespecificaciónsecuencial delcomportamiento.Tambiénpuede contener
una tablade activacióndel programa,especificacióncombinatoriadel comportamiento.

3. La especificacióndelprocesoLaespecificacióndelproceso(PSPEC)se utilizaparadescribirtodoslos
procesosdel modelodel flujoque aparecenenel nivel final de lamejora.El contenidode la
especificacióndel proceso incluyeel textonarrativo,unadescripcióndellenguajede diseñodel
programa5 del algoritmodel proceso,ecuacionesmatemáticas,tablasodiagramasde actividadUML. Si
se da una PSPEC
7.3 CREACIÓN DE UN MODELO DE COMPORTAMIENTOLa notaciónde modeladoque hemosestudiado
hasta el momentorepresentaelementosestáticosdel modelode requerimientos.Eshorade hacerla
transiciónal comportamientodinámicodel sistemaoproducto.Parahacerlo,dichocomportamientose
representacomofunciónde eventosy tiempoespecíficos.El modelode comportamientoindicala
formaen laque responderáel software aeventosoestímulosexternos.Paragenerarel modelodeben
seguirse lospasossiguientes:1.Evaluartodosloscasos de uso para entenderporcompletolasecuencia
de interaccióndentrodel sistema.2.Identificarloseventosque conducenlasecuenciade interaccióny
que entiendenel modoenel que éstosse relacionanconobjetosespecíficos.3.Crearuna secuencia
para cada caso de uso.4. Construirundiagramade estadopara el sistema.5. Revisarel modelode
comportamientoparaverificarlaexactitudyconsistencia.
7.5 MODELADO DE REQUERIMIENTOS PARA WEBAPPS14 Es frecuente que losdesarrolladoresde web
manifiestenescepticismocuandose plantealaideadel análisisde losrequerimientosparawebapps.
Acostumbrandecir:“despuésde todo,el procesode desarrolloenwebdebe serágil yel análisistoma
tiempo.Nosharáser lentosjustocuandonecesitemosdiseñaryconstruirlawebapp”.El análisisde los
requerimientosllevatiempo,peroresolverel problemaequivocadotomaaúnmás tiempo.Lapregunta
que debe respondertododesarrolladorenwebessencilla:¿estássegurode que entiendeslos
requerimientosdel problema?Si larespuestaesun“sí” inequívoco,entoncestal vezseaposibleomitir
el modeladode losrequerimientos,perosi larespuestaes“no”,entonceséstadebe llevarseacabo.
7.5.1 ¿Cuántoanálisisessuficiente?El gradoenel que se profundice enel modeladode los
requerimientosparalaswebappsdependede losfactoressiguientes:•Tamañoy complejidaddel
incrementode lawebapp.•Númerode participantes(el análisisayudaaidentificarlosrequerimientos
conflictivosque provienende distintasfuentes).•Tamaño del equipode lawebapp.•Grado enel que
losmiembrosdel equipohantrabajadojuntosantes(el análisisayudaadesarrollarunacomprensión
comúndel proyecto).• Medidaenla que el éxitode laorganizacióndepende directamente deléxitode
la webapp.El inversode lospuntosanterioresesque amedidaque el proyectose hace más chico,que
el númerode participantesdisminuye,que el equipode desarrolloesmáscohesivoyque laaplicación
esmenoscrítica, esrazonable aplicarunenfoque másligeroparael análisis.Aunque esunabuenaidea
analizarel problemaantesde que comience el diseño,noesverdadque todoel análisisdebaprecedera
todoel diseño.Enrealidad,el diseñode unaparte específicade lawebappsólodemandaunanálisisde
losrequerimientosque afectanasóloesaparte de la webapp.Comounejemploproveniente de
CasaSegura,podríadiseñarse convalidezlaestéticageneral del sitioweb(formatos,colores,etc.) sin
tenerque analizarlosrequerimientosfuncionalesde lascapacidadesde comercioelectrónico.Sólose

4. necesitaanalizaraquellaparte del problemaque searelevante parael trabajode diseñodel incremento
que se va a entregar.