SlideShare uma empresa Scribd logo
Projeto do Software
Wagner Zaparoli
wzaparoli@gmail.com
Projeto do Software 2
Agenda
Projeto do Software 3
Fundamentos
Projeto do Software 4
Definição
Atividade do ciclo de vida da engenharia de
software na qual os requisitos são analisados
com o objetivo de produzir uma descrição da
estrutura interna do software que sirva de
base à Construção
Arquitetura do software que apresenta a
decomposição e organização do software em
componentes e a interface entre esses
componentes
Processo
Resultado
Projeto do Software 5
Escopo
Arquitetura Interfaces
Estrutura de Dados
Análise Projeto Construção ...... Projeto
Componentes
Projeto do Software 6
Importância
Projeto é o único modo que se pode
traduzir precisamente os requisitos
Projeto serve como base para todas as
etapas posteriores do ciclo de vida
Projeto dá alma à qualidade do software
Projeto do Software 7
Competências
O projeto deve implementar todos os requisitos
contidos no modelo de análise
O projeto deve ser um guia inteligível para os
codificadores e testadores
O projeto deve fornecer um quadro completo do
software, focalizando aspectos informacionais,
funcionais e comportamentais
Projeto do Software 8
Princípios Básicos
O projeto não deve reinventar a roda (padrões)
O projeto deve exibir uniformidade e integração
O projeto deve ser avaliado quanto à qualidade, à medida que é criado
O projeto deve ser estruturado para permitir modificações
Projeto não é codificação
Projeto do Software 9
Conceitos
Abstração: transformação do mundo real em modelos
Refinamento: decompor um enunciado macroscópico de função em
enunciados menores
Modularidade: conceito de divisão do software em componentes, cada
um com um objetivo, que quando integrados satisfazem os requisitos do
problema
Ocultamento: técnica pela qual um componente torna inacessível a
outro, suas informações e comportamento
Coesão: técnica que torna um componente independente ou pouco
dependente de outros, através de sua especialização
Acoplamento: medida da interconexão entre componentes numa
estrutura de software
Projeto do Software 10
Modelo – Abordagem Estruturada
Projeto de Dados
Projeto Arquitetural
Projeto da Interface
Projeto de
Componentes
Projeto do Software 11
Modelo – Abordagem OO
Projeto de Subsistemas
Projeto de Classes e Objetos
Projeto de Mensagens
Projeto de
Responsabilidades
Projeto do Software 12
Processo
Projeto do Software 13
Processo – OOD
1 Particionar modelo de análise
2
Identificar a concorrência
3
Alocar subsistemas4
Desenvolver o projeto para interface
5
Escolher a estratégia para a gestão de dados
6
Definir esquema de colaborações
7
Definir o projeto do objeto
Projeto do Software 14
Particionar o Modelo
Definir coleções de classes, relacionamentos e
comportamentos coesivos, a serem empacotados como um
subsistema*
*Subsistema
• Deve possuir uma responsabilidade.
• Deve ter uma interface bem definida.
• Classes de um subsistema devem colaborar
apenas entre si.
• Um subsistema deve ser particionado para mitigar
a complexidade.
Projeto do Software 15
Identificar a Concorrência
Classes que precisam agir sobre eventos de modo
assíncrono e simultaneamente, são vistas como
concorrentes
Aloca-se cada
subsistema a um
processador
independente
Aloca-se os
subsistemas ao mesmo
processador e adota-se
suporte de
concorrência
ou
Projeto do Software 16
Alocar Subsistemas a Processadores e Tarefas
Tarefas normalmente são dirigidas por evento (interrupção
externa ao sistema) ou por relógio (interrupção por um
relógio do sistema).
Template
para
Identificação
do objeto
• Nome da Tarefa: o nome do objeto.
• Descrição: narrativa que descreve a finalidade do objeto.
• Prioridade: prioridade da tarefa (alta, média, baixa).
• Serviços: lista de operações sob responsabilidade do objeto.
• Coordenada por: modo pelo qual o comportamento do objeto é
invocado.
• Comunica-se através de: valores de dados de entrada e saída
relevantes para a tarefa.
Projeto do Software 17
Desenvolver o Projeto de Interface
Usa como entrada o diálogo entre sistema e ator descrito
nos casos de uso e os requisitos não funcionais de
usabilidade
Questões
Importantes
• Haverá funcionalidades críticas que exijam desempenho do usuário?
• Há a necessidade de tecnologia assistida?
• Qual é a taxa aceitável de erros (de operação) cometidos na execução
de funcionalidades específicas?
• Qual o tempo de aprendizagem para o domínio do uso do sistema?
Considerações
• Facilidade de aprender: associado ao tempo e esforço mínimo exigido
para alcançar um determinado nível de desempenho no uso do sistema.
• Facilidade de uso: relacionado à velocidade de execução de tarefas e à
redução de erros no uso do sistema.
Projeto do Software 18
Escolher a Estratégia para Gestão de Dados
Resume-se ao desenvolvimento do projeto dos atributos e
das operações necessárias para gerir (persistir) os objetos
• Construir o modelo de classes.
• Construir o modelo conceitual de dados.
• Construir o modelo lógico de dados.
• Construir o modelo físico de dados.
• Utilizar padrão DAO (Data Access Object) ou AR
(Active Record) para gerir operações primitivas de
acesso ao banco de dados.
Considerações
Projeto do Software 19
Definir Esquema de Colaboração
Colaboração é um meio de comunicação entre
subsistemas, endereçado por um contrato
Colaboração
• O contrato indica o modo que o subsistema deve
interagir.
• É manifestado por mensagens que se movem
entre os objetos dentro dos subsistemas.
• Deve conter as classes, operações e formato das
mensagens que implementam as interações entre
colaboradores.
Projeto do Software 20
Definir Projeto do Objeto
Processo para especificar os objetos, suas informações,
seu comportamento e sua interface
Objeto Instância da Classe
Projeto do Software 21
Especificação de Classe
Descrição: objetivos da classe sob a visão dos dados que serão armazenados e dos serviços que
serão prestados;
Regra de Integridade Referencial: regras de integridade que envolvem essa classe e as classes
a ela relacionadas (analisar a cardinalidade);
Regra de Processo: regras de processo de negócio que comporão os serviços prestados por esta
classe;
Atributos Identificadores: atributos identificadores desta classe.
Descrição: Esta classe tem por objetivo armazenar os dados dos clientes, sejam eles pessoas
física ou jurídica.
Regra de Integridade Referencial: Para excluir um registro de cliente, deve-se antes, excluir o
respectivo registro de endereço na classe EnderecoCliente.
Regra de Processo: Na inclusão de um novo cliente, caso seja pessoa física, validar CPF; caso
seja pessoa jurídica, validar CNPJ.
Atributos Identificadores: cd_cpf (para pessoas físicas); cd_cnpj (para pessoas jurídicas).
Projeto do Software 22
Especificação de Atributo
Descrição: detalhar aqui o significado e os objetivos do atributo em função de sua natureza;
Regra de Integridade do Valor do Dado: definir as restrições e regras que devem ser seguidas
em função do tipo do atributo;
Regra de Derivação: descrever aqui a origem do atributo, caso ele seja formado por outros
atributos, por uma fórmula, ou por qualquer origem que não seja ele próprio.
Descrição: valor da multa por atraso de pagamento.
Regra de Integridade do Valor do Dado: o valor da multa não pode ultrapassar o valor de
R$100,00.
Regra de Derivação: o valor da multa deve ser calculado da seguinte forma:
vl_multa_atraso = vl_fatura * i_atraso * nu_dias_atraso.
Projeto do Software 23
Especificação de Operação
Nome da Operação
Verbo no infinitivo representando uma ação
Nome da classe associada
Nome da classe, a qual a operação pertence
Descrição da Operação
Detalha todos os serviços que a operação tem por objetivo realizar
Argumentos
Nome Descrição
Nome que descreve a natureza do argumento significado de cada argumento
Retorno
Nome Descrição
Nome da informação resultante do processamento
(execução) da operação
detalhar aqui o significado do retorno
Pré-Condições
Ocorrência que deve acontecer antes da execução da operação
Semântica
Descrição da lógica da operação
Pós-Condições
Resultado produzido depois da execução da operação
Exceções
Exceptions ocorridas durante a execução da operação. Aqui deve-se detalhar os tratamentos
necessários para cada exception.
Projeto do Software 24
Padrões
Projeto do Software 25
Padrões
Representam uma solução conhecida para um
problema conhecido em um dado contexto
• Encapsulamento: um padrão encapsula um problema/solução bem definida.
• Generalidade: todo padrão deve permitir a construção de outras realizações a partir
deste padrão.
• Abstração: os padrões representam abstrações da experiência.
• Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
• Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto
nível podem ser compostos ou relacionados com padrões que endereçam problemas de
nível mais baixo.
Projeto do Software 26
Padrões
GoF
Gang of Four
Criação
(criação de objetos)
Estruturais
(tratam da associação entre
classes e objetos)
Comportamentais
(divisões de
responsabilidades entre
classes e objetos)
Abstract Factory
Builder
Prototype
Singleton
Adapter
Bridge
Decorator
Façade
Mediator
Memento
Observer
State
Projeto do Software 27
Padrões
GRASP
Projetando Objetos com
Responsabilidade
Fornecem uma abordagem
sistemática para a atribuição
de responsabilidades às
classes do projeto
• Quem deve ser responsável por criar uma nova instância de uma classe?
• Que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento",
mas as soluções oferecidas pelo "Especialista" não são apropriadas?
• Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a
possibilidade de reuso?
• Como tratar alternativas baseadas no tipo? Como criar componentes de software
"plugáveis"?
• Como manter os objetos focados, compreensíveis, gerenciáveis e, em conseqüência, com Baixo Acoplamento?
• Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma
operação?
• Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta
reutilização?
• Qual é o princípio geral para a atribuição de responsabilidades aos objetos?
GRASP
Projeto do Software 28
Padrões
Information
Expert
Creator
Indirection
Low Coupling
Pure
Fabrication
Polymorhism
Controller
High
Cohesion
Protected
Variations
Projeto do Software 29
Refatoração
Projeto do Software 30
É difícil de modificar
Software Mal Projetado
É difícil de entender onde as mudanças são
necessárias
Aumenta-se a probabilidade de erros ao se
modificar
Projeto do Software 31
Falta de recursos (tempo, dinheiro, etc.)
Motivos?
Falta de pessoal especializado
Assunto complexo
Projeto do Software 32
Atualizar um sistema para melhorar a
sua estrutura e legibilidade, sem alterar
o seu comportamento externo.
Refatorar
Projeto do Software 33
Para fazer com que o Software seja fácil de entender e
modificar
Por que utilizar?
Para manter o Software saudável ao acrescentar ou
alterar
funcionalidades
Para eliminar duplicidade de funcionalidade
Para ajudar a encontrar bugs
Para ajudar a desenvolver mais rápido
Projeto do Software 34
Código duplicado
Evitando
Método longo
Classe grande
Lista de parâmetros longa
Má indentação
Projeto do Software 35
Nomes significativos, que fazem sentido:
• confirmarSaldoCCClientePJInternet
• confirmarSaldoCCClientePFInternet
Bons Vícios
Funções tem de ser pequenas, com poucos
parâmetros e fazer uma coisa só
Comentários em excesso e que dizem o óbvio não
são legais
Formatação do código-fonte. Usar TABs são legais
Projeto do Software 36
Arquitetura
Projeto do Software 37
Camadas
Apresentação Aplicação Dados
Aplicação
Model
Browser
Projeto do Software 38
Camadas
Apresentação Dados
Controller
View
Servidor de
Dados
Servidor
Aplicação
Frameworks
Transversais BD
Projeto do Software 39
MVC – Conceito
Model: representa a lógica e os dados de domínio da aplicação ou as regras
nas quais os objetos de negócio deverão ser acionados. Provê a interface com
o Controller para o acesso das regras de negócio.
View: é utilizado para prover e formatar o conteúdo fornecido pelo Model. Deve
acessar os dados de domínio e definir como esses dados serão apresentados
na interface. Deve ainda prover ao Controller as interações com o usuário (um
clique de botão, um evento de alteração de estado de algum controle da
interface e etc.).
Controller: é responsável por definir e controlar o comportamento da aplicação,
como qual interface deve ser apresentada e como o fluxo de informações da
aplicação deverá ser disponibilizado para o usuário.
Projeto do Software 40
MVC – Tecnologia
Objeto
MVC
Tecnologia J2EE
Model • EJB (Enterprise Java Beans)
• Objetos Java
View • JSP
• Parte dos Frameworks para desenvolvimento Web, como
o JSF
Controller • Java Servlets
• Struts
• Alguns módulos de estruturas de Frameworks Web, como
o JSF
Projeto do Software 41
Estruturação
Projeto do Software 42
Estruturação*
* IEEE, 2004
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesFundamentos
• Projeto Arquitetural: descreve como o software é decomposto e
organizado em componentes;
• Projeto Detalhado: descreve o comportamento desses
componentes;
Projeto do Software 43
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesFundamentos
Técnicas Importantes
• Acoplamento e Coesão: força do relacionamento entre módulos e como os elementos que
compõem um módulo se relacionam;
• Decomposição e modularização: dividir e organizar o software em diferentes
funcionalidades;
• Encapsulamento: agrupar e empacotar elementos tornando os detalhes internos
inacessíveis;
Projeto do Software 44
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesFundamentos
Técnicas Importantes
• Separação – Interface/Implementação: envolve a definição de um componente para
especificar uma interface pública, separado dos detalhes de como esse componente é
realizado;
• Suficiência e Completude: significa garantir que os componentes do software capturam
todas as características para as quais foi desenhado e nada mais;
Projeto do Software 45
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade Notações
Características
Chaves
Propriedades que afetam o desempenho e a semântica dos
componentes
• Concorrência: define como decompor o software em processos, tarefas e passos de forma a
se manter a eficiência, atomicidade e sincronismo;
• Controle e Execução de Eventos: define como organizar dados, fluxos de controle, e
tratamento de eventos reativos e temporais utilizando mecanismos disponíveis;
Projeto do Software 46
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade Notações
Características
Chaves
• Distribuição de Componentes: define como distribuir o software ao longo do hardware, como
os componentes vão se comunicar e como o middleware pode ser utilizado para tratar
ambientes heterogêneos;
• Tratamento de erros: define como tratar erros, tolerar falhas e conviver com condições
especiais;
Projeto do Software 47
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade Notações
Características
Chaves
• Interação e Apresentação: define como organizar as interações com usuários e como
apresentar as informações (utilizando por exemplo, o Model-View-Controller);
• Persistência de dados: define, por exemplo, por quanto tempo os dados devem ser
mantidos e tratados;
Projeto do Software 48
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesArquitetura
Descreve os subsistemas e componentes de um software e a
relação entre eles
• Estrutura Arquitetural: pode ser dividida em visões, as quais apresentam um aspecto
específico da arquitetura (visão lógica – satisfação dos requisitos funcionais; visão de
processos – trata das características de concorrência; visão física – trata das características
de distribuição; visão de implementação – como o software é organizado por unidades de
implementação);
Projeto do Software 49
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesArquitetura
• Design Patterns (padrões de projeto): representam uma solução conhecida para um
problema conhecido em um dado contexto. Visualiza um nível mais detalhado da arquitetura.
• Padrões de criação: builder, factory, prototype, singleton;
• Padrões estruturais: adapter, bridge, composite, decorator, façade;
• Padrões comportamentais: command, iterator, mediator, memento, observer;
Projeto do Software 50
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesQualidade
Projeto do Software 51
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesQualidade
Análise da Qualidade
• Revisões formais dos artefatos de projetos
• Provas de conceito da arquitetura (ou componentes)
• Análise estática formal (fault-tree analysis, automated cross-checking,
rastreabilidade dos requisitos)
• Simulação ou prototipagem (desempenho, exeqüibilidade, ...)
Projeto do Software 52
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesQualidade
Métricas
Apoiam as estimativas de vários aspectos do software, como tamanho, estrutura
ou qualidade.
• Medidas orientadas a funções: são obtidas através da decomposição
funcional (diagrama hierárquico)
• Medidas orientadas a objetos: baseadas normalmente no diagrama de classes
e em cada classe especificamente
Projeto do Software 53
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade Notações
Descrição da Estrutura (visão estática)
• Diagrama de classes
• Diagrama de componentes
• CRCs (class responsability collaborator cards)
• Diagramas de implantação
• Diagramas de entidades e relacionamentos
• Linguagens para descrição de interfaces
Notações
Projeto do Software 54
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade Notações
Descrição do Comportamento (visão dinâmica)
• Diagrama de atividades
• Diagrama de colaboração
• Diagrama de fluxo de dados
• Tabelas de decisão
• Fluxogramas
• Diagrama de sequência
• Diagrama de estados
Notações
Projeto do Software 55
Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade Notações
• Projeto Orientado a Função: geralmente utilizado para abordagem estruturada, gera
produtos como diagrama de fluxo de dados e descrição de processos associados.
•Projeto Orientado a Objetos: utiliza a filosofia de manter num mesmo objeto, a estrutura e
o comportamento, maneira pela qual a realidade se manifesta. Gera inúmeros produtos
visuais, como diagrama de classes, sequência, colaboração, pacotes, etc.
• Projeto Ágil: entregas rápidas, resumidas a pequenas iterações. Pouca documentação,
resumidas às especificadas em código.
Métodos
Sugestões Bibliográficas
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable
Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995.
• Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development. 1 ed. Estados Unidos da América: Prentice Hall, 2004.
• Fowler, Martin. Refactoring: Improving the Design of Existing Code. Massachusetts: Addison Wesley,
2006.
• Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure. ISBN
1890367125.
• Project Management Institute. Project Management Institute Practice Standard for Work Breakdown
Structures. ISBN 1880410818.
• Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Estruturas Analíticas de Projeto . ISBN
9788521205043.
• Meyer, B. Object-Oriented Software Construction. New Jersey: Prentice Hall, 1988.
• Pressman, R. S. Engenharia de Software. 5. ed. São Paulo: Makron Books, 2002.
• Kosanski, N., Woods, E.. Software Systems Architecture: working with stakeholders using view points
and perspectives. New Jersey: Addison-Wesley, 2005.
Projeto do Software 56
Projeto do Software
Wagner Zaparoli
wzaparoli@gmail.com

