~ F E DEL S FTWARE. Un enfoque practico ' "-- ~\'I.,

Tamaño: px
Comenzar la demostración a partir de la página:

Download "~ F E DEL S FTWARE. Un enfoque practico --- - . ' "-- ~\'I.,"

Transcripción

1 ~ F E DEL S FTWARE Un enfoque practico I l I ' "-- ~\'I.,

2 CAPiTULO MODELADO, DEL ANALISIS CONCEPTOS CLAVE ooii"'del IIooinIo ooiisi. _urado dose ,.... de IIojo de datos dose IIOIIoIado _. 202 ere 225 de dolo 197 del CDlftpor _ sptdf"kodo. de,onlrol 215 orietolado alliujo 211 objoto. de dato reglas pt'actkas 194 En el ambito tecnico. la ingenieria de software comienza con una serie de tareas de model ado que conducen a una especificaci6n de requisitos y a una representaci6n completa del disef\o del software que se construira. EI modelo de analisis, que en realidad es una serie de modelos, es la primera representaci6n tecnica de un sistem a. En un libra sobre metodos de model ado del analisis, Tom DeMarco [OEM 79] describe el praceso de la siguiente manera: Al observar los problemas y fallas reconocidas de la rase de analisis es necesario agregarle los siguientes objetivos: Los productos del analisis deben tenet una ejevacta facilidad de man ten i rniento. Esto se aplica en particular al documento final [especificaci6n de requisitos de software). Los problemas de gran tamafto deben tratarse con un metoda efectivo de partidon. La especificaci6n del tipo de las novelas victorianas ya no sirve. Deben utilizarse graficas cuando sea posible. Se debe diferenciar entre consideraciones J6gicas [esenciales) y fisicas [de implementaci6n).. Como minima se necesita.. Algo que ayude a hacer una partici6n de los requisitos y a documentarla antes de Ja especificaci6n.. Algunos medios para el seguimiento y evaluaci6n de las interfases.. Herramientas nuevas para describir la 16gica y la tactica, algo mejor que un texto narrativ~. Aunque DeMarco escribi6 acerca de los atributos del modelado del analisis hace mas de un cuarto de siglo, sus contribuciones se siguen aplicando en la notaci6n y los metodos modernos de model ado del analisis. a,qui? La palabro eocriia as un vehiculo morovilloso parala comunlcaci6n, pero no es, necesariament&, la mejor forma de rep~."" _ requisitos para ei sofiwore1. cie ~. putodora. EI modelado del anali.i. uiiiiza ImO combinaci6n de formalo$ en 1exta y cliqpqlilol para representor los requisilo$ de 10. ciatoi, _ funciones y el compartamiento de uno I1I(IiIjIIQ que eo relativamente fac il de entender y, aun mas importante, conduce a una revision para Iograr la c:orrecci6n, la inlegridad y 10 consistencia..quilln 10 hac.? Un ingeniero de software [algu nos vace. liamado analistol conslruye el madelo empleanda requisitas abtenidas del d iente. tpor que.s importante? Para validar los..requisitos del software es necesario examinarlos desde algunos puntos de visto diferenles. EI mode 191

3 192 PARTE DOS PAAcnCA DE LA INGEN1ERlA DEL SOF1WARE lado del aoolisis represenla las requillitos en niul _ Una vez que se han creacio los modelos tiples U dimensiones#, con 10 que $& ~ fa ""'_.. ares, estos se refinon y analizan para probobilidad de encontrar errones,' de ~ sur- su calidad, integridad 'I cansistenda. jan'1'ncansistendas y de que se ~.omi madeia de anellisis ~nal 10 validan sianes. ',. las inlel~ ~Cuales son los pasos? Los requisitosdell..,:,cu61... producto obienido? Para el madan, funcionales y de comportamienlo;.:.;~.. 1IICde1o de anc'iiisis <i!sposible elegir una amplia madelan mediante varies ~pos de diagramos. w -:VGriedad de tipos de diagrornas. Coda una de madelada basado en escenarias representa.1' :,," 'ISlas representaciones afrece una visian de uno sistema desde ei punto de vista del usooria. EI.~de las elementos del modeia. madelada orien!ado 01 Hujo indico c6ma se,~ JMMIo eskir seguro de que 10 he transforman los objelas de datos allllq!izarse hecho._tamente? Los praductos de las funcianes del pracescimlerlio,;~.~1eiado ~.Jj\!KWado del aoolisis deb... revisarbasado en doses define objetos, ~t-- se en 10 nsiotiva a sue oarreccion, integridad y ciones. EI madelada del comportomiento PflI" cansistencia. Estos deben rehejar las neeesidasenta los estados del sistema y sus closes, <lsi' des de!ados 100 inleresadoo y eotablecer una como el impodo de 10. eventoo sabre sus esto- base desde 10 cual pueda condudrse el di.eno. 8 r 1 ANi,LISIS DE R QyISIIOS EI modelo de onolisis y Ie especificoci6n de requisitos proporciono un media para evoluar 10 colidod uno vel que el sohware este conslruido. El andlisis de requisitos genera la especificacion de caracterfsticas operacionales de software; indica la interfaz del software con otros elementos del sistema. y establece las restricciones que debe tener el software. El anidisis de requisitos permite que el ingeniero de software (a veces llamado en este contexto analisla 0 mode/ador) se extienda sobre requerimientos basicos establecidos durante tareas anteriores a la ingenieria de requisitos y construya modelos que representen escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones, el comportamiento de las clases y el sistema y, a medida que se transforma, el flujo de datos. EI analisis de requisitos Ie proporciona al disenador de software una representaci6n de informacion, funcion y comportamiento que puede trasladar a disefios arquitectonicos, de interfaz y en el nivel de componentes. Por ultimo, el modele de analisis y la especificacion de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software. Por medio del model ado del anal isis el ingeniero de software se centra primero en ei que, no en el como. ~Que objetos manipuia ei Sistema, que funciones debe desempeflar el sistema, que comportamientos muestra el sistema, que interfaces se definen y que restricciones se aplican?l En capitulos anteriores se estableci6 que en esta etapa tal vez no fuera posible realizar una especificacion compieta de requisitos. Quiza el desarrollador no este I Es necesario mencionar que con forme los clientes se vuelven mas refinados en el sentido tecnologico existe una tendencia hacia la especificacion tanto del c6mo como del que. Sin embargo, el en roque prima rio debe permanecer en el que.

4 CAPITULO 8 MODELADO DEL ANAusIS 193 Elmodelo de cm6l1s1scomo an puente ae 1a descrtpclon del sistema y I1modelo de diseno. De5Cripcion del sistema segura de que enfoque espedfico realizara la fund6n y si se desempefiara de manera apropiada. Estas realidades favoreeen un enfoque iterativo para el anal isis y el mode I ado de requisitos. EI analista debe modelar 10 que se conoce y utilizar ese modelo como base para diseiiar un incremento de software Filosofia y objetivos generales EI modelo de analisis debe cumplir tres objetivos primari os: I) describir 10 que requiere el cliente, 2) establecer una base para la creaci6n de un disefio de soflware, y 3) definir un conjunto de requisitos que puedan validarse una vez conslruido el soflware. EI modelo de analisis Ilena el vacio entre una descripci6n al nivel de sistema (capitulo 6) - que detalla la funcionalidad general del sistema, la eual se logra al aplicar soflware, hardware, datos, humanos- y otros elementos del sistema y del disefio de soflware (capitulo 9) - que detallan la arquitectura de aplicaci6n del soflware, la interraz con el usuario y la estructura en ei nivei de componentes-. Esta relaci6n se i1ustra en la figura 'los problemas dignos de olaear demu"lran su volor devolvi.ndo el golp. PietHein Es importante puntualizar que algunos elementos del modelo de anal isis estan presentes (en un grado mas alto de abstracci6n) en la descripci6n del sistema, y que esas tareas de ingenieria de requisitos en realidad comienzan como parte de la ingenieria de sistemas. Ademas, todos los elementos del modelo de analisis son identificables de manera directa en las partes del modelo del disefio. No siempre es posible una divisi6n clara de tareas de analisis y disefio entre estas dos importantes actividades del modelado. De modo invariable, como parte del analisis se realiza algun disefio y algun analisis se efectua durante el disefio. 2 De manera alternativa, el equipo de software puede elegir la creaci6n de un prototipo (capitulo 3) en un esfuerzo encaminado a entender mejor los requisitos para el sistema.

