Princípios e Conceitos de Software(v2)

Slides:



Advertisements
Apresentações semelhantes
Desenvolvimento de aplicativos Orientados a Objetos: Definição e Características THIAGO IDEALI.
Advertisements

Introdução a Algoritmos
ENGENHARIA DE SOFTWARE Garantia de Qualidade de Software
Engenharia de Software
Engenharia de Software
Especificação de Requisitos
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO ENGENHARIA DE SOFTWARE Métricas de Software Prof.ª Adriana dos Santos Caparróz Carvalho.
Teste de Software.
Identificando requisitos
Projeto conceitual Mostra ao cliente exatamente o que o sistema fará
Engenharia de Software
Orientação por Objectos > Modelo de Processo OO > Identificação de Classe e Objectos Aula 12.
João Carlos Porto Orientadora: Prof.ª Dr.ª Junia Coutinho Anacleto 26/03/2010 Projeto de interceo.
FACULDADE DOS GUARARAPES
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
Técnicas eTipos de Requisitos
Adélia Barros Requisitos Adélia Barros
Professora: Aline Vasconcelos
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
Análise Estruturada O mais amplamente usado dos métodos de modelagem de requisitos Modelos que retratam fluxo e o conteúdo da informação (dados e controle)
Tecnologia da Informação Orientação a Aspectos
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
RUP: Fluxo de Análise e Projeto
Modelagem de Interações
Plano de Projeto de Software
Principios e Conceitos de Projeto
Engenharia de Software
Copyright Marcos L. Chaim 2005 Princípios de Projeto de Software Orientado a Objetos Segundo Semestre 2005 Marcos L. Chaim ACH Turma 02 EACH – USP.
ANÁLISE DE REQUISITOS DE ENGENHARIA DE SOFTWARE
Fluxograma.
Separation of Concerns (SoC)
Prof.Alfredo Parteli Gomes
Fundamentos de Engenharia de SW
Arquitetura de software
Conceitos.
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Análise e Projeto de Sistemas
REQUIREMENTS DEVELOPMENT DESENVOLVIMENTO DE REQUISITOS
Estilos de Arquitetura- uma outra visão
Projeto de Banco de Dados
PSBD II Projeto de Sistemas de Banco de Dados II
UTFPR – Campus Curitiba - DAELN Cursos de Eng. Eletrônica/Eng
Campus de Caraguatatuba Aula 2: Introdução a Tecnologia de BD
RUP - Cap. 4 – Processo Centrado na Arquitetura
METODOLOGIA, MÉTODOS E FERRAMENTAS
Aula01 – Técnicas de Programação II
Requisitos de Software
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
Engenharia de Software
Testes de SW Aula 24.
Padrões de projeto M.Sc. Sílvio Bacalá Jr..
Introdução a Orientação a Objetos
Arquitetura de Software Projetos de Interface
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula /08/2012 Professor Leomir J. Borba-
Silvia Regina Vergilio - UFPR
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Semana /08/2012 Professor Leomir J. Borba-
Profa. Reane Franco Goulart. É uma representação de engenharia de algo que vai ser construído. Para a engenharia de software o projeto foca em quatro.
Projeto de Banco de Dados
Módulo II Capítulo 1: Orientação a Objetos
Professora Michelle Luz
PROCESSOS DECISÓRIOS PD MODELOS DE TOMADA DE DECISÃO – MODELO RACIONAL
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
Princípios de Análise 1. O domínio de informação de um problema deve ser representado e compreendido. 2. Modelos que descrevam a informação, função e comportamento.
TÉCNICAS DE ESTIMATIVAS
Técnicas e Tipos de Requisitos
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Modelagem de Banco de Dados: Conceitos
Transcrição da apresentação:

Princípios e Conceitos de Software(v2) Compreender os fundamentos de projeto de software

Agenda Conceitos de Projetos. Projeto Modular Efetivo. Heurísticas de Projeto para Modularidade efetiva.

Conceitos de Projetos Abstração Refinamento Modularidade Arquitetura de Software Hierarquia de Controle Particionamento estrutural Estrutura de dados Procedimento de Software Ocultamento da informação

Abstração Quando consideramos uma solução modular para qualquer problema, muitos níveis de abstração pode ser levantados. No nível mais alto de abstração, uma solução é enunciada em termos amplos usando a linguagem de ambiente do problema. Nos níveis mais baixos de abstração, uma orientação procedimental é adotada.

Refinamento Um programa é desenvolvimento pelo refinamento sucessivo de níveis de detalhes procedimentais. Refinamento é na verdade um processo de elaboração. Começamos com um enunciado da função(ou descrição da informação) que é definida em alto nível de abstração. Isto é, o enunciado descreve a função ou informação conceitualmente, mas não fornece qualquer informação sobre o funcionamento interno da função ou a estrutura interna da informação. O refinamento leva o projetista a elaborar o enunciado original, fornecendo mais e mais detalhes à medida que cada refinamento(elaboração) ocorre.

Abstração e Refinamento Abstração e refinamento são conceitos complementares. A abstração permite ao projetista especificar procedimentos e dados e ainda suprimir detalhes de baixo nível. O refinamento ajuda o projetista a revelar detalhes de baixo nível à proporção que o projeto progride. Ambos os conceitos ajudam o projetista a criar um modelo completo de projeto à medida que o projeto evolui.

Modularidade Isto é o software é dividido em partes nomeados separadamente e endereçaveis, frequentemento chamados de módulos, que são integrados para satisfazer os requisitos do problema.

Hierarquia de Controle Hierarquia de controle, também chamada estrutura de programa, representa a organização dos componentes de programa(módulos) e implica uma hierarquia de controle.

