Tarciane Andrade.

Transcrição

1 Tarciane Andrade

2 Contexto Análise Passando de casos de uso para diagramas de classes 2

3 Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso em mãos. Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso. Este modelo é chamado de modelo de análise. 3

4 Requisitos Análise Projeto ARQUITETURA 4

5 Vai proporcionar um método que permita que criemos um modelo de classes do sistema a partir dos casos de uso Trará a resposta para a pergunta: Quais classes preciso para implementar estes casos de uso? 5

6 A maneira como vamos realizar a etapa de análise se baseia no processo do RUP (Rational Unified Process) A análise será orientada a casos de uso, ou seja, os casos de uso servirão de guia para a etapa de análise 6

7 casos de uso Descritos na linguagem do cliente Visão externa do sistema Captura as funcionalidades do sistema Estruturado por casos de uso análise Descrito na linguagem dos desenvolvedores Visão interna do sistema Mostra, de modo abstrato, como a funcionalidade pode ser realizada Estruturado por classes e pacotes 7

8 Identificar as classes Identificar persistência Identificar responsabilidades das classes Identificar relacionamentos Identificar atributos 8

9 No primeiro passo de análise, identificaremos três tipos de classes: Fronteira Entidade Controle Tais classes são identificadas separadamente para cada caso de uso 9

10 Utilizada para modelar a interação entre um ator e o sistema Para cada interação entre um ator e caso de uso, é criada uma classe de fronteira Possuem o estereótipo <<boundary>> 0

11 Utilizadas para modelar a informação manipulada pelo sistema Podem ser persistentes ou não São identificadas a partir do fluxo de eventos do caso de uso Possuem o estereótipo <<entity>>

12 Classes responsáveis por controlar o fluxo de execução do caso de uso Normalmente é criada uma classe de controle para cada caso de uso Possuem o estereótipo <<control>> 2

13 efetuar login Usuario adicionar turma registrar súmulas das aulas remover turma Secret ária Professor registrar faltas Aluno editar turma consultar freqüência editar alunos remover alunos adicionar alunos Servidor de 3

14 Efetuar Login Fluxo de eventos:. Usuário informa login e senha 2. Sistema checa se o login e senha conferem 3. Sistema registra a informações do aluno e a tela principal do sistema é exibida 4

15 Que classes preciso criar? uma classe de fronteira para lidar com a interação dos atores com o sistema uma classe de entidade para representar as informações relevantes do aluno uma classe de controle para gerenciar o fluxo de execução do caso de uso 5

16 TelaLogin ControladorLogin Usuario Há diferentes opções de visualização dos estereótipos. A opção padrão é mostrada acima - os estereótipos são visualizados através da mudança dos ícones das classes. Há também a opção de se visualizar os estereótipos do modo convencional (<<estereótipo>>). <<boundary>> TelaLogin <<control>> ControladorLogin <<entity>> Us uario 6

17 Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa 7

18 : usuário : TelaLogin : Con troladorlogin : CadastroAlunos efetuarlogin(login, s enha) efetua rlogin(log in, se nha) c hecar(login, senh a) registrars ess ao() 8

19 Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (º passo) 9

20 <<boundary>> TelaLogin efetuarlogin(login, senha) <<control>> ControladorLogin efetuarlogin(login, senha) registrarsessao() <<entity>> Usuario 20

21 As classes identificadas não funcionam isoladamente, elas se relacionam com as demais classes Os diagramas de interação são muito úteis nesta tarefa Para cada ligação presente nos diagramas de interação, é necessário um relacionamento no diagrama de classes 2

22 <<boundary>> TelaLogin * efetuarlogin(login, senha) <<control>> ControladorLogin efetuarlogin(login, senha) registrarsessao() <<entity collection>> CadastroUsuarios checar(login, senha) <<entity>> Usuario 22

23 Também é necessário identificar quais os atributos das classes Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade Nesta etapa ainda não precisamos indicar quais os tipos dos atributos 23

24 <<boundary>> TelaLogin <<control>> ControladorLogin efetuarlogin(login, senha) * efetuarlogin(login, senha) registrarsessao() <<entity collection>> CadastroUsuarios checar(login, senha) <<entity>> Usuario login senha 24

25 Secretária adicionar alunos Servidor de Fluxo de eventos:. Secretária informa dados do aluno 2. Secretária seleciona a opção confirmar cadastro 3. Sistema checa se os dados são válidos 4. Sistema adiciona o aluno à base de dados 5. Sistema envia um para o aluno, informando-o seu login e senha 6. Sistema exibe uma mensagem de confirmação de cadastro Identificar as classes do caso de uso adicionar aluno 25

26 <<entity>> () <<boundary>> TelaAdicionarAluno adicionaraluno()..* <<entity>> Aluno nome em ail login senha Aluno() <<boundary>> ComunicacaoServidor enviarem ail() <<control>> ControladorAdicionarAluno adicionaraluno() <<entity collection>> Cadas troalunos adicionaral uno() 26

27 Tarciane Andrade 27

28 Contexto Projeto Refinando o modelo de análise Classes Arquitetura Pacotes 28

29 Após a etapa de análise temos um primeiro modelo do sistema Queremos agora melhorar esse modelo, a ponto de gerarmos facilmente a implementação do sistema Este modelo é chamado de modelo de Projeto 29

30 Requisitos Análise Projeto 30

31 Abstrato X Concreto Independente X dependente da tecnologia de implementação Simples X detalhado Modelos por caso de uso X unificação em um único modelo 3

32 Refinar o modelo de classes Projetar arquitetura Camadas Separação em pacotes Projetar Banco de Dados 32

33 Juntar todas as classes em um só diagrama Analisar se é necessário criar novas classes ou remover classes existentes Eliminar os estereótipos de análise Adicionar modificadores de visibilidade aos métodos e atributos Definir os tipos dos atributos 33

