Ir p/ primeira página Antonio Francisco do Prado prado@dc.ufscar.br Engenharia de Software

Ir p/ primeira página

Antonio Francisco do Pradoprado@dc.ufscar.br

Engenharia de Software

Sumário

Visão Geral – Fatores Críticos

TESTES : Mostram a presença de erros e não sua ausência

10 caminhos14

< 21 vezes

Início

Testes

Bomba !

Analista

Usuário

Comunicação

O que era

necessário !

O que foisolicitado pelo

Usuário

O que foi Especificado

pelo desenvolvedor

O que foi Implementado

peloprogramador

Comunicação

Onde está o erro ?

Sistema

OUTROS FATORES CRÍTICOS

•Software é um artefato invisível•Falta de consenso

Documentação e outros fatores

CONSEQUÊNCIAS

• Software não atende as necessidades do usuário;• Desentendimentos entre usuários e desenvolvedor;• Perda de tempo e dinheiro; e• Problemas judiciários.

Solução

Desenvolver com Engenharia de Software que: PREOCUPA-SE: com a qualidade do produto e do processo de desenvolvimento do produto BUSCA: A criação de soluções econômicas para problemas práticos COMPREENDE: Uma Metodologia Integrada para todo o ciclo de vida do software:

Análise e EspecificaçãoProjeto, Implementação e TesteManutenção

Visão Geral - PDS

Fases do desenvolvimento de

Software Coleta de fatos ou Identificação dos requisitos Modelagem ou Especificação

Análise Projeto

Implementação Teste

Coleta de Fatos

Documentos Entrevistas Reuniões Questionários Observação

Modelagem: Enfoques

DECOMPOSIÇÃO FUNCIONAL

FLUXO DE DADOS ENTIDADES E

RELACIONAMENTOS ORIENTADO A OBJETOS ORIENTADO A

COMPONENTES

Pagar Funcionários

Horistas

Obter Horas

Trabalhadas

Calcular

Pagamento

Emitir Contra

Cheque

CalcularPagtoBruto

Calcular Descontos

Calcular

Líquido

Decomposição Funcional

ObterHT

Funcionário

Serviço

Imposto

CalcularPagto

EmitirContraCheque

Funcionário

Fluxo de Dados

Funcionário

Serviço

Recolhe

Emprega

Imposto

Entidades e Relacionamentos

Sistema

Problemas

Orientado a Objetos

Mundo Real

Orientado a Componentes

Visual Java

Acesso a BD com componentes

Componentes em Delphi

Internet

TDataBase

TTable

TDataSource

DatabaseName: DBDEMOS TableName: Animal.db

Alias Name: DBDEMOSName: DBDEMOS

DataSet:

TTable

Acesso a BD em Delphi

Edição de Cena no Jazmine

Cenas no Jazmine

Java Beans em Aplicações

Java Beans na WEB

Análise

Identi- ficação deRequisitos

Projeto

Implementação

Versão

Modelo Espiral

P D S Atual

Sumário

Princípios da OO

Abstração Encapsulamento Classe e Objeto Herança Escala(Todo-Parte) Associação Conexão de Mensagem Polimorfismo Genericidade

Propriedades

Modelo

Descrição

Preço Venda

Operações

Faturar

Garantir

Requisitar

Propriedades

Tamanho

Velocidade

Número Instruções

Operações

+ * / - = ÷

Abstração

297 + 333 = 630

Requisitar ( Modelo : string )

Requisitar ( HP 97 )

Não interessa !

• Acessar diretamente as Propriedades

• Saber “como” são realizadas as Operações

Encapsulamento

Torna disponível apenas a assinatura ou protótipo dos métodos.

Por exemplo:

classe Pessoa

objeto Maria objeto Pedro

Classe e Objeto

Pessoa

NomeEndereçoTelefoneIdadeAltura

Registrar()Matricular()Pagar()Estudar()Cadastrar()

ATRIBUTOS

MÉTODOS

Objetos

Vermelha

Orquídea

Espécie

Região

Flor do Limão

Branca

Construtor

BC 4580

XP 3244

Modelo

MJ 1256

Construtor

Exercício 01

Sistema Hospitalar

Baseado nos princípios da Abstração e Encapsulamento, especificar:

Duas classes de um sistema Hospitalar, com seus principais atributos e métodos, incluindo os construtores.

Pessoa

Estudante Professor Funcionário Diretor

Herança

Peso BrutoPeso líquidoAlturaMotor

Veículo

ProprietárioPlacaAnoModeloMarca

Herança – Exemplo

Pessoa

NomeEndereçoTelefone

Estudante

MatrículaCursoAnoGraduação

Professor

TítuloSalario

Herança - Notação

NomeEndereço Idade Telefone

Matrícula

TempoServiço

Salário

Funcionário Vendedor

