Engenharia de Software Unidade XI UML Parte 2

Transcrição

1 Engenharia de Software Unidade XI UML Parte 2 Prof. Francisco Gerson A. de Meneses Diagramas de Interação... O diagrama de interação na verdade é um termo genérico aplicado à junção de dois outros diagramas: seqüência e colaboração. Esses diagramas juntos conseguem demonstrar o comportamento dos objetos, considerando-se a seqüência da troca de mensagens existentes entre eles, para que se cumpra um determinado papel ou se atenda a determinado contexto. Ao trocar mensagens para atingir determinado objetivo, estabelece-se um contexto de colaboração entre os objetos. Os diagramas de sequência e colaboração favorecem a identificação de responsabilidades que as classes poderão ter, uma vez que as mensagens trocadas pelos objetos correspondem a métodos que devem existir nas classes. franciscogerson10@gmail.com Para avaliar uma interação é necessário eleger um caso de uso específico, daí então busca-se identificar quais objetos participam da interação. À medida que se vai identificando os objetos envolvidos, percebe-se a forma como eles estão relacionados, o que vem a facilitar o entendimento de como se deve estabelecer associações entre classes no diagrama de classes, bem como quais métodos devem existir para determinadas classes. Vejamos portanto os diagramas de Seqüência e Colaboração: Mostra-se a interação entre objetos com a preocupação de documentar os métodos executados ao longo do tempo. A ênfase é a ordenação temporal de mensagens trocadas entre os objetos. Os métodos utilizados no diagrama de seqüência devem estar definidos nas respectivas classes dos objetos empregados. Possui duas dimensões: vertical, que representa o tempo, e horizontal, que representa diferentes objetos (se for necessário, as dimensões podem ser invertidas). Para exemplificar, a seguir apresenta-se um diagrama de casos de uso, o diagrama de classes e o diagrama de seqüência. O diagrama de seqüência modela, no exemplo, como se realiza o caso de uso cadastrar clientes. Diagrama de Casos de Uso Diagrama de Classe Os diagramas de casos de uso, classes e seqüência formam um tripé mínimo necessário para a documentação da análise orientada a objetos utilizando-se a UML. Tais diagramas devem estar consistentes entre si; por exemplo, o diagrama de seqüência não deve fazer menção a uma operação ou objeto que não estejam representados no diagrama de classes, tão pouco deve realizar algo que não esteja previsto como funcionalidade do diagrama de casos de uso. O diagrama de seqüência mostra como utilizar os métodos definidos no diagrama de classes (a troca de mensagens entre objetos) para suprir o sistema com uma das funcionalidades previstas no diagrama de casos de uso.

2 O diagrama de seqüência visto, documenta a realização de uma funcionalidade que está presente no diagrama de casos de uso, com o nome Cadastrar Clientes. Tem-se um objeto chamado pessoa, que interage com um Formulário (tela de cadastro). No formulário, além dos campos a serem preenchidos, há dois botões que podem ser clicados e, então, será acionada a respectiva ação (um método será executado no objeto). Façamos uma análise detalhada desse diagrama analisando todos os seus componentes: Object0:Pessoa: Pessoa é um ator que deve estar desenhado no diagrama de casos de uso, associado a um caso de uso Cadastrar Clientes. A operação realizada por pessoa é que dispara todas as demais; daí o número 1(um) que aparece no fluxo identificado como nome digitadados(), que parte de pessoa em direção ao objeto Formulário. Abaixo do ator que representa Pessoa há riscos tracejados e, em seguida, uma barra que se estende verticalmente. Esta barra indica o tempo durante o qual a Pessoa participou ativamente do processo a parte tracejada indica tempo de ociosidade. O desenho dos riscos tracejados e a barra têm o mesmo objetivo em todos os elementos do diagrama onde são empregados; ou seja indicar o tempo ocioso e o tempo de processamento. Object1:Formulário rio: Tela ou Formulário são os termos mais empregados para a interface a ser apresentada por meio do monitor de vídeo do computador, porém evita-se utilizar o termo interface para não confundir com as classes de interface. A mensagem 1.1 :botão-cadastrar() sai do formulário para ele mesmo; trata-se de uma mensagem de autodelegação. A mensagem ocorrerá sempre que o botão cadastrar do Formulário for pressionado; assim, há a criação de uma barra de processamento do botão, onde serão documentados os procedimentos relativos ao botão cadastrar. No caso, é enviada uma mensagem cadastrar() ao objeto do tipo Cliente, ou seja, um método daquele objeto é executado. Tal método tem que estar previsto na respectiva classe. Object1:Formulário rio: Por meio do botão sair é acionada uma mensagem predefinida pelo estereótipo <<destroy>>, a qual não reside no objeto. Refere-se à liberação de memória, ocupada pelo objeto até aquele momento. Tal mensagem, representa, em geral, um comando em uma linguagem de programação, que libera a área de memória ocupada por um objeto quando era necessário o processamento do mesmo....diagramas de Interação Object2:Clientes: Trata-se de um objeto pertencente à classe de negócio Clientes. A classe deve estar definida no diagrama de classes, com todos os seus atributos e métodos. Métodos acionados em objetos devem estar previamente definidos nas respectivas classes. Diagrama de Colaboração: É um modo alternativo para representar a troca de mensagens entre um conjunto de objetos, mostrando a interação organizada em torno dos objetos e suas ligações uns com os outros, sem a preocupação de expressar a vida útil das mensagens no tempo. O diagrama de colaboração não mostra a dimensão do tempo, por isso as seqüências de mensagens devem ser determinadas usando-se a seqüência de números.

