Modelos de Análise e Projeto

Apresentação em tema: "Modelos de Análise e Projeto"— Transcrição da apresentação:

1 Modelos de Análise e Projeto
Engenharia de Softwares e Sistema – IF682 (2012.1) Modelos de Análise e Projeto Bruno

2 Relembrando... Algumas definições
Engenharia de Software – conjunto de tecnologias e práticas usadas para construir software de qualidade e dentro de estimativas de custo e tempo. Projeto – “Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.” [PMBOK, 2004]. Processo – é um conjunto de passos parcialmente ordenados que objetivam atingir uma meta; é uma receita a ser seguida por um projeto; uma abstração concretizada pelo projeto. Não confundir processo, projeto e produto!

3 O que veremos hoje? Estudaremos a seguir os fluxos de Análise e de Projeto (design) baseados no processo de desenvolvimento de software do RUP. Concepção Elaboração Construção Transição ... Análise Projeto

4 FLUXO DE ANÁLISE

5 Objetivos do Fluxo de Análise
Após o levantamento dos requisitos desejamos detalhar, estruturar e validar tais requisitos através de um modelo conceitual do problema. Nesta etapa, queremos: Modelar de forma precisa os conceitos relevantes ao domínio do problema; Verificar a qualidade dos requisitos obtidos pelo fluxo de Requisitos; Atingir um nível de detalhes suficiente para alimentar o fluxo de Projeto, mas evitar aspectos próprios à implementação e não ao problema.

6 Atividades do Fluxo de Análise
Cada caso de uso deve ser analisado individualmente para: Identificação das classes - a partir dos fluxos dos casos de uso são identificadas as classes do produto. Organização das classes - as classes são agrupadas em pacotes e marcadas com os estereótipos de fronteira, entidade, controle ou coleção. Identificação dos relacionamentos - determina os relacionamentos entre as classes. Identificação dos atributos - levantamento dos atributos que fazem parte dos conceitos expressos pelas classes. Realização dos casos de uso - representa os fluxos dos casos de uso através de diagramas de seqüencia.

7 Notação UML Classes Objetos

8 Identificação das classes
Estereótipos de classes Fronteira <<boundary>> : Modela interação entre um ator e o sistema. Entidade <<entity>>: Representa abstrações e conceitos chaves; freqüentemente corresponde a entidades de banco de dados. Controle <<control>>: Tipicamente dependente da aplicação; encapsula lógica que não se enquadra na entidade; em geral, uma por caso de uso. Estabelecem uma interface entre fronteira e entidade. Coleção <<entity collection>>: Classe de entidade que deve ser persistida.

9 Notação UML Representações dos estereótipos

10 Hierarquias de classes
Em geral, pode-se ter uma hierarquia de classes relacionadas por herança / generalização em cada classe da hierarquia colocam-se as propriedades que são comuns a todas as suas subclasses  evita-se redundância, promove-se reutilização! Aluno Professor Pessoa

11 Polimorfismo Numa sub-classe podem-se redefinir operações da super-classe Em UML, quando se repete (a assinatura) de uma operação numa sub-classe, quer-se dizer que a operação tem uma implementação diferente (a implementação não é herdada) chama-se método à implementação da operação

12 Os casos de uso QIB - Qualiti Internet Banking
[UC-02] Efetuar pagamento Qualiti Card. [UC-06] Comprar ações.

13 [UC-02] Efetuar pagamento Qualiti Card
Prioridade: Essencial Ator(es): Cliente e Operadora de cartão de crédito. Descrição: Permite ao cliente realizar o pagamento da fatura do cartão de crédito. Ao efetuar o pagamento o sistema se comunica com a operadora de cartão para autenticar o número do cartão do usuário. Precondições: Usuário deve estar conectado ao sistema (ter efetuado o login). Pós-condições: Pagamento realizado (o sistema informa a operadora de cartão de crédito que o pagamento foi efetuado), com débito do valor pago na conta do usuário e comprovante de pagamento. Fluxo principal O usuário escolhe a opção de pagamento do Qualiti Card. Include Informar dados do Qualiti Card. O sistema verifica a data de vencimento da fatura. Se a data de pagamento da fatura for inferior ou igual à data de vencimento, o usuário pagará o valor correspondente da fatura. Se não, se a data for superior a data de vencimento da fatura o sistema cobrará 10% de juros em cima do valor da fatura. Se a diferença entre a data da fatura e a data de pagamento for superior a 30 o banco emitirá uma mensagem ao usuário informando que o pagamento só poderá ser efetuado na operadora do cartão de crédito. O usuário informa o tipo de pagamento a ser feito da fatura, parcial ou total. Se o pagamento for parcial, ele pagará 10% do valor da fatura, ficando o restante para ser debitado na próxima fatura. Se o pagamento for total o usuário pagará todo o valor correspondente da fatura. O usuário confirma o pagamento. O sistema efetua o pagamento e emite para o usuário um comprovante informando que o pagamento da fatura do cartão foi realizado. Fluxo de erros [FE-001] - No passo 10 do fluxo de eventos principal, caso o saldo da conta do cliente não seja suficiente para realizar o pagamento da fatura, o sistema informa ao usuário que ele não possui saldo suficiente para fazer o pagamento e cancela a operação.