5 194 PARTE DOS PAAcnCA DE LA INGENIERlA DEL SOFTWARE Reglas practicas de an6lisis Arlow y Neustadt [ARL02[ sugieren varias reglas practicas que deben seguirse para crear el modelo de analisis, El modelo debe centrarse en los requisitos visibles dentro del problema a dominio de negocio. EI grade de abstraccion debe ser alto de forma relativa. "No se debe perder tiempo en detalles" IARL02] que tratan de explicar como funcionara el sistema. Cada elemento del modelo de analisis debe agregarse a un acuerdo general de los requisitos de software y proporcionar una vision interna del dominio de informa cion, funcion y comportamiento del sistema. Debe retrasarse la consideracion de la infraestructura y otros modelos no fun cionales hasta el diseflo. Por ejemplo, es posible que se requiera una base de datos, pero las clases necesarias para implementarla, las funciones que se requieren para acceder a ella y el comportamiento que se exhibira cuando se utilice debe considerarse solo despues de que se haya completado el analisis de dominio del problema. Se debe minimizar el acoplamiento de todo el sistema. Es importante representar las relaciones entre clases y funciones. Sin embargo, si el nivel de "interconexion" es extremadamente alto se deben hacer esfuerzos para reducirlo. Se debe tener la seguridad de que el modelo de andlisis proporciona valor a todos los interesados. Cada ci rcunscripcion tiene su propio uso del modelo. Por ejemplo, los interesados relacionados con los negocios deben utilizar el modelo para validar los requisitos; los disefiadores, como base para el disefio; la gente de asegu ramiento de la calidad, como ayuda para planear pruebas de aceptacion. EI modelo debe mantenerse tan simple como sea posible. No se deben agregar diagramas adicionales cuanda estos no ofrezcan informacion nueva. No se deben utilizar formas de notaci6n nuevas cuanda basta con una simple!isla An6lisis del dominio [n wwwji...,om/lngii.h/ Software Inglneerlog/ 51_","5., pueden enconrrorse mochos recursos atlles pora ei onolisis del dominio. AI examinar la ingenieria de requisitos (capitulo 7) se establecio que los patrones de analisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominic de negocio especifico. Si estos patrones se definen y se clasifican por categoria de una manera que permitan a1 ingeniero 0 al analista de software reconocerl os y reutilizarlos, la creacion del modelo de analisis se acelera. Un factor de mayor importancia es que la probabilidad de aplicar patrones de disefio reutili zables y componentes ejecutables de software aumenta en forma sustancial. Esto ofrece tiempo al mercado y reduce los costos del desarrollo.

6 CAPiTULO 8 MODELADO DEL ANALISIS 195 Entrada y salida para el cmcl1isis del dominio. Fuentes del conocimienlo del dominio Literatura tecnica - Aplicociones existentes Sondeos a los clientes / Anal;.;. T axonomias de close \ Estondares de reutilizadon Modelo Modelos funcionales de an61isis Recomendocion experto del dominio del dominio Requisitos octuoles/futuros '\ ' ~ Lenguojes de dominio ~Pero, en primer lugar, como se reconocen los patrones de analisis?.;.quienes los definen, los asignan a una categoria y los preparan para aplicarlos en proyectos subsecuentes? Las respuestas a estas preguntas residen en e! analisis del dominio. Firesmith [FIR93] describe el aniliisis del dominio de la siguiente manera, El aniilisis del dominio de software es la identificacion, el analisis y la especificacion de re quisitos comunes de un dominio especifico de aplicacion para, de manera tipica, reutilizarlo en multiples proyectos dentro de ese dominio de aplicacion.. [EI anal isis del dominio orientado a objetos es] la identificacion, el anal isis y la especificacion de capacidades comunes reutilizables dentro de un dominic especifico de aplicacion, en terminos de objetos, clases, subensamblajes y marcos de trabajo. El "dominio de aplicacion especifico" puede variar desde aeronautica hasta servicios bancarios, desde videojuegos en multimedia hasta software aplicado en instrumental medico. La meta del analisis 0 de dominio es directa: encontrar 0 crear aquel\as clases de analisis 0 funciones y caracteristicas comunes que se aplican ampli amente para que puedan reutilizarse 3,.,iij!,! iih' &1 Enwww.sei... fslrf descriptionsf detio.bhnl puede enconltorse una exposici6n volioso sobre el onlliisis y 10 ingenieno del dominio. /lei gran arte del aprendizoie as entender poco a poco" John l.ck. En cierta forma, el papel de un analista de dominic es similar al de un maestro forjador de herramientas en un ambiente de manufactura pesada. EI trabajo de este ultimo es disefiar y fabricar instrumentos que puedan ser usados por much a gente que realiza trabajos simi lares. EI papel del analista de dominio4 es descubrir y definir 3 Una vision complementaria del analisis del dominio "involucra el modelado del dominio de forma que los ingenieros de software y otros interesados puedan aprender mas de el... no todas las clases del dominio resultan necesariamente en el desarrollo de clases reutilizables"[let03]. 4 No debe suponerse que si se cuenta con la colab oraci6n de un analista del dominio, un ingeniero de software no tiene por que comprender el dominio de aplicacion. Todos los miembros de un equipo de software deben tener algun conocimiento del dominio en el cual se colocara el software.

7 196 PARTE DOS PAAcnCA DE LA lngenierla DEL SOFJ'INARE patrones de analisis reutjlizables, clases de analisis e informacion relacionada que pueda usar mucha gente en aplicaciones parecidas. La figura 8.2 [ARA89] ilustra entradas y salidas clave para el proceso de analisis de dominio. Las fuentes de conocimiento del dominic se examinan en un intento por identificar objetos que pueden ser reutilizados a traves del dominio. Una visi6n del modelado del analisis, Ilamado analisis estructurado, considera que los datos y el proceso que transforman los datos son entidades separadas. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Los procesos que manipulan los objetos de los datos se modelan de tal manera que muestran c6mo transforman los datos, mientras los objetos de datos fluyen por el sistema. Un segundo enfoque del modelado del anal isis, Ilamado analisis orientado a objetos, se centra en la definicion de clases y en la manera en que estas colaboran entre elias para efectuar los requisitos del cliente. EI UML Y el proceso unificado (capitulo 3) estan orientados a objetos en forma predominante. B [olnolisil os frustronte, lieno de relociones interperlonoles complejol, indefinido y dill«l. En pocos polabros, 8\ foscinonte. Una vez que estos engonchado, el vieio placer de 10 construcdon de sistemas mmca sera 5uficiente pam sotisfocert." T... DeM.rco Aunque el modele de analisis propuesto en este capitulo combina caracteristicas de ambos enfoques, es com lin que los equipos de software elijan uno y excluyan todas las representaciones del otro. El cuestionamiento no es ellal es el mejot, sino que combinaci6n de representaciones Ie proporcionara a los interesados el mejor modelo de requisitos de software y el puente mas efectivo para el disefio de software. EI modelado del analisis conduce a la derivaci6n de cad a uno de los elementos de modelado mostrados en la figura 8.3. No obstante, el contenido especifico de cada elemento (por ejemplo, los diagramas con que se construyen el elemento y el mode- 10) puede diferir de proyecto a proyecto. Como ya se ha puntuajizado muchas veces en este libro, el equipo de software debe trabajar para mantenerlo simple. S610 se deben utilizar aquellos elementos que agreguen valor al modelo. If,Por que debemos construir modelos?,por que no (onstruimos el sistema y yo? Lo respuesto es que podemos construir modelos de tal forma que resoltemos 0 enfaticemos dertos coracteristicas criticos de un sistema l 01 mismo nempo que quitomos ;nlolil 0 otros' olpectol del liltema." Ed YOIrdon

8 CAPITULO 8 MODELADO DEL ANAuSIS 197 Elementos delmodelo de ancilisis. E~mentos basaoos en escenanos Cosos de usa, redo Cosos de usa, diogromo$ Diogromos de odividod Diogromos de corril Ele mentos on.ntados 01 fluio DiogfOmoS de Huio de dolos Diogromos de Ruio de (onlrol NOffOlivos de proce$omienlo Modelo de an61isis Erementos basadas en closes Diogromos de dose Poquetes de onalisis Modelos CRC Diogromos de coloborod6n Ele mentos de camdortamiento Diogromos de estodo Diogromos de secuencio EI modelado del analisis a menudo comienza con el mode/ado de datos. EI ingeniero o analista de software define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos, ademas de otra informacion pertinente para las relaciones Objetos de datos,como se manifiestan a si mismos los dalas denlra del contexto de una oplicadon? Un objeto de datos es uno representoci6n de cuolquier informacion compuesto que se proceso (on software. Un objeto de datos es una representacion de casi cualquier informacion compuesta que el software debe en tender. Informaci6n compuesla se refiere a algo que tiene muchas propiedades a atributos diferentes. Por 10 tanto, "anchura" (un valor individual) no seria un objeto de datos valido, pero las dimensiones (Ia incorporacion de altura, an chura y profundidadl podrian defi nirse como un objeto. Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que produzca 0 consuma infonnacion). una cosa (por ejemplo, un reporte 0 un despliegue). un suceso (como una liamada telefonica) 0 un even to (como una alarma), un papel (por ejemplo, un vendedor). una unidad organizacional (como un departamento de contaduria), un lugar (como un almacen). 0 una estructura (como un archivo). Por ejemplo, una persona 0 un auto pueden verse como un objeto de datos en el sentido de que cualquiera de elias puede definirse en tenninos de un conjunto de atributos. La descripcion del objeto de datos incorpora el objeto y todos sus atributos. Un objeto de datos encapsula solo datos: no existe alguna referencia dentro de un objeto de datos a las operaciones actlien sobre los datos S Par 10 tanto, el objeto de datos puede representarse como una tabla, tal como se muestra en la figura 8.4. Los encabezados de la tabla reflejan los atributos del objeto. En este caso, un auto se define en terminos de marca, modelo, numero de serie, tipo de carrocerfa, color Y pt'opietario. EI contenido de la tabla representa ejemplos especificos del objeto de datos. Por ejemplo, un Chevy Corvette es una muestra del objeto de datos auto. 5 Esta distinci6n sepa ra los objetos de datos y las clases u objetos definidos como parte del enfoque orientado a objetos.

9 198 PARTE DOS PRAcnCA DE LA INGENIERiA DEL SOFTWARE Representaclon tabular de objetos de datos. - Ins! oneie Nombres de otributos /r ~A'- ~, Une los obietos de dotos entre 5i, en este coso, propielorio Atributos idenlificodor descriptivos ~~ ~ Atributos referencioles ~ Morea Modelo # de id. Tipo Color Propietario lexus l5400 AB123. Sedan Blanco R5P Chevy Corveffe X456. DeportivQ Roje CCD BMW 750il XZ765. Coupe Blanco Ul Ford Taurus Q12A45... Sedan Azul BlF 8.3,2 Atrlbutos Los otribulos definen a un objeto de dotos, describen ~s corocteristicos y, en algunos rosos, hocen referencio (] olro objeto. ;." ; EI (oocepfo Ilomrn:lo "normoliloci6n es importonte pam todos oquellos que intenton realizer modelodo de detos. En www. d"amodel.olg puede encontrorse UflO intjoducci6n om. Los alribulas deflnen las propiedades de un objeto de datos y toman una de las tres caracteristicas diferentes. Se pueden utilizar para l) nombrar una ocurrencia del objeto de datos, 2) describir la ocurrencia 0 3) hacer referencia a otra ocurrencia en otra tabla. Ademas, se debe deflnir uno 0 mas atributos como un identiflcador; es decir, el atributo identificador se convierte en una "clave" cuando se desea encontrar una ocurrencia del objeto de datos. En algunos casos, los valores para el (los) identiflcador(es) son (micas, aunque esto no es un requisito. En referencia al objeto de datos auto, un identiflcador razonable podria ser el numero de serie. EI canjunto de atributos apropiado para un objeto de datos se determina mediante la comprensi6n del contexto del problema. Los atributos para auto sirven bien para una aplicaci6n que utilice el Departamento de vehiculos de motor, pero estos atributos serian inutiles para una compania automotriz que necesite un software para el control de fabricaci6n. En este ultimo caso, los atributos para auto tal vez incluirian tambie!n nurnero de serie, tipo de carrocerfa y color, pero ademas tendrian que adicionarse much os mas atributos (como c6digo interior, tipo de tren de rnanejo, designadar de paquete de ajuste, tipo de transmisi6n),.para hacer de auto un objeto s i gnificativ~ en el contexto de control de fabricaci6n. ~ Objetos de datos y clases 00, "son 10 mismo? (uando se debate ocerco de los objetos de tambien incorpora las operociones que manipulan los datos es comun que suria una pregunto: aun datos implicodos por dichos atributos. Ademes, 10 objeto de dotos es 10 mismo que una dose orientado a definicion de doses implico una infraestructura completa objetos? La respuesta es: "non. que es parte del enfoque de la ingenierio de software Un objeto de dotos define un elemento compuesto de orientado a objetos. Las doses se comunican entre 51 a los datos' esto es incorpora una coleccion de elementos de troves de mensajes; pueden organizarse en jerorquios; datos individuale's (atributos) y do un nombre a 10 proporcionan caracteristicas heredadas para objetos que coleccion de elementos (el nombre del objeto de datos). son uno instancio para una dose. Uno dose 00 encapsula atributos de los datos, pero

10 CAPiTULO 8 MODELADO DEL ANAuSIS 199 Relac10nes entre objetos de datos. p."ono I I oulomov;1 1 0) Una conexion b6sica entre objetos de dotos b) Relaciones entre objetos de datos Relaciones Los lelociones indicon ~ monelo en que los objetos de dotos eston conectodos entre sf. Los objetos de datos estan conectados entre si de muchas maneras diferentes. Por ejemplo. dos objetos de datos, persona y auto, pueden representarse con la simple notaci6n ilustrada en la figura S.Sa. Se establece una conexi6n entre persona y auto porque los objetos se relacionan entre sl. l.pero, cuales son las relaciones? La respuesta se determina entendiendo el papel de las personas (propietarios, en este caso) y de los autos dentro del contexte del software que se construira. Se puede definir un conjunto de parejas objeto/ relaci6n que definan las relaciones relevantes. Por ejemplo: Una persona posee un auto, Una persona esta asegurada para conducir un auto. Las relaciones posee y esla asegurada para conducir definen las conexiones rei evantes entre persona y auto. En la figura S.Sb se ilustran estas parejas objeto/relaci6n de manera grafica. Las fiechas de la figura S.Sb ofrecen informaci6n importante ace rca de la direccionalidad de la relaci6n y a menudo reducen la ambiguedad 0 las malas interpretaciones Cardinalidad y modalidad Los elementos del modelado de datos -objetos de datos, atributos y relacionesofrecen la base para en tender el dominio de informaci6n de un problema. Sin embargo, tam bien es necesario comprender informacion adicional relacionada con estos elementos basi cos. Hasta este punto se ha definido un conjunto de objetos y se han representado las parejas objeto/relaci6n que los limitan. Pero un simple par que establece que objetox se re/adona con objetoy no proporciona suficiente informaci6n para los prop6sitos de la ingenieria del software. Se debe en tender cuantas ocurrencias del objetox estan relacionadas con cuantas ocurrencias del objetoy. Esto conduce al concepto del model ado de datos llamado cardinalidad. El modele de datos debe ser capaz de representar el numero de ocurrencias de los objetos en una relaci6n dada. Tillmann [TIL93] define la cardinali dad de un par objeto/ relaci6n de la siguiente manera: "Cardinalidad es la especificaci6n del nume-

11 200 PARTE DOS pracnca DE LA INGENIERlA DEL SOFIWARE,COmo se maneja una situation en 10 que un objeto de datos esta rela~ donado (on 10 o(urrencia de muchos olros objeto, de doto,? ro de ocurrencias de un [objetoj que puede relacionarse con el numero de ocurrencias de otro [objetoj". Por ejemplo, un objeto puede relacionarse solo con otro objeto (una relacion I : I ); un objeto puede relacionarse con muchos objetos (una relacion I:N); un numero de ocurrencias de un objeto puede relacionarse con algun otro numero de ocurrencias de otro objeto (una relacion M:N)6 La cardinalidad tambien define "el numero maximo de objetos que puede participar en una relacion" [TIL93]. Sin embargo, no indica si un objeto particular de datos debe participar 0 no en la relacion. EI modele de datos agrega modalidad al par objeto/ rela cion para especificar esta informacion. ~ Diagramas de entidad-rejacion La porejo objeto-relaci6n es 10 piedra angular del modele de datos. Estes porejas pueden representorse de monero grcifica mediante el diagromo de enlidad-reloci6n (OERJ. 7 EIDER 10 propu$o originalmente Peter Chen [CHEll] para el diseno de sistema!. de bases relacionale!., y despues otrmlo han ompliado. Con eider se identifieo un caniunlo de componentes primarios: objetos de datos, atributos, relaciones e indicodores de vorios tipos. EI proposito primordial del DER es representor objetos de dotos y sus relaciones. Ya se ha hecho una introduccion de 10 notacion rudimentaria para eider. Los objetos de datos se represenlan par medio de un rectangulo etiquelado. Los relociones se representan mediante una linea etiquelada que conedo objetos. En algunos variaciones del DER 10 linea de conexion conliene un rombo que esta etiquelado con 10 relacion. Las conexiones entre objetos de datos y relaciones se establecen mediante una voriedod de simbolos especioles que indican su cardinalidad y modolidod. Para mas informacion sabre el modelodo de datos y el diogromo de entidad-relacion ellector inleresado puede consultor [THAOOj La modalidad de una relacion es de 0 si no hay una necesidad explicita para que ocurra la relaci6n 0 la relaci6n es opcional. La modalidad es 1 si una ocurrencia de la relacion es obligatoria. Pora que un sistemo de information seo util, "nfioble, odoptoble y economico debe es10r bosodo primero en 01 mocieiodo de dol.., y solo de monero,e(undorio en el onoli,i, del proceso... porque 10 esinkiuro d. dot.. so roliore de Ionno inherente a 10 verdod, mientro, que el proceso os relotivo 0 10 tirniro." ~ ModeJado de datos Objetivo: Las herramientas para el modelodo de datos proparcionon 01 ingeniero de sohware 10 copocidod de representor objetos de datos, sus caraclerislicas y relaciones. Estas herramientas -que se utilizan sabre lodo para grondes aplicaciones de bases de datos y olres proyectos de sistemas de informacion- 6 Par ejempia, un tia puede tene r muchos sobrinos y un sabrina puede tene r muchos tias. 7 Aunque el DER todavia se usa en algunas aplicacianes para el disefio de bases de datos, en la actualidad la notacion en UML es la mas utilizada para el disefia de datos

12 CAPITULO 8 MODELADO DEL ANAuSIS 201 proporcionon un medio automatizodo para crear diagramas de entidad-relacion, diccionarios de objetos de datos y modelos relacionados. Mecanica: las herramientas en esta categorla permiten 01 usuario describir objetos de datos y sus relaciones. En algunos casos uti lizan 10 notacion del DER; en otras ocasiones modelan las relaciones por medio de otros mecanismos. Adem6s permiten 10 creacion de un modelo de base de datos 01 generar un e5quema de bose de datos pora 5MBD. Herramientas representativas 8 AI/Fusion ERWin, desarrollado por Computes Associates (WWVv'3.ca.com), oyuda en el disena de objetos de datos, estructuras propias y elementos clove para bases de datos. ER/Sfudio, desorrollado per Embarcadero Software (www.embarcodero.coml.brindo soporte 01 modelado entidad-relaci6n. Oroefe/Designer, desarrollado per Oracle Systems (www.oracle.com). modelo procesos de negocios, entidades de datos y relaciones que se transforman en disenos a partir de los cuales se generan aplicaciones completas y bases de datos. MetaScope, desarrollado per Madrone Systems (www.madronesystems.coml. es uno herramienta para el modelado de datos de bajo costo que do soperte a 10 representacion gr6fica de datos. Mode/Sphere, desarrollado per Magno Solutions GMBH (www.mognosolutions.coml, do soporte a uno variedad de herromientas de modelado relocional. Visib/eAno/yst, desorrollodo por Visible Systems (www.visible.coml, do soporte a una va riedad de fvnciones de modelado del analisis, incluido el modelado de datos. Cualquier estudio sobre el amilisis orientado a objetos deberia comenzar definiendo el termino orientado a objetos. tque es un punto de vista orientado a objetos? tpor que un metodo se considera orienta do a objetos? tque es un objeto? Cuando la 00 obtuvo una amplia variedad de adeptos durante las decadas de 1980 y 1990, existieron muchas opiniones diferentes (por ejemplo, [BER93], [TAY90], [STR88], [B0086] acerca de las respuestas correctas a estas preguntas. En la actualidad ha surgido una vision coherente de la 00. EI objetivo del amilisis orientado a objetos (AOO) es definir todas las c1ases (ademas de las relaciones y el comportamiento asociado con elias) relevantes para el problema y que deben resolverse. Esto se logra lievando a cabo algunas tareas: 1. Deben comunicarse los requisitos basicos del usuario entre el cliente y el ingeniero de software. 2. Deben identificarse las clases (es decir, se definen los atributos y metodos). 3. Se define una jerarquia de c1ases. 4. Deben representarse las relaciones de objeto a objeto (conexiones entre objetos). 5. Debe modelarse el comportamiento del objeto. 6. Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo este completo. 8 Las herramientas mencionadas aqui son una muestra de esta categoria. En la mayoria de 105 casos los nombres estan regi strados par sus respectivos desarrolladores.

13 202 PARTE DOS pracnca DE LA INGENIERlA DEL SOFIWARE En lugar de examinar un problema mediante un modelo mas convencional del tipo entrada-procesamiento-salida (flujo de informacion) 0 un modelo derivado en forma exclusiva de las estructuras jerarquicas de informaci6n, el AOO construye un modelo orientado a las clases que se basa en la comprension de los conceptos 00. Conceptos orientados a objetos ~, Los conceptos orientodos a objetos (00) est6n bien establecidos en el mundo de 10 ingenieria del sohware. A continuoci6n 5e presentan los descripciones abreviodos de conceptos 00 que 5e encuentran con frecuencia durante el modelado del ancilisis. En el capitulo lose presenton aires objetos 00 que est6n alineados de monero mas cercone 01 diseno de software. Atributos: una colecci6n de valores de los datos que describen una close. Close: encapsulo los dotos y las abstracciones de procedimiento requeridos para describir el contenido y el comportomiento de alguna entidad del mundo real. Oicho de olra manera, una clase es una descripcion generolizada (por ejemplo, una plantilla, un patron 0 un plano de Irabajo) que describe una coleccion de objelos similares. Objelos: inslancias de una close espedfica. los obielos heredan los atributos y operaciones de una close. Operaciones: tambieln liamodas mefodos y servicios, proporcionan 10 representacion de uno de los comportamientos de una close. Subclase: una especializacion de 10 superclase. Uno subclose puede heredar tanto los atributos como las operaciones de una superclase. Superclase: tambien liamada uno close basico, es una generalizacion de un conjunto de closes que estan relacionadas con ella., Aunque el exito de un sistema 0 producto basado en computadora se mide en much as formas, la satisfaccion del usuario encabeza la lista. Si los ingenieros de software entienden la manera en que los usuarios finales (y otros acto res) quieren interactuar con el sistema, el equipo de software sera mas capaz de caracterizar en forma apropiada los requisitos y construir modelos significativos de analisis y diseno. Por 10 tanto, el modelado del analisis con UML comienza con 1a creaci6n de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril Escritura de casos de uso Un caso de uso captura las interacciones que ocurren entre los productores y consumidores de informaci6n y del sistema en sf mismo. En esta secci6n se examina 1a forma en que se desarrollan los casos de usa como una parte de la actividad del modelado del amilisis 9 El concepto de un caso de uso (capitulo 7) es relativamente facil de entender: describe un escenario de uso especifico en un lenguaje directo desde el punto de vista 9 Los casos de uso son una parte particularmente importante del modelado del analisis para las in terfases con el usuario. El analisis de la interfaz se trata con detalle en el capitulo 12.

14 CAPITULO 8 MODELADO DEL ANALlSIS 203 de un actor definido.lo Pero como puede saberse 1).;.sobre que escribir? 2)..;.cuanto escribir acerca de ella' 3), <que tan detallada debe ser la descripcion', y 4) <coma organizar la descripcion? Estas son las preguntas que deben contestarse para que los casas de usa tengan un valar como herramienta para el modelada del anillisis. '[los!ll!os d. usa) son simplemente uno oyuda para delinif 10 que existe luera del sistema (odoresl y 10 que deberi. reaiiw ei sisfemo (OOIOS de usol." 1.0' JtKObsoo En afgunas situa (ianes, fos casas de usa se vuefven ef mecanismo dominante de fa ingenierfa de requisifos. Sin embargo, esto no signifiea que deban descof/voe los mnceptos y temicas eslud/odos en el copilulo 7. lsobre que escribir? Las primeras dos tareas de la ingenieria de requisitos 11 -inicia y obtenci6n- proporcionan la informaci6n necesaria para comenzar a escribir casas de usa. Las reuniones para la recapilacion de requisitas, despliegue de la funcion de calidad (QFD) y atros mecanismas para la ingenierla de requisitas se utilizan para identificar a las interesados, definir el ambito del problema, especificar las metas aperativas glabales, esquematizar todas las requisitas funcianales canacidos y describir las casas (abjetas) que manipulara el sistema. El desarrollo de una serie de casos de uso se comienza haciendo una lista de las funciones a actividades que realiza un actar especifico. Estas pueden abtenerse de una lista de funciones requeridas del sistema par medio de conversaciones can los clientes a usuarios finales, 0 mediante una evaluaci6n de los diagramas de actividad (seccion 8.5.2) desarrolladas camo parte del madelada del analisis. Desarrollo de otro escenario de uso preumlnar II escenario: Uno sola de II1II""''' 'aultln'lela segundo junto para 10 recopilacion ~.CI!I,",S: Jamie Lazor, miembro del equipo de Robbim, miembro del equipo de software; 'II~:~,'.::~:i~ngenierio del software; tres n de metcadotechio; un representonte de de producto; y un moderodor. """,II6or: Es hora de que comencemos a hablar de.1a n.nci6n de vigilancia de HagarSeguro. CI desonollor un escenorio de usuorio para el "Ia funci6n de seguridad en.1 hagar. Jamie:,Qui.. hoc.. ei flo!"" del odor en _, Moderador: Creo qu<>menedhh luna penonci de mercodotecnial he.. tado ft'abaiando en... funcionalidod.,par que no hoces I!i ei pafmiif Meredith:,Quieres que 10 hogamo. iguai qu<> Ia 6IIima vez, no es asf? Moderador: (orredo... de 10 misma forma. Meredith: Bueno, es abvia que 10 raz6n pare Ia vigilancia es permitir que el propietario est6 peldente de 10 coso mientras el 0 ella est6n vera, grabar y reprodudr videos que se hoyon capturodo.. _ ese tipo de cosas. 10 Un actor no es una persona especifica, sino el papel que desempeiia una persona (0 dispositivo) dentro de un contexto especifico. Un actor "llama al sistema para entregar uno de sus servicios" [CaCOII II Estas tareas de la ingenieria de requisitos se examinan con detalle en el capitulo 7.

15 204 PARTE DOS pracnca DE LA!NGENIERiA DEI.. SOFIWARE De ocuerdo, entonces b6sicamente hay dos funci6n de vigilancia primero ~Vura.llislerna, induyendo el establecimiento de un -necesitomos herramientos que cyuden movimiento y los acercamienlos de una c:6maro especi~ca. Especi~co 10 camara seleccionada doodo.. plano de 10 coso. Ouiero grabar y nepraduclr Ia saiidco de los comoros de manera seiectivo. Tombi," quiero.. copaz de bloqueor ej occeso a uno 0 mas c6maros con uno contrasena especifico. Y quiero fa opci6n de wr pequenos ventanos que muestren vistas de todas los comoros y despues ser capoz de selecxionc. Ia que quiera destacar. rt;~:~:~ 0 hacerlo- y Ia segundo parte es 10 funci6n ':~i real en sf misma. Como ei establecimiento Jamie: Eso$ se liaman vistas en miniatura. ~r.;;;~. '~S parte de Ia octividod de conflguroci6n, me.~ Ia funci6n de vigilancio.... _... (... riencio): Me quilasfe las palabras boca..,. r I... : Mm... Quiero tener occeso a 10 funci6n de ~, yo sea a troves de 10 PC 0 de Internet. Siento que ei ocxeso por Internet serio ei de uso mas frecuente. De... ier monera, quiero ser capaz de desplegor Wtos de las c6ma1'o> en uno PC y cantrolar el Meredith: Bien, entonces quiero vistas en minioturtl de todas las comaras. Tambier, quiero que Ia interfaz can Ia funci6n de vigilancia tengo Ie misma opariencia que todas las otras inlerloses de HogarSeguro. OUi... que sea intuitiva; es decir, que no sea n&ce$orto leer un manual para poder usorta. Moderador: Suen trabajo, ahara entremos en esta funci6n con un poco m6s de detalle... La funcian de vigilancia en el hagar de HogarSeguro que se examina en el recuadro identifica las siguientes funciones (una lista abreviadal que realiza el actor identificado como propietario de 1a casa: Tener acceso a la camara de vigilancia via Internet. Seleccionar la camara que desea ve r. Solicitar vistas en miniatura de tadas las camaras. Desplegar vistas de 1a cama ra en una ventana de una Pc. Controlar la visi6n panoramica y de acercamiento en una camara especifica. Registrar en forma select iva la salida de camara. Repetir la salida de camara. Con forme se realizan las conversaciones posteriores con el interesado (quien desempef\a el papel de un propietario), el equipo de recopilacian de requisitos desarrolla casos de uso para cada una de las funciones mencionadas. En general, los casos de uso se escriben primero en un estilo narrativo informal. Si se requiere mayor formalidad se rescribe el mismo caso de usa utilizando un formato estructurado similar al propuesto en el capitulo 7 y reproducido en esta seccian como un recuadro. Con fines i1ustrativos, considerese la fundon "acceso a camara de vigilancia-despliegue de vistas de camara (ACV-DVC)". EI interesado que desempef\a el papel del propietario pod ria escribir el siguiente rel ata:

16 CAPITULO 8 MODELADO DEL ANAuSIS 205, caso de uso: Acceso a camara de vigilancia-desplie gue de vistas de camara (ACV-DVC) Actor: propietario Si me encuentro en un lugar lejano puedo usar una PC con un soflware de navegad6n apropiado para en trar al sitio web de los productos HogarSeguro, Ingreso mi clave de usuario y dos niveies de contrasenas y, despues de que estoy validado, tengo acceso a toda la funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una camara especifica selecciono "vigilancia" de los botones desplegados para las funciones mas importantes. Oespues escojo "seleccionar una camara" y se despliega un plano de planla de la casa. Entonces selecciono la camara en la que estoy interesado. En forma alterna, puedo ver simultaneamente una lista con vistas en miniatura de todas las camaras al seleccionar "todas las camaras" como mi opd6n de visualizaci6n. Una vez que he seleccionado una camara, selecciono "vista" y una vista de un cuadro por segundo aparece en una ventana, a la cual identifica la camara clave. 5i quiero cambiar de camara, elijo "seleccionar una camara" y la ven tana de visi6n original desaparece y se despliega de nuevo el plano de planta de la casa. Una variaci6n del caso de usa relatada presenta la interacci6n como una secuencia orden ada de las acciones del usuario. Cada acci6n se representa como un enunciado declarativo. Despues de vi sitar la funci6n ACV-DVC, se puede escribir: Caso de uso: Acceso a camara de vigilancia-despliegue de vistas de camara (ACV-DVC) Actor: propietario 1. El propietario entra en el sitio Web de HogarSeguro. 2. EI propietario introduce su clave de usuario. 3. EI propietario introduce dos contrasenas (cada una de a1 menos ocho caracteres). 4. EI sistema despjiega todos los botones de las funciones mas importantes. 5. EI propietario selecdona "vigilancia" de los botones de funciones mas importantes. 6. EI propietario elige "seleccionar una camara". 7. EI sistema despliega el plano de planta de la casa. 8. El propietario seiecciona un icono de camara del plano de pianta, 9. EI propietario selecciona el boton "vista", 10. Ei sistema despliega una ventana de visi6n, identificado por la clave de la camara. 11. El sistema muestra salida de video dentro de la ventana de visi6n con una velocidad de un marco por segundo. Es importante destacar que esta presentacion secuencial no considera algunas interacciones aiternativas (la narrativa tiene un flujo mas Iibre y representa unas cuantas alternativas). Los casos de uso de este tipo se refieren algunas veces como escenarios primarios [SCH98]. "Los msos de UIO pueden UIOIW en muchos p,o<osos [de softwnre]. Nuestr. levoril. es un PC"'" que sea iiwaiiyo Y aniu<ido pot ei 'iesgo: - Geri SdooeIder Y... WIIItn

17 206 PARTE DOS pracnca DE LA INGENIERlA DEL SOFlWARE Por supuesto, para una comptensi6n completa de la funci6n que se pretende describir es esendal una descripcion de las interacciones alternativas. Por 10 tanto, cada paso en el escenario primario se eva ilia realizando las siguientes preguntas [5CH98j:,COmo se examinan (ursos alternativo5 de acci6n mientras se desarrollo un coso de usa? LEI acto puede ejecutar atra acd6n en este punto? "Es posible que el actor encuentre alguna condici6n de error en este punto? 5i es asi, l..cual podria ser? "Es posible que el actor encuentre algun otro comportamiento provocado por algun evento fuera de su control? 5i es as1, Lcual podria ser? EI resultado de las respuestas a estas preguntas es la creaci6n de un conjunto de escenarios secundarios que son parte del caso de uso original, pero que representan comportamientos alternativos. Por ejemplo, considerense los pasos 6 y 7 en el escenario primario presentado Iineas atras: 6. EI propietario elige "seleccionar una camara". 7. EI sistema despliega el plano de planta de la casa. tiel actor puede ejecutqr aua acdon en este punta? La respuesta es: "si". Con referencia al relato de flujo libre, el actor puede elegir ver las vistas en miniatura de todas las camaras de manera simultanea. Por ende, un escenario secundario podria set: "Ver las vistas en miniatura de todas las camaras".,es posible que ei actor encuenlre alguna condici6n de error en este punto' Cuando un sistema basado en computadora esta en funcionamiento puede ocurrir cualquier cantidad de condiciones de error. En este contexte se consideran s6lo las condiciones de error que pueden ocurrir como resultado directo de las acciones descritas en los pasos De nuevo, la respuesta a la pregunta es: "si". Puede ser que nunca se haya configurado un plano de planta con iconos de las camaras. Por 10 tanto, al elegir "seleccionar una camara" se produce una cond ici6n de error: "no existe un plano de planta configurado para esta casa"y Esta condici6n de error se convierte en un escenario secunda rio.,es posible que ei actor encuentre algun OIrO comportamiento en este punto' De nuevo, la respuesta a la pregunta es: "si". Cuando se realizan los pasos 6 y 7 el sistema puede encontrar una condici6n de alarma. Esto pod ria resultar en que el sistema desplegara una notificaci6n especial de alarma (tipo, ubicaci6n, acci6n del sistema) y Ie proporcione al actor una serie de opciones relacionadas con la naturaleza de la alarma. Como este escenario secundario puede ocurrir para casi todas las interacciones, no se convertira en una parte del caso de uso para el ACV-OVC. En 12 En este caso, otro actor, el administrador del sistema, tendria que configurar el plano de planta, instalar e inicializar (es decir. asignar una [D a cada equipo) para todas las camaras, asl como realizar pruebas para estar seguro de que cada una de elias es accesible por medio del sistema y a tra ves del plano de planta.

18 CAPiTULO 8 MODELADO DEL ANAuSIS 207 vez de eso, se desarrollara un caso de uso par separado - "condici6n de alarma encontrada"-, el cual estara referenciado a otros casos de uso, segun se requiera. En relaci6n con las plantillas formales para los casas de usa que se muestran en el recuadro, los escenarios secundarios se representan como excepciones a la secuencia basica descrita respecto al ACV-DVC. HOGARSEGURO Plantilla de caso de usa para la vigilanda Actor primario: Meta en conlexlo: Coso de uso: Acceso a la camara de vigilancio-despliegue de vistas de comora (ACY DVq. Propietorio Ver 10 solido de los comoros colocadas a 10 largo de 10 coso desde cualquier ubicaci6n remota a traves de Internet. Condiciones previas: EI sistema se debe configuror por completo; se deben obtener 10 y controsenas apropiadas para los usuarios. Disparodor: EI propietario decide echarle un vitam a su caso mientros se encuentra fuera de ella. 1. EI propielorio entra 01 sitio web de Productos HogorSeguro. 2. a propietario introduce su 10 de usoorio. 3. EI propietorio introduce dos controsenas (cada una de ai monos acha coracte,..,.... EI sistema despliega todos 10. botones de las Iunciones me. impartante. 5. EI propietario selecciona "vigilancia" de los botones 'de las, funciones mos importontes. 6. EI propietario seiecciona "escoger uno coma ron. 7. EI sistema despliega el plano de 10 cosa. 8. Et propietario selecciono el icono de una camara del plano de planlq. 9. EI propietario selecciona el boron "vista". 10. EI sislemo despliega una ventana de visualizaci6n que est6 identificodo can de la comaro. 11. EI sistema despliego 10 salida de video dentro de Ia ventano de visuolizoci6n a un cuadro pot segundo. Excepciones: 1. La 100 los contrasenos son incorrectos 0 no se reconocen; vease el coso de uso: "volidar 10 y contrasei'ias". 2. lo fvnci6n de vigiloncia no esro configuroda para este sistema, asi que el sistema despliega at mensaje de error opropiodo; veose el coso de usa: "configurar 10 fvnci6n de vigilancia". 3. EI propietario selecciono "Ver vistas en miniatura para todas las comoros"; vease el coso de uso: "Ver vistas en miniatura para todas las comaras". 4. No esta disponible un plano de planta 0 este no se ha configurodo, asi que el sistema despliego ei mensoje de error apropiaclo; vease ei coso de U50 "configurar plano de 10 coso". 5. Se encuentra una condici6n de olorma; vease ei coso de uso: n condici6n de aiormo encontrado n. Prioridod: Oisponible en; Frecuencia de uso: Prioridad moderacla, que se impiemenlqr6 despue. de 10. Funciones b6sicos. EI tercer incremento. Poco frecuente. Conal hacio el odor: A troves de un browser bosodo en PC y conexi6n de Internet al sitio web de HogarSeguro. Adores secundarios: Administrodor del sistema, comoros. Canales hacia los adores secundarios: 1. Admi[listrador del sistema: ~istemo basodo en PC. 2. Camaras: conectividad inalombrica

19 208 PARTE DOS practica DE LA INGENIERlA DEL SOFrVVARE Aspectos pencli.nles: 1. acu61 es ei meconismo que protege contro el usc no autorizado de esfa capacidad pa' parte de los empieados de Ia campania? 2. ela seguridod $$ sofidente? EI ingreso no outorizodo en esta carocteristico representario una invasi6n impartanle de Ia privocidod. 3. ilo respuesta del sistema via Internet ser6 ac:epkihie dado el ancho de banda requerido para las vistas de cornaro? 4. ise desorrollor6 uno capacidod para proporcionor video a una tosa mayor de cuodros pot' segundo cuando esten disponibles conexiones con ~ oncho de banda?. MI,}!.!!,) &1 t (uando se han terminodo de escribir los (Osos de usa? POf{! uno exposici6n volioso de asle t6piro, veose ootips.org/ use~cases'1loae. hlmloo!ip org/ use-cases'1ione. hlml. En muchos casas no es necesario crear una representacion gratica de un escenario de lisa. Sin embargo, la representacion diagramatica puede facilitar 1a comprensian, en particular cuando el escenario es complejo. Como se mendono en el capitulo 7, el UML proporciona una capacidad para hacer diagram as de casos de uso preliminar para ej producto HogarSeguro. Cada caso de uso se representa mediante un 6valo. En esta secci6n 5610 se ha examinado en detalle el caso de uso para ej ACV DVe Desarrollo de un diagrama de actividad EI diagrama de actividad en UML (que se trat6 en forma breve en los capitulos 6 y 7) complementa el caso de uso aj proporcionar una representaci6n gni.fica del flujo de interaedon dentro de un escenario especifico. De manera similar al diagrama de flujo, un diagrama de actividad utiliza rectimgulos redondeados para indicar una funcian especifica del sistema, flechas para representar el flujo a traves del sistema, rombos de decision para mostrar una ramificacian por decision (cada flecha que sale del rombo se eliqueta), y lineas horizontales s6lidas para indicar que ocurren actividades paralelas., Diagrama prellminar de casode uso para el sistema HogarSeguro. HogorSeguro Camoras ~ \ Propielario de 10 coso

20 CAPITULO 8 MODELAOO DEL ANALISIS 209 Diagrama de actlvidad para la funcionde acceso a la ccanara de viguanciadespliegue de vistas de camara. Contrasefias/ID v61idas Tambien se pueden _":::::='-7':;';';";;'~~ seleccionar otras funciones Introducir contrasefia }- ---, e ID del usuario Contrasefias/ID no validas Opcion para No reston intentos de entrada Vistas en miniatura Seleccionar una camara especifico Solir de esta funci6n Ver olro camara Un diagrama de ocnvidad en UMl representa las acciones y decisiones que ocurren mientros se realiza alguna fund6n. En la figura 8.7 se muestra un diagrama de actividad para la funci6n de ACV DVC. Se debe resaltar que el diagrama de actividad agrega detalles adicionales que no se men cion an de manera directa (pero si implicita) en el caso de uso. Por ejempio, un usuario puede intentar ingresar la IDusuario y la contrasefta s610 un numero limitado de veces. Esto se representa mediante un rombo de decisi6n debajo de opcion para reingreso Diagramas de ccmil El diagrama de earni de UML es una variaci6n util del diagrama de actividad, ya que permite al modelador la representaci6n del flujo de actividades descritas por el caso de usc y, al mismo tiempo, indicar que aclor (si hay multiples actores involucrados en una funci6n especifica) 0 clase de analisis tiene la responsabilidad de la acci6n descrita mediante un rectangulo de actividad. Las responsabilidades se representan

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION UNIDAD V ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION Contenido: 5.1 Introducción 5.2 Principios del Análisis 5.3 Construcción de Prototipos del Software 5.4 Métodos de Análisis de Requisitos 5.5 La Especificación

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Elementos del modelo de análisis. Modelado del análisis

Elementos del modelo de análisis. Modelado del análisis Mecanismos del anál. Ingeniería del Software 1 Elementos del modelo de análisis Objetivos Describir lo que requiere el cliente Establecer base para la creación de un diseño SW Definir conjunto de requisitos

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

TEMA 7: DIAGRAMAS EN UML

TEMA 7: DIAGRAMAS EN UML TEMA 7: DIAGRAMAS EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Modelo de Casos de Uso (MCU) Todos los casos de uso constituyen el MCU que describe

Más detalles

6.4 Actores y casos de uso para el sistema de reservaciones de vuelos

6.4 Actores y casos de uso para el sistema de reservaciones de vuelos jen la vision logica del sistema, debiendo haber consistencia entre la imagen conceptual del usuario y el comportamiento real del sistema. Si las interfaces son protocolos de hardware, se pueden referir

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

PROGRAMACION ORIENTADA A OBJETOS CON PHP

PROGRAMACION ORIENTADA A OBJETOS CON PHP PROGRAMACION ORIENTADA A OBJETOS CON PHP COMO SE DEFINE EN PHP La programación orientada a objetos es una metodología de programación avanzada y bastante extendida, en la que los sistemas se modelan creando

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

ICONIX. Notas del método con ampliaciones y mejoras

ICONIX. Notas del método con ampliaciones y mejoras ICONIX Notas del método con ampliaciones y mejoras Juan Manuel Fernández Peña y María de los Ángeles Sumano López Colaboración de Josué Andrade Mirós Octubre de 2004 Método ICONIX Referencia El método

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

ESTÁNDAR DIAGRAMA DE SECUENCIA

ESTÁNDAR DIAGRAMA DE SECUENCIA ESTÁNDAR DIAGRAMA DE SECUENCIA Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO) Universidad de Cantabria Facultad de Ciencias Patricia López y Francisco Ruiz Objetivos del Tema Objetivos:

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles

Introducción. Entre los modelos de análisis y diseño esta el estructurado.

Introducción. Entre los modelos de análisis y diseño esta el estructurado. Análisis y Diseño Orientado a Procesos Sección: 5T2_Co. Grupo: N 2 Docente: Ing. Magda Luna. Asignatura: Ingeniería De Software II Integrantes: Yessenia Del Carmen Meléndez Morales 2001-10007. Tania Margarita

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su 88 CAPÍTULO 5 5. IMPLEMENTACIÓN 5.1 Modelo Utilizado en Programación. Hemos utilizado la técnica de programación orientado a objetos por su eficiencia y eficacia en el modelo mvc, ya que permite la reutilización

Más detalles

ARQUITECTURA DE SOFTWARE

ARQUITECTURA DE SOFTWARE ARQUITECTURA DE SOFTWARE Introducción n a la Arquitectura de Software (sistemas) Requisitos de calidad Documento de Diseño RTFS-Método del control de diseño Introducción n al Diseño o de la interfaz Humano/Computador

Más detalles

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010 INTRODUCCION Un concepto fundamental que debemos tener en cuenta a la hora de modelar la realidad por medio de objetos es que los mismos no son entidades aisladas. Los objetos interactúan entre ellos constantemente

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

EL PROCESO DE DISEÑO DEL SOFTWARE

EL PROCESO DE DISEÑO DEL SOFTWARE UNIDAD VI EL PROCESO DE DISEÑO DEL SOFWARE Contenido: 6.1 El diseño en la Ingeniería de Software 6.2 El proceso de Diseño 6.3 Fundamentos de Diseño 6.4 Diseño de Datos 6.5 Diseño Arquitectónico 6.6 Diseño

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

7.1 Arquitectura de clases

7.1 Arquitectura de clases 7.1 Arquitectura de clases El modelo de analisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diserio del sistema. Como se discutio en el capitulo 3, dependiendo

Más detalles

Universidad del Azuay

Universidad del Azuay Universidad del Azuay Facultad de Ciencias de la Administración Escuela de Ingeniería en Sistemas (Sistema de Gestión y Control de Flujo de Trámites, aplicado en la Intendencia Regional de Bancos y Seguros

Más detalles

6.5 Modelo del dominio del problema

6.5 Modelo del dominio del problema 6.5 Modelo del dominio del problema El modelo del dominio del problema define un modelo de clases comun para todos los involucrados en el modelo de requisites, tanto analistas como clientes. Este modelo

Más detalles

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Introducción al UML Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Contenido Qué es UML?. Diagramas Utilizados en UML. Ejemplos. Qué es UML UML es un Lenguaje de Modelado

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

Conceptos y Principios de Análisis

Conceptos y Principios de Análisis Conceptos y Principios de Análisis Roger S. Pressman 2002 Ingeniería de Software. Un enfoque práctico, Capítulo 11 Principios Operativos (PO) del Análisis Debe representarse y entenderse el dominio de

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Uso del software Notebook de SMART

Uso del software Notebook de SMART Uso del software Notebook de SMART El software de Notebook de SMART ha sido diseñado para su uso con la pantalla interactiva SMART Board. Puede utilizarlo para crear material de presentación interactivo

Más detalles

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado DIAGRAMAS DE CLASES RELACIONES ENTRE CLASES Una vez que tengamos todas nuestras clases, será necesario que estas se asocien, con el fin de mostrar la

Más detalles

Weitzenfeld: Capítulo 6 1

Weitzenfeld: Capítulo 6 1 Weitzenfeld: Capítulo 6 Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema para los eventos enviados o recibidos por los actores. En esta etapa

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

GESTIÓN DEL CAMBIO. Fernanda M. Soto 1, Henry F. Montalván 2 GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE INTRODUCCIÓN

GESTIÓN DEL CAMBIO. Fernanda M. Soto 1, Henry F. Montalván 2 GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE INTRODUCCIÓN GESTIÓN DEL CAMBIO Fernanda M. Soto 1, Henry F. Montalván 2 El arte de coordinar el desarrollo de software para minimizar la confusión se llama gestión de la configuración (GC-GCS). La Gestión de la Configuración

Más detalles

Índice. Acerca de PenReader... 2. Cómo empezar... 2. Ajustes de PenReader... 4. Estándar... 4. Perfiles... 5. Reconocimiento... 6. Registrar...

Índice. Acerca de PenReader... 2. Cómo empezar... 2. Ajustes de PenReader... 4. Estándar... 4. Perfiles... 5. Reconocimiento... 6. Registrar... Índice Acerca de PenReader... 2 Cómo empezar... 2 Ajustes de PenReader... 4 Estándar... 4 Perfiles... 5 Reconocimiento... 6 Registrar... 7 Acerca del programa... 7 Ajustes avanzados de reconocimiento...

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen)

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen) Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla Avda Reina Mercedes s/n. 402 Sevilla Tlf/Fax 954 557 39 E-mail lsi@lsi.us.es Web www.lsi.us.es E.T.S.

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

UNIDAD V DISEÑO DEL SOFTWARE

UNIDAD V DISEÑO DEL SOFTWARE UNIDAD V DISEÑO DEL SOFTWARE El diseño es lo que todo ingeniero quiere hacer Requisitos del cliente Especificaciones técnicas PRODUCTO Necesidades de negocio El diseño crea una representación del modelo

Más detalles

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

CA ERwin Data Profiler

CA ERwin Data Profiler RESUMEN DEL PRODUCTO: CA ERWIN DATA PROFILER CA ERwin Data Profiler CA ERWIN DATA PROFILER AYUDA A LAS ORGANIZACIONES A REDUCIR LOS COSTOS Y RIESGOS ASOCIADOS CON LA INTEGRACIÓN DE DATOS, AL BRINDAR CAPACIDADES

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1.

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. 3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. Compartimento del nombre...21 3.2.2.2. Compartimento de la lista

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

Más detalles

Tópicos a ser desarrollados

Tópicos a ser desarrollados Diseño de Software El Diseño no puede ser definido solo puede explicarse en base a los distintos puntos de vista y tareas que realizan los diseñadores del software Basado en la traducción de Sommerville

Más detalles

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.

Más detalles

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño.

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño. Definición de diseño Proceso para la definición detallada de un sistema con el fin de su realización física. Ingeniería del Software 1 Ingeniería del Software 2 Modelo de diseño vs. Paradigma de IS 3 actividades

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

Más detalles

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: CICLO DE VIDA DE DESARROLLO DE SI FASES GENÉRICAS DEL CICLO DE VIDA DE DESARROLLO DE SI VISIÓN TRADICIONAL DEL CICLO DE VIDA DE DESARROLLO DE SI DE DESARROLLO DE SI: ANÁLISIS Material diseñado

Más detalles

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de:

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: Conceptos de modelado de datos (diagramas entidad-relación) Modelado de negocios (flujos de trabajo) Modelado de objetos Modelado

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

Guía de aprendizaje del software de Notebook SMART

Guía de aprendizaje del software de Notebook SMART Guía de aprendizaje del software de Notebook SMART Software de Notebook de SMART Board, versión 10 Para sistemas operativos Windows SMART Technologies ULC Oficina central 3636 Research Road NW Calgary,

Más detalles

INGENIERIA EN MICROCONTROLADORES. Guía de Usuario para Cursos On-Line. www.i-micro.com. Manual

INGENIERIA EN MICROCONTROLADORES. Guía de Usuario para Cursos On-Line. www.i-micro.com. Manual INGENIERIA EN MICROCONTROLADORES Guía de Usuario para Cursos On-Line Manual G U I A D E U S U A R I O P A R A C U R S O S O N L I N E Ingeniería en Microcontroladores Teléfono 044 55 11 29 55 05 E-mail:

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 8 Contexto y Requisitos del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz y Patricia López Objetivos del Tema Conocer en detalle la técnica de

Más detalles

DEFINICION, ANALISIS Y DISEÑO DE UN SISTEMA DE INTRANET PARA UNA EMPRESA PRODUCTORA DE BIENES Y SERVICIOS PARA EL SECTOR ELECTRICO COLOMBIANO

DEFINICION, ANALISIS Y DISEÑO DE UN SISTEMA DE INTRANET PARA UNA EMPRESA PRODUCTORA DE BIENES Y SERVICIOS PARA EL SECTOR ELECTRICO COLOMBIANO UNIVERSIDAD NACIONAL DE COLOMBIA SEDE MEDELLÍN FACULTAD DE MINAS ESCUELA DE SISTEMAS E INFORMÁTICA TRABAJO DE GRADO DEFINICION, ANALISIS Y DISEÑO DE UN SISTEMA DE INTRANET PARA UNA EMPRESA PRODUCTORA DE

Más detalles

Cisco Commerce Workspace Guía de pedidos para el usuario

Cisco Commerce Workspace Guía de pedidos para el usuario Cisco Commerce Workspace Guía de pedidos para el usuario Contenido Acerca de Cisco Commerce Workspace...2 Acerca de esta Guía del usuario...2 Navegación general...2 Sección 1: Página de inicio...3 Sección

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Operación Microsoft Windows XP

Operación Microsoft Windows XP Entornos de red Concepto de red En el nivel más elemental, una red consiste en dos equipos conectados entre sí mediante un cable de forma tal que puedan compartir datos. Todas las redes, no importa lo

Más detalles

Métricas. Valentin Laime. Calidad de Software

Métricas. Valentin Laime. Calidad de Software Calidad de Software: Métricas Valentin Laime Calidad de Software 10/29/2014 1 Métricas Que miden Beneficios Medidas Productividad Calidad Futuras Estimaciones Directas Indirectas Defecto/fallo Vs. Error

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

Más detalles

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Análisis de Sistemas M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Metodologías de Desarrollo de Software Las metodologías existentes se dividen en dos grandes grupos: Metodologías estructuradas Metodologías

Más detalles