Paradigmas de Análise e Desenvolvimento 06

Prévia do material em texto

Paradigmas de Análise e Desenvolvimento
Aula 06
Análise Orientada à Objeto
Nesta aula, você irá: 
1. Entender um projeto desenvolvido com a técnica de análise orientada a objeto, usando UML. 
2. Entender a UML e sua integração ao contexto de desenvolvimento OO.
3. Aprender a elaborar Diagramas de Caso de uso com suas respectivas especificações.
4. Aprender a elaborar Diagramas de Classes
5. Aprender a elaborar Diagramas de Sequência.
6. Enterder a relação entre o diagrama de Casos de Uso, de Classes e de sequência, que formam a base da análise O.O.
UML no contexto de desenvolvimento de software
1 - Em meados e final da década de 90, a modelagem orientada a objeto ainda contava com diferentes modelos propostos por autores de renome internacional. Surgiu a idéia de unificar esses modelos sob uma única estrutura que na época (1997) foi batizada de UML.
Na medida em que o desenvolvimento orientado a objeto ganha força pelo uso crescente de linguagens de programação OO surge a necessidade de um modelo universal que congregasse o que havia de melhor no mercado.
2 - A UML não é uma metodologia e nem um processo de desenvolvimento. É uma linguagem que permite a construção de uma série de diagramas que, juntos, ajudam no entendimento e modelagem de um sistema orientado a objeto.
A UML pode ser usada em qualquer processo de desenvolvimento de software cuja proposta seja desenvolver um sistema dentro do paradigma orientado a objeto.
3 - A UML não diz por qual diagrama devemos começar a especificação de um sistema. Não especifica obrigatoriedade em ter esse ou aquele diagrama. Nada disso. A forma de fazer e a ordem de uso de cada diagrama previsto fica por conta do processo de desenvolvimento usado e da metodologia de trabalho.
4 - No atual estado da arte a UML está na versão 2.0 e é constituída de 13 diagramas oficiais, sendo 3 novos, 9 oriundos da UML 1.0 e um que teve sua nomenclatura alterada (diagrama de colaboração passou a ser chamado de Diagrama de Comunicação).
Os Diagramas da UML (2.0)
Os 13 diagramas da UML 2.0 estão divididos em Diagramas Estruturais e comportamentais.
- Diagramas Estruturais
Os diagramas estruturais tratam o aspecto estrutural de um sistema de software o que abrangem a existência e a colocação de itens como classes, interfaces, colaborações, componentes.
Diagrama Estrutural UML (2.0)
- Diagramas Comportamentais
Os diagramas de comportamento são voltados a descrever como o sistema responde quando em execução.
Diagrama Comportamental UML (2.0)
Para aprender mais sobre esse assunto, veja a Divisão da UML 2.0 documento 06-01
O Tripé da Análise
- O diagrama de classes mostra as classes do domínio do problema.
- Casos de Uso apresentam especificam o comportamento do sistema (ou parte dele), descrevendo as funcionalidades deste. O caso de uso é um conjunto de cenários, onde
• O cenário é uma seqüência de passos que descreve uma interação entre sistema e um usuário.
• Todo caso de uso tem o Cenário Principal, que é o “caminho sem erros”, ou seja tudo acontece sem nenhum problema ou exceção.
• A cada problema ou exceção pode-se derivar um novo cenário, mostrando como o sistema vai se comportar.
- O diagrama de seqüência mostra a interação entres os objetos (classes) de um determinado cenário.
• Para cada cenário de um caso de uso, teremos um diagrama.
Em contrapartida, o diagrama de seqüência contribui com a descoberta de novas operações, que serão acrescidas nos métodos das classes envolvidas no diagrama de seqüência.
Vamos apresentar os três diagramas de forma prática, mostrando o uso de cada um bem como a integração dos mesmos. Partimos do princípio que todos conhecem os elementos de cada um dos três diagramas como também sabem como construir cada um. Caso sinta necessidade em uma pequena revisão dos diagramas, consulte:
Diagramas de Casos de Uso (documento pdf)
Especificação de Casos de Uso e Caso de Uso: Manter Cliente. (documento pdf)
Conceitos de classes e Diagrama de Classes (documento pdf)
Diagrama de Seqüência. (documento pdf)
Modelo de requisitos
A *UML por não ser uma metodologia e muito menos uma técnica de análise não apresenta organização para o trabalho de análise. Cada empresa implementa a sua metodologia conforme as necessidades específicas. 
A  fase de análise requer a especificação dos requisito, que vamos chamar de Modelo de Requisitos.
*A UML por si só não garante um resultado satisfatório no processo de desenvolvimento do sistema.
Usando a UML vamos definir que o Modelo de Requisitos será composto das seguintes ferramentas:
Diagrama de Casos de Uso (conforme especificações da UML).
Especificações dos Casos de Uso.
Diagrama de caso de uso
O diagrama de Caso de Uso tem por objetivo apresentar:
• As funcionalidades (caso de uso) do sistema, do ponto de vista do usuário.
• Os atores (interface) que interagem com o sistema
• Eventuais relacionamentos entre os casos de uso e entre os atores.
A figura mostra os possíveis relacionamentos entre os casos de uso:
Conforme já citado, o Caso de Uso especifica o comportamento do sistema e descreve a funcionalidade do sistema desempenhada pelos atores.
Analisando apenas o diagrama de Casos de Uso, sabemos quais as funcionalidades do sistema, e como algumas se relacionam, mas não sabemos como efetivamente ocorre cada passo, ou seja, a especificação do caso de uso. A UML não especifica um formato rígido para essa especificação, o que pode ser mais ou menos detalhado dependendo da especificação.
Cabe ressaltar que, dependendo da complexidade, essa especificação pode ser feita, inclusive, por outros diagramas da UML, como o diagrama de sequencia ou diagrama de atividade.
Para maiores detalhes das possíveis formas para especificação dos casos de uso, consulte Especificação de Casos de Uso (doc 06-02).
Na figura (Roteiro de Caso de Uso) apresentamos o formato de especificação que julgamos mais adequado, independente da complexidade do caso de uso.
Toda especificação ou roteiro de caso de uso terá:
• Sempre: um fluxo principal, onde todos os passos acontecem com perfeição, sem nenhum porém ou exceção. Pelo exemplo abaixo, seriam os passos especificados em CENÁRIO PRINCIPAL.
• Opcionalmente: um ou mais passos de fluxos alternativos que são os passos a serem seguidos no caso de falhas dos passos do cenário principal, especificados em CENÁRIOS ALTERNATIVOS.
Atenção: É importante ressaltar que a especificação de caso de uso é mais relevante que o próprio diagrama de Caso de uso, pois é onde especifica-se o que acontece no caso de uso. Observe que não descreve “COMO” e sim “O QUE”.
Pacotes: decomposição de diagramas de casos de uso
Um projeto de software, modelado com UML, geralmente contém apenas um diagrama contemplando todos os casos de uso do sistema. No entanto, para sistemas maiores ou mais complexos, é possível a construção de vários diagramas de casos de uso, elaborados a partir da decomposição de um diagrama principal.
Essa decomposição pode ser elaborada usando o chamado diagrama de pacotes. Um pacote é um elemento de agregação, que não possui uma semântica específica dentro dos projetos. É usado essencialmente para separar ou agrupar elementos do projeto sem criar necessariamente com isso algum vínculo entre os elementos.
Casos de Uso Administrativos Casos de Uso Gerais Casos de Uso Acadêmicos
Com pacotes é possível criar um primeiro diagrama principal contendo todos os pacotes maiores do sistema e, a seguir, explodir cada pacote em um novo diagrama, tal qual fazíamos na explosão do DFD em níveis, com uso da metodologia top-down, de refinamentos sucessivos.
Não há limites de níveis, sendo possível construir uma hierarquia com vários níveis de decomposição conforme a dimensão do sistema e o número de casos de uso e atores.
Os pacotes de um diagrama podem se relacionar, pelo relacionamento da dependência (seta tracejada).
Diagrama de classes
1 - Conforme já dito anteriormente, a UML não especifica a ordem com que os diagramas devam ser modelados. Tal ordem seráespecificada pela metodologia de desenvolvimento que a empresa adotar.
Muitas empresas de desenvolvimento iniciam a modelagem UML pelo Diagrama de Classes. Nada contra. Porém como o Diagrama de Casos de Uso modela os requisitos defendemos a tese de que deva ser elaborado antes do de Classes.
2 - O Diagrama de Classes mostra as classes que constituem o sistema, com os respectivos relacionamentos entre elas, bem como a especificação dos atributos e métodos de cada classe.
O Diagrama de Classes evolui a medida que a projeto avança. Inicialmente, em sua primeira versão, na fase de análise, o diagrama apresenta as classes do negócio (também chamada de entidades) e chama-se Diagrama de Classes Conceitual. É um diagrama compatível com as funcionalidades dos casos de uso, ou seja, mostra a modelagem em classes dos requisitos essenciais do sistema.
3 - Na fase seguinte, de projeto, novas classes podem ser inseridas no Diagrama de Classes, que passa a chamar-se Diagrama de Classes de Projeto. Nesse diagrama são inseridas classes que mostram como será a arquitetura do sistema, surgem as classes de controle, as classes de interface (ou fronteira)  e classes auxiliares (como representação de persistência de dados e et|). Vejamos as principais:
Classe de fronteira (Boundary) ou interface.
Responsável pela interação com os atores. Exemplo: classe para representar um formulário, classe para representar a interface com outro equipamento (uma acionador de cancelas de entrada e saída de veículos, por exemplo)
Classes de controle.
Responsável pela coordenação da interação entre os objetos, na realização de um caso de uso. Em princípio cada caso de uso teria uma classe de controle.
4 - Até mesmo durante a implementação (codificação na linguagem) novas classes podem surgir como classes que implementem determinada característica da linguagem de programação ou determinada forma de programar. É o Diagrama de Classes de Implementação.
5 - Na verdade, embora com diferentes nomenclaturas o Diagrama de Classes é um só, que vai crescendo e sendo alterado a cada fase do ciclo de desenvolvimento. Algumas equipes de projeto podem optar por guardar as versões finais de cada Diagrama, mas a ultima versão guarda todas as alterações feitas.
Podemos usar diferentes níveis de abstração nos Diagramas de Classes.
Diagrama de seqüência
O objetivo do diagrama de seqüência é demonstrar a interação entre os objetos envolvidos na realização de uma cenário (um caso de uso pode conter vários cenários). O nome “seqüência” advém advêm do fato dele descrever, ao longo da linha do tempo, a sequencia de  comunicações entre os objetos.
Um cenário é um conjunto de passos contidos em um caso de uso. Todo caso de  uso terá sempre um cenário principal e possivelmente outros, chamados alternativos, que são variações na execução do caso principal.
As imagens a seguir apresentam exemplos do diagrama de sequencia. Nos dois exemplos, a mensagem de retorno (seta pontilhada) a cada mensage enviada a um objeto é opcional. Muitos evitam usa-la para não poluir o diagrama, uma vez que toda mensagem terá um retorno de execução.
Nas duas imagens, temos exemplos de auto delegação, que ocorre quando uma mensagem é enviada ao próprio objeto:
Gera No. Do Contrato, na figura 12
CalcSubTotal, na figura 13
Saiba mais: estudos de caso
Veja como elaborar, passo a passo, diagramas de Caso de Uso e suas respectivas especificações, (documento 06-03).
 
