Análise e Projeto de Software Parte I. Marcos Dósea

Transcrição

1 Análise e Projeto de Software Parte I Marcos Dósea marcosdosea@gmail.com

2 Agenda Apresentação do professor Apresentação da disciplina Metodologia e avaliação

3 Apresentação do professor Marcos Barbosa Dósea

4 Currículo Formação: Formado em Ciência da computação Mestre em Engenharia de Software e Linguagens de Programação Certificado Java 5. Experiência: 1 ano como Analista de Sistemas e suporte à Equipe de Desenvolvimento na Plataforma Java EE na Secretaria de Estado da Fazenda de Sergipe. 2 anos na Qualiti Software Processes como consultor na área de arquitetura de software, análise e projeto de sistemas e melhoria e implantação de processos de desenvolvimento de software. Consultor na suíte de ferramentas da IBM Rational. Professor em Disciplinas de Pós-Graduação em Gerência de Projetos e Engenharia de Software. Consultor do Centro de Processamento de Dados da Universidade Federal de Sergipe. Professor da Universidade Federal de Sergipe.

5 Contatos para atendimento: Telefone: (79)

6 Apresentação da disciplina Análise e Projeto de Software

7 Característica da disciplina Nome: Análise e Projeto de Software Carga horária: 20 horas/aula Datas: 06/11 e 20/11 Horário: 08:00 às 12:00h e 13:00 às 17:00h Intervalos: 10:00h e 15:00h (15 minutos)

8 Objetivo da disciplina Proporcionar ao aluno um conhecimento amplo das principais técnicas e ferramentas que podem ser utilizadas para realizar análise e projeto de software Orientado à Objetos.

9 Ementa Princípios da Orientação a Objetos. Classes, Objetos, Encapsulamento, Herança, Agregação e Composição; Modelagem Orientada a Objetos. Diagramas UML. Análise de Software Orientada a Objetos. Projeto de Arquitetura de Software Projeto de Software Projeto de Banco de Dados Padrões de desenho (Design Patterns).

10 Divisão da ementa PARTE I: Diagrama de Classes; Diagramas de Interação; Análise e Projeto de Software; PARTE II: Análise de Software Orientado à Objetos; Projeto da Arquitetura; Projeto de Software Orientado à Objetos;

11 Divisão da ementa PARTE III: Arquitetura de Software; Projeto de Software Orientado à Objetos (continuação) Projeto de Banco de Dados Padrões de Projeto Orientado à Objetos

12 Bibliografia FILHO, Wilson de Pádua Paula. Engenharia de Software: Fundamentos, Métodos e Padrões. 2. ed. São Paulo: LTC, SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson, PRESSMAN, R. S. Engenharia de Software. 5. ed. São Paulo: MCGraw-Hill, 2006.

13 Bibliografia Rational IBM. RUP (Rational Unified Process). Disponível em: m. Acesso em: 15/09/2009. FOWLER, Martin. UML Essencial. 3. ed. São Paulo: Bookman, LARMAN, Craig. Utilizando UML e Padrões. 3. ed. São Paulo: Bookman, 2007.

14 Metodologia e avaliação

15 Metodologia e avaliação Aulas expositivas; Dinâmicas e atividades em grupo; Os alunos serão avaliados da seguinte forma: Participação em sala de aula (Presença + Participação) 2,0; Estudo de caso 8,0;

16 Cronograma de aulas Aula Data Turno Assunto 1 6/11 manhã 01 - Apresentação da Disciplina 1 6/11 manhã 02 - Diagrama de Classes 2 6/11 manhã 03 - Diagrama de Interação 2 6/11 manhã 04 - Introdução à Análise e Projeto de Software OO 2 6/11 manhã Estudo de Caso: Criando diagramas de classe e interação 3 6/11 tarde 05 - Análise de Software OO 4 6/11 tarde 06 - Projeto da Arquitetura 4 6/11 tarde 07 - Projeto de Software OO 4 6/11 tarde Estudo de Caso: Criando modelo de análise e projeto 5 20/11 manhã Revisão 5 20/11 manhã 09 - Arquitetura de Software 6 20/11 manhã 10 - Projeto de Software OO (continuação) 6 20/11 manhã 11 - Projeto de Banco de Dados 6 20/11 manhã Estudo de Caso: Projetando o Banco de Dados 7 20/11 tarde 12 - Padrões de Projeto 8 20/11 tarde Apresentação do trabalho

