A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Bruno Engenharia de Softwares e Sistema – IF682 (2012.1)

Apresentações semelhantes


Apresentação em tema: "Bruno Engenharia de Softwares e Sistema – IF682 (2012.1)"— Transcrição da apresentação:

1 Bruno Engenharia de Softwares e Sistema – IF682 (2012.1)

2 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 Estudaremos a seguir os fluxos de Análise e de Projeto (design) baseados no processo de desenvolvimento de software do RUP. ConcepçãoElaboraçãoConstruçãoTransição

4

5 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 Cada caso de uso deve ser analisado individualmente para: 1.Identificação das classes - a partir dos fluxos dos casos de uso são identificadas as classes do produto. 2.Organização das classes - as classes são agrupadas em pacotes e marcadas com os estereótipos de fronteira, entidade, controle ou coleção. 3.Identificação dos relacionamentos - determina os relacionamentos entre as classes. 4.Identificação dos atributos - levantamento dos atributos que fazem parte dos conceitos expressos pelas classes. 5.Realização dos casos de uso - representa os fluxos dos casos de uso através de diagramas de seqüencia.

7 Classes Objetos

8 Estereótipos de classes Fronteira > : Modela interação entre um ator e o sistema. Entidade >: Representa abstrações e conceitos chaves; freqüentemente corresponde a entidades de banco de dados. Controle >: 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 >: Classe de entidade que deve ser persistida.

9 Representações dos estereótipos

10 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! AlunoProfessor Pessoa AlunoProfessor Pessoa

11 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 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 1.O usuário escolhe a opção de pagamento do Qualiti Card. 2. Include Informar dados do Qualiti Card. 3.O sistema verifica a data de vencimento da fatura. 4.Se a data de pagamento da fatura for inferior ou igual à data de vencimento, o usuário pagará o valor correspondente da fatura. 5.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. 6.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. 7.O usuário informa o tipo de pagamento a ser feito da fatura, parcial ou total. 8.Se o pagamento for parcial, ele pagará 10% do valor da fatura, ficando o restante para ser debitado na próxima fatura. 9.Se o pagamento for total o usuário pagará todo o valor correspondente da fatura. 10.O usuário confirma o pagamento. 11.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 1.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. 2.O sistema calcula o valor das ações a serem compradas. 3.O sistema verifica se o saldo da conta do cliente é suficiente para a realização da compra. 4.O sistema envia a compra à operadora do mercado de ações. 5.O valor é debitado da conta do cliente. 6.O QIB registra a ocorrência desta transação (uma compra de ações). 7.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 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 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 Agrupar classes em pacotes lógicos e indicar os estereótipos. Explicitar fronteiras, entidades, controles e coleções.

18 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

20 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 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

23

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

25

26 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 Modelo de AnáliseModelo de Projeto Abstrato Independente da tecnologia Simples Modelos por caso de uso Concreto Dependente da tecnologia Detalhado Unificação em um único modelo

28 1. Refinar o modelo de classes. 2. Aplicar padrões de projeto – Ex.: fachada. 3. Projetar arquitetura – Ex.: divisão em camadas. 4. Projetar Banco de dados.

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

31

32 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

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

35 [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, [PMBOK, 2004] Project Management Institute. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK). 3ª ed., [ESS, 2008] Site da disciplina Engenharia de Softwares e Sistema. Disponível em : Curso de UML, Universidade do Porto Faculdade de Engenharia(FEUP)


Carregar ppt "Bruno Engenharia de Softwares e Sistema – IF682 (2012.1)"

Apresentações semelhantes


Anúncios Google