Para ter acesso a modelagem de Casos de Uso, Diagrama de Classes e de Sequencia, de um Sistema de Controle de Contas Correntes.
Acesse (http://www.labin.unilasalle.edu.br/infoedu/siteinfoedu1_03/trabalhos/sitescc/uml_final/exemplo.htm).
Estudo de caso: sistema hoteleiro
Vamos apresentar na sequência um estudo de caso, que será comentado pelo professor na aula tele transmitida.
Mini mundo do estudo de caso.
Regras do negócio.
Diagrama de Casos de Uso.
Diagrama de Classes.
Diagrama de Sequência (Alguns).
- Mini Mundo
O Sistema de Hotel objetiva automatizar os processos de reserva e locação de quartos para clientes, devendo armazenar os dados dos clientes que reservaram quartos e se hospedaram no hotel. Deve haver controle dos quartos reservados e locados, armazenando os dados de entrada e saída de hóspedes do hotel. No registro da saída, deverá ser cobrada a estadia, cujo valor deverá ficar armazenado no sistema.
O Procedimento de Reserva:
O cliente telefona ou chega ao hotel e solicita a reserva de um quarto, informando período de estada e quantidade de hóspede; 
O atendente verifica de existe quarto disponível no período solicitado. 
Caso afirmativo (há disponibilidade), é feita a reserva do quarto. 
Caso negativo é informado ao cliente a não disponibilidade do quarto. 
Esse procedimento da reserva pode ser feito tanto presencialmente, como por telefone ou ainda pelo site do hotel na Internet.
O Procedimento de Cancelamento da Reserva:
Caso o cliente informe que não tenha mais interesse na reserva, o funcionário providenciará  cancelamento da mesma, disponibilizando o(s)  quarto(s) a ela relacionados.  Esse procedimento de cancelamento da reserva pode ser feito tanto  por telefone como pelo site do hotel.
Quando o cliente não comparecer ao hotel para hospedar-se até as 12:00 horas no dia da reserva, ela deverá ser cancelada, disponibilizando novamente o(s) quarto(s) associado(s).
O Procedimento de Check in (chegada no Hotel):
Quando o cliente ocupar um quarto, previamente reservado, o atendente faz seu registro. Caso o quarto não esteja reservado, uma mensagem de rejeição da ocupação será emitida. Caso contrário, um pacote com informações úteis e a confirmação serão fornecidos ao cliente.
O Procedimento de Check out (saída do hotel):
Quando o cliente deixar o hotel, notificando sua saída, será fornecido a conta, e o quarto será disponibilizado para limpeza;
O Procedimento de Pagamento do Cliente:
O cliente pode pagar a conta à vista ou usar o cartão de crédito. Pode-se  também, no caso de reserva feitas por empresas, emitir uma nota de cobrança contra a empresa;
O Procedimento de Limpeza do Quarto:
Após uma ocupação, um quarto sofrerá o reabastecimento e limpeza, somente após este fato é que o funcionário o torna  disponível para nova locação.
- Diagrama de casos de uso
A figura, mostra uma das possíveis modelagens para o Diagrama de Casos de uso, mostrando as principais funções que serão tratadas pelo Sistema Hoteleiro, de nome VIP_Hotel.
Repare que foi modelada uma herança (generalização/especialização) de atores.
O Ator genérico de nome USUÁRIO representa tanto o ator Cliente como o ator Funcionário.
Diagrama de Caso de Uso do Estudo de Caso
Vamos entender como isso funciona, na prática:
O ator USUÀRIO interage com os casos de uso Efetuar Reserva e Cancelar Reserva, isso significa que tanto o ator Funcionário como o ator Cliente podem interagir com esse caso de uso.  O mini mundo especificado que o cliente pode realizar sua reserva tanto pelo telefone, como internet ou pela sua chegada ao hotel. Nos dois primeiros casos, a interação será com o Cliente e apenas no terceiro caso (presença no hotel) é que a interação será com o Funcionário. O mesmo acontece com Cancelar reserva.
Outro aspecto que merece comentário é o relacionamento de <Extends> entre os casos de uso Cadastrar Cliente e Efetuar Reserva. Por que o <extends>?
Simples, nem sempre que uma reserva for efetuada o novo hóspede (Cliente) será cadastrado. Somente no caso de um novo cliente é que o cadastro será feito, nos demais casos não, pois já haverá esse registro do cliente (Hóspede).
Já no relacionamento entre os casos de uso Registrar Saída e Registrar pagamento, há uma obrigatoriedade, ou seja, sempre que houver uma saída (check out) de cliente (hóspede), haverá um registro de pagamento do mesmo. A teoria nos ensina que em casos de uso que são inclusão (<Uses>) só devem sê-lo quando pelo menos dois casos de uso o utilizam; mas nesse caso apenas 1 caso de uso o esta usando. Isso é errado? 
Não, essa modelagem foi usadanesse caso, pois é muito importante separar as funcionalidades e mostrar que são casos de uso distintos, porém um (registrar pagamento) depende do outro (registrar saída).
Diagrama de classes
Com base nos diagramas de caso de uso, serão identificadas as classes de negócio (ou entidades) e comerá a ser desenhado o Diagrama de Classes Conceitual. 
A seguir uma tabela onde destacamos as classes identificadas em cada Caso de Uso.
Passo 1: Identificação das Classes nos casos de uso
O segundo passo é identificar os atributos (dados) e métodos (procedimentos) que podem ser identificados pelo enunciado (mini mundo).
Passo 2: Identificação dos atributos e métodos no mini mundo
Bom, agora é desenhar as classes com os atributos e métodos. Repare que até o momento são apenas classes de negócio (entidade).
Passo 3: Identificação dos relacionamentos
Diagrama de Classe de Negócio
Passo 4 : Cardinalidade dos relacionamento
Diagrama de Classe de Negócio com cardinalidade
Diagrama de sequência
O Diagrama de Sequência deve ser elaborado para cada cenário de uso. Como assim?
Para elaborar o diagrama de sequência é fundamental que tenhamos em mãos a especificação do caso de uso. Como nenhum foi elaborado agora, vamos fazer a especificação do caso de Uso Efetuar Reserva.
Como já mencionado, o diagrama de sequência deve ser elaborado para cada cenário de uso, caracterizado como sendo um caminho a ser seguido no roteiro (especificação) do caso de uso. Para o caso de uso Efetuar Reserva, temos 3 cenários: O cenário principal (caso perfeito), O cenário Cliente não cadastrado e o Cenário Não há disponibilidade.
Observe que todas as mensagens que chegam das Classes de Negócio (Entidade) são métodos das respectivas classes. Se olharmos o diagrama de sequência, vamos constatar que “Verifica_Existencia_Cliente e “Verificar Disponib” são métodos que não existem em Cliente e Quarto respectivamente.
Eureka!
Essa é a grande finalidade do Diagrama de Sequencia: identificar novos métodos para as classes.
Completa-se o ciclo do “tripé da análise”.
Exercitando
Sugerimos que desenvolva as especifações de cada caso de uso e elebore os respectivos diagrama de sequencia para os cenários de uso identificados.
Sugerimos o acesso aos seguintes sites, referentes aos conceitos e práticas inerentes a técnica de Analise Essencial para desenvolvimento de sistemas.
 
Procure explorar todos os links existentes nas URLs abaixo relacionadas.
 
http://www.malima.com.br/article_read.asp?id=39
 
http://www.ufpa.br/cdesouza/teaching/es/6-use-cases.pdf
 
http://www.fca.pt/docs-online/722-636-8_des_sis_inf.pdf
 
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/classes/classes1.htm
Nesta aula, você: 
Entendeu um projeto desenvolvido com a técnica de análise orientada a objeto, usando UML.
Entendeu a UML e sua integração ao contexto de desenvolvimento OO
Aprendeu a elaborar Diagramas de Caso de uso com suas respectivas especificações.
Aprendeu a elaborar Diagramas de Classes
Aprendeu a elaborar Diagramas de Sequência.
Enterdeu a relação entre o diagrama de Casos de Uso, de Classes e de sequência, que formam a base da análise O.O.
Na próxima aula, abordaremos os seguintes assuntos: 
Diagrama de Estados.
Diagrama de Atividades.
Respostas: 3, 4, 1, 3, 1