Código

Comissão

RegiãoTrabalho

Funcionário/Vendedor

Pessoa

Herança Múltipla

Exercício 02

Sistema Acadêmico

Considerando que o domínio tenha: Pessoa

ProfessorDedicação exclusivaTempo Parcial

AlunoResidente(interno)Externo

Funcionário Monitor é um aluno que tem

atribuições de professor.Especifique o Modelo de classes usando

herança.

PARTES

Agregação

Item 1: Relógio Item 2: Computador

PEDIDO

PARTES

Agregação

Pedido Número: 125 Data: 03 Fev 2000 Situação: PendenteItem Descrição Qtd Preço Total01 Cadeira 3 15,00 45,0002 Mesa 2 40,00 80,0003 Relógio 1 50,00 50,0004 Computador 1 900,00 900,00 Total Geral 1.075,00

Pedido

ItemPedido

Agregação por valor

Código

Período

Numero MatriculaNomeEndereço

Agregação por referência

Cliente

Pedido

Associação

Biblioteca

BIBLIOTECA

USUÁRIO

NomeEndereço

IdentidadeNomeEndereço

TítuloISBNSituação

EmprestarLivroReceberLivro

Validar UsuárioRegistrar Empréstimo

Validar LivroMudar Situação

EMPRÉSTIMO

0..10..1

Associação

Estudante Teste

SalaNota

realiza

Link de Atributo

Exercício 03

Sistema Acadêmico

Especifique o Modelo de Classes, para um domínio Acadêmico, no qual:

Escola tem Departamentos Departamentos têm Professores e

Cursos. Alunos freqüentam cursos Cursos são ministrados aos alunos

pelos professores Cada Departamento é dirigido por

um Professor( membro do departamento)

Quando será que você vai aprender minha linguagem ?

Conexão de Mensagem

Abram seuslivros na página 36

Qual apróximalição?

Mensagens entre objetos

BIBLIOTECA

NomeEndereço

EmprestarLivro

ReceberLivro

USUÁRIO

Identidade

Endereço

ValidarUsuário

Registrar Empréstimo

Título

ISBNSituação

ValidarLivroMudar Situação

0..10..1

EMPRÉSTIM

ValidarUsuário

RegistrarEmpréstimo

ValidarLivro

Mudar Situação

Solicita Livro

Conexão de Mensagem -

Exemplo

empresta ou devolve

E-mail

Inter-face

Conexão de Mensagem – Especificação com Modelo de Seqüência

:Biblioteca : AtorUsuário

Interface Empresta Livro

:Usuário : Livro

Solicita um livro

Solicita Info Usuário

Dados Usuário

EmprestarLivro(DadosLivro)

ValidarUsuário()

Solicita Info Livro

Dados Livro

ValidarLivro()

MudarSituação()

Livro SolicitadoRegistrarEmpréstimo()

Orientação a Eventos

Sinalização com estímulo:• Externo:

• Handle( inteiro sem sinal )• Fluxo de Dados ( Dados Pedido )

• Interno (Condição):• Tempo ( Fim de Semana )• Temperatura ( 10 < t < 30 )• Outros

TBUTTON :BOTÃO1

TFORM1 :FORM1

program Project1; uses Forms, . . . begin APPLICATION.Initialize; APPLICATION.CreateForm(TForm1, Form1); APPLICATION.Run; end.

TAPPLICATION :APPLICATION

Evento:

OnClick

TFORM1.Botão1Click begin

Edit1.Text := ‘325,00’ ; end

Eventos - Exemplo

SistemaOperacional

Objeto1Objeto1

Método1Método1 MétodoMMétodoM. . .

. . . ObjetoN

Método1 . . .

Eventos - Tratamento

ObjetoN

95 + 5 = 100

Janela ( )

Janela ( 1 x 2 , 2 )

Janela ( 1 x 2 , 2, Azul )

Polimorfismo

5 66 33

11 5 9

2 1 55

Redesenhar (NovoCentro:Ponto);

MoverFigura (NovoCentro:Ponto) { . . .

Redesenhar (NovoCentro);

. . . }

Polimorfismo - Exemplo

Exercício 04

Classe Pessoa

Classe Cliente

Atributos Nome, Endereço, e Telefone

Métodos Construtor com Nome Construtor com Nome, Endereço, e

Telefone Construtor de cópia

Atributos Cpf e Dívida

Métodos Construtor com Cpf Construtor de cópia

T,k: Integer

k..k T

Parametrizada (Template)

Genericidade ou Tipos Genéricos

Modificadores de Visibilidade:Modificadores de Visibilidade:

•PrivatePrivate

•ProtectedProtected

•ImplementedImplemented

•PublicPublic

Placa : StringDescricao : StringSituacao : Integer

Carro(Placa : String)SelecionarCarrosDisponíveis()EncontrarCarro(Placa : String)