Mais conteúdo relacionado

Mais procurados

Aula 4 banco de dados
Aula 4   banco de dados Aula 4   banco de dados
Aula 4 banco de dados
Jorge Ávila Miranda
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rafael Sanches
 
Aula 7 banco de dados
Aula 7   banco de dadosAula 7   banco de dados
Aula 7 banco de dados
Jorge Ávila Miranda
 
Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02
thomasdacosta
 
Algoritmos e Técnicas de Programação - Aula 01
Algoritmos e Técnicas de Programação - Aula 01Algoritmos e Técnicas de Programação - Aula 01
Algoritmos e Técnicas de Programação - Aula 01
thomasdacosta
 
Aula03 - JavaScript
Aula03 - JavaScriptAula03 - JavaScript
Aula03 - JavaScript
Jorge Ávila Miranda
 
Aula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de ProjetoAula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de Projeto
Daniela Brauner
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
Camilo Ribeiro
 
Aula 04 coneitos de auditoria de sistemas
Aula 04   coneitos de auditoria de sistemasAula 04   coneitos de auditoria de sistemas
Aula 04 coneitos de auditoria de sistemas
sorayaNadja
 
Linguagem C - Strings
Linguagem C - StringsLinguagem C - Strings
Linguagem C - Strings
Elaine Cecília Gatto
 
10 Java Script - Exemplos práticos
10 Java Script - Exemplos práticos10 Java Script - Exemplos práticos
10 Java Script - Exemplos práticos
Centro Paula Souza
 
Introdução básica ao JavaScript
Introdução básica ao JavaScriptIntrodução básica ao JavaScript
Introdução básica ao JavaScript
Carlos Eduardo Kadu
 
Estrutura de Dados - Aula 01
Estrutura de Dados - Aula 01Estrutura de Dados - Aula 01
Estrutura de Dados - Aula 01
thomasdacosta
 
Es capítulo 5 - modelagem de sistemas
Es   capítulo 5  - modelagem de sistemasEs   capítulo 5  - modelagem de sistemas
Es capítulo 5 - modelagem de sistemas
Felipe Oliveira
 
Aula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de Atividade
Alberto Simões
 
Ferramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de softwareFerramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de software
elliando dias
 
Aula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de ProjetoAula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de Projeto
Vinícius de Paula
 
Aula 1 requisitos
Aula 1   requisitosAula 1   requisitos
Aula 1 requisitos
licardino
 
Aula 01 - Algoritmo e Programação
Aula 01 - Algoritmo e ProgramaçãoAula 01 - Algoritmo e Programação
Aula 01 - Algoritmo e Programação
Aislan Rafael
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
Luís Fernando Richter
 

Mais procurados (20)

Aula 4 banco de dados
Aula 4   banco de dados Aula 4   banco de dados
Aula 4 banco de dados
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Aula 7 banco de dados
Aula 7   banco de dadosAula 7   banco de dados
Aula 7 banco de dados
 
Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02
 
Algoritmos e Técnicas de Programação - Aula 01
Algoritmos e Técnicas de Programação - Aula 01Algoritmos e Técnicas de Programação - Aula 01
Algoritmos e Técnicas de Programação - Aula 01
 
Aula03 - JavaScript
Aula03 - JavaScriptAula03 - JavaScript
Aula03 - JavaScript
 
Aula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de ProjetoAula03 - Termo de Abertura de Projeto
Aula03 - Termo de Abertura de Projeto
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
 
Aula 04 coneitos de auditoria de sistemas
Aula 04   coneitos de auditoria de sistemasAula 04   coneitos de auditoria de sistemas
Aula 04 coneitos de auditoria de sistemas
 
Linguagem C - Strings
Linguagem C - StringsLinguagem C - Strings
Linguagem C - Strings
 
10 Java Script - Exemplos práticos
10 Java Script - Exemplos práticos10 Java Script - Exemplos práticos
10 Java Script - Exemplos práticos
 
Introdução básica ao JavaScript
Introdução básica ao JavaScriptIntrodução básica ao JavaScript
Introdução básica ao JavaScript
 
Estrutura de Dados - Aula 01
Estrutura de Dados - Aula 01Estrutura de Dados - Aula 01
Estrutura de Dados - Aula 01
 
Es capítulo 5 - modelagem de sistemas
Es   capítulo 5  - modelagem de sistemasEs   capítulo 5  - modelagem de sistemas
Es capítulo 5 - modelagem de sistemas
 
Aula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de Atividade
 
Ferramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de softwareFerramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de software
 
Aula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de ProjetoAula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de Projeto
 
Aula 1 requisitos
Aula 1   requisitosAula 1   requisitos
Aula 1 requisitos
 
Aula 01 - Algoritmo e Programação
Aula 01 - Algoritmo e ProgramaçãoAula 01 - Algoritmo e Programação
Aula 01 - Algoritmo e Programação
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 

Destaque

C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
Facuuldade Norte Sul
 
Desenvolvimento de Software - Escopo, Solução
Desenvolvimento de Software - Escopo, Solução Desenvolvimento de Software - Escopo, Solução
Desenvolvimento de Software - Escopo, Solução
Jonathan Célio
 
Atitudes ágeis nas fases de um projeto de software - 2013
Atitudes ágeis nas fases de um projeto de software - 2013Atitudes ágeis nas fases de um projeto de software - 2013
Atitudes ágeis nas fases de um projeto de software - 2013
Gustavo Piccin
 
Mitos do Desenvolvimento de Software
Mitos do Desenvolvimento de SoftwareMitos do Desenvolvimento de Software
Mitos do Desenvolvimento de Software
guest2f8cba
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
Álvaro Farias Pinheiro
 
Projeto de software
Projeto de softwareProjeto de software
Projeto de software
Marcelo Yamaguti
 
Projeto de Interfaces - Aula 01
Projeto de Interfaces - Aula 01Projeto de Interfaces - Aula 01
Projeto de Interfaces - Aula 01
Carlos Rosemberg
 
Lista de Eventos
Lista de EventosLista de Eventos
Lista de Eventos
Dalbson Paulo
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de software
Sigelman Araujo
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
Felipe Goulart
 
