8. Análise e projeto orientados a objetos e UML (casos de uso) 8 8. Análise e projeto orientados a objetos e UML (casos de uso) 8.1 A junção da análise orientada a objetos com a UML e com outros métodos 8.2 Casos de uso Objetivo: compreender os acréscimos dados a análise orientada a objetos e aplicar casos de uso em UML

8.1 A junção da análise orientada a objetos com a UML e com outros métodos UML (unified modeling language) é uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software É um padrão aceito para a indústria para a modelagem orientada a objetos Resultou de um esforço conjunto de três autores e da aceitação da OMG (object management group) Grady Booch Jim Rumbaugh Ivar Jacobson http://www.omg.org UML tem ao menos dez/treze notações/diagramas e é voltada para modelar e não para dizer como fazer uma análise ou projeto

Atualizações em UML estão em http://www.omg.org/tecnology/documents/formal/uml UML 1.X UML 2.0 Atividade Caso de uso Classe Objetos Sequência Colaboração Comunicação Estado Pacotes Componentes Instalação Implantação Interação – Visão geral Timing Composite structure diagram

É importante compreender que a UML surgiu como uma linguagem que integrava a modelagem orientada a objetos com outras notações UML também não é orientação a objetos em si Razões do que é hoje UML I) Padronização e mudanças de metodologias e notações II) Resposta aos velhos problemas do software De uma maneira geral, transposição do modelo em cascata para um processo unificado

De uma maneira mais específica, um conjunto de fatos históricos que resultaram na união dos “três amigos”

Como estabeleceremos nossa metodologia de desenvolvimento? PERGUNTA CRUCIAL: Como estabeleceremos nossa metodologia de desenvolvimento? RUP? XP? ICONIX? AM? Remendos de outras metodologias, hibridismos, ecletismos? E as questões para a Web? E as questões de hoje sobre software livre? Há questões específicas, por exemplo, para o desenvolvimento de produtos educacionais? Etc, etc e etc

Além da padronização e mudanças de metodologias e notações dos “três amigos” atender um apelo comercial, há razões para esta padronização que dizem respeito II) aos velhos problemas do software… 1) O software não apresenta a mesma constância que em outras áreas 2) A “burrice” do usuário X a “burrice” de não entender que os requisitos de software sofrem mudanças

Na concepção do software – o usuário pode ter certa uma necessidade, mas a forma de resolver ou atender a necessidade não tem um formato definido Na área civil, o engenheiro pode delimitar a medida e as possibilidades de terreno em um formato definido Na aprovação da concepção – o usuário requer conhecimento específico sobre as modelagens e outras questões que lhe formos remeter, mesmo se for da área de informática, para amadurecer sua idéia inicial Na área civil, ele vê a planta sabendo o que é uma parede No detalhamento das necessidades – após às funcionalidades escritas a própria equipe de desenvolvimento descobre suas inconsistências Na área civil, isso simplesmente não acontece

No início da construção – a idéia de como atender a necessidade muda a partir de um formato Na área civil, geralmente os requisitos simplesmente não mudam (já imaginou quebrar as paredes de um quarto porque se viu que uma cama de casal não cabia?) Nos testes – problemas podem ocorrer pelo fato de o usuário não participar e até haver a demissão anterior de um elemento da equipe Na área civil, o usuário normalmente visita a obra periodicamente e a demisão de um trabalhador não afeta que outro continue o mesmo trabalho Na entrega – normalmente, o usário diz “não era bem isso que eu queria” ou pede mais uma modificação O que representaria tal frase depois de uma casa entregue?

3) Não há uma forma CORRETA de construir software, pois esta construção depende de vários fatores atuando em conjunto: Conhecimento do negócio a ser modelado Conhecimento da tecnologia a ser utilizada Capacidade de abstração do usuário Capacidade de abstração do desenvolvedor Dinheiro e outros recursos… 4) Relações MODELAGEM X REALIDADE 5) Intangibilidade 6) Condições de automatizar algo que já tem em pleno vigor (problema para os casos de uso, ver adiante!) 7) Má formação profissional em informática (ver o profissional dos casos de uso – o analista de negócios – adiante!)

8.2 Casos de uso O caso de uso é a mais importante construção de orientação a objetos, utilizando UML Acompanha do início ao fim da conclusão Acontece em todas as iterações Conceitos importantes: Ator É uma pessoa, um sistema, uma entidade externa, um roteador Representa um determinado papel

Caso de uso Macroatividade que encerra diversas tarefas ou atividades Ex.: Pagamento de compras Atividades – mostrar e validar cartão, informar valor debitado, informar senha que permite o débito, validar senha, retorno da instituição financeira, resumo da operação Ex.: imprimir nota fiscal O limite de um caso de uso é uma decisão pessoal

Quanto um caso de uso deve ser descrito? Com bastantes detalhes Com objetividade que não sacrifique a composição do detalhe Aplicado a partir de abstrações Quem faz a extração dos casos de uso? Um profisional habilitado em análise de negócios Métodos usados Observação Entrevista Perfil do profissional de casos de uso: Boa capacidade de comunicação interpessoal # de extrovertido Com capacidade de ouvir # escutar Capacidade de escrever o que ouviu Bom relacionamento interpessoal Cultura geral

Como extrair casos de uso? Sugestão de estrutura de caso de uso Nome referência: AB200501 – Nome do caso de uso Verbo no infinitivo (informar, comprar, pagar) Breve descritivo Informar o que trata o caso de uso Pré-condições Descrição que informa o que é necessário para que este caso de uso se inicie Atores envolvidos Cenário principal Descrição do mundo perfeito, sem exceções (presente do indicativo e substantivos) Cenário alternativo Requisitos especiais Dados Observação Analista de negócio:___________________________________ Entrevistado:________________________________________ Área:_______________________________________________ Data:___/___/___ Versão:

Como lidar com as mudanças de requisito nos casos de uso? Entender que requisito é uma condição ou capacidade que um software deve ter Entender que mudança de requisito não é mudança do negócio Essas implicam não só novos modelos, mas novos documentos, novos prazos e novos preços Dependerá de uma avaliação coletiva e da comunicação entre os stakeholders Quem e como é aprovado um caso de uso? Em primeiro lugar, seu colega Por qualquer meio Nunca, caso de uso um a um

Modelar “o que é” ou “como será”? Se o negócio existir e se desejar levar ele para a Internet, retratar “como é” Se o usuário disser que gostaria de modelar “diferente”, modele “como será” Enfim, pense como um analista de objetos Como acompanhar o progresso dos casos de uso? Reuniões quinzenais ou mensais O que usar, além da forma escrita? Gráficos, organogramas e uma notação padrão adiante

Notação gráfica para casos de uso

Exemplo1 – Locadora de DVD (alguns problemas)

Exemplo 2 – Posto de vendas (problema típico)

Exemplo 3 – Operações bancárias (incluir a descrição)