Visão Lógica

AluguelAluDataInicio : Date = current date

CarroCarPlaca : StringCarDescricao : StringCarSituacao : Integer = 0CarAno : IntegerCarKm : IntegerCarPrecoKm : CurrencyCarTaxaDiaria : CurrencyCarObservacao : String

ClienteCliCpf : StringCliNome : StringCliEndereco : StringCliTelefone : StringCliDivida : Currency = 0

Diagrama de Classes

Modelo de classes

Modelo de Objetos

SQL MVCASE generated SQL data.

CREATE TABLE Table_Cliente (cpf VARCHAR(255),nome VARCHAR(255),endereco VARCHAR(255),PRIMARY KEY (cpf ) );CREATE TABLE Table_Pedido (codigoPedido VARCHAR(255),data VARCHAR(255),cpf VARCHAR(255) REFERENCES Table_Cliente(cpf),PRIMARY KEY (codigoPedido ) );CREATE TABLE Table_ItemPedido (quantidade INTEGER,Table_ItemPedido_ID INTEGER,codigoPedido VARCHAR(255) REFERENCES Table_Pedido(codigoPedido),codigoProduto VARCHAR(255) REFERENCES Table_Produto(codigoProduto),PRIMARY KEY (Table_ItemPedido_ID ) );CREATE TABLE Table_Produto (codigoProduto VARCHAR(255),descricao VARCHAR(255),PRIMARY KEY (codigoProduto ) );

UML - Visão LógicaUML - Visão Lógica

Navegabilidade

Funcionario

Matricula

Dependente

Direção da Navegabilidade

CREATE TABLE Funcionario( Matricula VARCHAR(40) NOT NULL UNIQUE, PRIMARY KEY(Matricula)) CREATE TABLE Dependente( Nome VARCHAR(30), Matricula VARCHAR(40) NOT NULL UNIQUE, FOREIGN KEY (Matricula) REFERENCES Funcionario, DependenteId NUMBER(5), PRIMARY KEY(DependenteId))

Funcionario

Matricula

Dependente

Relacionamentos de Dependênciae Implementação

ServidorBD

Pedido

Dependência

Implementação

interfacePedido

<<Interface>>

Conecta()

Exibir()

Sumário

Estudo de caso DISTRIBUIDORA DE PRODUTOS

Uma distribuidora recebe pedidos de produtos. O pedido é aceito se o cliente e o produto estiverem previamente cadastrados. Caso contrário, o pedido é devolvido ao cliente. Ao final da semana, a distribuidora emite requisições de produtos para os fornecedores, previamente cadastrados, com base nos pedidos recebidos. Quando o fornecedor envia catálogo de seus produtos o cadastro de produto é atualizado. Periodicamente a distribuidora envia catálogo dos produtos para seus clientes. Quando os produtos são fornecidos, a distribuidora confere as notas de entregas dos fornecedores com a requisições, devolve as notas de entregas que estiverem com erros e atende aos pedidos dos clientes, emitindo as respectivas faturas.

Exercício 05

Use Case

DadosCliente

AtorCliente CadastrarCliente

MensagemCadastro

UML - Use CaseUML - Use CaseDiagrama de Use Case

AlugarCarro

LiquidarDivida

CadastrarCliente

DevolverCarro

AtorCliente

Msg01, Carro Alugado

Msg05, Recibo

DadosAluguel

DadosPagamento DadosCliente

Msg02, Recibo

DadosDevolução

Use Case por Ator

Relacionamento <<uses>>

ValidarCliente

Cliente RealizarPedido

<<uses>>

Relacionamento <<extends>>

CadastrarCliente

ClienteRealizarPedido

<<extends>>

dadosPedido

Relacionamentos em Use Cases

Ator Usuário Msg01, Livro Solicitado

Dados Empréstimo

EmprestarLivro

Curso Normal:

1. Usuário solicita um livro.2. Sistema solicita informações do usuário.3. Usuário informa seus dados(Identidade, Nome e e-mail).4. Sistema verifica que existe o usuário associado à Identidade.5. Sistema solicita informações do livro.6. Cliente informa o nome do livro.7. Sistema verifica que o livro existe e está disponível.8. Sistema muda a situação do livro para “emprestado”.9. Sistema registra o empréstimo do livro para o usuário.10. Sistema entrega o livro para o usuário.

Especificação de Modelo de caso de uso

Cursos Alternativos:

Alternativa 4. Usuário não está cadastrado 4.1 Sistema emite emite Msg01 informando que o usuário não está cadastrado e encerra o caso de uso.

Alternativa 7. Livro não existe ou já está emprestado 7.1 Sistema emite Msg01 informando que o livro não existe ou já está emprestado encerra o caso de uso.

Modelo de Caso de Uso – Fluxos alternativos

