Análise e Projetos de Sistemas Orientados a Objetos

1. Análise e Projetos de Sistemas Orientados a Objetos Prof. André Argeri andreargeri@hotmail.com Ribeirão Preto, Fevereiro 2010

2. Apresentação da Disciplina Conteúdo Programático: • O que é a UML? • Histórico UML • Princípios da modelagem • Orientação a Objetos • Ferramentas CASE baseadas na linguagem UML • Diagramas

3. Apresentação da Disciplina • Objetivo Geral • Conhecer e desenvolver todos diagramas da UML.

4. Apresentação da Disciplina • Bibliografia: • BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usuário (2ª Edição). Rio de Janeiro: Elsevier, 2005. • Guedes, G.T.A. UML 2 Guia de Consulta Rápida (2ª Edição). São Paulo: Notatec, 2005. • Pilone, D.; Pitman, N. UML 2 Rápido e Prático. Alta Books, 2006.

5. O que é a UML? • UML – Unified Modeling Language ou Linguagem de Modelagem Unificada. • Linguagem altamente adotada mundialmente pela indústria de Engenharia de Software. • Não é linguagem de programação. • O objetivo dela é auxiliar todas as pessoas que estão envolvidas no projeto.

6. Características da UML • Requisitos. • Comportamento. • Estrutura lógica. • Dinâmica de seus processos. • Até necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. Importante: Todas essas características são definidas por meio da UML antes do software começar a ser realmente desenvolvido.

7. Histórico da UML • União de três metodologias: • Método Booch. • Método OMT (Object Modeling Techinique) – Jacobson. • Método OOSE (Object Oriented Software Engineering) – Rumbaugh. Estas eram as metodologias usadas até meados da década de 90.

8. Histórico da UML • O esforço inicial do projeto iniciou com a União do método de Booch com o método OMT de Jacobson, o que resultou no lançamento do método Unificado no final de 95. Logo em seguida, juntou-se Rumbaugh com o método OOSE que começou a ser incorporado à nova tecnologia. • Em 96 foi lançada a primeira versão da UML.

9. Histórico da UML • Tão logo a primeira versão foi lançada, diversas grandes empresas atuantes na área de engenharia e desenvolvimento de software passaram a contribuir com o projeto, fornecendo sugestões para melhorar e ampliar a linguagem.

10. Princípios da modelagem • 1º - A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida; • 2º - Cada modelo poderá ser expresso em diferentes níveis de precisão;

11. Princípios da modelagem • 3º - Os melhores modelos estão relacionados à realidade; • 4º - Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes com vários pontos de vista.

12. Orientação a Objetos • O método orientado a objetos para o desenvolvimento do software é, com certeza, uma parte do fluxo principal, simplesmente porque tem sido provado seu valor para a construção de sistemas em todos os tipos de domínios de problemas, abrangendo todos os graus de tamanho e de complexidade. Alem disso, muitas linguagens, sistemas operacionais e ferramentas contemporâneos são, de alguma forma, orientados a objetos, fortalecendo a visão de mundo em termos de objetos.

13. UML é uma Linguagem para documentação Requisitos Arquitetura Projeto Código fonte Planos de projetos Testes Prototipos