Particionamento estrutural Se o estilo arquitetural de um sistema hierárquico, as estruturas do programas podem ser particionadas tanto horizontalmente quanto verticalmente. Particionamento horizontal, define ramos separados da hierarquia modular para cada função principal do programa Particionamento vertical, sugere que o controle(tomada de decisão) e o trabalho sejam distribuídos de maneira descendente na estrutura do programa. Os módulos de nível alto devem desempenhar funções de controle e fazer pouco trabalho de processamento real. Módulos que se situam abaixo na estrutura devem ser os trabalhadores, realizando todas as tarefas de entrada, de computação e de saída.

Estrutura de Dados Estrutura de Dados é uma representação do relacionamento lógico entre elementos de dados individuais. Como a estrutura da informação vai invariavelmente afetar o projeto procedimental final, a estrutura de dados é tão importante quanto a estrutura do programa para a representação da arquitetura de software. A estrutura de dados determina a organização, os métodos de acesso, o grau de associatividade e as alternativas de processamento da informação.

Procedimento de Software O procedimento de software focaliza os detalhes de processamento de cada módulo individualmente. O procedimento deve fornecer uma especificação precisa do processamento, incluindo sequencia de eventos, pontos exatos de decisão, operações repetitivas e até organização e estrutura de dados.

Ocultamento da Informação Ocultamento implica que efetiva modularidade pode ser conseguida pela definição de um conjunto de módulos independentes que informam uns aos outros apenas o necessário para realizar uma função do software.

Abstração X Ocultamento Abstração ajuda a definir as entidades procedimentais(ou informacionais) que constituem o software. Ocultamento define e impõe restrições de acesso, tanto a detalhes de processamento dentro de um módulo quanto a qualquer estrutura de dados local usada pelo módulo.

Projeto Modular Efetivo Todos os conceitos fundamentais de projeto descrito anteriormente servem para induzir projetos modulares. Um projeto modular reduz a complexidade, facilita a modificação(um aspecto critico da manutenibilidade de software) e resulta em implementação mais fácil pelo incentivo ao desenvolvimento paralelo de diferentes partes de um sistema. Alguns conceitos usados em Projeto Modular. Independência Funcional Coesão Acoplamento

Independência funcional O conceito de independência funcional é uma decorrência direta da modularidade dos conceitos de abstração e ocultamento funcional A independência funcional é conseguida pelo desenvolvimento de módulos com função de “finalidade única” e uma “aversão” a interação excessiva com outros módulos.

Independência funcional Dito de outro modo, queremos projetar software de maneira que cada módulo cuide de uma subfunção específica dos requisitos e tenha uma interface simples quando visto de outras partes da estrutura do programa. Módulos independentes são mais fáceis de manter(e testar) porque os efeitos secundários causados por modificação de projeto ou código são limitados, a propagação de erros é reduzida e os módulos reusáveis são possíveis.

Independência funcional Para resumir, independência funcional é a chave para um bom projeto, e o projeto é a chave da qualidade de software. Independência é medida usando dois critérios qualitativos: coesão e acoplamento.

Coesão Um modulo coeso realiza uma única tarefa dentro de um procedimento de software, requerendo pouca interação com procedimentos que estão sendo realizados em outras partes de um programa. Um módulo coeso deveria (idealmente) fazer apenas uma coisa. Altamente coeso: Excelente. Baixa coesão: Problemas

Acoplamento Acoplamento é uma medida da interconexão entre módulos numa estrutura de software. O acoplamento depende da complexidade da interface entre módulos, do ponto em que é feita entrada ou referência a um módulo e que dados passam através da interface. Em projeto de software, lutamos por acoplamento mais baixo possível. Conectividade simples entre módulos resulta em software bem mais fácil de entender e menos propenso a “efeito de propagação” que acontece quando erros que ocorrem em um lugar se propagam por todo o sistema.

Heurísticas de Projeto para Modularidade efetiva A estrutura do programa pode ser manipulada de acordo com o seguinte conjunto de heurísticas: (Heurística, popularmente falando, trata-se de um método não comprovado cientificamente, ou seja, não tem confirmação matemática. Portanto, uma decisão tomada por experiência na função, intuição, bom senso ou outra forma que não seja confirmada por um método matemático, trata-se de confirmação heurística)

Heurísticas de Projeto para Modularidade efetiva 1. Avalie a “primeira iteração” da estrutura do programa para reduzir o acoplamento e melhorar a coesão: Uma vez desenvolvida a estrutura do programa, os módulos podem ser explodidos ou implodidos com o objetivo de melhorar a independência modular. Um módulo explodido transforma-se em dois ou mais módulos na estrutura final do programa. Um módulo implodido é o resultado da combinação do processamento implícito em dois ou mais módulos.

Heurísticas de Projeto para Modularidade efetiva 2. Avalie as interfaces do módulo para reduzir a complexidade e redundância e aperfeiçoar a consistência: A complexidade de interface de um módulo é uma causa importante de erros de software. Interfaces devem ser projetadas para passar informação de modo simples e devem ser consistentes com a função do módulo.

Heurísticas de Projeto para Modularidade efetiva 3. Defina módulos cuja função seja previsível, mas evite módulos que são excessivamente restritivos. Um módulo que restringe o processamento a uma única subfunção exibe alta coesão e é visto favoravelmente por um projetista.

Heurísticas de Projeto para Modularidade efetiva 4. Procure obter módulos “de entrada controlada” evitando “conexões patológicas”. Um software é mais fácil de entender e consequentemente mais fácil de manter quando as interfaces de módulos são restritas e controladas. Conexão patológica refere-se a desvios ou referências no meio de um módulo.

Bibliografia Pressman Capitulo 10.