3 Diagrama de Estado......Diagrama de Estado... Normalmente, um sistema reage a estímulos provenientes de fora dele, ou ainda a estímulos temporais por ele mesmo desencadeado. Esta reação pode originar respostas externas ao sistema. Essa dinâmica existente nos sistemas é fruto da colaboração entre objetos, os quais estarão em determinado estado certo momento no tempo. O Diagrama de Estados é usado para mostrar os possíveis estados dos objetos de uma classe no decorrer do seu ciclo de vida. A mudança de um estado para outro é chamado de transição de estados. Os eventos do Diagrama de Estados causam uma transição de um estado para outro. Cada diagrama está associado a uma classe ou a um diagrama de um nível mais alto. O início de um Diagrama de Estados é indicado pelo chamado estado inicial, cuja representação gráfica é um círculo preenchido. Na verdade ele não expressa um estado específico de um objeto da classe, indica apenas o início do diagrama. Na seqüência se conecta o primeiro estado real com uma transição, rotulada ou não. Em cada diagrama de estado há somente um estado inicial. A notação gráfica de um estado inicial é mostrado abaixo:...diagrama de Estado......Diagrama de Estado Um estado demonstra uma situação no tempo de algum aspecto do sistema sobre o qual existe interesse de controle. Durante a vida de um objeto, pode vir a existir controle sobre várias situações, cada qual podendo assumir diversos estados possíveis no tempo. Um objeto permanece em um estado por um tempo finito. A notação gráfica e um exemplo de diagrama de estado é mostrada a seguir: O estado final representa o término do ciclo de controle previsto para mudanças de estado de um dos aspectos do sistema. Para o objeto passar de um estado para o outro (transição de estado), são necessários dois mecanismos: condição e ação. A condição, se existir, deverá ser satisfeita para que a ação seja executada. A ação é a responsável pela transição de estados. Diagrama de Componentes... A UML prevê que se faça uma documentação da organização física do software que será gerado. A documentação que refletirá o mundo físico irá considerar a existência de componentes, como um código-fonte, um executável ou uma biblioteca. Um diagrama de componentes mostra as dependências entre componentes de software, incluindo componentes de código-fonte, componentes de código binário e componente executável. Um módulo de software é representado como um tipo de componente. Um diagrama de componentes contém elementos que representam:...diagrama de Componentes Packages de componentes Componentes ou módulos Packages Programa Subprogramas Tarefas Dependências Um relacionamento de dependência (indicado pela seta tracejada) mostra que um módulo, em um Diagrama de Componentes, usa serviços ou facilidades de outro. Dependências em um Diagrama de Componentes representam dependências de compilação.