Exercício 06

Número: 01 Use Case: AtenderPedido Descrição: Este use case trata do pedido do Cliente. Ator: Cliente

AtenderPedido

Cliente

Questão:• Completar o Use Case.

Diagrama de Use Case

Exercício 07

Diagrama de Sequência atenderPedido - Curso Normal:

: Item Pedido

Cliente InterfacePedido

:Cliente :Produto :Pedido

Questão:• Completar o Diagrama.

Sumário

Componentes ?

1. Blocos previamente testados2. Interfaces bem definidas3. Plug-In4. Mostra apenas o que interessa5. Suporta:

• reuso direto através de instâncias• Criação de componentes mais específicos

Componentes e Interfaces

Cliente.jarClienteHome

Cliente

<<interfaces>>

Servidor WEB Servidor Aplicação

Web.war

HtmlJSPServlet

FramePrincipal.java

FrameCliente.java

FrameCarro.java

FrameAluguel.java

"LocadoraClient.jar"

Locadora.db

Cliente

Regras de Negócio

Banco de Dados

Regras de Negocio e Banco de Dadospara um domínio de Aplicações, fornecendoas seguinte principais vantagens:

•Reuso de código previamente testado•Evita duplicação do código nas aplicações•Facilita a manutenção

Arquitetura em camadas

Diagrama de Componentes

Outras Tecnologias

1.Orientação a Aspectos2.Padrões3.Frameworks4.Agentes de Software5.Web Services6.XML e outras LPs WEB

Conclusão

Orientação a Objetos Banco de Dados OO(componentes) D B C com Padrões, Frameworks, Aspectos

e outras técnicas Engenharia de Domínio Componentes Distribuídos Aplicações com reutilização de

Componentes Evita redundância Facilita a manutenção Sistemas mais confiáveis

Programação “Plug in” Ambientes que suportam todo o PDS DBC e Banco de Objetos: Futuro do PDS

Estudo de caso proposto SISTEMA HOTELEIRO

Deseja-se modelar um sistema para um pequeno hotel que atenda aos seguintes requisitos: · Quando o Cliente telefona ou vem até o hotel e pede para reservar um quarto o funcionário verifica se existe quarto disponível no período solicitado. Caso positivo, é feita a reserva do quarto. Caso negativo, é informado ao cliente a não disponibilidade do quarto.· Quando o cliente não mais desejar o quarto reservado o funcionário providencia o cancelamento da reserva, disponibilizando novamente o quarto.· Quando o cliente não comparecer ao hotel para hospedar-se até as 12:00 horas do dia da Reserva, deve ser cancelada a sua Reserva.· Quando o cliente ocupar um quarto, reservado previamente, o funcionário faz o registro do cliente. Caso o quarto não esteja reservado uma mensagem de rejeição será emitida. Caso contrário, um pacote com informações úteis e a confirmação serão fornecidos ao Cliente.· Quando o cliente deixar o hotel e solicitar que providencie sua saída, será fornecida a respectiva conta, e o quarto será tornado indisponível para a limpeza.· O cliente pode pagar a conta à vista ou usando cartão de crédito. Caso use cartão de crédito, é verificado sua situação para aceitar ou rejeitar o cartão. Esta verificação é feita por telefone.· Quando o quarto estiver limpo, após uma ocupação, o gerente torna-o disponível.

Ir p/ primeira página Antonio Francisco do Prado prado@dc.ufscar.br Engenharia de Software

Documents

Prado brochure

Barrio Prado

Denise Prado

Linguagens Concorrentes Antonio Francisco do Prado Prado@dc.ufscar.br

Prado Hidalgo

medilab prado

PRADO Diseño

Prado Maguillo

Julia prado

JornaldeLetrasn 02Mural Literário e dos Portais Poéticos que trazia Adélia Prado, escritora contemporânea, como primeira homenageada. E para os amantes da poesia, um Varal Poético

Personal Software Process Uma Visão Geral Profa. Sandra C. P. F. Fabbri e-mail sandraf@dc.ufscar.br 1o.semestre/1999

Rambla Prado

Fundamentos do Modelo Prado-MMGP - maturityresearch.com · Fundamentos do Modelo Prado-MMGP Darci Prado O modelo Prado-MMGP (Modelo de Maturidade em Gerenciamento de Projetos) foi

TOYOTA PRADO

Paulo Prado

Desenvolvimento de software PDS Revisão Projeto DBC prado@dc.ufscar.br DC - UFSCar

Mix-Net Filipe Nunes Ribeiro filipe_ribeiro@dc.ufscar.br

Normalização de Dados Profa. Dra. Marilde Santos Departamento de Computação – UFSCar marilde@dc.ufscar.br

AUTOR: JOSE JULIAN PRADO PRADO

Leoncio Prado