Projeto de Software

Projeto do Software

Wagner [email protected]

Projeto do Software 2

Agenda


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 – 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


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çã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.


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

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?

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

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;


Estruturação

Projeto de Software




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




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



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;


Estruturação

Projeto de Software





• 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





• 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



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


Estruturação

Projeto de Software



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;


Estruturação

Projeto de Software



ChavesArquitetura Qualidade NotaçõesQualidade


Estruturação

Projeto de Software




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




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




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




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




• 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

Wagner [email protected]

Documents

Projeto de Software