14 [UC-06] Comprar ações Prioridade: Essencial Ator(es): Cliente e Operadora do Mercado de Ações. Descrição: Este caso de uso é responsável por realizar a compra de ações. Precondições: O cliente deve estar conectado ao sistema (ter efetuado o login) e estar cadastrado para comprar e vender ações. Pós-condições: O valor da compra debitado na conta do cliente. Fluxo principal O cliente informa os dados necessários para a realização da compra: De quem ele quer comprar as ações (BOVESPA, NASDAQ, MERVAL); A quantidade de ações. O sistema calcula o valor das ações a serem compradas. O sistema verifica se o saldo da conta do cliente é suficiente para a realização da compra. O sistema envia a compra à operadora do mercado de ações. O valor é debitado da conta do cliente. O QIB registra a ocorrência desta transação (uma compra de ações). Emite-se um comprovante da compra para o usuário, contendo os dados da conta do usuário, data, valor da compra e de quem as ações foram compradas. Fluxos alternativos [FA-001] - Em qualquer momento o usuário pode cancelar a operação. Fluxo de erros [FE-001] - No passo 3, se o saldo disponível na conta do usuário for menor que o valor da compra, o sistema informa que o saldo é insuficiente e retorna ao passo 1 do fluxo principal de eventos. [FE-002] No passo 4, se a operadora do mercado de ações estiver inativa ou se ocorrer algum erro de comunicação que impeça a efetivação da transação, o sistema emite uma mensagem para o cliente e aborta a transação.

15 Exemplo Para que fique claro o processo de obtenção do Modelo de Análise, faremos um exemplo utilizando o caso de uso [UC-02] Efetuar pagamento Qualiti Card.

16 Identificação das classes
Listar as classes a partir do fluxo do caso de uso: Buscar por substantivos; Eliminar aspectos de implementação; Identificar responsabilidades das classes e suas, possíveis, colaboradoras.

17 Organização das classes
Agrupar classes em pacotes lógicos e indicar os estereótipos. Explicitar fronteiras, entidades, controles e coleções.

18 Identificação dos relacionamentos
Determinar os relacionamentos com multiplicidades e, quando necessário, com nomes. Tipos de relacionamentos: Associação: denota dependência semântica entre as classes, é o tipo mais comum. Agregação: caso particular do anterior, indica o caráter “todo-parte”. Ex.: um conjunto de pontos formam um polígono, mas um ponto existe sem que exista um polígono. Composição: tipo mais forte do relacionamento “todo-parte”, objetos da classe “parte” não existem sem a classe “todo”. Ex.: o centro de um círculo só existe quando em presença deste.

19 Diagrama de classes v1.0

20 Identificação dos atributos
Localizar atributos relevantes que ainda não foram incluídos. Atributos e relacionamentos podem expressar o mesmo conceito, a escolha deve visar à clareza do modelo. Evitar atributos necessários apenas à implementação (gambi, temp, aux1, aux2, auxN...) 

21 Realização dos casos de uso
Nesta atividade são descobertas as operações (métodos) de cada classe através da interação entre seus objetos. Representam-se as interações entre objetos por meio de diagramas de interação: seqüência e colaboração. Diagramas de seqüência exprimem o caráter temporal das ações em andamento. Num único diagrama de seqüência pode-se representar todo os fluxos de um caso de uso, ou se utilizar vários diagramas (mais comum).

22 Diagrama de seqüência

23 Diagrama de classes v2.0

24 Exercício Obter o Modelo de Análise para o caso de uso [UC-06] Comprar ações.

25 FLUXO DE PROJETO

26 Objetivos do Fluxo de Projeto
O fluxo de Análise forneceu o primeiro modelo da arquitetura do sistema. Queremos melhorar esse modelo a fim de se chegar a algo codificável. Ao final desse fluxo obtemos o Modelo de Projeto (design).

27 Comparativo Análise X Projeto
Abstrato Independente da tecnologia Simples Modelos por caso de uso Concreto Dependente da tecnologia Detalhado Unificação em um único modelo Modelo de Análise Modelo de Projeto

28 Atividades do Fluxo de Projeto
Refinar o modelo de classes. Aplicar padrões de projeto – Ex.: fachada. Projetar arquitetura – Ex.: divisão em camadas. Projetar Banco de dados.

29 Refinar o modelo de classes
Eliminar os estereótipos de análise; Definir os tipos dos atributos, de retorno e de parâmetro dos métodos; Adicionar modificadores de visibilidade aos métodos e atributos; Identificar redundância; Criar ou remover classes; Identificar necessidades de herança; Agrupar todas as classes de análise em um único diagrama.

30 Projetar arquitetura Apresentação Comunicação Negócio Dados
Divisão do sistema em camadas, arquitetura bastante comum. Apresentação Interface com o usuário Comunicação Comunicação entre apresentação e negócio e com outros sistemas Negócio Regras de negócio inerentes à aplicação Dados Código relacionado ao mecanismo de persistência utilizado Agrupar classes em pacotes: criar diagrama de pacotes.

31 Diagrama de classes - Modelo de Projeto

32 Pacotes Em UML, um pacote é definido como: "Um mecanismo de propósito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de "Conteúdo do pacote". Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos em outros pacotes.

33 Pacotes

34 Exercício Obter o Modelo de Projeto para os casos de uso:
[UC-02] Efetuar pagamento Qualiti Card; [UC-06] Comprar ações.

35 Referências bibliográficas
[Pádua, 2003] Pádua, Wilson de. P. F. Engenharia de Software: Fundamentos, métodos e padrões. Editora LTC, 2ª ed., Rio de Janeiro - RJ, 2003. [PMBOK, 2004] Project Management Institute. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK). 3ª ed., 2004. [ESS, 2008] Site da disciplina Engenharia de Softwares e Sistema. Disponível em : Curso de UML, Universidade do Porto Faculdade de Engenharia(FEUP)