Modelagem de
Dados
Prof. Jorge Dias
jorge@dcx.ufpb.br
Por que modelar
software antes de
partir para a
codificação?
Dinâmica
• Dividir a turma em 2 equipes de especificação
• Equipe 1: Dispensa/aproveitamento de disciplinas • Equipe 2: Revisão de avaliação
• Para cada equipe, definir os seguintes times:
• Time para entender o problema
• Time para especificar os requisitos do sistema • Time para projetar o sistema
• Cada time tem 10 minutos para trabalhar
Problemas identificados
• Abstração da realidade
• Falta de um método para guiar as atividades de cada time
• Falta de padrão de como documentar os artefatos
• Ociosidade dos times por seguir uma abordagem “cascata”
Comunicação no
ciclo de vida
Requisitos
Análise
Projeto
Código
Usuários Comunicação Comunicação Comunicação ComunicaçãoComunicação
• O profissional de software passa cerca de 50%
do seu dia se comunicando com pessoas [Lago, 2000]
• Todos do grupo devem ter em mente os
objetivos do trabalho
• Requisitos, produto, arquitetura etc.
• Barreiras:
• Pessoais • Físicas
Ok Sobre as
orelhas.
Entendendo o problema do cliente...
• Segundo Brooks*, a Engenharia de Requisitos é a parte mais difícil da
construção de um software.
• Nenhuma outra parte do desenvolvimento causa tantos danos se
feita de forma errada.
• Nenhuma outra parte é tão difícil de ser corrigida.
Objetivos não estavam claros Ignorar um grupo de clientes
Omitir um grupo de requisitos
Permitir inconsistências entre grupos de requisitos
Aceitar um requisito ambíguo e inconsistente
Requisitos e especificações incompletos
Requisitos e especificações instáveis (mudanças)
Aceitar requisito inadequado, incorreto, indefinido, ou impreciso
Fatores de falhas nos projetos
11
Aspectos econômicos
40% 66% 30% 25% 30% 9% 0% 10% 20% 30% 40% 50% 60% 70%total erros % total do custo de correção erros % Especificação Projeto
Codificação
Além disso, o software…
2014.1 UFPB - Engenharia de Requisitos 13
• Está cada vez mais
complexo
• Os riscos são cada vez
maiores
• Os orçamentos são sempre
apertados
• Os prazos são cada vez
menores
• Há uma demanda por
Tenha em mente que...
• Eles estão satisfeitos quando você:
Atende às expectativas Entrega no prazo
Entrega no orçamento
14
O sucesso do software depende da satisfação do cliente
Tudo começa com Requisitos!!!
O que são requisitos?
Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo
É o que o sistema deve fazer para implementar uma necessidade de
automação requerida pela solução
Desde as necessidades básicas do cliente, premissas e restrições obtidas na
fase de levantamento do projeto até as condições de negócio explicitadas no
contrato com o fornecedor da solução.
• “Você começa a codificar
enquanto eu vou descobrir o que o cliente quer”;
• Requisitos são fáceis de obter;
• O cliente/usuário sabe o que
quer;
• Quando os requisitos
estiverem congelados ...
Modelos
• Um modelo de sistema é uma abstração do sistema em
estudo
• O modelo deve simplificar a realidade, realçando as
características mais importantes Existem diferentes tipos
de modelo, cada um
enfatizando um aspecto
(Ex: interface, arquitetura, BD, etc)
Análise e Modelos
•
Vantagens de usar um modelo
• Documentar decisões• Entender melhor o sistema
• Guiar a implementação e outras disciplinas do ciclo de vida • Ajudar na entrada de novas pessoas
Princípios da Modelagem
•
A
escolha dos modelos
a serem criados tem profunda
influência sobre a maneira como um determinado problema
é atacado e como uma
solução
é definida
•
Cada modelo poderá ser expresso em diferentes
níveis de
precisão
•
Os melhores modelos estão relacionados à
realidade
•
Geralmente, nenhum modelo único é suficiente
Linguagem de Modelagem
•
Linguagem Gráfica de Modelagem para:
• Visualizar
• Especificar
• Construir • Documentar
• Comunicar
Artefatos de sistemas complexos
Linguagem de Modelagem Unificada
UML não é:
um processo uma metodologia Análise e Projeto OO regras de projetoCriadores da UML
• James Rumbaugh - Object Modeling Technique (OMT)
• Grady Booch - Booch Method
Diagramas
• Apresentações gráficas de um conjunto de
elementos, geralmente representadas como
gráficos de vértices (itens) e arcos (relacionamentos)
• Nove tipos:
• classes, objetos, pacotes, casos de uso,
seqüências, colaborações, estados, atividades, componentes e implantação
Elementos Essenciais
Elementos Estruturais Elementos Comportamentais Elementos de Agrupamento Elementos de Anotação• São as partes estáticas de um modelo, representando
elementos que são ou conceituais ou físicos.
• Exemplos:
Elementos Estruturais
• Classe • Interface • Use Cases • Componente • NóElementos Comportamentais
São as partes dinâmicas dos modelos da UML. Exemplos:
• Interação - especifica um conjunto de mensagens trocadas
entre objetos
• Máquina de Estado - especifica seqüências de estados de um
Elementos de Agrupamento
São partes organizacionais dos modelos da UML. Exemplo:
• Pacotes - mecanismo para organização de elementos dentro de
Elementos de Anotação
São partes explicativas dos modelos da UML. São comentários que você aplica para descrever, iluminar e remarcar elementos no modelo.
Exemplo:
• Nota - símbolo contendo restrições ou comentários que são
Diagrama Use Cases
• São especialmente importantes na organização e modelagem
das principais funcionalidades de um sistema
• Use Case é a especificação de sequências de ações atender a
Diagrama de Use cases
Estudante
Secretária <<estende>> Solicitar histórico do
semestre atual Solicitar histórico de todos os semestres Solicitar histórico <<estende>> Verificar dependências Matricular aluno <<inclui>> Sistema de controle de pré-requisitos
Diagrama de Classe
• Os diagramas de classes são os principais diagramas estruturais
da UML
• Diagramas de classe mostram classes, interfaces e seus
relacionamentos
• As classes especificam a estrutura e o comportamento dos
Diagrama de Classe
+confirmar() +cancelar() -calcularTotal():Currency gerarNovoCodigo: String -codigo: Integer -dataRecebido -total: Currency Pedido #creditoPermitido: Currency #nivelCredibilidade() -nome: String -endereco: String -dataPrimeiraCompra: Date -dataUltimaCompra: Date -totalComprado: Currency Cliente -quantidade: Integer -preco: Currency -emEstoque: Boolean Item de Pedido nomeContato: String telefones[1..10]: String CGC: String FAX[1..3]: String Cliente pessoa-jurídica colocarListaNegra() nome: String CPF: String numCartaoCredito Cliente pessoa-física Empregado Produto * representante de vendas * IPessoa itens 0..* ←faz 1Diagrama de Objetos
• Mostram objetos e seus relacionamentos
• Representam instâncias estáticas de elementos dos diagramas
de classes
• Os diagramas de objetos são úteis para a modelagem de
Diagrama de Objetos
p2: Professor matricula: "205-6712-09"
nome: "Jaelson Castro" p1: Professor codCurso: "IF291" descrição: "MPS" codTurma: I7 : Curso codCurso: "IF185" descrição: "AER" codTurma: I6 : Curso matricula: "219846534" nome: "Nelson Mandella"
:aluno
matricula: "562746134" nome: "John Major"
:aluno : Aluno : Aluno : Aluno : Aluno c1: Curso c2: Curso c3: Curso Bill : Aluno : Aluno Lewinsky -matrícula: String -nome: String Professor -codDisciplina: String -descrição: String -codTurma: String Curso -matrícula: String -nome: String -período: Integer Aluno [0..10] ministra [1..5] * [1..3]
Diagrama de Seqüência
• Mostra um conjunto de objetos, seus relacionamentos e as
Diagrama de Seqüência
Janela de entradade pedido p: Pedido : ItemPedido :ItemEstoque preparar()
* [para cada item do pedido]
preparar() emEstoque := verificar() [emEstoque] remover() estoqueBaixo := verificEstoqueBaixo() :ItemRenovEstoque :ItemEntrega [estoqueBaixo] <<criar>> [emEstoque] <<criar>>
Diagrama de Colaboração
• Mostra um conjunto de objetos, seus relacionamentos e as
mensagens que enfatizam a organização dos objetos que trocam mensagens
Diagrama de Colaboração
Janela de entrada de pedido p: Pedido : ItemPedido :ItemEstoque :ItemRenovEstoque :ItemEntrega 1: preparar()1.1: *[para cada item do pedido] preparar()
1.1.1 : emEstoque := verif icar() 1.1.2 : [emEstoque] remover() 1.1.2.1: estoqueBaixo := verif icEstoqueBaixo() 1.1.2.2 [estoqueBaixo] <<criar>> 1.1.3 : [emEstoque] <<criar>>
Diagrama de Estados
• Mostra uma máquina contendo estados, transições, eventos e
atividades
• Estes diagramas são usados para modelar o comportamento de
objetos (com comportamento complexo)
• Nestes diagramas são modelados os estados em que um objeto
pode estar e os eventos que fazem o objeto passar de um estado para outro
Ocioso Manutenção fazerManutenção Validando Selecionando Processando Imprimindo [continuar] [não continuar] H entry / lerCartão exit / ejetarCartão cartãoInserido cancelar Ativo
Diagrama de Estados
Diagrama de Atividades
• Destaca a lógica de realização de uma tarefa
• Mostra o fluxo entre atividades (ações não-atômicas)
• É semelhante aos antigos fluxogramas
• É usado também para modelar alternativas de execução e
Diagrama de Atividades
Procurar bebida[achou café]
H
Pessoa
H [sem café] [sem Coca] [achou Coca] Pegar lata de Coca Beber Adicionar água à máquina Colocar café no filtro Colocar filtro na máquina Ligar máquina Filtrar café Pegar xícara Colocar café na xícara
Diagrama de Componentes
• Mostra os componentes de hardware e software de uma aplicação
e os relacionamentos entre eles
• É usado para modelar o aspecto físico de um sistema
• Exemplos de componentes são documentos, executáveis e tabelas
Diagrama de Componentes
FormCadastro.html Cadastro.exe Principal.html FormEntrada.html Autenticacao.exe <<link>> <<link>> Banco Usuários SenhasDiagrama de Implantação
• É usado para modelar a arquitetura de distribuição em que o
sistema será executado
• É composto por nós e relacionamentos de comunicação
• Um nó pode ser um computador, uma rede, um disco rígido,
Diagramas de Implantação
servidorWeb Autenticação.exe Cadastro.exe servidorDeArquivos FormCadastro.html Principal.html FormEntrada.html servidorBancoDeDados SGBD O SGBD a ser utilizado ainda não foi escolhido. PC - G309Nestscape Communicator