17 Dúvidas

18 Agenda Aula I Motivação Diagrama de Classes

19 Motivação Marcos Dósea

20 O que é análise e projeto?

21 Qual a importância?

22 Por onde começar? Visão do Sistema Modelagem de Negócio Requisitos Análise Projeto Implementação

23 Por que fazer visualmente? Vamos arrumar a estante... Geografia Física História / Inglês Matemática Física Estatística Biologia

24 Diagrama de Classes Marcos Dósea

25 Agenda Diagrama de Classes Características Classes Interfaces Relacionamentos Esteriótipos Quando construir? Análise Projeto

26 Características Mais importante e o mais utilizado diagrama da UML. Exibe as classes que irão compor o sistema com seus respectivos métodos, atributos e relacionamentos. Visão estática da organização das classes.

27 Características Pode ser utilizado para modelar classes persistentes. Intencionalmente projetado para ser uma evolução do modelo Entidade- Relacionamento.

28 Classes Podem possuir atributos e métodos. Não se preocupam com os passos que devem ser percorridos pelos métodos. Possui 3 divisões não obrigatórias: Nome da Classe Atributos e seus tipos de dados. Métodos. Cliente -cpf: long #endereco: String ~nome: String +validar(cpf: long): boolean

29 Classes Visibilidade dos Atributos e Métodos Privada (-) Protegida (#) Pacote (~) Pública (+) Cliente -cpf: long #endereco: String ~nome: String +validar(cpf: long): boolean

30 Classes Podemos visualizar ainda... Tipo dos atributos e argumentos. Retorno dos métodos. Valor padrão dos atributos quando criados. Cliente -cpf: long #endereco: String ~nome: String -emdebito: boolean = false +validar(cpf: long): boolean Tipo dos atributos Valor padrão Tipo dos argumentos Retorno do método

31 Classes Atributos e Operações de Instância e Estáticos A única diferença na representação é que os estáticos ficam sublinhados. Cliente -cpf: long #endereco: String ~nome: String -emdebito: boolean = false +validar(cpf: long): boolean Cliente -cpf: long #endereco: String ~nome: String -emdebito: boolean = false +validar(cpf: long): boolean Instância Estático

32 Classes Classe Concreta e Abstrata Única diferença é o estilo da fonte da classe abstrata que fica em itálico. Pessoa Pessoa Concreta Abstrata

33 Vamos pensar um pouco... Qual seria o melhor nível de visibilidade para os atributos de uma classe? Qual o objetivo de uma classe abstrata?

34 Interfaces Duas representações: Fachada <<interface>> Fachada

35 Diagrama de Classes Relacionamentos Associações Especialização / Generalização Dependência Realização

36 Relacionamentos Associações Descreve o vínculo que ocorre entre classes. Instâncias das classes ligadas às instâncias de outras classes para troca de informações, utilização de métodos, etc. São representadas por retas ligando as classes envolvidas. Navegabilidade não é obrigatória e representa o fluxo das informações. É bom dar um nome para associação quando não estiver implícita.

37 Relacionamentos Associações Multiplicidade 0..1 : No mínimo 0 no máximo : Um e somente um. 0..* : No mínimo nenhum e no máximo muitos. 1..* : No mínimo 1 no máximo muitos. 3..5: No mínimo 3 no máximo 5.

38 Relacionamentos Associações Associação Unária ou Reflexiva Associação Multiplicidade Papel

39 Relacionamentos Associações Associação Binária

40 Relacionamentos Associações Agregação Objeto-todo é composto por vários objetos-parte. Objetos-parte podem existir sem um objeto-todo. Significado contém, faz parte de, é constituído por Equipe 0..1 * Jogador A equipe é constuída por n jogadores. Os objetos-parte (jogadores) podem existir sem o objeto-todo (equipe), por isso a multiplicidade do relacionamento 0..1.

41 Relacionamentos Associações Composição É uma agregação com uma restrição mais forte. Objetos-Parte pertencem exclusivamente a um Objeto-Todo. São criados e destruídos juntos. Pedido * ItemPedido 1 O pedido é constituído por vários itens do pedido. Os objetos-parte (ItemPedido) não podem existir sem o objeto-todo (Pedido), por isso a multiplicidade do relacionamento é 1.

42 Outros exemplos... Qual o tipo de associação existente entre as entidades turma e aluno? Qual o tipo de associação existente entre as entidades filme e atores?

43 Diagrama de Classes Relacionamentos Associações Especialização / Generalização Dependência Realização

44 Relacionamentos Especialização / Generalização Relação semântica é um ou é uma. A subclasse herda atributos e operações da super classe, podendo adicionar outras.

45 Diagrama de Classes Relacionamentos Associações Especialização / Generalização Dependência Realização

46 Relacionamentos Dependência Objetos de um classe usam serviços de objetos de outra classe. Muito úteis para gestão de dependências. Cliente Servidor

47 Diagrama de Classes Relacionamentos Associações Especialização / Generalização Dependência Realização

48 Relacionamentos Realização Um elemento (classe) implementa as operações especificadas por outro elemento (interface). A classe String implementa a interface Hashtable A classe String implementa a interface Comparable

49 Classes Associativas São classes que estão ligadas a associações, em vez de estarem ligadas a outras classes. Também chamadas classes de associação. Comum entre associações de conectivade muitos para muitos, mas podem aparecer em relacionamentos de qualquer conectividade.

50 Classes Associativas Exemplo Emprego +salario +datacontratacao Classe associativa Pessoa +nome +telefone +endereco +empregado * contrata +empregador * Empresa +razaosocial +endereco Papel na associação

51 Outros exemplos... Como ficaria o relacionamento das entidades Venda e Produto? Como ficaria o relacionamento das entidades pessoa e filme?

52 Esteriótipos Mecanismos de extensibilidade da UML. Bastante utilizado para gerar código. Ex: << EJB >> Nos diagramas de classes podem ser usados nas: Classes Métodos Atributos

53 Esteriótipos Exemplos Esteriótipos de Classes << file >> : denota o arquivo físico << library >> : bliblioteca de arquivos. << table >> : denota uma tabela do banco de dados. << thread >>: representa uma thread Exemplos Esteriótipos de Métodos << create >>: cria uma instância da classe. << destroy >>: destrói uma instância de classe.

54 Esteriótipos Exemplos <<table>> Pessoa +nome +telefone +endereco +nome +telefone +endereco Pessoa <<create>>+criar()

55 Agenda Diagrama de Classes Características Classes Interfaces Relacionamentos Esteriótipos Quando construir? Análise Projeto

56 Quando construir? Modelo de Casos de Uso Diagramas de Seqüência Diagramas de Colaboração Diagrama de Componentes Modelo de Análise e Projeto Visão de Casos de Uso Diagramas de Classes de Projeto Visão Lógica + Diagrama de Distribuição Visão de Processos + Visão de Distribuição

57 Classes de Análise Tipos de Classes de Análise fronteira ( <<boundary>> ) Controle ( <<control>> ) Entidade ( <<entity>> ) Estes estereótipos são uma conveniência de análise que desaparecem no projeto

58 Classes de Análise Exemplo: <<boundary>> TelaLogin efetuarlogin() 0..n 1 <<control>> ControladorLogin efetuarlogin() 1 1 <<en tity col lectio n>> CadastroContas existecon ta() 0..n <<entity>> Conta login senha

59 Quando construir? Modelo de Casos de Uso Diagramas de Seqüência Diagramas de Colaboração Diagrama de Componentes Modelo de Análise e Projeto Visão de Casos de Uso Diagramas de Classes de Projeto Visão Lógica + Diagrama de Distribuição Visão de Processos + Visão de Distribuição

60 Perspectivas no Projeto Conceitual Classe interpretada como um conceito. Apenas classes e atributos são utilizados. Especificação Principais interfaces e métodos. Prover maior entendimentos da arquitetura. Implementação Especificação é detalhada. Visibilidades, parâmetros tipos são adicionados.

61 Perspectiva Conceitual

62 Perspectiva de Especificação

63 Perspectiva de Implementação

64 Atividade de Sala I Crie o diagrama de classes com suas respectivas associações e cardinalidades contendo as classes que você achar necessário para realizar o caso de uso cadastro de pessoas físicas / jurídicas.

65 Atividade Sala I Exercite a criação de diagrama de classes usando o StarUML criando alguns dos diagramas exibidos na apresentação. Exercite a geração do código em diferentes linguagens.

66 Agenda Aula II Diagramas de Interação Introdução à Análise e Projeto de Software

67 Diagramas de Interação Marcos Dósea

68 Motivação Como os diagramas estudados até o momento podem ajudar? Auxiliam na definição dos requisitos. Auxiliam o processo de análise do sistema. Definem classes e responsabilidades. Definem associações entre classes.

69 Motivação Como determinar a sequência de chamada dos métodos? Qual classe inicia o encadeamento das chamadas? Todos os métodos necessários já foram descritos? Quais as classes que participam numa interação?

70 Agenda Diagrama de Seqüência Características Componentes Básicos Diagrama de Comunicação

71 Diagrama de Seqüência Características Determina a seqüência de eventos que ocorrem num determinado processo. Para um mesmo processo (caso de uso) existirão vários diagramas de seqüência. Semelhante ao caso de uso especificado. Os diagramas de sequência e comunicação são chamados diagramas de interação da UML.

72 Diagrama de Seqüência Características Depende do diagrama de classes e por isso normalmente são construídos em conjunto. Concentra-se na seqüência temporal dos eventos.

73 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

74 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

75 Diagrama de Seqüência Atores São exatamente os mesmo descritos no caso de uso, ou seja, entidades externas que interagem com o sistema e solicitam serviços.

76 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

77 Diagrama de Seqüência Objetos Representam as instâncias das classes envolvidas no processo. Representação através dos dois pontos (:) seguido do nome da classe. O nome do objeto é opcional.

78 Diagrama de Seqüência Objetos Quando o objeto existe desde o início o retângulo aparecerá na parte superior do diagrama. Quando ele é criado no decorrer do processo ele surgirá na mesma altura da mensagem. Objeto criado após o início do processo. Mensagem de criação do objeto.

79 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

80 Diagrama de Seqüência Linha de Vida Representa o tempo em que um objeto existiu durante um processo. É interrompida com um X quando um objeto é destruído. Linha da vida. X

81 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

82 Diagrama de Seqüência Foco de Controle ou Ativação Indica os períodos em que um determinado objeto está participando ativamente do processo. Foco de controle.

83 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

84 Diagrama de Seqüência Mensagens ou Estímulos Demonstram a ocorrência de eventos que normalmente forçam a chamada de um método de algum objeto envolvido no processo. Ator Ator Ator Objeto Objeto Ator Objeto - Objeto

85 Diagrama de Seqüência Mensagens ou Estímulos Mensagem de criação. Auto-Chamadas ou Auto-delegações. <destroy> Mensagem para objetos que já existem. Mensagem de retorno. Método destrutor

86 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

87 Diagrama de Seqüência Condições de Guarda Indica que uma mensagem só poderá ser enviada a um objeto se uma condição for verdadeira. Condição de guarda.

88 Diagrama de Sequência Condicão de Guarda na UML 2.0

89 Diagrama de Sequência Condicional Mutuamente Exclusiva

90 Diagrama de Seqüência Componentes Básicos Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços

91 Loop Diagrama de Sequência

92 Vamos pensar um pouco... Utilizando as classes criadas para realizar o cadastro de clientes crie o diagrama de sequência para realizar a operação de inserção e remoção de dados no banco de dados.

93 Roteiro Diagrama de Seqüência Diagrama de Comunicação Características Componentes Básicos

94 Diagrama de Comunicação Características Possui as mesmas funções do diagrama de seqüência. Concentra-se na organização estrutural dos objetos. É possível gerá-lo a partir do diagrama de seqüência e vice-versa.

95 Diagrama de Comunicação Componentes Básicos Objetos Atores Vínculos Mensagens Condições

96 Diagrama de Comunicação Objetos São as instâncias da classe que participam de um processo. Semelhante a representação do diagrama de seqüência. Coleção de dependentes.

97 Diagrama de Comunicação Componentes Básicos Objetos Atores Vínculos Mensagens Condições

98 Diagrama de Comunicação Atores São os mesmos do diagrama de seqüência e conseqüentemente os mesmo do diagrama de casos de uso.

99 Diagrama de Comunicação Componentes Básicos Objetos Atores Vínculos Mensagens Condições

100 Diagrama de Comunicação Vínculos Indicam as ligações que existem entre os objetos envolvidos em um processo, ou seja, os objetos colaboram entre si.

101 Diagrama de Comunicação Componentes Básicos Objetos Atores Vínculos Mensagens Condições

102 Diagrama de Comunicação Mensagens Representam a chamada dos métodos. São as mesmas do diagrama de seqüência. Não existem mensagens de retorno. A seta indica a direção para onde a mensagem foi enviada.

103 Diagrama de Comunicação Mensagens Também é possível disparar uma mensagem para si próprio. Auto-Chamada.

104 Diagrama de Comunicação Mensagens Podem ser enviadas diversas vezes. Variável de Retorno Mensagem enviada repetidas vezes. Pode-se restringir o número de vezes. Ex: *[i := 1..10] Coleção de objetos

105 Diagrama de Comunicação Componentes Básicos Objetos Atores Vínculos Mensagens Condições

106 Diagrama de Comunicação Condições Mensagem só é enviada se a condição for satisfeita. Condição.

107 Diagrama de Comunicação

108 Atividade Sala II Crie um projeto no StarUML contendo as classes necessárias para realização de um CRUD para os dados de uma Pessoa. Crie diagramas de interação para definir os métodos necessários nessas classes.

109 Introdução à Análise e Projeto de Software Marcos Dósea marcosdosea@gmail.com

110 Agenda Introdução Como fazer Análise? Fluxo de Análise e Projeto do RUP

111 Onde estamos? Introdução

112 Introdução O que faremos? Analisar o Software Definir a arquitetura Projetar o Software Componentes Banco de Dados

113 Análise x Projeto Análise Foco no problema Comportamento caixa preta Estrutura geral da arquitetura do sistema Requisitos Funcionais Modelo simples Projeto Foco na solução Detalha operações e atributos dos objetos Representação próxima do código. Requisitos Funcionais e Não Funcionais Modelo complexo.

114 Quais os artefatos produzidos? Modelo de Análise e Projeto Documento da Arquitetura Modelo de Casos de Uso Análise e Projeto Mapeamento das Classes de Análise em Elementos de Projeto Glossário Documento de Requisitos Projeto de Banco de Dados

115 Quais os artefatos produzidos? O que é produzido? Modelo de Casos de Uso Modelo de Análise e Projeto Caso de Uso Realização de Caso de Uso Diagrama de Seqüência Diagrama de Colaboração Diagrama de Classes

116 Quais os artefatos produzidos? Pode ser um modelo que inicia na atividades de análise (visão abstrata) e é concluído no projeto (visão detalhada). Podem ser dois modelos Modelo de Análise Modelo de Projeto (evoluído do modelo de análise) Como escolher? Documentação x Esforço Manutenção

117 Fluxo de Análise e Projeto Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados