Engenharia de Softwares e Sistema – IF682 (2012.1)
Bruno Medeiros([email protected])

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.
Concepção
Elaboração
Construção
A
P
.
n
r
.
á
.
l
i
s
e
o
j
e
t
o
Transição
.
.
.


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!
Pessoa
Aluno
Professor
Pessoa
Aluno
Professor


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 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.
[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.
 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).




Abstrato
Independente da
tecnologia
Simples
Modelos por caso de
uso
Modelo de Análise




Concreto
Dependente da
tecnologia
Detalhado
Unificação em um
único modelo
Modelo de Projeto
1.
2.
3.
4.
Refinar o modelo de classes.
Aplicar padrões de projeto – Ex.: fachada.
Projetar arquitetura – Ex.: divisão em
camadas.
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

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.

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
Engenharia(FEUP)
de