Roteiro básico Projeto de Intervenção
Roteiro básico Projeto de IntervençãoRoteiro básico Projeto de Intervenção
Roteiro básico Projeto de Intervenção
Goretti Silva
 

Destaque (11)

C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
 
Desenvolvimento de Software - Escopo, Solução
Desenvolvimento de Software - Escopo, Solução Desenvolvimento de Software - Escopo, Solução
Desenvolvimento de Software - Escopo, Solução
 
Atitudes ágeis nas fases de um projeto de software - 2013
Atitudes ágeis nas fases de um projeto de software - 2013Atitudes ágeis nas fases de um projeto de software - 2013
Atitudes ágeis nas fases de um projeto de software - 2013
 
Mitos do Desenvolvimento de Software
Mitos do Desenvolvimento de SoftwareMitos do Desenvolvimento de Software
Mitos do Desenvolvimento de Software
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
 
Projeto de software
Projeto de softwareProjeto de software
Projeto de software
 
Projeto de Interfaces - Aula 01
Projeto de Interfaces - Aula 01Projeto de Interfaces - Aula 01
Projeto de Interfaces - Aula 01
 
Lista de Eventos
Lista de EventosLista de Eventos
Lista de Eventos
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de software
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Roteiro básico Projeto de Intervenção
Roteiro básico Projeto de IntervençãoRoteiro básico Projeto de Intervenção
Roteiro básico Projeto de Intervenção
 

Semelhante a Projeto de Software

Padrões de Projeto de Software
Padrões de Projeto de SoftwarePadrões de Projeto de Software
Padrões de Projeto de Software
Fabio Moura Pereira
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
Rodrigo Cândido da Silva
 
Zachman framework
Zachman frameworkZachman framework
Zachman framework
Joao Santos
 
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídosAula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Messias Batista
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
elliando dias
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
06-engenharia de softwere Análise e Projeto de Software.docx
06-engenharia de softwere Análise e Projeto de Software.docx06-engenharia de softwere Análise e Projeto de Software.docx
06-engenharia de softwere Análise e Projeto de Software.docx
JulioCesar371362
 
Tees Final
Tees FinalTees Final
Tees Final
Marcus Oliveira
 
Modelagem 16102006
Modelagem 16102006Modelagem 16102006
Modelagem 16102006
LEANDRO DE SOUZA RAMOS
 
Apresentação dissertação
Apresentação dissertaçãoApresentação dissertação
Apresentação dissertação
Dorgival Netto
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
Priscila Stuani
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
elliando dias
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Programação Oritentada a Aspecto
Programação Oritentada a AspectoProgramação Oritentada a Aspecto
Programação Oritentada a Aspecto
Benicio Ávila
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
Leinylson Fontinele
 
Logica de Programação Vitor Jose de Souza.pptx
Logica de Programação Vitor Jose de Souza.pptxLogica de Programação Vitor Jose de Souza.pptx
Logica de Programação Vitor Jose de Souza.pptx
JoseVitorSantanadeMe
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
Fco Edilson Nascimento
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Cloves da Rocha
 
Tendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de SoftwareTendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de Software
Norberto Santos
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semana
Gabriel Moura
 

Semelhante a Projeto de Software (20)

Padrões de Projeto de Software
Padrões de Projeto de SoftwarePadrões de Projeto de Software
Padrões de Projeto de Software
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
 
Zachman framework
Zachman frameworkZachman framework
Zachman framework
 
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídosAula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
06-engenharia de softwere Análise e Projeto de Software.docx
06-engenharia de softwere Análise e Projeto de Software.docx06-engenharia de softwere Análise e Projeto de Software.docx
06-engenharia de softwere Análise e Projeto de Software.docx
 
Tees Final
Tees FinalTees Final
Tees Final
 
Modelagem 16102006
Modelagem 16102006Modelagem 16102006
Modelagem 16102006
 
Apresentação dissertação
Apresentação dissertaçãoApresentação dissertação
Apresentação dissertação
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Programação Oritentada a Aspecto
Programação Oritentada a AspectoProgramação Oritentada a Aspecto
Programação Oritentada a Aspecto
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
Logica de Programação Vitor Jose de Souza.pptx
Logica de Programação Vitor Jose de Souza.pptxLogica de Programação Vitor Jose de Souza.pptx
Logica de Programação Vitor Jose de Souza.pptx
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
 
Tendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de SoftwareTendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de Software
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semana
 

Mais de Wagner Zaparoli

Early Warning Systems For Epidemic
Early Warning Systems For EpidemicEarly Warning Systems For Epidemic
Early Warning Systems For Epidemic
Wagner Zaparoli
 
Transformações_Corporativas
Transformações_CorporativasTransformações_Corporativas
Transformações_Corporativas
Wagner Zaparoli
 
Técnicas_Implementação
Técnicas_ImplementaçãoTécnicas_Implementação
Técnicas_Implementação
Wagner Zaparoli
 
Qualidade do Software
Qualidade do SoftwareQualidade do Software
Qualidade do Software
Wagner Zaparoli
 
Checklist para Avaliação da Documentação.PDF
Checklist para Avaliação da Documentação.PDFChecklist para Avaliação da Documentação.PDF
Checklist para Avaliação da Documentação.PDF
Wagner Zaparoli
 
Padrões_Desenvolvimento
Padrões_DesenvolvimentoPadrões_Desenvolvimento
Padrões_Desenvolvimento
Wagner Zaparoli
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
Wagner Zaparoli
 
Manutenção de Software
Manutenção de SoftwareManutenção de Software
Manutenção de Software
Wagner Zaparoli
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Wagner Zaparoli
 
Ciclo de Vida
Ciclo de VidaCiclo de Vida
Ciclo de Vida
Wagner Zaparoli
 
Gerenciamento_Projetos
Gerenciamento_ProjetosGerenciamento_Projetos
Gerenciamento_Projetos
Wagner Zaparoli
 

Mais de Wagner Zaparoli (11)

Early Warning Systems For Epidemic
Early Warning Systems For EpidemicEarly Warning Systems For Epidemic
Early Warning Systems For Epidemic
 
Transformações_Corporativas
Transformações_CorporativasTransformações_Corporativas
Transformações_Corporativas
 
Técnicas_Implementação
Técnicas_ImplementaçãoTécnicas_Implementação
Técnicas_Implementação
 
