Bruno Medeiros(bmo@cin.ufpe.br)

Engenharia de Softwares e Sistema – IF682 (2012.1)

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!

Estudaremos a seguir os fluxos de Análise e de Projeto (design) baseados no processo de desenvolvimento de software do RUP.

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.

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.

Classes

Objetos

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.

Representações dos estereótipos

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

Aluno Professor

Pessoa

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

QIB - Qualiti Internet Banking◦ [UC-02] Efetuar pagamento Qualiti Card.◦ [UC-06] Comprar ações.

[UC-02] Efetuar pagamento Qualiti CardPrioridade: 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 principal1.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.

[UC-06] Comprar açõesPrioridade: EssencialAtor(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 principal1.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.

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.

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.

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

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.

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...)

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).

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

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).

Modelo de Análise Modelo de Projeto

Abstrato Independente da

tecnologia Simples Modelos por caso de

uso

Concreto Dependente da

tecnologia Detalhado Unificação em um

único modelo

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.

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.

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 mecanismode persistência utilizado

ComunicaçãoComunicação entre apresentação e negócio e com outros sistemas

Agrupar classes em pacotes: criar diagrama de 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.

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

[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 : http://www.cin.ufpe.br/~if682.

Curso de UML, Universidade do Porto Faculdade de Engenharia(FEUP)