14. Ferramentas CASE baseadas na linguagem UML • Ferramentas CASE (computer aided software engineering ou engenharia de software auxiliada por computador, são softwares que de alguma maneira colaboram para a execução de uma ou mais atividades realizadas durante o processo de engenharia de software.

15. Exemplos de Ferramentas • Rational Rose • Enterprise Architect • Visual Paradigm for UML ou VP-UML • Poseidon for UML • ArgoUML • Jude • Entre outros.

16. Diagramas • Diagrama de Classes • Diagrama de Objetos • Diagrama de componentes • Diagrama de estruturas compostas • Diagrama de caso de uso • Diagrama de seqüências • Diagrama de comunicações

17. Diagramas • Diagrama de gráficos de estados • Diagrama de atividades • Diagrama de implantação • Diagrama de pacote • Diagrama de temporização • Diagrama de visão geral de interação No total são 13 diagramas.

18. Diagrama de caso de uso • Este diagrama procura, por meio de uma linguagem simples, demonstrar o comportamento externo do sistema, procurando apresentar o sistema através de uma perspectiva do usuário, demonstrando as funções e serviços oferecidos e quais usuários poderão utilizar cada serviço.

19. Diagrama de caso de uso • Este diagrama é, dentre todos os diagramas da UML, o mais abstrato, flexível e informal, sendo utilizado principalmente no inicio da modelagem do sistema, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros programas.

20. Diagrama de caso de usoAtores (Bonecos Magros) • Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar ou interagir com os serviços e funções do sistema. Eventualmente um ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Ele possuem uma breve descrição logo abaixo do seu símbolo que identifica o papel que o autor assume dentro do diagrama

21. Diagrama de caso de usoCasos de Uso • Os casos de uso referem-se aos serviços, tarefas ou funções oferecidas pelo sistema, como emitir um relatório ou cadastrar a venda de algum produto. São utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema.

22. Diagrama de caso de usoCasos de Uso • Os casos de uso costumam ser documentados , demonstrando qual o comportamento pretendido para o caso de uso em questão e quais funções ele executará quando for solicitado.

23. Diagrama de caso de usoCasos de Uso. • Nome do caso de uso • Objetivo • Atores • Passos

24. Diagrama de caso de usoCasos de Uso. • Exemplo da descrição do caso de uso: • Nome: Visualizar Notas e faltas. • Objetivo: Listar para o aluno as suas respectivas informações. • Ator: Aluno. • Passos • 1 – O ator entra com o seu numero de matricula e senha. • 2 – O sistema Lista os períodos. • 3 – O ator seleciona o período desejado • 4 – O sistema lista as informações para o ator.

25. Diagrama de caso de usoCasos de Uso. • Restrições • 1.1 – O sistema verifica se o nome o número de matricula está correto, caso negativo, o sistema bloqueia a entrada no sistema e exibe mensagem. • 1.2 – O sistema verifica se a senha condiz com o número de matricula, caso negativo, o sistema bloqueia a entrada do sistema e exibe mensagem. • 3.1 – O ator não seleciona o período, o sistema solicita o preenchimento do mesmo.

26. Diagrama de caso de usoAssociações. • As associações representam os relacionamentos entre os atores que interagem com o sistema, entre os atores e os casos de uso. Relacionamentos entre os casos de uso recebem nomes especiais, como inclusão, extensão e generalização.

27. Diagrama de caso de usoAssociações. • Uma associação entre um ator e um caso de uso demonstra que o ator utiliza-se, de alguma maneira, da função representada pelo caso de uso. A associação entre um ator e um caso de uso é representado por uma reta ligando o ator com o caso de uso, podendo ocorrer que as extremidades da reta contenham setas, indicando a navegabilidade da associação, ou seja, se as informações são fornecidas pelo autor ao caso de uso, se não transmitidas do caso de uso para o autor ou ambos (neste ultimo caso a reta não possui setas).

28. Diagrama de caso de usoEspecialização / Generalização • Este relacionamento é uma forma de associações entre casos de uso na qual existem dois ou mais casos de uso com características semelhantes, apresentando pequenas diferenças entre si.

29. Diagrama de caso de usoEspecialização / Generalização • Quando tal situação ocorre, costuma-se definir um caso de uso geral, que descreve as características compartilhadas por todos os casos de uso em questão, e então relacioná-lo com estes, cuja documentação conterá somente as características específicas de cada um. Assim não é necessário colocar a mesma documentação para todos os casos de uso envolvidos, porque toda a estrutura de um caso de uso generalizado é herdada pelos casos de uso especializados, incluindo quaisquer possíveis associações.

30. Diagrama de caso de usoInclusão (include) • Esta associação é utilizada quando existe um situação ou rotina comum a mais de uma caso de uso. Quando ocorre, a documentação dessa rotina é colocada em caso de uso específico para que outros caso de uso utilizem-se desse serviço, evitando-se descrever uma mesma seqüência de passos em vários casos de uso.

31. Diagrama de caso de usoInclusão (include) • Os relacionamentos de inclusão indicam uma obrigatoriedade, ou seja, quando um determinado caso de uso possui um relacionamento de inclusão com outro, a execução do primeiro obriga também a execução do segundo. Um relacionamento de inclusão pode ser comparado à chamada de uma sub-rotina.

32. Diagrama de caso de usoInclusão (include) • Exemplo

33. Diagrama de caso de usoExtensão (extend) • Esta associação é utilizada para descrever cenários opcionais de um caso de uso, que somente ocorrerão se uma determinada condição for satisfeita. As associações de extensão possuem uma representação muito semelhante às associações de inclusão, sendo também representados por uma linha tracejada.

34. Diagrama de caso de usoExtensão (extend) • Exemplo

35. Diagrama de caso de usoMultiplicidade • A multiplicidade em uma associação entre um ator e um caso de uso basicamente especifica o número de vezes que um ator pode utilizar um determinado caso de uso.

36. Diagrama de caso de usoFronteira do Sistema • Um fronteira do sistema identifica um classificador que contém um conjunto de casos de uso. Uma fronteira de sistema permite identificar um sub-sistema ou mesmo um sistema completo, além de destacar o que está contido no sistema e o que não está.

37. Diagrama de caso de usoExercício Fazer o diagrama de caso de uso referente ao atendimento do paciente: • O atendimento começa quando o paciente chega e avisa o atendente de sua chegada. • O atendente por sua vez entra no sistema e marca que o paciente já está pronto para a consulta. • O medico faz a consulta e pode pedir exames e receitar medicamentos, após a consulta o paciente pode solicitar o retorno. • Ao finalizar o atendimento o médico seleciona o próximo paciente da lista dos presentes. • Descrever o caso de uso para a Consulta do paciente

38. Diagrama de caso de usoExercício • Monte um caso de uso para uma oficina mecânica, segue os dados: • O cliente, conta todos os problemas pertinentes com o veículo. • O atendente adiciona cada item que o cliente está solicitando para fazer a Ordem de Serviço. • O mecânico vai imprimir os problemas que o cliente reclamou e começa a verificar o veículo.

39. Diagrama de caso de usoExercício (Cont) • Após as constatações efetuadas o mecânico entra com as informações sobre o serviço a ser executado. • O atendente verifica quais orçamentos podem ser passados para o cliente. • O cliente pode solicitar que nada seja feito ou efetuar o concerto total ou parcial . • O atendente passa um prazo para o cliente buscar seu veículo. • Ao chegar a oficina o cliente vai efetuar o pagamento no caixa, para liberar seu veículo.

40. Diagrama de caso de usoExercício

41. Diagrama de caso de usoExercício

42. Diagrama de Classe • O diagrama de classe é o diagrama mais utilizado na UML. Se objetivo é permitir a visualização das classes utilizadas pelo sistema e como estas se relacionam. Esse diagrama apresenta uma visão estática de como suas classes estão organizadas, preocupando-se em definir sua estrutura lógica.

43. Diagrama de Classe • Um diagrama de classe pode ser utilizado para modelar o modelo lógico de um banco de dados, quando se assemelha aos antigos Modelos- Entidade-Relacionamento. Na verdade o diagrama de classe foi propositalmente projetado para ser uma evolução do MER.

44. Diagrama de Classe • No entanto deve ficar bem claro que o diagrama de classe não é utilizado unicamente para a modelagem de modelos lógicos e banco de dados e mais importante, que uma classe não corresponde a uma tabela.

45. Diagrama de ClasseRelacionamentos ou Associações • As classes costumam possuir relacionamentos entre si, chamados associações que as permitem compartilhar informações e colaborarem para a execução dos processos executados pelo sistema. Uma associação descreve um vínculo que ocorre normalmente entre os objetos de uma ou mais classes.

46. Diagrama de ClasseExemplo Nome da classe Atributos Métodos

47. Diagrama de ClasseRelacionamentos ou Associações • As associações são representadas por retas ligando as classes envolvidas, podendo também possuir setas em suas extremidades para indicar a navegabilidade da associação, o que representa o sentido em que as informações são transmitidas entre os objetos das classes envolvidas.

48. Diagrama de ClasseAssociação Unária • Este tipo de associação ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe.

49. Diagrama de ClasseAssociação Binária • Associações binárias ocorrem quando são identificados relacionamentos entre objetos de duas classes.

50. Diagrama de ClasseAssociação Ternária ou N-ária • Associações ternárias ou N-árias são associações que conectam objetos de mais de duas classes. São representadas por um losângulo para onde convergem todas as ligações da associação.