Modelagem de Interações -slides - Principios de Analise e Projeto de Sistema com UML - BEZERRA

65
Princípios de Análise Princípios de Análise e Projeto de Sistemas e Projeto de Sistemas com UML com UML 2ª edição 2ª edição Eduardo Bezerra Editora Campus/Elsevier

description

Modelagem de Interações -slides - Principios de Analise e Projeto de Sistema com UML - BEZERRA

Transcript of Modelagem de Interações -slides - Principios de Analise e Projeto de Sistema com UML - BEZERRA

  • Princpios de Anlise e Projeto de Sistemas com UML2 edioEduardo Bezerra Editora Campus/Elsevier

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Captulo 7 Modelagem de InteraesSomente aps a construo de diagramas de interao para os cenrios de um caso de uso, pode-se ter certeza de que todas as responsabilidades que os objetos devem cumprir foram identificadas -Ivar Jacobson.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • TpicosIntroduoDiagrama de seqnciaDiagrama de comunicaoModularizao de interaesConstruo do modelo de interaesModelo de interaes em um processo iterativo

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • IntroduoO objetivo dos modelos vistos at agora fornecer um entendimento do problema correspondente ao SSOO a ser desenvolvido.Entretanto, esses modelos deixam algumas perguntas sem respostas.No modelo de casos de uso:Quais so as operaes que devem ser executadas internamente ao sistema?A que classes estas operaes pertencem?Quais objetos participam da realizao deste caso de uso?

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • IntroduoNo modelo de classes de anlise:De que forma os objetos colaboram para que um determinado caso de uso seja realizado?Em que ordem as mensagens so enviadas durante esta realizao?Que informaes precisam ser enviadas em uma mensagem de um objeto a outro?Ser que h responsabilidades ou mesmo classes que ainda no foram identificadas?Sesses CRC pode ajudar a identificar quais so as responsabilidades de cada objeto e com que outros objetos ele precisa colaborar.Mas sesses CRC no fornecem um modo de documentar essas interaes.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • IntroduoPara responder s questes anteriores, o modelo de interaes deve ser criado.Esse modelo representa mensagens trocadas entre objetos para a execuo de cenrios dos casos de uso do sistema.A construo dos diagramas de interao uma consolidao do entendimento dos aspectos dinmicos do sistema, iniciado nas sesses CRC.A modelagem de interaes uma parte da modelagem dinmica de um SSOO.Diagramas de interao representam como o sistema age internamente para que um ator atinja seu objetivo na realizao de um caso de uso. A modelagem de um SSOO normalmente contm diversos diagramas de interao. O conjunto de todos os diagramas de interao de um sistema constitui o seu modelo de interaes.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • IntroduoOs objetivos da construo do modelo de interao so:Obter informaes adicionais para completar e aprimorar outros modelos (principalmente o modelo de classes)Quais as operaes de uma classe?Quais os objetos participantes da realizao de um caso de uso (ou cenrio deste)?Para cada operao, qual a sua assinatura?Uma classe precisa de mais atributos?Fornecer aos programadores uma viso detalhada dos objetos e mensagens envolvidos na realizao dos casos de uso.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • MensagemUma mensagem representa a requisio de um objeto remetente a um objeto receptor para que este ltimo execute alguma operao definida para sua classe. Essa mensagem deve conter informao suficiente para que a operao do objeto receptor possa ser executada.O conceito bsico da interao entre objetos a mensagem.Um sistema OO uma rede de objetos que trocam mensagens.Funcionalidades so realizadas pelos objetos, que s podem interagir atravs de mensagens.Um objeto envia uma mensagem para outro objeto quando o primeiro deseja que o segundo realize alguma tarefa.O fato de um objeto precisar de ajuda indica a necessidade de este enviar mensagens. Na construo de diagramas de interao, mensagens de um objeto a outro implicam em operaes que classes devem ter.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Mensagens versus responsabilidadesQual o objetivo da construo dos diagramas de interao?Identificar mensagens e, em ltima anlise, responsabilidades (operaes e atributos)Uma mensagem implica na existncia de uma operao no objeto receptor. A resposta do objeto receptor ao recebimento de uma mensagem a execuo da operao correspondente.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Sintaxe da UML para mensagens Na UML, o rtulo de uma mensagem deve seguir a seguinte sintaxe:

    Onde o termo controle pode ser uma condio ou um iterao:

    O nico termo obrigatrio corresponde ao nome da mensagem.

    [[expresso-seqncia] controle:] [v :=] nome [(argumentos)] * [ clusula-iterao ] [ clusula-condio ]

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Exemplos (sintaxe UML para mensagens) Mensagem simples, sem clusula alguma.1: adicionarItem(item)Mensagem com clusula de condio.3 [a > b]: trocar(a, b)Mensagem com clusula de iterao e com limites indefinidos.2 *: desenhar( )Mensagem com clusula de iterao e com limites definidos. 2 *[i := 1..10]: figuras[i].desenhar( )Mensagem aninhada com retorno armazenado na varivel x.1.2.1: x := selecionar(e)

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Exemplos (sintaxe UML para mensagens)

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Exemplos (sintaxe UML para mensagens)

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Notao para objetosObjetos so representados em um diagrama de interao utilizando-se a mesma notao do diagrama de objetos.Pode-se representar objetos annimos ou objetos nomeados, dependendo da situao.Elementos de uma coleo tambm podem ser representados.Classes tambm podem ser representadas.Para o caso de mensagens enviadas para a classe.Uma mensagem para uma classe dispara a execuo de uma operao esttica. A representao de uma classe em um diagrama de seqncia a mesma utilizada para objetos, porm o nome da classe no sublinhado

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • MultiobjetosUm multiobjeto o nome que a UML d para uma coleo de objetos de uma mesma classe. Pode ser utilizado para:representar o lado muitos de uma associao de conectividade um para muitos.representar uma lista (temporria ou no) de objetos sendo formada em uma colaborao.Um multiobjeto representado na UML atravs de dois retngulos superpostos.A superposio dos retngulos evita a confuso com a notao usada para objetos.O nome do multiobjeto apresentado no retngulo que fica por cima e segue a mesma nomenclatura utilizada para objetos.Conveno: usar o nome da classe de seus elementos para nomear o multiobjeto.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Notao para multiobjetosUma multiobjeto representado graficamente na UML atravs de dois retngulos superpostos.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Mensagens para Objetos/ColeoUma mensagem pode ser enviada para um multiobjeto, ou pode ser enviada para um nico objeto (elemento) do multiobjeto.Quando o smbolo de iterao no usado, convenciona-se que a mensagem est sendo enviada para o prprio multiobjeto.Exemplo:

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Implementao de multiobjetosMultiobjetos so normalmente implementados atravs de alguma estrutura de dados que manipule uma colees.Portanto, algumas mensagens tpicas que podemos esperar que um multiobjeto aceite so as seguintes: Posicionar o cursor da coleo no primeiro elemento.Retornar o i-simo objeto da coleo.Retornar o prximo objeto da coleo.Encontrar um objeto de acordo com um identificador nico.Adicionar um objeto na coleo.Remover um objeto na coleo.Obter a quantidade de objetos na coleo.Retornar um valor lgico que indica se h mais objetos a serem considerados.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Implementao de multiobjetos (cont)A interface List da linguagem Java apresenta operaes tpicas de um multiobjeto.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Tipos de diagrama de interao H trs tipos de diagrama de interao na UML 2.0: diagrama de seqncia, diagrama de comunicao e diagrama de viso geral da interao.O diagrama de seqncia e o diagrama de comunicao so equivalentes.Diagrama de seqncia: foco nas mensagens enviadas no decorrer do tempo.Diagrama de comunicao: foco nas mensagens enviadas entre objetos que esto relacionados.Diagrama de viso geral de interao. Pode ser utilizado para apresentar uma viso geral de diversas interaes entre objetos, cada uma delas representada por um diagrama de interao. Diagrama til para modularizar a construo do diagramas de seqncia (ou de comunicao).

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • 7.2 Diagrama de seqncia

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Diagrama de seqnciaOs objetos participantes da interao so organizados na horizontal.Abaixo de cada objeto existe uma linha (linha de vida)Cada linha de vida possui o seu foco de controle. Quando o objeto est fazendo algo.As mensagens entre objetos so representadas com linhas horizontais rotuladas partindo da linha de vida do objeto remetente e chegando a linha de vida do objeto receptor.A posio vertical das mensagens permite deduzir a ordem na qual elas so enviadas.Ordem de envio de mensagens em um diagrama de seqncia pode ser deduzida a partir das expresses de seqncia.Criao e destruio de objetos podem ser representadas.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Elementos grficos de um DSElementos bsicos em um diagrama de seqncia:AtoresObjetos, multiobjetos e classesMensagensLinhas de vida e focos de controleCriao e destruio de objetosIteraes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Elementos grficos de um DS

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Mensagens reflexivas em um DSEm uma mensagem reflexiva (ou auto-mensagem) o remetente tambm o receptor.Corresponde a uma mensagem para this (self). O que isso significa na prtica?

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Criao/destruio de objetos em um DS

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • 7.3 Diagrama de comunicao

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Diagrama de comunicaoChamado de diagrama de colaborao na UML 1.X.Estruturalmente, bastante semelhante a um diagrama de objetos.A diferena que so adicionados setas e rtulos de mensagens nas ligaes entre esses objetos.As ligaes (linhas) entre objetos correspondem a relacionamentos existentes entre os objetos.Deve haver consistncia com o diagrama de classes...Os objetos esto distribudos em duas dimensesVantagem: normalmente permite construir desenhos mais legveis comparativamente aos diagramas de seqncia. Desvantagem: no h como saber a ordem de envio das mensagens a no ser pelas expresses de seqncia.Direo de envio de mensagem indicada por uma seta prxima ao rtulo da mensagem.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Elementos grficos de um DCElementos bsicos em um diagrama de comunicao:AtoresObjetos, multiobjetos e classesMensagensLigaes entre objetosCriao e destruio de objetosIteraes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Elementos grficos de um DC

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Criao de objetos em um DCDurante a execuo de um cenrio de caso de uso, objetos podem ser criados e outros objetos podem ser destrudos.Alguns objetos podem sobreviver execuo do caso de uso (se conectando a outro objetos); outros podem nascer e morrer durante essa execuo.A UML define etiquetas (tags) para criao e destruio de objetos (ou de ligaes entre objetos) no diagrama de comunicao.{new}: objetos ou ligaes criados durante a interao.{destroyed}: objetos ou ligaes destrudos durante a interao.{transient}: objetos ou ligaes destrudos e criados durante a interao.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Criao de objetos em um DC

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • 7.4 Modularizao de interaes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Quadros de interaoElemento grfico, que serve para modularizar a construo de diagramas de seqncia (ou de comunicao).Objetivos especficos:Dar um nome ao diagrama que aparece dentro do quadro;Fazer referncia a um diagrama definido separadamente;Definir o fluxo de controle da interao.Notao:

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Diagramas nomeadosDar um nome ao diagrama que aparece dentro do quadro

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Diagramas referenciadosFazer referncia a um diagrama definido separadamente.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Fluxo de controle: alternativas

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Fluxo de controle: opes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Fluxo de controle: iteraes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • 7.5 Construo do modelo de interaes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Mensagens versus responsabilidadesO objetivo da modelagem de interaes identificar mensagens e, em ltima anlise, responsabilidades.Uma mensagem implica na existncia de uma operao no objeto receptor. A resposta do objeto receptor ao recebimento de uma mensagem a execuo da operao correspondente.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Alocao de responsabilidadesPodemos ento entender a modelagem de interaes como um processo cujo objetivo final decompor as responsabilidades do sistema e aloc-las a classes. Dado um conjunto de N responsabilidades, uma possibilidade criar uma nica classe no sistema para assumir com todas as N responsabilidades. Outra possibilidade criar N classes no sistema, a cada um delas sendo atribuda uma das N responsabilidades.Certamente, as duas alternativas anteriores so absurdas do ponto de vista prtico. Mas, entre as muitas maneiras possveis de alocar responsabilidades, como podemos saber quais delas so melhores que outras?

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Acoplamento e coesoA resposta pergunta anterior no nenhuma receita de bolo.De fato, para construirmos uma bom modelo de interaes, devemos lanar mo de diversos princpios de projeto:Dois dos principais princpios so o acoplamento e a coeso.A coeso uma medida do quo fortemente relacionadas e focalizadas so as responsabilidades de uma classe. extremamente importante assegurar que as responsabilidades atribudas a cada classe sejam altamente relacionadas. Em outras palavras, o projetista deve definir classes de tal forma que cada uma delas tenha alta coeso.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Acoplamento e coesoO acoplamento uma medida de quo fortemente uma classe est conectada a outras classes, tem conhecimento ou depende das mesmas. Uma classe com acoplamento fraco (baixo) no depende de muitas outras.Por outro lado, uma classe com acoplamento forte menos inteligvel isoladamente e menos reutilizvel. Alm disso, uma classe com alto acoplamento mais sensvel a mudanas, quando necessrio modificar as classes da qual ela depende.Concluso: criar modelos com alta coeso e baixo acoplamento deve ser um objetivo de qualquer projetista.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MIIdentifique as classes conceituais que participam em cada caso de uso. Estas so as entidades do mundo real que estariam envolvidas na tarefa do caso do uso se este fosse executada manualmente. Exemplos so: Aluno, OfertaDisciplina, Venda, Pagamento, etc. Note que classes de fronteira tambm podem ser classes conceituais. Por exemplo, FormulrioInscrio um objeto de fronteira (para o caso de uso Realizar Inscrio) que tambm corresponde a um conceito existente no domnio do problema.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MI (cont)Identifique quaisquer classes de software que ajudem a organizar as tarefas a serem executadas. classes daque no tm correspondente no mundo realEssas classes normalmente so necessrias para manter a coeso das demais classes em um nvel alto. Segundo Craig Larman, essas classes so fabricaes puras (pure fabrications).Aqui, se encaixam algumas classes de fronteira, classes de controle. Tambm: classes de acesso ao mecanismo de armazenamento, classes de autenticao, etc.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MIDefina tambm que objetos criam (destrem) outros objetos.Na realizao de um caso de uso, objetos de entidade podem ser criados pelo objeto de controle, que recebe os dados necessrios instanciao a partir de objetos de fronteira. Objetos de entidade tambm podem ser criados (destrudos) por outros objetos de entidade.De uma forma geral, em uma agregao (ou composio), o objeto todo tem prioridade para criar (destruir) suas partes.Portanto, em uma agregao (ou composio) entre objetos de entidade, mais adequado que o objeto todo crie (destrua) suas partes quando requisitado por outros objetos.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MI (cont)Verifique a consistncia dos diagramas de interao em relao ao MCU e ao modelo de classes.Verifique que cada cenrio relevante para cada caso de uso foi considerado na modelagem de interaes.Se assegure de que as mensagens que um objeto recebe esto consistentes com as responsabilidades a ele atribudas.Alguns dos objetos necessrios em uma interao j podem ter sido identificados durante a construo do modelo de classes de anlise.Durante a construo do diagrama de interao, o modelador pode identificar novas classes.Atributos, associaes e operaes tambm surgem como subproduto da construo dos diagramas de interao.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MI (cont)Se certifique de que o objeto de controle realiza apenas a coordenao da realizao do caso de uso.Como o controlador tem a responsabilidade de coordenao, todas as aes do ator resultam em alguma atividade realizada por esse objeto de controle.Isso pode levar ao alto acoplamento; no pior caso, o controlador tem conhecimento de todas as classes participantes do caso de uso.Responsabilidades especficas no domnio devem ser atribudas aos objetos de domnio (entidades).Sempre que for adequado, segundo os princpios de coeso e de acoplamento, devemos fazer com que as classes de domnio enviem mensagens entre si, aliviando o objeto de controle.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MI (cont)Faa o mximo para construir diagramas de interao o mais inteligveis possvel.Por exemplo, podemos utilizar notas explicativas para esclarecer algumas partes do diagrama de interao que esteja construindo. Essas notas podem conter pseudocdigo ou mesmo texto livre. Outra estratgia que ajuda a construir um modelo de interaes mais inteligvel utilizar os recursos de modularizao que a UML 2.0 acrescentou.quadros de intereao, referncias entre diagramas, etc.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Dicas para construo do MI (cont)Utilize o princpio de projeto conhecido como Lei de Demeter. Esse princpio est associado ao princpio do acoplamento e impe restries acerca de quais so os objetos para os quais devem ser enviadas mensagens na implementao de uma operao:(a) ao prprio objeto da classe (ou self); (b) a um objeto recebido como parmetro do mtodo; (c) a um atributo da classe; (d) a um objeto criado dentro do mtodo; (e) a um elemento de uma coleo que atributo da classe.A inteno evitar acoplar excessivamente um objeto e tambm evitar que ele tenha conhecimento das associaes entre outros objetos.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Na modelagem de interaes, quando definimos uma mensagem, estamos criando uma dependncia entre os objetos envolvidos. Isso mesmo que dizermos que estamos aumentando o acoplamento entre os objetos em questo.Portanto, necessrio que o modelador fique atento para apenas definir mensagens que so realmente necessrias.Sempre que possvel, devemos evitar o envio de mensagens que implique na criao de associaes redundantes no modelo de classes.Isso porque a adio de uma associao entre duas classes aumenta o acoplamento entre as mesmas.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Procedimento de construoVamos agora descrever um procedimento para construo do modelo de interaes. Note, primeiramente,Esse procedimento genrico serve tanto para diagramas de seqncia quanto para diagramas de comunicao, resguardando-se as diferenas de notao entre os dois.Durante a aplicao desse procedimento, recomendvel considerar todas as dicas descritas anteriormente.Antes de descrevermos esse procedimento, necessrio que definamos o conceito de evento de sistema

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Eventos de sistemaEventos de sistema correspondem s aes do ator no cenrio de determinado caso de uso. Sendo assim, relativamente fcil identificar eventos de sistemas em uma descrio de caso de uso: devemos procurar nessa descrio os eventos que correspondem a aes do ator.No caso particular em que o ator um ser humano e existe uma interface grfica para que o mesmo interaja com o sistema, os eventos do sistema so resultantes de aes desse ator sobre essa interface grfica, que corresponde a objetos de fronteira.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Eventos de sistema (cont)Considere o formulrio a seguir, para o caso de uso (do SCA) denominado "Fornecer Grade de Disponibilidades:

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Eventos de sistema (cont)No formulrio anterior, temos a seguinte lista de eventos de sistema:solicitao de validao de matrcula de professor;solicitao de adio de uma disciplina grade;solicitao de adio de um item de disponibilidade (dia, hora final e hora final) grade;solicitao de registro da grade.Importante: nem todo evento de sistema originado em um objeto de fronteira correspondente a uma interface grfica. essa ocorrncia pode ser gerada por um ator que no seja um ser humano (e.g., outro sistema ou um equipamento).

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Eventos de sistema (cont)Mas, por que os eventos de sistema so importantes para a modelagem de interaes? Porque as interaes entre objetos de um sistema acontecem por conta do acontecimento daqueles.Um evento de sistema alguma ao tomada por um ator que resulta em uma sequencia de mensagens trocadas entre os objetos do sistema.Portanto, o ponto de partida para a modelagem de interaes a identificao dos eventos do sistema.Uma vez feita essa identificao, podemos desenhar diagramas de interao que modelam como os objetos colaboram entre si para produzir a resposta desejada a cada evento do sistema.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Procedimento de construoPara cada caso de uso, selecione um conjunto de cenrios relevantes.O cenrio correspondente ao fluxo principal do caso de uso deve ser includo. Considere tambm fluxos alternativos e de exceo que tenham potencial em demandar responsabilidades de uma ou mais classes.Para cada cenrio selecionado, identifique os eventos de sistema:Posicione o(s) ator(es), objeto de fronteira e objeto de controle no diagrama.Para cada passo do cenrio selecionado, defina as mensagens a serem enviadas de um objeto a outro.Defina as clusulas de condio e de iterao, se existirem, para as mensagens.Adicione multiobjetos e objetos de entidade medida que a sua participao se faa necessria no cenrio selecionado.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Observaes sobre o procedimentoA definio das mensagens deve ser feita com base nas responsabilidades de cada objeto envolvido:O nome da mensagemOs argumentos de cada mensagem, se existirem.O valor de retorno da operao correspondente, se existir.Clusulas de condio e de repetio, se existirem.A maioria dos objetos j devem ter sido identificados durante a construo do modelo de classes.Verificar as consistncias:Cada cenrio relevante para cada caso de uso foi considerado?A mensagens que um objeto recebe esto consistentes com suas responsabilidades?As mensagens de um ator a um objeto de fronteira normalmente so rotuladas com a informao fornecidapor exemplo, item de pedido, id e senha, etc.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • Observaes sobre o procedimentoMais de um controlador podem ser criados em um mesmo caso de uso, dependendo de sua complexidade.O controlador pode mesmo ser suprimido, tambm em funo da complexidade do caso de uso.Mensagens enviadas pelo objeto de fronteira por conta de um evento de sistema resultam na necessidade de definir operaes de sistema no objeto controlador do caso de uso.Por exemplo, no do formulrio de fornecimento de disponibilidades, o controlador deve possuir as seguintes operaes de sistema:validarProfessor(matrcula); adicionarDisciplina(nomeDisciplina);adicionarItemDisponibilidade(dia, horaInicial, horaFinal). registrarGrade()

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • 7.6 Modelo de interaes em um processo iterativo

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • MI em um processo iterativoSo utilizados na fase de construo de um ciclo de vida incremental e iterativo.So construdos para os casos de uso alocados para uma iterao desta fase.H controvrsias sobre o momento de incio da utilizao desse modelo (se na anlise ou se no projeto).Inicialmente (+anlise), pode exibir apenas os objetos participantes e mensagens exibindo somente o nome da operao (ou nome da responsabilidade).Posteriormente (+projeto), pode ser refinado.criao e destruio de objetos, tipo e assinatura completa de cada mensagem, etc.

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • MI em um processo iterativoEmbora modelos de um SSOO representem vises distintas, eles so interdependentes e complementares.O MCU fornece cenrios a serem considerados pelo MI.O modelo de classes de anlise fornece objetos iniciais para o MI.A construo do MI fornece informaes teis para transformar o modelo de classes de anlise no modelo de classes de especificao. Em particular, MI fornece os seguintes itens para refinar o modelo de classes de anlise:Detalhamento de operaesDetalhamento de associaesOperaes para classesNovos atributos para classesNovas classes

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • MI em um processo iterativo

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

  • DiscussoComo informaes so passadas de um objeto a outro em um sistema OO? Quando utilizar diagramas de interaes (seqncia ou comunicao)?H alternativas para esse momento?Qual a conseqncia da construo dos DIs sobre os demais artefatos do sistema.H possibilidade de gerao de cdigo a partir de um diagrama de interaes?

    Princpios de Anlise e Projeto de Sistemas com UML - 2 edio

    Para que um objeto realize alguma tarefa, deve haver um estmulo enviado a este objeto.Independentemente da origem do estmulo, quando este ocorre, diz-se que o objeto destinatrio est recebendo uma mensagem.Objetos de um sistema trocam mensagensisto significa que objetos enviam mensagens uns aos outros com o objetivo de realizar alguma tarefa dentro do sistema no qual esto inseridos.

    Um DI mostra objetos relevantes para a realizao de um cenrio de caso de uso.Esses objetos podem ser nomeados ou annimos.O uso do nome depende da necessidade.Se for preciso fazer referncia ao objeto, necessrio dar um nome a ele.Sublinhado pode no ser utilizado.

    Algumas ferramentas CASE no possuem a notao para multiobjetos. Nesses casos, pode-se utilizar a notao comum para objetos e o esteretipo multiobject.

    Seu nome apresentado no retngulo superior e segue a mesma nomenclatura utilizada para objetos.Conveno: usar o mesmo nome da classe dos objetos componentes para nomear a coleo. A superposio dos retngulos evita a confuso.

    Diagrama de seqncia:Exibe as mensagens ordenadas no tempo.A visualizao fica dificultada conforme o nmero de objetos cresce (disposio em uma dimenso).Diagrama de comunicao:Exibe mensagens enfatizando relacionamentos.Melhor utilizao do espao (disposio em duas dimenses).Mais adequado para profissionais que esto acostumados sesses CRC.Como o diagrama de seqncia e de comunicao so equivalentes, a escolha por um ou outro mais questo de gosto.Ferramentas CASE: transformao automaticamente.

    A invocao de um mtodo por um objeto exibida no diagrama por uma seta rotulada. O rtulo desta seta segue a sintaxe para definio de mensagens. Na fase de anlise, esta seta pode apenas conter uma descrio da operao cuja execuo solicitada.

    O perodo de tempo no qual um objeto est executando um mtodo que lhe foi requisitado denominado ativao.

    Criao de objetos em diagramas de seqncia:Adicione o novo objeto na posio desejada.A mensagem de criao (construtor) termina no novo objetoAtivao denota execuo do construtorCriao de objetos em diagramas de comunicao:Novos objetos e ligaes so anotados (rotulados) com a propriedade {new}

    Representada atravs de uma mensagem com o esteretipo destroy e com um X ao final da linha de vida do defunto.

    Estruturalmente semelhante ao diagrama de objetos.A diferena que so adicionados setas e rtulos de mensagens nas ligaes entre esses objetos.Objetos (nomeados e annimos) e classes podem aparecer.As ligaes (linhas) entre objetos correspondem a relacionamentos existentes entre os objetos.A ordem de envio das mensagens determinada pelas expresses de seqncia.Direo de envio de mensagem indicada por uma seta prxima ao rtulo da mensagem.

    Ligaes em um DC Um diagrama de comunicao apresenta ligaes entre objetos.Vrias mensagens, e mensagens em ambos os sentidos, fluem no mesma ligao. No necessrio criar uma ligao por mensagem.Ordem de envio das mensagens.Em um DC, mensagens so numeradas para evitar ambigidade na definio da ordem de envio.

    O quadro de interao foi introduzido pela UML 2.0.

    Mensagens condicionais podem ser mutuamente exclusivas.