Activitat de disseny. INEP : Empenteta final (Tardor del curs 2018/2019)

Empententa final Activitat de disseny. INEP. Curs 20181 Josep M Merenciano mer[email protected] Departament de Ci` encies de la Computaci´ o EPSEVG-UPC 15 de gener de 2019 2 Validaci´ o final d’INEP 20181 SUMARI Sumari Enunciat 3 1T EORIA Dels Diagrames de comunicaci´o al Model de components 7 1.1 Una observaci´ o preliminar ...................... 7 1.2 Lectura dels diagrames de col·laboraci´ o (DC) ........... 7 1.2.1 Q¨ uesti´ o de noms ....................... 7 1.2.2 Objectes vs identificadors .................. 9 1.2.3 Components .......................... 9 1.2.4 Multiobjectes ......................... 9 1.2.5 Visibilitats ........................... 10 1.2.6 Multiobjectes i comunicaci´ o................. 11 1.3 Construcci´ o del Model de components ............... 12 1.3.1 An` alisi dels DC ........................ 12 1.3.2 Dibuix de MComp ...................... 13 1.4 Contractes a partir del disseny ................... 14 1.5 MC per enginyeria inversa ...................... 16 2 Soluci´o 19 2.1 Guia de lectura ............................ 19 2.2 Model de components ........................ 19 2.2.1 Detall del proc´ es: nouControl() ............. 19 2.2.2 Detall del proc´ es: novaPregunta() ........... 23 2.2.3 Detall del proc´ es: fiControl() .............. 34 2.2.4 MComp ............................ 43 2.3 Contractes des del disseny ...................... 43 2.3.1 Contractes segons la sem` antica dels DC .......... 43 2.3.2 Correctesa i robustesa .................... 49 2.4 MC per enginyeria inversa ...................... 54 2.4.1 Proc´ es d’enginyeria inversa per a obtenir MC ...... 54 2.4.2 El model conceptual (MC) resultant ............ 64 2.5 Conclusions sobre l’enginyeria inversa ............... 64 Josep M. Merenciano 3 EPSEVG-UPC Activitat INEP. Tardor curs 2018/18 1 Activitat de disseny. INEP 15 de novembre de 2018. Empenteta Final va consolidant-se com a projecte. Per això, en Mestre Tites, que n’és el promotor, fa uns dies va contractar uns analistes per tal que fessin un disseny robust del sistema informàtic necessari per gestionar els exàmens i controls. Però per error va contractar uns impresentables que van desaparèixer d’un dia per l’altre. Revisant el que han deixat hem trobat documentació parcial i dispersa. En Mestre Tites ens demana que documentem el sistema que aquests analistes van deixar. Revisant la documentació de l’especificació hem trobat aquest diagrama, corresponent al cas d’ús introoduirControl. La documentació del disseny conté els següents diagrames: Activitat INEP. Tardor curs 2018/18 2 : List<Avaluació> : List<Avaluació> est : Estudiant 3.1.1.1.1: add(av) 3.1.1.1.1.1: add(av) : K : Profe 3: fiControl() 3.1: fiControl() 3.1.1: fiControl() : Control 3.1.1.1: fiControl() Activitat INEP. Tardor curs 2018/18 3 Es demana: 1. MComp. Construïu el model de components del sistema • Indiqueu totes les visibilitats: d’atribut, local i de paràmetre. • Indiqueu els mètodes i atributs de cada component • Per cada paràmetre dels ES digueu si és un literal, un identificador o una entitat 2. Especificació. Doneu l’especificació dels diferents esdeveniments de sistema • Tant pels arguments com pels diferents elements que apareguin en el contracte, indiqueu quins elements són realitzacions d’un component, i quins són simples identificadors. • Desconeixem el problema, i tenim part de la solució. El que es tracta és d’intentar reconstruir el problema (la seva especificació) a partir del fragment de solució donat 3. Enginyeria inversa. Tenint en compte el model de components obtingut, quin creieu que hauria de ser el model conceptual? Dibuixeu MC. • La separació en preguntes és per facilitar-vos la feina, i no correspon a cap criteri numèric. L’exercici es valora en tota la seva totalitat i no pas donant punts acumulatius als diferents apartats. • Els punt interns de cada pregunta recorden coses que no us heu d’oblidar, però no els heu de llegir com la llista exhaustiva d’allò que es demana. Expliqueu i justifiqueu tot el que feu Data màxima de lliurament: 20 de desembre de 2018 Format de lliurament: En paper Tipus de lliurament: Individual Lloc de lliurament: Bústia del despatx 120 1T EORIA Dels Diagrames de comunicaci´ o al Model de components 1.1. Una observaci´ o preliminar En el que segueix es presenten de forma esquem` atica els aspectes te` orics necessaris per llegir el DC, i per construir a partir d’ells el MComp. El redactat i l’estructuraci´ o permet usar-ho com material de refer` encia. El preu a pagar ´ es que el resultat pot resultar m´ es feixuc de llegir del que potser caldria. La lectura simult` ania, en paral·lel, d’aquests apunts te` orics i de la soluci´ o pas a pas de m´ es avall ha donar llum al redactat. 1.2. Lectura dels diagrames de col·laboraci´ o (DC) 1.2.1 Q¨uesti´o de noms ` Ambit de visibilitat •En principi cada DC ´ es un ` ambit de visibilitat independent –Res impedeix usar el mateix nom en DC diferents per a referenciar diferents elements •Malgrat tot, sovint s’usa la coincid` encia de noms en DC diferents per expressar que hi ha una comunicaci´ o entre els ES –´ Es a dir, que l’element ´ es el mateix en ambd´ os DC •Davant d’un nom compartit entre dos DC cal: –Observar si hi ha algun motiu clar per considerar que s´ on elements diferents ∗Per exemple, en un DC un nom s’usa per un identificadr, i en un altre DC s’usa per referenciar un objecte Josep M. Merenciano 7 EPSEVG-UPC T EORIA Dels Diagrames de comunicaci´o al Model de components 8 –Determinar si per la sem` antica del problema t´ e sentit que siguin el mateix element ∗Exemple. En un ES cerquem un objecte, i en el seg¨ uent ES iterat, l’anem modificant An` omies •Un objecte sense nom ´ es una an` omia •L’aparici´ o d’una an` omia en un DC ot significar que: –Estem davantd’un singleton –En el DC hi ha prou context per saber de quin objecte estem parlant ∗En aquest cas el nom ´ es redundant, i per simplicitat el dissenyador ha preferit ometre’l ∗Compte per` o: l’objecte t´ e nom; simplement no l’explicitem •Generalment el component que rep els ES ´ es un singleton •La resoluci´ o de les an` omies (aix` o´ es, decidir quin ´ es el nom no explicitat) es fa tenint en compte: –La sem` antica del problema ∗Hem creat un objecte i ara li volem delegar determinada tasca, significa que l’objecte creat i l’objecte que rep el missatge de delegaci´ o han de ser el mateix –Necessitats de visibilitat ∗Suposem que per poder enviar un determinat missatge necessitem un enllac¸ dirigit amb destinaci´ o:B ∗Suposem que en tot el nostre disseny del CU estem usant un ´ unic objecte :B, que en un altre moment hem anomenat b ∗Llavors l’objecte :B que ´ es destinaci´ o de l’enllac¸ dirigit considerat nom´ es pot ser b Validaci´ o final d’INEP 20181 1.2 Lectura dels diagrames de col·laboraci´o (DC) 9 1.2.2 Objectes vs identificadors Objectes •Tot aquell qui en un diagrama de col·laboraci´ o(DC) rep un missatge ´ es un objecte •El find() retorna objectes •L’argument d’un add() ´ es un objecte Identificadors •Els arguments del find() s´ on identificadors 1.2.3 Components Detecci´ o de components •Tot objecte que apareix en algun diagrama de col·laboraci´ o(DC) ´ es realitzaci´ o d’un component. –Els multiobjectes s´ on una ficci´ o emprada pels DC. No s´ on la realitzaci´ o de cap component. •Tot identificador ho ´ es d’algun component –El nom del component ´ es el que apareix en el mateix DC 1.2.4 Multiobjectes Els multiobjectes en els models •Els multiobjectes s’expressen en els DC en forma de pila d’objectes, o com un objecte de tipus <List>B •Els multiobjectes no s’expressen en forma de component a MComp. •La pres` encia d’un multiobjecte en un DC indica una visibilitat multiavaluada aMComp Validaci´ o final d’INEP 20181 T EORIA Dels Diagrames de comunicaci´o al Model de components 16 Casos t´ ıpics de POST add() •L’add() afegeix un objecte a un multiobjecte. Tot multiobjecte ´ es un conjunt •Cal assegurar, en forma de PRE si el DC no ho assegura pr` eviament, que l’objecte que es vol afegir no s’ha afegit anteriorment •L’an` alisi es pot reduir a dos casos: –Objecte nou ∗Cada nou objecte (aquell obtingut amb un new) t´ e un identificador diferent ∗Per tant no cal afegir cap PRE –Objecte pre-existent ∗Hem obtingut, amb un find() o similar, un objecte, que ara volem afegir en un multiobjecte ∗Cal una PRE per assegurar que l’objecte a afegir no s’ha afegit pr` eviament 1.5. MC per enginyeria inversa Procediment 1. Supressi´ o dels emmagatzemadors •Cal suprimir tot component tal ue la seva ´ unica responsabilitat sigui l’emmagatzematge –L’emmagatzematge ´ es propi del disseny, per` o no t´ e cap mena de sentit en l’especificaci´ o –Sovint els components dedicats a l’emmagatzematge s’anomenen magatzem,repositoris,compendi, etc •Per suprimir-los cal curtircuitar les visibilitats d’atribut incidents amb les sortints (les depend` encies no ens interessen) –Suposem que M´ es un magatzem, i que tenim les visibilitats A→M∗iM→B Validaci´ o final d’INEP 20181 1.5 MC per enginyeria inversa 17 –Com a resultat de la suressi´ o tindrem: A→B 2. Suprimim les depend` encies •Ens quedem nom´ es amb les visibilitats d’atribut 3. Convertim les visibilitats en associacions •Aix` o implica trobar-ne les multiplicitats i dotar-les de sem` antica 4. Suprimim les activacions locals al CU •Determinem quines s´ on les associacions que provenen d’una visibilitat d’activaci´ o •Analitzem si l’activaci´ o t´ e sentit que es mantingui fora del CU o no. En cas negatiu, suprimim l’associaci´ o 5. Analitzem les obligatorietats i optativitats Detecci´ o de multiplicitats i optativitats Fonts d’informaci´ o •Cada problema ´ es diferent. En general per` o cal cercar la informaci´ o en: 1. DC 2. Problema 3. Prefer` encies generals An` alisi dels DC •Cal analitzar la sem` antica dels DC –Qu` e fan –Quin ´ es el seu prop` osit –Quines precondicions pressuposen ∗Exemple. Si fem un find() i no comprovem si ens ha donat un resultat ´ es perqu` e assumim que en tot moment hi ha un objecte amb el valor d’identificaci´ o donat Validaci´ o final d’INEP 20181 T EORIA Dels Diagrames de comunicaci´o al Model de components 18 An` alisi del problema •Cal rec´ orrer al nostre coneixeent del problema i analitzar si hi ha alguna PRE que ens afecti –Exemple. Una pregunta pot estar en molts controls •Cal tornar a analitzar els DC assumint les PRE trobades Prefer` encies generals •Hi ha casos on ni la lectura dels DC ni el nostre coneixement del problema ens donen la informaci´ o necess` aria •Dit amb d’altres paraules, hi ha casos on, per exemple, res ens permet decidir entre la multiavaluaci´ o o la monoavaluaci´ o d’una associaci´ o •En aquests casos recorrem a prefer` encies generals –Per exemple, quan dues opcions siguin possibles, ens decantem per la menys marcada ∗Aquest criteri obliga a definir qui ´ es m´ es marcat que un altre Validaci´ o final d’INEP 20181 2Soluci´ o 2.1. Guia de lectura La construcci´ o de MComp, l’obtenci´ o dels contractes per enginyeria inversa o la construcci´ o del MC tamb´ e per enginyeria inversa, s´ on de lectura independent. En el detall del proc´ es de construcci´ o del Model de components es fan explicacions que davant els aspectes te` orics expressats m´ es amunt potser no caldrien. S’ha preferit per` olareiteraci´ oper facilitar l’aprenentatge. Es recomana que a mesura que es vagi llegint la soluci´ o, es vagin repassant els aspectes te` orics involucrats. 2.2. Model de components 2.2.1 Detall del proc´es: nouControl() Components i primers objectes observant nouControl(c,p) •Els objectes expl´ ıcits del DC ens porten a considerar els seg¨ uents components: –K –Profe –Control –Avaluaci´ o •El multobjecte List<Control>diu que hem de tenir una visibilitat multiavaluada sobre un component Control •El multobjecte List<Avaliuaci´ o>diu que hem de tenir una visibilitat multiavaluada sobre un component Avaluaci´ o. D’aqu´ ı que tenim Avaluaci´ o Josep M. Merenciano 19 EPSEVG-UPC Soluci´o 20 •c´ es l’argument d’un find(). Per tant ´ es un identificador. El multiobjecte on es fa el find() ´ es de Controls; per tant l’identificador cha de permetre referenciar un :Control •pest` a etiquetat com un objecte realitzaci´ o del component Profe •control ´ es un objecte, ja que ´ es el valor de retorn d’un find(). El component del qual n’´ es realitzaci´ o´ es e lControl, ja que el find() el realitzem sobre un multiobjecte de :Controls Primers resultats S´ ımbols del DC de nouControl() cidentificador d’un objecte :Control pobjecte, realitzaci´ o de Profe control objecte, realitzaci´ o de Control Validaci´ o final d’INEP 20181 2.2 Model de components 21 Visibilitats •Kpar →Profe –Pel missatge 1i el fet que p´ es un objecte •Profe ? →Control∗ –Pel multiobjecte –De moment no podem dir quin tipus de visibilitat ´ es •Profeloc →Control –Missatge 1.1.1. L’emissor del missatge find() t´ e una visibilitat sobre l’objecte :Control retornat –L’objecte retornat s’usa per a enviar-li el missatge 1.1.2. Aix´ ı, la visibilitat Profe→Control no ´ es de par` ametre; no tenim de moment cap motiu per considerar que hi ha emmagatzematge; i per tant concloem que ´ es local ∗El raonament parteix de la base que e l:Control a qui penvia un missatge ´ es el mateix control:Control que ha obtigut amb el find(). M´ es endavant discutim aquesta afirmaci´ o •Control ? →Avaluaci´ o∗ –Pel missatge de creaci´ o1.1.2.1 –De moment no podem dir quin tipus de visibilitat ´ es Validaci´ o final d’INEP 20181 Soluci´o 22 Comprovaci´ o •Missatge 1 –L’argument objecte indueix la visibilitat Kpar →Profe –L’argument identificador no indueix cap visibilitat •Missatge 1.1 –L’argument cel rep en el seu context d’emissi´ o (el missatge 1) –L’enllac¸ dirigit :K→pes correspon a l’enllac¸ de par` ametre que ´ es realitzaci´ o de la visibilitat K→Profe •Missatge 1.1.1 –L’argument cel rep en el seu context d’emissi´ o (el missatge 1.1) –Com a resultat del find() hi ha un enllac¸ dirigit p→control •Missatge 1.1.2 –El canal de comunicaci´ o´ es un enllac¸ dirigit p→:Control. Quin objecte, per` o´ es la destinaci´ o de l’enllac¸ dirigit? –L’´ unic :Control sobre el que pen t´ e visibilitat, ´ es l’obtingut amb el find(). Per tant hem d’assumir que el canal de comunicaci´ o del missatge 1.1.2´ es l’enllac¸ dirigit p→control, realitzaci´ o de la visibilitat local Profe→Control ∗El DC l’hem de llegir com si enlloc de :Control tingu´ essim control:Control •Misatge 1.2.1.1 –Un missatge de creaci´ o sempre ´ es possible –El missatge no t´ e arguments, i per tant: ∗No ens hem de preocuar d’obtenir-los ∗No indueixen cap visibilitat –Despr´ es d’una creaci´ o el creador t´ e una visibilitat sobre l’objecte creat ∗Aquesta ´ es la visibilitat Control ? →Avaluaci´ o∗ Validaci´ o final d’INEP 20181 2.2 Model de components 23 Q¨ uestions pendents •Naturalesa de Profe ? →Control∗ •Naturalesa de Control ? →Avaluaci´ o∗ •La visibilitat Profe→Control hem dit que ´ es local perqu` e no v` eiem la necessitat de cap emmagatzematge. Aquesta suposici´ o es referma a la vista dels altres DC? 2.2.2 Detall del proc´es: novaPregunta() Components i primers objectes observant novaPregunta() •Nous components expl´ ıcits al DC: –MagatzemPreguntes •K,Profe,Control iAvaluaci´ os´ on components que ja ten´ ıem •El multobjecte List<Avaluaci´ o>diu que hem de tenir una visibilitat multiavaluada sobre un component Avaluaci´ o, que ja tenim •av ´ es l’argument d’un add(). Per tant ´ es un objecte. El multiobjecte on es fa l’add() ´ es d’Avaluacions; per tant tenim l’objecte av:Avaluaci´ o •De moment no podem dir res dels altres arguments Primera an` alisi del DC novaPregunta() S´ ımbols del DC de novaPregunta() est ??? pr ??? v ??? av objecte, realitzaci´ o d’Avaluaci´ o Validaci´ o final d’INEP 20181 Soluci´o 24 Visibilitats •Katr →MagatzemPreguntes –Pel missatge 2.1. Hi ha una col·laboraci´ o amb un objecte que no rebem per par` ametre, i tampoc creem. Per tant ha de ser conegut pr` eviament –Una pista d’aquest coneixement previ ´ es que en la col·laboraci´ o no es d´ ona nom a l’objecte. No col·laborem amb un magatzem, ans amb el magatzem. Per tant, ´ es conegut, i nom´ es n’hi ha un •Katr →Profe –´ Es el mateix argument que hem donat per Katr →MagatzemPreguntes per` o aplicat al missatge 2.2. •Profeloc →Avaluaci´ o –El missatge 2.2.1retorna un objecte av:Avaluaci´ o. Per` o aquest objecte es comunica a un objecte c:Control. De moment no veiem necessitats d’emmagatzematge, i per tant assumim que l’enllac dirigit :Profe→av ´ es local •Profeatr →Control –En el missatge 2.2.2un objecte realitzaci´ o de Profe col·labora amb un objecte realitzaci´ o de Control. En el DC l’objecte :Profe emissor del missatge 2.2.2no t´ e cap coneixement expl´ ıcit de cap objecte realitzaci´ o de Control. Per tant hem d’assumir que en hi una visibilitat d’atribut Profe→Control •Controlpar →Avaluaci´ o –Pel missatge 1.1.2 •Control ? →Avaluaci´ o∗ –El multiobjecte indica una visibilitat multiavalauda –L’add tamb´ e indica una visibilitat multiavaluada –De moment no tenim prou elements per determinar el tipus de la visibilitat Validaci´ o final d’INEP 20181 2.2 Model de components 25 Q¨ uestions pendents •Visibilitats per analitzar –Control ? →Avaluaci´ o∗ •Visibilitats amb suposicions que cal refermar –Profeloc →Avaluaci´ o •Comprovaci´ o –Cal assegurar que tot missatge es pot enviar (t´ e el canal i els arguments) –Que no ens haguem deixat cap visibilitat Validaci´ o final d’INEP 20181 Soluci´o 32 Visibilitats •Kpar →Profe •Katr →Profe •Katr →MagatzemPreguntes •Kloc →PreguntaNOU •Profepar →PreguntaNOU •Profeatr →Control∗ MOD •Profeatr →Control •Profeloc →Avaluaci´ o •Controlpar →Avaluaci´ o •Controlatr →Avaluaci´ o∗ •Avaluaci´ opar →PreguntaNOU •MagatzemPreguntespar →PreguntaNOU •MagatzemPreguntesatr →pregunta∗ NOU Q¨ uestions pendents acumulades •Suposicions per refermar –Kloc →Pregunta –Profeloc →Avaluaci´ o –MagatzemPreguntes es comporta com un emmagatzematge multiavaluat de preguntes •Comprovaci´ o –Cal assegurar que tot missatge es pot enviar (t´ e el canal i els arguments) –Que no ens haguem deixat cap visibilitat Validaci´ o final d’INEP 20181 2.2 Model de components 33 Comprovaci´ o de les conclusions actuals •Missatges 1.x –Aquesta an` alisi ja ha estat feta durant l’an` alisi del DC de nouControl() –Llavors no hi havia cap llacuna que ara calgui revisar •Missatge 2 –L’´ unic argument del qual sabem la seva naturalesa (pr)´ es un identificador i per tant no indueix cap visibilitat –M´ es endavant caldr` a revisar qu` e passa amb els altres dos arguments •Missatge 2.1 –L’argument l’obtenim del context d’emissi´ o (el missatge 2) –L’emissi´ o del missatge ´ es possible gr` acies a Katr →MagatzemPreguntes –El valor de retorn del missatge indueix una visibilitat Kloc →Pregunta ∗La visibilitat no ´ es de par` ametre, i no tenim motius per pensar en un emmagatzematge •Missatge 2.2 –Dos arguments els obtenim del context d’emissi´ o (el missatge 2). L’altre argument, pregunta, l’obtenim com a resultat del missatge 2.1, i es correspon a una realitzaci´ o de la visibilitat Kloc →Pregunta –L’emissi´ o del missatge ´ es possible gr` acies a Katr →Profe –Queda pendent per analitzar la influ` encia dels arguments est iv •Missatge 2.2.1 –Els arguments els obtenim del context d’emissi´ o (el missatge 2.1) –Emetre un missatge de creaci´ o sempre ´ es possible –La creaci´ o indueix un enllac¸ dirigit que ´ es realitzaci´ o de la visibilitat Profeloc →Avaluaci´ o ∗Diem que ´ es local perqu` e no tenim cap argument en contra Validaci´ o final d’INEP 20181 Soluci´o 34 •Missatge 2.2.2 –L’argument ´ es l’objecte obtingut en la creaci´ o. En concret, a trav´ es de la visibilitat Profeloc →Avaluaci´ o –L’emissi´ o del missatge ´ es possible gr` acies a Profeatr →Control •Missatge 2.2.2.1 –L’argument l’obtenim del context d’emissi´ o (el missatge 2.2.2) –L’emissi´ o del missatge ´ es possible gr` acies a Controlatr →Avaluaci´ o∗ 2.2.3 Detall del proc´es: fiControl() Components i primers objectes observant fiControl() •Nous components expl´ ıcits al DC: –Estudiant •El multobjecte List<Avaluaci´ o>diu que hem de tenir una visibilitat multiavaluada sobre un component Avaluaci´ o •av ´ es l’argument d’un add(). Per tant ´ es un objecte. Els multiobjectes on es fa l’add() s´ on d’Avaluacions; per tant tenim l’objecte av:Avaluaci´ o An` alisi del DC fiControl() S´ ımbols del DC de fiControl() est objecte, realitzaci´ o de Estudiant av ??? Validaci´ o final d’INEP 20181 2.2 Model de components 35 Visibilitats •Katr →Profe –Pel missatge 3.1 –No ´ es cap visibilitat nova •Profeatr →Control –Pel missatge 3.1.1 –No ´ es cap visibilitat nova •Controlatr →Avaluaci´ o∗ –Pel missatge 3.1.1.1 –No ´ es cap visibilitat nova •Avaluaci´ o? →Estudiant –Pel missatge 3.1.1.1.1 –Els missatges que emet un multiobjecte en un DC de fet s´ on missatges que emet cada objecte emmagatzemat en el multiobjecte –Per tant ´ es un objecte :Avaluaci´ oqui emet el missatge add(av) ∗Cal analitzar com ´ es que enviem un add() a un objecte que no ´ es un multiobjecte ∗Cal analitzar qu` e es l’argument av •Estudiantatr →Avaluaci´ o∗ –Pel missatge 3.1.1.1.1.1 –Aquest darrer missatge ´ es un emmagatzematge sobre un multiobjecte. Per aix` o demanem que la visibilitat sigui d’atribut Validaci´ o final d’INEP 20181 Soluci´o 36 Missatges i multiobjectes Qu` e´ es av •List<Avaluaci´ o>emet el missatge add(av). Aix` o vol dir que qui realment emet el missatge ´ es cada objecte :Avaluaci´ ode dins el multiobjecte •L’argument del missatge ´ es av, que ´ es un s´ ımbol que ´ es el primer cop que apareix. Qu` e pot representar? –El nom ens pot fer pensar que ´ es un objecte :Avaluaci´ o.´ Es a dir, interpretem que cada :Avaluaci´ odel multiobjecvte s’envia a s´ ı mateixa com a argument del missatge add() –Si mirem el missatge que emet :Estudiant veiem que ´ es un add(av) sobre un multiobjecte d’Avaluacins. Per tant tenim que av:Avaluaci´ o –Aix` o referma la idea que l’argument del missatge 3.1.1.1.1´ es el propi emissor del missatge •En conseq¨ u` encia tenim les seg¨ uents visibilitats: –Estudiantpar →Avaluaci´ o ∗L’estudiant rep una avaluaci´ o –Estudiantatr →Avaluaci´ o∗ ∗Hi ha emmagatzematge multiavalaut ∗De fet aix` o ja ho hav´ ıem vist Validaci´ o final d’INEP 20181 2.2 Model de components 37 Qu` e´ es el missatge add •add() es un missatge de grup. Aix` o´ es, est` a perfectament definit •Aix` o nom´ es ´ es veritat si qui rep el missatge ´ es un multiobjecte!! Altrament ´ es un missatge d’enllac¸, definit pel desenvolupador •En aquest cas, qui ha dissenyat aquest DC ha posat el nom add() a un missatge d’Estudiant per remarcar que la seva sem` antica ´ es la de delegar l’add() aut` entic sobre un multiobjecte •Per tant, l’add() que cada :Avaluaci´ oenvia a Estudiant ´ es un missatge d’enllac¸. •Com hem vist, av ´ es un objecte :Avaluaci´ o. I en conseq¨ u` encia el missatge add() indueix la visibilitat Estudiantpar →Avaluaci´ o Avaluaci´ o? →Estudiant Necessitat d’una vissibilitat d’atribut •El missatge add() ´ es d’una :Avaluaci´ oa un :Estudiant •L’:Avaluaci´ oemissora del missatge ´ es alhora l’argument av que passem amb el missatge •Per` o quin ´ es l’:Estudiant receptor del missatge? •Per tal de poder enviar el missatge cal una visibilitat Avaluaci´ o? →Estudiant. Com que l’estudiant no el rebem en el missatge fiControl() ni el creem, necess` ariament la visibilitat ha de ser d’atribut: Avaluaci´ oatr →Estudiant Validaci´ o final d’INEP 20181 Soluci´o 38 Possibilitat de la visibilitat d’aribut •Necessitem Avaluaci´ oatr →Estudiant. La tenim? •Tota :Avaluaci´ odel multiobjecte d’Avaluacions considerat, s’ha creat en el missatge 1.2.1 •La visibilitat que necessitem, per ser d’atribut, s’ha de crear en crear l’:Avaluaci´ o •Per` o quin ´ es l’estudiant que ha de mantenir, amb visibilitat d’atribut, cada :Avaluaci´ o? •Un dels arguments del missatge de creaci´ o d’Avaluaci´ o ´ es est, que de moment no sabem qu` e´ es. Si admetem que aquest argument ´ es un :Estudiant llavors el que t´ e l` ogica ´ es considerar que sigui aquest estudiant el que cal mantenir amb un visibilitat d’atribut •En d’altres paraules, tenim un argument, est; i sabem que els arguments han de ser ´ utils. No sabem si l’argument ´ es un identificador, un valor o un objecte, per` o sabem que el m` etode de creaci´ o ha de crear un enllac¸ dirigit d’atribut sobre un :Estudiant. Tot sembla indicar que aquest :Estudiant ´ es l’est que ens passen!! •Per tant: –est:Estudiant ´ es un objecte –Kpar →Estudiant –Profepar →Estudiant –Avaluaci´ opar →Estudiant –Avaluaci´ oatr →Estudiant Una visibilitat oblidada •La visibilitat Avaluaci´ oatr →Estudiant ´ es una visibilitat de recuperaci´ o: es tracta d’un argument rebut, que com que no s’usa ni es comunica, entenem que s’emmagatzema •El mateix passa amb l’argument pregunta. Per tant tenim Avaluaci´ oatr →Pregunta Validaci´ o final d’INEP 20181 2.2 Model de components 39 S´ ımbols detectats S´ ımbols del DC de nouControl() cidentificador d’un objecte :Control pobjecte, realitzaci´ o de Profe control objecte, realitzaci´ o de Control S´ ımbols del DC de novaPregunta() est objecte, realitzaci´ o d’Estudiant MOD pr Identificador d’un objecte Pregunta v ??? av objecte, realitzaci´ o d’Avaluaci´ o S´ ımbols del DC de fiControl() est objecte, realitzaci´ o d’Estudiant av objecte, realitzaci´ o d’Avaluaci´ oMOD Validaci´ o final d’INEP 20181 Soluci´o 40 Conclusions quasi finals Visibilitats •Kpar →Profe •Kpar →EstudiantNOU •Katr →Profe •Katr →MagatzemPreguntes •Kloc →Pregunta •Profepar →Pregunta •Profepar →EstudiantNOU •Profeatr →Control∗ •Profeatr →Control •Profeloc →Avaluaci´ o •Controlpar →Avaluaci´ o •Controlatr →Avaluaci´ o∗ •Avaluaci´ opar →Pregunta •Avaluaci´ oatr →PreguntaNOU •Avaluaci´ opar →EstudiantNOU •Avaluaci´ oatr →EstudiantMOD •MagatzemPreguntespar →Pregunta •MagatzemPreguntesatr →pregunta∗ •Estudiantpar →Avaluaci´ oNOU •Estudiantatr →Avaluaci´ o∗ NOU Validaci´ o final d’INEP 20181 2.2 Model de components 41 Q¨ uestions pendents •Suposicions per refermar –Kloc →Pregunta –Profeloc →Avaluaci´ o –MagatzemPreguntes es comporta com un emmagatzematge multiavaluat de preguntes •Comprovaci´ o Comprovaci´ o de les conclusions actuals •Tots els missatges estaven comprovats. Calia nom´ es veure la influ` encia de est i –Cal assegurar que tot missatge es pot enviar (t´ e el canal i els arguments) –Que no ens haguem deixat cap visibilitat pr i comprovar el missatge add() que rep l’:Estudiant •Hem vist que est ´ es un objecte, i que per tant indueix una visibilitat de par` ametre sobre Estudiant al llarg de tota la cadena on es passa l’argument –Les crides s´ on correctes perqu` e els arguments es reben del context d’emissi´ o; i els canals de comunicaci´ o ja els ten´ ıem comprovats –El missatge de creaci´ o2.2.1ha d’assegurar que els arguments s´ on ´ utils. Com que no els usem ni els comuniquem, ´ es que els estem emmagatzemant ∗D’aqu´ ı la visibilitat Avaluaci´ oatr →Estuidiant ∗Queda per veure com afecta l’argument v –Pel que fa a l’add() que rep l’:Estudiant ∗La visibilitat Avaluaci´ oatr →Estuidiant assegura el canal de comunicaci´ o ∗L’argument av ´ es el propi emissor, i per tant no genera cap problema Validaci´ o final d’INEP 20181 Soluci´o 48 POST. novaPregunta(est, pr, v) 1. Hi ha una nova av:Avaluaci´ oper a la pregunta, l’estudiant i la nota indicada 1.1. ∃nova av:Avaluaci´ o 1.2. puntua(av,est) 1.3. qu` e(av,pregunta) 1.4. av.valor = v 2. Aquesta nova av:Avaluaci´ o´ es pel :Control que estem avaluant •puntua(av,c) 3. El control que estem avaluant ha computat correctament el valor de la nova avaluaci´ o •c.nota = c.nota + v 1. Assumim una associaci´ o i qu` ecom a model de la visibilitat Avaluaci´ oatr →Pregunta, i una associaci´ o puntua com a model de la visibilitat de recuperaci´ o Avaluaci´ oatr →estudiant •Tot argument passat en una creaci´ o que no s’usi ni es comuniqui cal emmagatzemar-lo •est ´ es un objecte i per tant l’emmagatzematge ´ es una visibilitat d’atribut que volem expressar en l’especificaci´ o 2. Per lligar l’:Avaluaci´ oi el :Control usem l’associaci´ o avalua(), que ja ten´ ıem 3. La nota del control s’incrementa, en el DC, amb el valor de l’avaluaci´ o. Per` o aquest valor ´ es v Validaci´ o final d’INEP 20181 2.3 Contractes des del disseny 49 fiControl() Arguments fiControl() ∅ PRE fiControl() 1. Existeix un p:Profe diferenciat 2. pt´ e un c:Control diferenciat •Exigim com a entitats diferenciades aquells objectes que hem d’assumir que hi tenim acc´ es POST fiControl() 1. Cadascuna de les :Avaluacions del control tamb´ e ho s´ on de l’estudiant (∀av :Avaluaci´o)avalua(av,c) =⇒puntua(av,e) •Enviem un missatge a un multiobjecte; com a resposta cadascuna de les :Avaluacions del multiobjecte envia un missatge a l’estudiant corresponent per tal que l’emmagatzemi •Aquesta proliferacio de missatges ´ es el que expressem amb el quantificador universal 2.3.2 Correctesa i robustesa •Tot seguit repetim els contractes, per` o sense els comentaris •Afegim en color blau les assercions necess` aries per a la correctesa de la seq¨ uenciaci´ o •Afegim en color verd les assercions necess` aries per a la robustesa de la seq¨ uenciaci´ o Validaci´ o final d’INEP 20181 Soluci´o 50 Associacions que s’extreuen dels DC •realitza: Profe--Control •avalua: Avaluaci´ o--Control •qu` e: Avaluaci´ o--Pregunta •puntua: Avaluaci´ o--Estudiant nouControl(c,p) Arguments nouControl(c,p) •c: Identificador –´ Es l’argument d’un find() •p: Entitat –El nom coincideix amb un objecte del diagrama de comunicaci´ o PRE nouControl(c,p) 1. El professor ha fet el control al que correspon l’identificador donat • ∃ control :Control tal que: 1.1. realitza(p,control) 1.2. conntrol.id = c 2. 6 ∃c:Control diferenciat Validaci´ o final d’INEP 20181 2.3 Contractes des del disseny 51 POST nouControl(c,p) 1. cest` a diferenciat 2. La nota del control ´ es 0 •control.nota = 0 3. Dins del c:Control,p:Profe est` a diferenciat 4. El control cno t´ e cap avaluaci´ o • 6 ∃av :Avaluaci´otal que avalua(av, c) novaPregunta(est, pr, v) Arguments novaPregunta(est, pr, v) •est: Entitat •pr: Identificador •v: Valor literal PRE. novaPregunta(est, pr, v) 1. Existeix un p:Profe diferenciat 2. pt´ e un c:Control diferenciat 3. pr ´ es un identificador correcte per a Pregunta • ∃ pregunta:Pregunta tq pregunta.id = pr Validaci´ o final d’INEP 20181 Soluci´o 52 POST. novaPregunta(est, pr, v) 1. Hi ha una nova av:Avaluaci´ oper a la pregunta, l’estudiant i la nota indicada 1.1. ∃nova av:Avaluaci´ o 1.2. puntua(av,e) 1.3. qu` e(av,pregunta) 1.4. av.valor = v 2. Aquesta nova av:Avaluaci´ o´ es pel :Control que estem avaluant •avalua(av,c) 3. El control que estem avaluant ha computat correctament el valor de la nova avaluaci´ o •c.nota = c.nota + v 4. p:Profe diferenciat 5. Dins de c:Control,pest` a diferenciat fiControl() Arguments fiControl() ∅ PRE fiControl() 1. Existeix un p:Profe diferenciat 2. pt´ e un c:Control diferenciat 3. ct´ e avaluacions •∃av :Avaluaci´otal que avalua(av,c) Validaci´ o final d’INEP 20181 2.3 Contractes des del disseny 53 POST fiControl() 1. Cadascuna de les :Avaluacions del control tamb´ e ho s´ on de l’estudiant (∀av :Avaluaci´o)avalua(av,c) =⇒puntua(av,e) 2. 6 ∃c:Control diferenciat 3. 6 ∃c:Control tal que ct´ e un :Profe diferenciat •La darrera POST no ´ es estrictament necess` aria per` o evita efectes laterals indesitjats –L’activaci´ o del control es fa durant l’execuci´ o del CU; el que volem ´ es que en acabar el sistema nom´ es s’hagi modificat en all` o rellevant per a ell –L’activaci´ o o diferenciaci´ o del :Profe dins del :Control nom´ es t´ e sentit durant l’execuci´ o del CU; despr´ es ´ es irrellevant Validaci´ o final d’INEP 20181 Soluci´o 54 2.4. MC per enginyeria inversa 2.4.1 Proc´es d’enginyeria inversa per a obtenir MC Esb´ os MC •A partir de MComp hem: –Suprimit el component que rep els ES –Suprimit els Magatzems i similars –De totes les visibilitats nom´ es mantenim les d’atribut ∗Convertim la visibilitat en associaci´ o, i mantenim les multiplicitats conegudes Procediment d’an` alisi de les associacions •Analitzem cada visibilitat d’atribut com apareix en els DC –Intentem extreure’n la multiplicitat en els dos extrems –Intentem extreure’n una sem` antica, que ens permeti etiquetar l’associaci´ o de la qual la visibilitat n’´ es el model Validaci´ o final d’INEP 20181 2.4 MC per enginyeria inversa 55 Profe→Control∗ Sem` antica i primeres conclusions •Cada professor mant´e un conjunt de controls; els seus (el glossari haur` a de donar sentit a aquest possessiu) •En l’enginyeria inversa dels contractes→49 hem anomenat realitza a l’associaci´ o corresponent •Per tant: realitza :P rof e −Control, ?−N Multiplicitats que manquen •No tenim cap informaci´ o adicional que ens permeti extreure la multiplicitat a l’extrem de Profe •Com que el find() el fem des del :Profe res impedeix que dos professors diferents tinguin controls amb el mateix identificador •Per aix` o considerarem que l’associaci´ o´ es multiavaluada a l’extrem de :Profe •La suposici´ o no s’extreu pr` opiament dels diagramens, ni tampoc del coneixement del problema: cal algun sup` osit addicional. Per tant la marcarem en verd •Per tant: realitza :P rof e −Control, M−N Validaci´ o final d’INEP 20181 Soluci´o 56 Obligatorietats i optativitats •Per coneixement del problema, un professor pot haver fer controls, per` o no necess` ariament –Com que el sup` osit de l’optativitat parteix del nostre coneixement del problema, i no s’extreu per tant directament dels diagrames, ho indicarem amb blau •Qu` e significa realitza? –El professor construeix el control. Llavors no t´ e massa sentit pensar en controls an` onims, aix` o´ es, que no sabem qui l’ha realitzat –El professor posa el control als seus alumnes. Llavors t´ e tot el sentit pensar en controls constru¨ ıts, per` o que encara cap profesor ha realitzat –Prenem una de les possibilitats a l’atzar –Com que la conclusi´ o dep` en del glossari, o de sup` osits adicionals, la marcarem amb verd •Per tant: realitza :P rof e −Control, ∗−N,optatiu−optatiu Validaci´ o final d’INEP 20181 2.4 MC per enginyeria inversa 57 Control→Avaluaci´ o∗ Sem` antica i primeres conclusions •Cada control mant´ e un conjunt d’avaluacions •A difer` encia de Profe→Control∗, ara sabem qui crea el multiobjecte, i qui l’alimenta –L’ES nouControl() crea el multiobjecte –L’ES novaPregunta() crea l’avaluaci´ o i l’emmagatzema al multiobjecte •En conseq¨ u` encia de l’an` alisi dels DC tenim que cada :Avaluaci´ ola crea i emmagatzema un ´ unic :Control –L’associaci´ oControl −Avaluaci´o´ es monoavaluada a l’extrem de Control –L’associaci´ oControl −Avaluaci´o´ es obligada a l’extrem de Control •A l’associaci´ o de la qual enllacdirMControlAvaluaci´ o n’´ es el model pr` eviament l’hem anomenada avalua→49 •Per tant: avalua :Control −Avaluaci´o, 1−N Obligatorietats i optatitivitats que manquen •Primer tenim els controls i despr´ es els avaluem. Per tant l’extrem d’Avaluaci´ o´ es optatiu •Per tant: avalua :Control −Avaluaci´o, 1−N, obligat, optatiu Validaci´ o final d’INEP 20181 Soluci´o 64 ∗D’aqu´ ı que el model no t´ e cap o gaireb´ e cap marca expl´ ıcita d’obligatorietat o optativitat 2.4.2 El model conceptual (MC) resultant Model conceptual (MC) 2.5. Conclusions sobre l’enginyeria inversa Enginyeria inversa •La lectura dels DC ens d´ ona molta informaci´ o, per` o no la suficient •Cal accedir a la sem` antica del CU, a la sem` antica del problema, o a criteris externs per a poder obtenir tota la indformaci´ o necess` aria •En conseq¨ u` encia, l’enginyeria inversa ´ es un proc´ es complex, on es produeixen molts errors, i on sovint ens manca informaci´ o •Aix` o significa que fer primer el disseny, i a posteriori intentar extreure’n l’especificaci´ o no ´ es , de cap de les maneres, una opci´ o v` alida Validaci´ o final d’INEP 20181 2.5 Conclusions sobre l’enginyeria inversa 65 MComp no ´ es MC •L’aspecte i els elements de MComp ideMC ´ es forc¸a diferent •L’enginyeria inversa no ´ es una opci´ o –Fer primer el disseny, i a posteriori intentar extreure’n l’especificaci´ o (enginyeria inversa), ´ es un proc´ es complex que cal alimentar amb molts sup` osits addicionals –El resultat pot ser totalment arbitrari, complex o fosc. I en general estar` a molt lluny d’una especificaci´ o m´ ınimament decent Validaci´ o final d’INEP 20181