Aula 06

Prévia do material em texto

Aula 06
 Análise Orientada a Objeto (Parte I)
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.
Diagrama 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 comportamentais
Os diagramas de comportamento são voltados a descrever como o sistema responde quando em execução.
O Tripé da Análise
Diagrama de Classe: O diagrama de classes mostra as classes do domínio 
do problema.
Caso de uso: 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 sequê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.
Diagrama de Sequencia: O diagrama de sequê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 sequência contribui com a descoberta de novas operações, que serão acrescidas nos métodos das classes envolvidas no diagrama de sequê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:
Diagrama de Casos de Uso.
Especificação de Casos de Uso e Caso de Uso: Manter Cliente.
Conceitos de classes e Diagrama de Classes
Diagrama de Sequencia.
Modelo de requisitos
A UML por não ser uma metodologia e muito menos uma tecnica 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.
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 digrama 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.
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.
OBS: É 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”.
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.
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).
DICA
A figura  (Diagrama de pacotes) mostra o exemplo de um diagrama de pacotes e o relacionamento de dependência entre eles.
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 diagramacompatí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.
O Diagrama de Classes representado na figura é o Conceitual
O modelo conceitual é elaborado na fase de Análise. Na fase seguinte, a de projeto, pensa-se, como já sabemos, na arquitetura da aplicação e precisamos começar a pensar nos princípios de coesão e acoplamento, adicionamos as classes de controle agregamos alguns modelos de projeto e pensamos na interface usuário-sistema.
A figura, apresenta um modelo inicial e genérico de como seria o diagrama de classes de projeto, incluindo as classes de Interface (boundary) e de controle (control).
Diagrama de  Classes de ProjetoII
Diagrama de Sequencia 
O objetivo do diagrama de sequê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
Diagrama de caso de uso do estudo do caso
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.
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 usada nesse 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.
Passo 2: Identificação dos atributos e métodos no mini mundo.
Passo 3: Identificação dos relacionamentos.
Passo 4 : Cardinalidade dos relacionamento.
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.
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”.
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