Qualidade do Software
Qualidade do SoftwareQualidade do Software
Qualidade do Software
 
Checklist para Avaliação da Documentação.PDF
Checklist para Avaliação da Documentação.PDFChecklist para Avaliação da Documentação.PDF
Checklist para Avaliação da Documentação.PDF
 
Padrões_Desenvolvimento
Padrões_DesenvolvimentoPadrões_Desenvolvimento
Padrões_Desenvolvimento
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
 
Manutenção de Software
Manutenção de SoftwareManutenção de Software
Manutenção de Software
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Ciclo de Vida
Ciclo de VidaCiclo de Vida
Ciclo de Vida
 
Gerenciamento_Projetos
Gerenciamento_ProjetosGerenciamento_Projetos
Gerenciamento_Projetos
 

Projeto de Software

  • 1. Projeto do Software Wagner Zaparoli wzaparoli@gmail.com
  • 3. Projeto do Software 3 Fundamentos
  • 4. Projeto do Software 4 Definição Atividade do ciclo de vida da engenharia de software na qual os requisitos são analisados com o objetivo de produzir uma descrição da estrutura interna do software que sirva de base à Construção Arquitetura do software que apresenta a decomposição e organização do software em componentes e a interface entre esses componentes Processo Resultado
  • 5. Projeto do Software 5 Escopo Arquitetura Interfaces Estrutura de Dados Análise Projeto Construção ...... Projeto Componentes
  • 6. Projeto do Software 6 Importância Projeto é o único modo que se pode traduzir precisamente os requisitos Projeto serve como base para todas as etapas posteriores do ciclo de vida Projeto dá alma à qualidade do software
  • 7. Projeto do Software 7 Competências O projeto deve implementar todos os requisitos contidos no modelo de análise O projeto deve ser um guia inteligível para os codificadores e testadores O projeto deve fornecer um quadro completo do software, focalizando aspectos informacionais, funcionais e comportamentais
  • 8. Projeto do Software 8 Princípios Básicos O projeto não deve reinventar a roda (padrões) O projeto deve exibir uniformidade e integração O projeto deve ser avaliado quanto à qualidade, à medida que é criado O projeto deve ser estruturado para permitir modificações Projeto não é codificação
  • 9. Projeto do Software 9 Conceitos Abstração: transformação do mundo real em modelos Refinamento: decompor um enunciado macroscópico de função em enunciados menores Modularidade: conceito de divisão do software em componentes, cada um com um objetivo, que quando integrados satisfazem os requisitos do problema Ocultamento: técnica pela qual um componente torna inacessível a outro, suas informações e comportamento Coesão: técnica que torna um componente independente ou pouco dependente de outros, através de sua especialização Acoplamento: medida da interconexão entre componentes numa estrutura de software
  • 10. Projeto do Software 10 Modelo – Abordagem Estruturada Projeto de Dados Projeto Arquitetural Projeto da Interface Projeto de Componentes
  • 11. Projeto do Software 11 Modelo – Abordagem OO Projeto de Subsistemas Projeto de Classes e Objetos Projeto de Mensagens Projeto de Responsabilidades
  • 12. Projeto do Software 12 Processo
  • 13. Projeto do Software 13 Processo – OOD 1 Particionar modelo de análise 2 Identificar a concorrência 3 Alocar subsistemas4 Desenvolver o projeto para interface 5 Escolher a estratégia para a gestão de dados 6 Definir esquema de colaborações 7 Definir o projeto do objeto
  • 14. Projeto do Software 14 Particionar o Modelo Definir coleções de classes, relacionamentos e comportamentos coesivos, a serem empacotados como um subsistema* *Subsistema • Deve possuir uma responsabilidade. • Deve ter uma interface bem definida. • Classes de um subsistema devem colaborar apenas entre si. • Um subsistema deve ser particionado para mitigar a complexidade.
  • 15. Projeto do Software 15 Identificar a Concorrência Classes que precisam agir sobre eventos de modo assíncrono e simultaneamente, são vistas como concorrentes Aloca-se cada subsistema a um processador independente Aloca-se os subsistemas ao mesmo processador e adota-se suporte de concorrência ou
  • 16. Projeto do Software 16 Alocar Subsistemas a Processadores e Tarefas Tarefas normalmente são dirigidas por evento (interrupção externa ao sistema) ou por relógio (interrupção por um relógio do sistema). Template para Identificação do objeto • Nome da Tarefa: o nome do objeto. • Descrição: narrativa que descreve a finalidade do objeto. • Prioridade: prioridade da tarefa (alta, média, baixa). • Serviços: lista de operações sob responsabilidade do objeto. • Coordenada por: modo pelo qual o comportamento do objeto é invocado. • Comunica-se através de: valores de dados de entrada e saída relevantes para a tarefa.
  • 17. Projeto do Software 17 Desenvolver o Projeto de Interface Usa como entrada o diálogo entre sistema e ator descrito nos casos de uso e os requisitos não funcionais de usabilidade Questões Importantes • Haverá funcionalidades críticas que exijam desempenho do usuário? • Há a necessidade de tecnologia assistida? • Qual é a taxa aceitável de erros (de operação) cometidos na execução de funcionalidades específicas? • Qual o tempo de aprendizagem para o domínio do uso do sistema? Considerações • Facilidade de aprender: associado ao tempo e esforço mínimo exigido para alcançar um determinado nível de desempenho no uso do sistema. • Facilidade de uso: relacionado à velocidade de execução de tarefas e à redução de erros no uso do sistema.
  • 18. Projeto do Software 18 Escolher a Estratégia para Gestão de Dados Resume-se ao desenvolvimento do projeto dos atributos e das operações necessárias para gerir (persistir) os objetos • Construir o modelo de classes. • Construir o modelo conceitual de dados. • Construir o modelo lógico de dados. • Construir o modelo físico de dados. • Utilizar padrão DAO (Data Access Object) ou AR (Active Record) para gerir operações primitivas de acesso ao banco de dados. Considerações
  • 19. Projeto do Software 19 Definir Esquema de Colaboração Colaboração é um meio de comunicação entre subsistemas, endereçado por um contrato Colaboração • O contrato indica o modo que o subsistema deve interagir. • É manifestado por mensagens que se movem entre os objetos dentro dos subsistemas. • Deve conter as classes, operações e formato das mensagens que implementam as interações entre colaboradores.
  • 20. Projeto do Software 20 Definir Projeto do Objeto Processo para especificar os objetos, suas informações, seu comportamento e sua interface Objeto Instância da Classe
  • 21. Projeto do Software 21 Especificação de Classe Descrição: objetivos da classe sob a visão dos dados que serão armazenados e dos serviços que serão prestados; Regra de Integridade Referencial: regras de integridade que envolvem essa classe e as classes a ela relacionadas (analisar a cardinalidade); Regra de Processo: regras de processo de negócio que comporão os serviços prestados por esta classe; Atributos Identificadores: atributos identificadores desta classe. Descrição: Esta classe tem por objetivo armazenar os dados dos clientes, sejam eles pessoas física ou jurídica. Regra de Integridade Referencial: Para excluir um registro de cliente, deve-se antes, excluir o respectivo registro de endereço na classe EnderecoCliente. Regra de Processo: Na inclusão de um novo cliente, caso seja pessoa física, validar CPF; caso seja pessoa jurídica, validar CNPJ. Atributos Identificadores: cd_cpf (para pessoas físicas); cd_cnpj (para pessoas jurídicas).
  • 22. Projeto do Software 22 Especificação de Atributo Descrição: detalhar aqui o significado e os objetivos do atributo em função de sua natureza; Regra de Integridade do Valor do Dado: definir as restrições e regras que devem ser seguidas em função do tipo do atributo; Regra de Derivação: descrever aqui a origem do atributo, caso ele seja formado por outros atributos, por uma fórmula, ou por qualquer origem que não seja ele próprio. Descrição: valor da multa por atraso de pagamento. Regra de Integridade do Valor do Dado: o valor da multa não pode ultrapassar o valor de R$100,00. Regra de Derivação: o valor da multa deve ser calculado da seguinte forma: vl_multa_atraso = vl_fatura * i_atraso * nu_dias_atraso.
  • 23. Projeto do Software 23 Especificação de Operação Nome da Operação Verbo no infinitivo representando uma ação Nome da classe associada Nome da classe, a qual a operação pertence Descrição da Operação Detalha todos os serviços que a operação tem por objetivo realizar Argumentos Nome Descrição Nome que descreve a natureza do argumento significado de cada argumento Retorno Nome Descrição Nome da informação resultante do processamento (execução) da operação detalhar aqui o significado do retorno Pré-Condições Ocorrência que deve acontecer antes da execução da operação Semântica Descrição da lógica da operação Pós-Condições Resultado produzido depois da execução da operação Exceções Exceptions ocorridas durante a execução da operação. Aqui deve-se detalhar os tratamentos necessários para cada exception.
  • 24. Projeto do Software 24 Padrões
  • 25. Projeto do Software 25 Padrões Representam uma solução conhecida para um problema conhecido em um dado contexto • Encapsulamento: um padrão encapsula um problema/solução bem definida. • Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão. • Abstração: os padrões representam abstrações da experiência. • Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe. • Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
  • 26. Projeto do Software 26 Padrões GoF Gang of Four Criação (criação de objetos) Estruturais (tratam da associação entre classes e objetos) Comportamentais (divisões de responsabilidades entre classes e objetos) Abstract Factory Builder Prototype Singleton Adapter Bridge Decorator Façade Mediator Memento Observer State
  • 27. Projeto do Software 27 Padrões GRASP Projetando Objetos com Responsabilidade Fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto • Quem deve ser responsável por criar uma nova instância de uma classe? • Que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento", mas as soluções oferecidas pelo "Especialista" não são apropriadas? • Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso? • Como tratar alternativas baseadas no tipo? Como criar componentes de software "plugáveis"? • Como manter os objetos focados, compreensíveis, gerenciáveis e, em conseqüência, com Baixo Acoplamento? • Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação? • Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização? • Qual é o princípio geral para a atribuição de responsabilidades aos objetos?
  • 28. GRASP Projeto do Software 28 Padrões Information Expert Creator Indirection Low Coupling Pure Fabrication Polymorhism Controller High Cohesion Protected Variations
  • 29. Projeto do Software 29 Refatoração
  • 30. Projeto do Software 30 É difícil de modificar Software Mal Projetado É difícil de entender onde as mudanças são necessárias Aumenta-se a probabilidade de erros ao se modificar
  • 31. Projeto do Software 31 Falta de recursos (tempo, dinheiro, etc.) Motivos? Falta de pessoal especializado Assunto complexo
  • 32. Projeto do Software 32 Atualizar um sistema para melhorar a sua estrutura e legibilidade, sem alterar o seu comportamento externo. Refatorar
  • 33. Projeto do Software 33 Para fazer com que o Software seja fácil de entender e modificar Por que utilizar? Para manter o Software saudável ao acrescentar ou alterar funcionalidades Para eliminar duplicidade de funcionalidade Para ajudar a encontrar bugs Para ajudar a desenvolver mais rápido
  • 34. Projeto do Software 34 Código duplicado Evitando Método longo Classe grande Lista de parâmetros longa Má indentação
  • 35. Projeto do Software 35 Nomes significativos, que fazem sentido: • confirmarSaldoCCClientePJInternet • confirmarSaldoCCClientePFInternet Bons Vícios Funções tem de ser pequenas, com poucos parâmetros e fazer uma coisa só Comentários em excesso e que dizem o óbvio não são legais Formatação do código-fonte. Usar TABs são legais
  • 36. Projeto do Software 36 Arquitetura
  • 37. Projeto do Software 37 Camadas Apresentação Aplicação Dados
  • 38. Aplicação Model Browser Projeto do Software 38 Camadas Apresentação Dados Controller View Servidor de Dados Servidor Aplicação Frameworks Transversais BD
  • 39. Projeto do Software 39 MVC – Conceito Model: representa a lógica e os dados de domínio da aplicação ou as regras nas quais os objetos de negócio deverão ser acionados. Provê a interface com o Controller para o acesso das regras de negócio. View: é utilizado para prover e formatar o conteúdo fornecido pelo Model. Deve acessar os dados de domínio e definir como esses dados serão apresentados na interface. Deve ainda prover ao Controller as interações com o usuário (um clique de botão, um evento de alteração de estado de algum controle da interface e etc.). Controller: é responsável por definir e controlar o comportamento da aplicação, como qual interface deve ser apresentada e como o fluxo de informações da aplicação deverá ser disponibilizado para o usuário.
  • 40. Projeto do Software 40 MVC – Tecnologia Objeto MVC Tecnologia J2EE Model • EJB (Enterprise Java Beans) • Objetos Java View • JSP • Parte dos Frameworks para desenvolvimento Web, como o JSF Controller • Java Servlets • Struts • Alguns módulos de estruturas de Frameworks Web, como o JSF
  • 41. Projeto do Software 41 Estruturação
  • 42. Projeto do Software 42 Estruturação* * IEEE, 2004 Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesFundamentos • Projeto Arquitetural: descreve como o software é decomposto e organizado em componentes; • Projeto Detalhado: descreve o comportamento desses componentes;
  • 43. Projeto do Software 43 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesFundamentos Técnicas Importantes • Acoplamento e Coesão: força do relacionamento entre módulos e como os elementos que compõem um módulo se relacionam; • Decomposição e modularização: dividir e organizar o software em diferentes funcionalidades; • Encapsulamento: agrupar e empacotar elementos tornando os detalhes internos inacessíveis;
  • 44. Projeto do Software 44 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesFundamentos Técnicas Importantes • Separação – Interface/Implementação: envolve a definição de um componente para especificar uma interface pública, separado dos detalhes de como esse componente é realizado; • Suficiência e Completude: significa garantir que os componentes do software capturam todas as características para as quais foi desenhado e nada mais;
  • 45. Projeto do Software 45 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Características Chaves Propriedades que afetam o desempenho e a semântica dos componentes • Concorrência: define como decompor o software em processos, tarefas e passos de forma a se manter a eficiência, atomicidade e sincronismo; • Controle e Execução de Eventos: define como organizar dados, fluxos de controle, e tratamento de eventos reativos e temporais utilizando mecanismos disponíveis;
  • 46. Projeto do Software 46 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Características Chaves • Distribuição de Componentes: define como distribuir o software ao longo do hardware, como os componentes vão se comunicar e como o middleware pode ser utilizado para tratar ambientes heterogêneos; • Tratamento de erros: define como tratar erros, tolerar falhas e conviver com condições especiais;
  • 47. Projeto do Software 47 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Características Chaves • Interação e Apresentação: define como organizar as interações com usuários e como apresentar as informações (utilizando por exemplo, o Model-View-Controller); • Persistência de dados: define, por exemplo, por quanto tempo os dados devem ser mantidos e tratados;
  • 48. Projeto do Software 48 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesArquitetura Descreve os subsistemas e componentes de um software e a relação entre eles • Estrutura Arquitetural: pode ser dividida em visões, as quais apresentam um aspecto específico da arquitetura (visão lógica – satisfação dos requisitos funcionais; visão de processos – trata das características de concorrência; visão física – trata das características de distribuição; visão de implementação – como o software é organizado por unidades de implementação);
  • 49. Projeto do Software 49 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesArquitetura • Design Patterns (padrões de projeto): representam uma solução conhecida para um problema conhecido em um dado contexto. Visualiza um nível mais detalhado da arquitetura. • Padrões de criação: builder, factory, prototype, singleton; • Padrões estruturais: adapter, bridge, composite, decorator, façade; • Padrões comportamentais: command, iterator, mediator, memento, observer;
  • 50. Projeto do Software 50 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesQualidade
  • 51. Projeto do Software 51 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesQualidade Análise da Qualidade • Revisões formais dos artefatos de projetos • Provas de conceito da arquitetura (ou componentes) • Análise estática formal (fault-tree analysis, automated cross-checking, rastreabilidade dos requisitos) • Simulação ou prototipagem (desempenho, exeqüibilidade, ...)
  • 52. Projeto do Software 52 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesQualidade Métricas Apoiam as estimativas de vários aspectos do software, como tamanho, estrutura ou qualidade. • Medidas orientadas a funções: são obtidas através da decomposição funcional (diagrama hierárquico) • Medidas orientadas a objetos: baseadas normalmente no diagrama de classes e em cada classe especificamente
  • 53. Projeto do Software 53 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Descrição da Estrutura (visão estática) • Diagrama de classes • Diagrama de componentes • CRCs (class responsability collaborator cards) • Diagramas de implantação • Diagramas de entidades e relacionamentos • Linguagens para descrição de interfaces Notações
  • 54. Projeto do Software 54 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Descrição do Comportamento (visão dinâmica) • Diagrama de atividades • Diagrama de colaboração • Diagrama de fluxo de dados • Tabelas de decisão • Fluxogramas • Diagrama de sequência • Diagrama de estados Notações
  • 55. Projeto do Software 55 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações • Projeto Orientado a Função: geralmente utilizado para abordagem estruturada, gera produtos como diagrama de fluxo de dados e descrição de processos associados. •Projeto Orientado a Objetos: utiliza a filosofia de manter num mesmo objeto, a estrutura e o comportamento, maneira pela qual a realidade se manifesta. Gera inúmeros produtos visuais, como diagrama de classes, sequência, colaboração, pacotes, etc. • Projeto Ágil: entregas rápidas, resumidas a pequenas iterações. Pouca documentação, resumidas às especificadas em código. Métodos
  • 56. Sugestões Bibliográficas • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. • Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 1 ed. Estados Unidos da América: Prentice Hall, 2004. • Fowler, Martin. Refactoring: Improving the Design of Existing Code. Massachusetts: Addison Wesley, 2006. • Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure. ISBN 1890367125. • Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures. ISBN 1880410818. • Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Estruturas Analíticas de Projeto . ISBN 9788521205043. • Meyer, B. Object-Oriented Software Construction. New Jersey: Prentice Hall, 1988. • Pressman, R. S. Engenharia de Software. 5. ed. São Paulo: Makron Books, 2002. • Kosanski, N., Woods, E.. Software Systems Architecture: working with stakeholders using view points and perspectives. New Jersey: Addison-Wesley, 2005. Projeto do Software 56
  • 57. Projeto do Software Wagner Zaparoli wzaparoli@gmail.com