34 <<boundary>> TelaLogin <<control>> ControladorLogin efetuarlogin(login, senha) * efetuarlogin(login, senha) registrarsessao() <<entity collection>> CadastroUsuarios checar(login, senha) <<entity>> Usuario login senha 34

35 <<entity>> () <<boundary>> TelaAdicionarAluno adicionaraluno()..* <<entity>> Aluno nome em ail login senha Aluno() <<boundary>> ComunicacaoServidor enviarem ail() <<control>> ControladorAdicionarAluno adicionaraluno() <<entity collection>> Cadas troalunos adicionaral uno() 35

36 Aluno nome : String String login : String senha : String Aluno() TelaAdicionarAluno adicionaraluno()..* TelaLogin efetuarlogin() * ComunicacaoServidor enviar () ControladorAdicionarAluno adicionaraluno() ControladorLogin efetuarlogin() registrarsessao() Usuario login : String senha : String () CadastroAlunos adicionaraluno() CadastroUsuarios checar() 36

37 Detalhar assinatura dos métodos definir todos os parâmetros dos métodos, seu tipos e o tipo de retorno dos métodos Mapear associações em atributos Analisar a possibilidade de utilizar herança 37

38 Usuario login : String senha : String Usuario() Aluno nome : String String Aluno() TelaAdicionarAluno adicionaraluno() TelaAdicionarAluno()..* TelaLogin efetuarlogin() TelaLogin() * ComunicacaoServidor ControladorAdicionarAluno ControladorLogin enviar () ComunicacaoServidor () adicionaraluno() ControladorAdicionarAluno() efetuarlogin() registrarsessao() ControladorLogin() assunto : String remetente : String destinatario : String corpo : String () CadastroAlunos adicionaraluno() CadastroAlunos() CadastroUsuarios checar() CadastroUsuarios() 38

39 Identificar padrões de projeto Ex: Fachada Revisar as classes 39

40 Usuario login : String senha : String Usuario() Aluno nome : String String Aluno() TelaAdicionarAluno adicionaraluno() TelaAdicionarAluno() TelaLogin..*..* efetuarlogin() TelaLogin() ComunicacaoServidor enviar () Comunic acaoservidor () assunto : String remetente : String destinatario : String corpo : String () ControladorAdicionarAluno adicionaraluno() ControladorAdic ionaraluno() <<singleton>> Fachada adic ionaraluno() efetuarlogin() Fachada Singleton ControladorLogin efetuarlogin() registrarsessao() ControladorLogin() CadastroAlunos adicionaraluno() CadastroAlunos() CadastroUsuarios checar() CadastroUsuarios() 40

41 Dividir o sistema em camadas Arquitetura bem comum: Apresentação Comunicação Negócio Dados Interface com o usuário Comunicação entre apresentação e negócio e com outros sistemas Regras de negócio inerentes à aplicação Código relacionado ao mecanismo de persistência utilizado 4

42 Por que dividir em camadas? Aumentar modularidade Diminuir dependências Facilitar possível troca de camadas 42

43 Apresentação TelaLogin efetuarlogin() TelaLogin()..* TelaAdicionarAluno adicionaraluno() TelaAdic ionaraluno()..* Comunicação Comunicação ComunicacaoServidor enviar () ComunicacaoServidor () Negócio assunto : String remetente : String destinatario : String corpo : String () adicionaraluno() ControladorAdicionarAluno() <<singleton>> Fachada adicionaraluno() efetuarlogin() ControladorAdicionarAluno ControladorLogin efetuarlogin() registrarsessao() ControladorLogin() Aluno nome : String String Aluno() Usuario login : String senha : String Usuario() CadastroAlunos adicionaraluno() CadastroAlunos() CadastroUsuarios checar() CadastroUsuarios() Dados 43

44 Agrupar classes em pacotes Possíveis critérios: Camadas Lógica do sistema Critérios escolhidos devem minimizar a dependência entre os pacotes Criar um diagrama de pacotes indicando as dependências entre os pacotes 44

45 Indicação do pacote da classe TelaLogin (from gui) efetuarlogin() TelaLogin()..* TelaAdicionarAluno (from gui) adicionaraluno() TelaAdicionarAluno()..* (from negocio) assunto : String remetente : String destinatario : String corpo : String () <<singleton>> Fachada (from negocio) adicionaraluno() efetuarlogin() Aluno (from negocio) nome : String String Aluno() ComunicacaoServidor (from comunicacao) enviar () ComunicacaoServidor () ControladorAdicionarAluno ControladorLogin (from negocio) adicionaraluno() ControladorAdicionarAluno() (from negocio) efetuarlogin() registrarsessao() ControladorLogin() Usuario (from negocio) login : String senha : String Usuario() CadastroAlunos (from dados) adicionaraluno() CadastroAlunos() CadastroUsuarios (from dados) checar() CadastroUsuarios() 45

46 gui comunicacao negocio dados 46

47 Divisão em grupos; Elaborar o diagrama de análise, projeto e pacote para o caso de uso Registrar Faltas. 47

48 Caso de Uso Registrar Faltas Pré-Condição: aulas realizadas cadastradas; Este caso de uso se inicia quando o professor entra no sistema; O professor escolhe a turma de alunos; O professor escolhe o aluno para cadastrar as faltas; Para cada aula realizada, o professor informa se o aluno estava presente ou se faltou a aula; O caso de uso se encerra; 48

49 The Unified Software Development Process - Jacobson, Rumbaugh, Booch The UML Reference Manual - Rumbaugh, Jacobson, Booch Vasconcelos, Alexandre. Disciplina de Engenharia de Software, UFPE. SWEBOK,