Projeto de Software

Projeto do Software
Wagner Zaparoli
wzaparoli@gmail.com

Projeto do Software 3
Fundamentos

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

Escopo
Arquitetura Interfaces
Estrutura de Dados
Análise Projeto Construção ...... Projeto
Componentes

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

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

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

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

Modelo – Abordagem Estruturada
Projeto de Dados
Projeto Arquitetural
Projeto da Interface
Projeto de
Componentes

Modelo – Abordagem OO
Projeto de Subsistemas
Projeto de Classes e Objetos
Projeto de Mensagens
Projeto de
Responsabilidades

Processo

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

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.

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

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.

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.

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

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.

Definir Projeto do Objeto
Processo para especificar os objetos, suas informações,
seu comportamento e sua interface
Objeto Instância da Classe

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

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.

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.

Padrões

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.

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

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
Padrões
Information
Expert
Creator
Indirection
Low Coupling
Pure
Fabrication
Polymorhism
Controller
High
Cohesion
Protected
Variations

Refatoração

É 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

Falta de recursos (tempo, dinheiro, etc.)
Motivos?
Falta de pessoal especializado
Assunto complexo

Atualizar um sistema para melhorar a
sua estrutura e legibilidade, sem alterar
o seu comportamento externo.
Refatorar

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

Código duplicado
Evitando
Método longo
Classe grande
Lista de parâmetros longa
Má indentação

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

Arquitetura

Camadas
Apresentação Aplicação Dados

Aplicação
Model
Browser
Camadas
Apresentação Dados
Controller
View
Servidor de
Dados
Servidor
Aplicação
Frameworks
Transversais BD

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.

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

Estruturação

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;

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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;

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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;

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;

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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;

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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;

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

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;

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
Arquitetura Qualidade NotaçõesQualidade

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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, ...)

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
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

Estruturação
Projeto de
Software
Fundamentos
Estratégias e
Métodos
Características
Chaves
• 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 de Software

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Projeto de Software

Mais de Wagner Zaparoli

Projeto de Software