projeto de software
TRANSCRIPT
![Page 2: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/2.jpg)
Projeto do Software 2
Agenda
![Page 3: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/3.jpg)
Projeto do Software 3
Fundamentos
![Page 4: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/4.jpg)
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
![Page 5: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/5.jpg)
Projeto do Software 5
Escopo
Arquitetura Interfaces
Estrutura de Dados
Análise Projeto Construção ...... Projeto
Componentes
![Page 6: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/6.jpg)
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
![Page 7: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/7.jpg)
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
![Page 8: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/8.jpg)
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
![Page 9: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/9.jpg)
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
![Page 10: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/10.jpg)
Projeto do Software 10
Modelo – Abordagem Estruturada
Projeto de Dados
Projeto Arquitetural
Projeto da Interface
Projeto de Componentes
![Page 11: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/11.jpg)
Projeto do Software 11
Modelo – Abordagem OO
Projeto de Subsistemas
Projeto de Classes e Objetos
Projeto de Mensagens
Projeto de Responsabilidades
![Page 12: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/12.jpg)
Projeto do Software 12
Processo
![Page 13: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/13.jpg)
Projeto do Software 13
Processo – OOD1 Particionar modelo de análise
2Identificar a concorrência
3Alocar subsistemas
4Desenvolver o projeto para interface
5Escolher a estratégia para a gestão de dados
6Definir esquema de colaborações
7Definir o projeto do objeto
![Page 14: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/14.jpg)
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.
![Page 15: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/15.jpg)
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
![Page 16: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/16.jpg)
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.
![Page 17: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/17.jpg)
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.
![Page 18: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/18.jpg)
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
![Page 19: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/19.jpg)
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.
![Page 20: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/20.jpg)
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
![Page 21: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/21.jpg)
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).
![Page 22: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/22.jpg)
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.
![Page 23: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/23.jpg)
Projeto do Software 23
Especificação de OperaçãoNome da OperaçãoVerbo no infinitivo representando uma açãoNome da classe associadaNome da classe, a qual a operação pertenceDescrição da OperaçãoDetalha todos os serviços que a operação tem por objetivo realizarArgumentosNome DescriçãoNome que descreve a natureza do argumento significado de cada argumentoRetornoNome DescriçãoNome da informação resultante do processamento (execução) da operação
detalhar aqui o significado do retorno
Pré-CondiçõesOcorrência que deve acontecer antes da execução da operaçãoSemânticaDescrição da lógica da operaçãoPós-CondiçõesResultado produzido depois da execução da operaçãoExceçõesExceptions ocorridas durante a execução da operação. Aqui deve-se detalhar os tratamentos necessários para cada exception.
![Page 24: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/24.jpg)
Projeto do Software 24
Padrões
![Page 25: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/25.jpg)
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.
![Page 26: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/26.jpg)
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
![Page 27: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/27.jpg)
Projeto do Software 27
Padrões
GRASPProjetando 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?
![Page 28: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/28.jpg)
GRASP
Projeto do Software 28
Padrões
Information Expert
Creator
Indirection
Low Coupling
Pure Fabrication
Polymorhism
Controller
High Cohesion
Protected Variations
![Page 29: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/29.jpg)
Projeto do Software 29
Refatoração
![Page 30: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/30.jpg)
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
![Page 31: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/31.jpg)
Projeto do Software 31
Falta de recursos (tempo, dinheiro, etc.)
Motivos?
Falta de pessoal especializado
Assunto complexo
![Page 32: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/32.jpg)
Projeto do Software 32
Atualizar um sistema para melhorar a sua estrutura e legibilidade, sem alterar
o seu comportamento externo.
Refatorar
![Page 33: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/33.jpg)
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
![Page 34: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/34.jpg)
Projeto do Software 34
Código duplicado
Evitando
Método longo
Classe grande
Lista de parâmetros longa
Má indentação
![Page 35: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/35.jpg)
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
![Page 36: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/36.jpg)
Projeto do Software 36
Arquitetura
![Page 37: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/37.jpg)
Projeto do Software 37
Camadas
Apresentação Aplicação Dados
![Page 38: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/38.jpg)
Aplicação
Model
Browser
Projeto do Software 38
Camadas
Apresentação Dados
Controller
View
Servidor de Dados
Servidor Aplicação
Frameworks Transversais BD
![Page 39: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/39.jpg)
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.
![Page 40: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/40.jpg)
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
![Page 41: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/41.jpg)
Projeto do Software 41
Estruturação
![Page 42: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/42.jpg)
Projeto do Software 42
Estruturação*
* IEEE, 2004
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura Qualidade NotaçõesFundamentos
• Projeto Arquitetural: descreve como o software é decomposto e organizado em componentes;
• Projeto Detalhado: descreve o comportamento desses componentes;
![Page 43: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/43.jpg)
Projeto do Software 43
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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;
![Page 44: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/44.jpg)
Projeto do Software 44
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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;
![Page 45: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/45.jpg)
Projeto do Software 45
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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;
![Page 46: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/46.jpg)
Projeto do Software 46
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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;
![Page 47: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/47.jpg)
Projeto do Software 47
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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;
![Page 48: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/48.jpg)
Projeto do Software 48
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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);
![Page 49: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/49.jpg)
Projeto do Software 49
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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;
![Page 50: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/50.jpg)
Projeto do Software 50
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura Qualidade NotaçõesQualidade
![Page 51: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/51.jpg)
Projeto do Software 51
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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, ...)
![Page 52: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/52.jpg)
Projeto do Software 52
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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
![Page 53: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/53.jpg)
Projeto do Software 53
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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
![Page 54: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/54.jpg)
Projeto do Software 54
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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
![Page 55: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/55.jpg)
Projeto do Software 55
Estruturação
Projeto de Software
FundamentosEstratégias e
MétodosCaracterísticas
ChavesArquitetura 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
![Page 56: Projeto de Software](https://reader030.vdocuments.pub/reader030/viewer/2022032700/55d33e31bb61eb27048b4787/html5/thumbnails/56.jpg)
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