4 Diagrama de Distribuição... Diagrama de Distribuição... Com a UML é possível especificar-se uma visão que reúne todos os elementos de processamento, incluindo-se hardware e o software. Com relação ao hardware, têm-se processadores, subentendendo-se que sejam quaisquer componentes capazes de executar programas. Este diagrama mostra a configuração dos processadores, visualizandose a distribuição por toda a empresa. O diagrama permite a documentação das conexões físicas entre os processadores, dispositivos e a alocação dos processos aos processadores. Mostra a organização do hardware e a ligação do software com os dispositivos físicos. O tipo de dispositivo de hardware é dado pelo seu estereótipo, tais como processador, vídeo, dispositivo, memória, disco e outros. Representação de um processador Representação de um dispositivo Um dispositivo é um componente de hardware sem efeito computacional. Cada dispositivo deve ter um nome, podendo ser genérico, como modem ou terminal. Um conexão física representa a interligação entre processadores ou dispositivos de hardware. A ligação de hardware pode ser direta ou indireta, sendo bidirecional. Um exemplo de conexão é mostrado a seguir:...diagrama de Distribuição Estudo de Caso... O estudo de caso escolhido é um sistema de Gestão de um Hotel: Controle de Reserva de Locação de Quartos (o mesmo utilizado para exemplificar os métodos de Análise Estruturada e Essencial). Como a UML não é um método de desenvolvimento de software, mas uma linguagem de especificação, a seqüência (caminho, método) apresentado a seguir é uma proposta a ser seguida. Qualquer que seja o método utilizado, espera-se que o Analista de Sistemas venha a desenvolver suas atividades com o apoio de um software CASE, no nosso caso utilizaremos o JUDE. Exemplos de outras ferramentas: Rose, ArgoUML, UMLStudio, etc. Considerando-se que a atividade de levantamento de requisitos tenha sido bem realizada, com reuniões, entrevistas, observação dos fluxos de trabalho e inspeção dos documentos utilizados, preparou-se uma relação de itens com todas as informações relevantes que foram colhidas: O acesso ao sistema será a partir de Login. O cliente telefona ou vem até o hotel e pede para reservar um quarto. O funcionário verifica se existe quarto disponível no período solicitado, verifica também se o cliente já é cadastro, caso não seja, o cadastro do cliente é realizado; Faz-se então a reserva do quarto. O cliente também poderá optar por fazer esta operação de reserva via internet, porém só poderá fazê-lo se já estiver previamente cadastrado. Os quartos serão cadastrados pelo funcionário. Cont...: Caso o cliente não mais deseje o quarto reservado, o funcionário providencia o cancelamento da reserva, disponibilizando novamente o quarto. O cliente também poderá realizar essa operação utilizando a internet. Quando o cliente não comparecer ao hotel para hospedar-se até as 12h no dia da reserva, esta deverá ser cancelada, disponibilizando-se novamente o quarto. Quando o cliente ocupa um quarto, reservado previamente, o funcionário faz o registro da entrada. Caso o quarto não esteja reservado previamente o processo de reserva é efetivado no momento. Quando o cliente deixar o hotel, notificando sua saída, será registrado a saída e lhe será apresentada a conta, registrando-se o pagamento, e o quarto será disponibilizado para limpeza sendo em seguida reabastecido e o funcionário o liberará para uma nova locação; O cliente pode pagar a conta à vista ou usando o cartão de crédito.

5 Uma vez que se tenha definidos os requisitos, a fase seguinte sugerida é o desenvolvimento de um diagrama de casos de uso que refletirá o contexto do sistema, onde ficarão documentas graficamente todas as ações estabelecidas no roteiro de tarefas, decorrente do levantamento de requisitos. Vejamos a seguir o Diagrama de Casos de Uso apresentando o cenário global do sistema: Entre os atores observa-se uma situação de herança já que Cliente e Funcionário tem algumas ações em comum como: Login no Sistema, Reservar Quarto, Cancelar Reserva. Antes de realizar qualquer ação no sistema os mesmos terão que obrigatoriamente (include) fazer Login no Sistema. Ao Reservar Quarto, obrigatoriamente (include) terá que ser feito: Identificar Quarto e Identificar Cliente, caso o cliente não seja identificado poderá a partir daí (extend) Cadastrar Clientes. Ao Cancelar Reserva o Funcionário poderá Liberar o Quarto para uma nova reserva, ou fazê-lo quando lhe convier (após a limpeza, reabastecimento). O Registrar Entrada só poderá ser feito pelo Funcionário e se ocorrer um Reservar Quarto. O Funcionário fará Cadastrar Clientes antes disso poderá (extend) Identificar Clientes. O Funcionário fará Cadastrar Quartos. O Funcionário fará Registrar Saída e obrigatoriamente (include) será feito o Registrar Pagamento sendo enviado uma Nota ou Recibo para o Cliente. O passo a seguir é o Diagrama de Classes que representa a parte estática da modelagem do software, onde se planeja os recursos que irão existir para que através deles se realizem as funcionalidades exigidas no diagrama de casos de uso. O passo inicial sugerido para se descobrir quais classes fazem parte do domínio do problema é examinar em detalhes as ações que compõe cada caso de uso e perguntar: Quais são os dados que o caso de uso necessitará? Um dado é característica de algo ou de alguém, este algo ou alguém é, potencialmente, uma classe que deverá ser criada e esses dados deverão ser persistidos. Os métodos das classes podem ser criados de acordo com a necessidade decorrente da realização dos casos de uso; é necessário, portanto, entender qual a responsabilidade da classe para a realização de um determinado caso de uso. Vejamos a seguir o Diagrama de Classes:

6 Há uma situação de herança representada pela Superclasse Usuario e as Subclasses Cliente e Funcionario, as Subclasses irão compartilhar os atributos e métodos referentes ao Longin do Sistema. A partir do relacionamento de Cliente e Quarto geram a Classe Associativa Reserva (dependência). O método Reserva.definirSituação() definirá o Estado do atributo Reserva.situaçãoQuarto a partir das operações feitas. A partir de Reserva.registrarPagamento ocorre o Reserva.emitirNota. O relacionamento das classes Reserva e Boletim é uma agregação fraca, se não houver Reserva não tem Boletim, agora se não houver Boletim pode haver reserva; um boletim é composto de uma ou várias reservas. O atributo Boletim.valorBoletim recebe o valor que será calculado pelo método Boletim.calculaBoletim(). Funcionário se relaciona com Cliente, Quarto, Reserva e Boletim através de uma Associação com navegabilidade indicando que pode se encontrar uma Instância de Funcionário a partir de uma instância das outras classes citadas; observa-se os atributos qualificadores (Funcionario.id) nessas outras classes. Após ter-se desenhado o Diagrama de Casos de Uso e o Diagrama de Classes, recomenda-se um detalhamento de cada caso de uso, empregando-se o Diagrama de Seqüência. A ordem de desenvolvimento dos diagramas é uma sugestão; há quem sugira primeiramente criar-se o Diagrama de Seqüência após os casos de uso e assim, descobrir os objetos envolvidos e somente então gerar o Diagrama de Classes. A sequência operacional no tempo, demonstrada pelo Diagrama de Sequência, envolve a interação do ator com uma tela ou formulário, o acionamento de métodos dos objetos a partir do formulário e a troca de mensagens entre os objetos participantes do caso de uso. Deve-se entender como um caso de uso é realizado, qual é o seu objetivo, quais são as restrições envolvidas, por que se faz de uma forma e não de outra; esta forma de atuar deve ser aplicada na análise de cada caso de uso existente, fato que facilitará a criação dos Diagramas de Sequência correspondentes. Ao detalhar cada um dos casos de uso, o Analista estará examinando cada particularidade que constitui o sistema, podendo vir a encontrar aspectos ainda não revelados. Trata-se de uma fase em que se quebra o todo em partes e examina-se detalhadamente tais partes. Portanto, os Diagramas de Sequência nada mais são do que um retrato gráfico das operações necessárias para se efetivar o caso de uso. Para que se possa iniciar o desenho do Diagrama de Seqüência, sugerese que se faça antes um esboço da tela ou formulário que se deseja utilizar. Assim pode-se observar quais são as interações que o formulário permite e, com base nelas (clicar um botão, por exemplo) documentar quais métodos serão acionados. Vejamos os casos de uso e seus respectivos Diagramas de Seqüência: Diagrama de Seqüência Login do Sistema : Diagrama de Seqüência Login do Sistema :

7 O ator usuário aqui representa tanto o Funcionário como o Cliente. O botão login aciona o método efetuarlogin() que envia login e senha como parâmetros. Após efetuarlogin(), as ações que Funcionário e Cliente farão no sistema, de acordo com suas permissões, poderão ser realizadas. As ações: alterarlogin, alterarsenha e Logout serão realizadas após o Login. O botão editar dados representa os métodos alterarlogin() e alterarsenha(). Ao clicar em Logout é feito o logout e é liberado o objeto (usuário que estava logado). Diagrama de Seqüência Reservar Quarto : Diagrama de Seqüência Reservar Quarto : O ator usuário aqui representa tanto o Funcionário como o Cliente. Essa ação é realizada após o Login. Inicialmente é feito uma consulta ao Cliente identificarcliente() e ao Quarto identificarquarto(), verificando também o período pretendido para a reserva, e é retornado situacaoquarto() se o quarto estiver Livre para aquele período selecionado é acionado o botão reservar passando como parâmetros o Cliente, o Quarto e as Datas através do método reservar(), daí então, é instanciado um objeto reserva. A situação da reserva passará para reservada, método definirsituacao(). Diagrama de Seqüência Cancelar Reserva : Diagrama de Seqüência Cancelar Reserva :

8 O ator usuário aqui representa tanto o Funcionário como o Cliente. Essa ação é realizada após o Login. Inicialmente é feito uma consulta consultarreserva() para localizar a reserva que será cancelada, a mesma pode ser localizada pelo Código (Id), Nome do cliente ou pelo Quarto, as datas aparecerão automaticamente e deverá ser preenchido o motivo do cancelamento, a partir do botão cancelar, é feito o cancelamento acionando o método cancelarreserva(). A situação da reserva passará para cancelada, método definirsituacao(). Diagrama de Seqüência Registrar Entrada : Diagrama de Seqüência Registrar Entrada : O Funcionário é quem fará essa ação. Essa ação é realizada após o Login. Inicialmente é feito uma consulta consultarreserva() para localizar a reserva que será efetivada (registro da entrada), a mesma pode ser localizada pelo Código (Id), Nome do cliente ou pelo Quarto, as datas aparecerão automaticamente, a partir do botão registrar, é efetivado a locação do quarto pelo cliente acionando o método registrarentrada(). A situação da reserva passará para registrada, método definirsituacao(). Diagrama de Seqüência Registrar Saída : Diagrama de Seqüência Registrar Saída :

9 O Funcionário é quem fará essa ação. Essa ação é realizada após o Login. Inicialmente é feito uma consulta consultarreserva() para localizar a reserva que será finalizada (registro da saída), a mesma pode ser localizada pelo Código (Id), Nome do cliente ou pelo Quarto, também será efetivado o cálculo do valor a ser pago pelo cliente registrarpagamento() sendo armazenado o valor no atributo Reserva.valorReserva, após isso o valor é mostrado na tela e a partir do botão registrar é efetivado a saída do quarto acionando o método registrarsaída(); como resultado dessa ação será emitida uma nota emitirnota() ao cliente. A situação da reserva passará para desocupado, método definirsituacao(). Diagrama de Seqüência Liberar Quarto : Diagrama de Seqüência Liberar Quarto : Diagrama de Seqüência Cadastrar Cliente : Conforme observado, as diversas situações que podem ocorrer em uma reserva (reservar, cancelar, ocupar, desocupar, liberar) são refletidas diretamente na situação do quarto, que deverá mudar de estado de acordo com as operações feitas (métodos). Para ter-se uma visão sobre a situação de um quarto, poderíamos desenvolver um Diagrama de Transição de Estados, onde visualizamos todos os estados possíveis em que o quarto pode estar, bem como a transição entre eles. Vejamos o Diagrama de Transição de Estados para representar esse cenário: A partir de uma reserva é realizada uma ocupação ou é feito um cancelamento, a partir da ocupação vem a seguir a desocupação, a partir da desocupação ou do cancelamento o quarto é liberado para uma nova reserva.

10 Os componentes de software utilizados nessa aplicação, de uma forma geral, podem ser observados no Diagrama de Componentes a seguir: Os componentes de hardware utilizados nessa aplicação, de uma forma geral, podem ser observados no Diagrama de Distribuição a seguir: Exercício Unidade VI Bibliografia 1 - Explique a afirmação: A UML não é um método de desenvolvimento de sistemas, é uma linguagem de modelagem gráfica que pode ser aplicada para descrever e documentar um projeto de software. 2 - Destaque 4 diagramas estáticos e 4 diagramas dinâmicos? 3 Tratando-se de UML, o que você entende por estereótipo? 4 - Qual a função do Diagrama de Casos de Uso? 5 - Qual a importância de uma ator em um caso de uso? 6 - Qual a diferença entre os relacionamentos <<include>> e <<extend>>? 7 - Qual a utilidade do Diagrama de Classes? 8 - Diferencie agregação forte e agregação fraca? 9 - O que representa o Diagrama de Seqüência? 10 - Para que é usado o Diagrama de Estados? TONSIG, S. L. Engenharia de Software Análise e Projeto de Sistemas. Editora Ciência Moderna, 2ª Edição, BEZERRA, E. Princípios da Análise Orientada a Objetos com UML. Editora Campus, 2ª Edição, Pesquisas na WEB Notas de aula