Engenharia de Software

Engenharia de Software
Graduação em Engenharia de Sistemas e Computação Faculdade de Engenharia Universidade do Estado do Rio de Janeiro UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Engenharia de Software [1]
Def1.: é a parte da Ciência da Computação que lida com a construção de Sistemas de Software que são grandes e complexos, de modo que são desenvolvidos por equipes de engenheiros (analistas e programadores). Estes Sistemas de Software existem em múltiplas versões e são usados por vários anos. Def2. [Parnas – 1987]: compreende a construção de software com múltiplas versões, envolvendo vários indivíduos. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A atividade de programação é individual, enquanto a Engenharia de Software é uma atividade de equipe. Mesmo para especificar o que um sistema de software deve fazer, não existem métodos de aceitação generalizada. Abordagem: apresentar alguns princípios gerais que são essenciais para o desenvolvimento de software. Princípios são mais importantes que metodologias ou notações particulares usadas para o desenvolvimento de software. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Sistema Sistema de software UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Engenharia de Software requer uma visão geral da área de Engenharia de Sistemas; É preciso que o engenheiro de software tenha envolvimento com os requisitos inicialmente formulados para o sistema (do qual o software é parte) como um todo; Requer um conhecimento da área de aplicação; Lembrar que em qualquer área da engenharia deve-se observar compromissos. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Visão histórica da ES [1]
Inicialmente implementação de alguns algoritmos (via seqüência de instruções) bem definidos (ainda que eventualmente complexos). Gradativamente foram surgindo projetos de software de grandes dimensões (Ex. Sistema SABRE na década de 60, IBM OS 360, etc.) Constatou-se dificuldades na aplicação das técnicas utilizadas no desenvolvimento de projetos de pequeno porte em projetos de grande porte (scalability). De uma forma geral, os projetos de grande porte ultrapassavam os custos e o tempo inicialmente previstos para a sua conclusão. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Profundas alterações no custo de hardware X custo de software Custo Total do Sistema (US$) HW (US$) SW (US$) t UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Mudanças nos requisitos iniciais do sistema pareciam afetar diversas partes do projeto (efeito cascata). Diversas soluções foram aventadas: Aprimorar as técnicas gerenciais; Novas formas de se organizar equipes; Melhores linguagens e ferramentas; Adoção de padrões (ex.: convenções para codificação dos programas, documentação, etc.); Consenso final: A construção de software deveria ser abordada de forma similar à de outros sistemas complexos de grande porte, tais como: pontes, refinarias, fábricas, navios e aviões. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A abordagem de engenharia no desenvolvimento de software requer: Gerência Organização Ferramentas Teorias Metodologias Técnicas UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

O Engenheiro de Software
Precisa dominar: Programming in the small Programming in the large UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

© Oscar Luiz Monteiro de Farias
Conhecimentos do ES [1] Programming in the small Conhecimento de LPs Estrutura de Informação Algoritmos Inteligência UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Conhecimentos do ES [2] Programming in the large Familiar com diversas abordagens de projetos Traduzir requisitos vagos em especificações precisas Ter conhecimento (ou capacidade de rapidamente adquirir conhecimento) do domínio de aplicação Capacidade de transitar entre os diferentes níveis de abstração exigido nas várias fases do projeto Técnicas de Modelagem Facilidade de Comunicação e de lidar com pessoas Capacidade de planejar o trabalho (scheduling) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Ciclo de Vida do SW Def.: Conjunto de fases associadas ao desenvolvimento e manutenção do software. Em cada fase desenvolve-se alguma parte do sistema ou algo associado ao sistema (ex.: plano de teste, manual do usuário, etc.) No modelo waterfall cada fase possui pontos de início e fim e outputs bem definidos. Existem outros modelos de ciclo de vida UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Ciclo de Vida do SW - Modelo Waterfall
Análise de Requisitos e Especificação Projeto (arquitetura e detalhado) Codificação e Teste de Módulos Integração e Teste do Sistema Entrega do SW e Manutenção UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

ES x Ciência da Computação
Linguagens de Programação Sistemas Operacionais Banco de Dados Inteligência Artificial Modelos Teóricos ES x Outras Disciplinas: Gerenciamento Engenharia de Sistemas UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Engenharia de Software
Princípios de Engenharia Aplicados a Diferentes produtos de software 10 passo: Discernir um conjunto de qualidades que caracterizam os produtos 20 passo: Descobrir que princípios devem ser aplicados para se desenvolver sw com as qualidades desejadas. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Natureza e Qualidades do SW
Maleabilidade (Contudo uma alteração no software deve ser encarada como uma mudança que afeta desde o projeto até o código gerado) Atividade mão-de-obra intensiva (todavia requer mais “engenheiros” do que pessoal tradicionalmente dedicado à manufatura) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Qualidades do SW - Perspectivas
Gerente do Projeto (produtividade e facilidade de controle) Software Usuário (confiabilidade, facilidade de uso, eficiência) Desenvolvedor (verificabilidade, manutenabilidade, portabilidade, extensibilidade) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Qualidades Externas x Internas
Qualidades externas: são aquelas visíveis aos usuários. Qualidades internas: são as que dizem respeito aos desenvolvedores do sistema. As qualidades internas lidam, em grande parte, com a estrutura do software e ajudam os desenvolvedores a atingir as qualidades externas. As qualidades internas são necessarias para se atingir a confiabilidade (reliability) do sw. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Processo x Produto de Software
Processo de Software: o conjunto de atividades desenvolvidas durante a produção de sw. Gerenciamento de Configuração: é a parte do processo de produção de sw que é voltado para a manutenção e controle das relações entre as várias versões de um produto de sw aí incluídos os seus diversos módulos. Ferramentas de gerenciamento de configuração possibilitam a manutenção de famílias de produtos e seus respectivos componentes. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Qualidades Principais:
[1] Def.: Correctness: Um programa é dito funcionalmente correto se ele se comporta de acordo com as especificações das funções que ele deve prover (functional requirements specifications). Conseqüências da definição de correctness:  Assume que a especificação do sistema está disponível.  Que é possível determinar de forma não ambígua se um programa está conforme ou não às especificações. Correctness é uma propriedade matemática que estabelece uma equivalência entre o sw e a sua especificação. Correctness especificação formal e testes. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Qualidades do Software [2]
[2] Def.: Reliability (Confiabilidade): Informalmente, um sw é reliable se o usuário pode depender dele. Def.: Reliability: a probabilidade de que o sw irá operar de acordo com o esperado dentro de um intervalo de tempo especificado. Espera-se que os produtos de engenharia sejam confiáveis (sw ainda não atingiu este estágio – ex.: Produtos são liberados para o mercado com lista de bugs). UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Qualidades do Software [2]...
Reliability Correctness UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[3] Def.: Robustness (Robustez): Um sistema é dito robusto se ele comporta-se “razoavelmente”, ainda que em circunstâncias que não foram antecipadas na especificação dos requisitos do sistema. Atenção! Se pudéssemos estabelecer precisamente o que deveríamos fazer para tornar uma aplicação robusta, seríamos capazes de especificar o seu comportamento “razoável” completamente. Neste caso robustness seria equivalente a correctness ou ainda a reliability (no sentido do slide anterior). UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[4] Def.: Performance: qualidade intimamente associada com eficiência. Um sistema de software é eficiente se ele usa os recursos computacionais economicamente. Performance afeta: a utilização do software a escalabilidade do software Abordagens para se avaliar a performance de um sistema: 1) análise da complexidade dos algoritmos; 2) medidas (via monitores); 3) simulação. Aplicada a processo, performance = produtividade UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[5] Def.: User Friendliness: um sistema de software é dito “user friendly” (amigável ao usuário), quando os seus usuários humanos acham-no de fácil utilização. A interface com o usuário é um dos importantes componentes da user friendliness. Importância do desenho industrial e psicologia. Em diversas áreas da engenharia alcança-se a facilidade de uso através da padronização da interface humana. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[6] Def.: Verificabilidade: qualidade de um sistema de software em que as suas propriedades são facilmente verificáveis. Pode-se verificar as propriedades de um sistema através de: métodos de análise formais testes (uso de monitores de software) Projeto modular, disciplina na codificação e uso de LP´s apropriadas contribuem para a verificabilidade. É uma qualidade interna. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[7] Def.: Maintainability (mantenubilidade): O termo manutenção de software é normalmente utilizado para se referir a modificações que são feitas a um sistema de software após o seu release inicial (i.e., após ter sido disponibilizado para o seu público alvo). A manutenção pode ser: corretiva, adaptativa e perfectiva. Manutenção corretiva: trata da remoção dos erros residuais presentes no software após a sua entrega, ou dos erros introduzidos durante a própria manutenção. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Manutenção adaptativa:compreende o ajuste da aplicação a alterações no seu ambiente (ex. adaptaçõ a um novo sistema operacional, a novos dispositivos legais, etc.) Manutenção perfectiva:compreende a alteração do software, de modo a melhorar a sua qualidade (ex.: acrescentar novas funções ao software de modo a facilitar o seu uso). Existem evidências de que os custos de manutenção excedem a 60% do custo total do software. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[8] Def.: Repairability: um sistema de software é dito reparável quando ele permite a correção de seus defeitos com uma quantidade limitada de trabalho. Na engenharia tradicional uma técnica para se tornar os produtos reparáveis é o uso de partes e peças padrão que possam ser facilmente substituíveis. Repairability é afetada pelo número de componentes do produto. Em software aumenta-se a reparabilidade através de técnicas adequadas de modularização e do uso de ferramentas adequadas (ex.: LPs de alto nível) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[9] Def.: Evolvability: trata-se da capacidade de um sistema de software de incorporar alterações ao seu projeto original, de modo a incorporar novas funções ou alterar funções já existentes. Estudos demonstram que a evolvability decresce a cada novo release de um produto de software. Desde a concepção inicial do produto deve-se levar em consideração a capacidade de evolução do produto. É uma das mais impportantes qualidades do sw. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[10] Def.: Reusability: trata-se de uma qualidade mais aplicável aos componentes de um sistema de software que ao sistema como um todo. É a capacidade de se usar módulos/componentes de software já existentes, a fim de se construir novos produtos. Exs.: bibliotecas científicas, classes do JDK, etc. É uma qualidade difícil de se conseguir a posteriori. Deve-se procurar alcançá-la à medida que os próprios componentes vão sendo construídos. A reusabilidade pode se dar em vários níveis: i) pessoas – conhecimento do domínio da aplicação; ii) requisitos do sistema; iii) módulos; iv) código. Aplica-se ao produto (sw) e ao processo (metodologias de software, ciclo de vida). UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[11] Def.: Portability: é a capacidade de um sistema de software ser executado em diferentes ambientes. Mesmo que restrita a uma mesma família de processadores, a portabilidade é importante, em virtude de variações no conjunto de instruções e na capacidade de memória. Há necessidade de técnicas que permitam ao sw determinar as capacidades do hw e se adaptar às mesmas. Ex. Java, padrões do tipo SQL. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[12] Def.: Understandability: é a facilidade com que um sistema de software é compreendido, levando-se em conta, naturalmente, que alguns tipos de sistemas são mais complexos que outros. Understandability é uma qualidade com aspectos internos e externos. Do ponto de vista interno ajuda a alcançar outras qualidades, tais como evolvability e verifiability. Do ponto de vista externo, o usuário considerará um sistema compreensível se ele possuir um comportamento previsível e for user friendly. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[13] Def.: Interoperability: diz respeito à habilidade de um sistema coexistir e cooperar com outros sistemas. O ambiente UNIX, encoraja as aplicações a possuir uma interface simples e padrão, o que permite que a saída de uma aplicação seja usada como entrada para outra aplicação. Interoperability pode ser atingida através da padronização de interfaces. Open System: é uma coleção extensível de aplicações independentes que cooperam entre si para formar um sistema integrado. Permite que organizações independentes adicionem novas funcionalidades após a entrega do sistema ao mercado. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[14] Def.: Produtividade: é uma qualidade do processo de produção de software. É a qualidade de performance aplicada ao processo de software. Trade-offs – Ex.: a programação de módulos reusáveis é mais difícil e implica em menor produtividade no desenvolvimento de software. Necessidade de métricas para se medir a produtividade do software ou qualquer outra qualidade. Ferramentas especiais têm um impacto positivo sobre a produtividade (ex,: ferramentas CASE, LPs de alto nível, emprego de determinadas metodologias, etc.) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[15] Def.: Timeliness: trata-se da habilidade de se entregar um produto no tempo aprazado para tal. Timeliness requer um planejamento cuidadoso, uma estimativa apropriada do trabalho a ser realizado e marcos (milestones) especificados e verificáveis (do trabalho já desenvolvido). Problemas: dificuldade de se mensurar a produtividade dos desenvolvedores de sw; falta de métricas adequadas; uso de marcos imprecisos e não verificáveis; alteração contínua dos requisitos do sistema. Incremental delivery UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

função Requisitos do usuário Sistema real tempo t0 t t t t4 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[16] Def.: Visibilidade: Um processo de desenvolvimento de sw é visível se todas as suas etapas e o seu estado corrente estão claramente documentados, i. e., estão facilmente disponíveis para um exame (análise) externo. a especificação dos requisitos do sistema e dos requisitos do projeto também devem estar bem documentados. Tensão entre membros da equipe de desenvolvimento: estabilização x desestabilização do estabilização x desestabilização do software UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Um produto é visível se ele é estruturado como uma coleção de módulos, com funções claramente compreensíveis e se há fácil acesso à sua documentação. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Princípios da Engenharia de Software...
Serão abordados princípios gerais que são centrais para um desenvolvimento de software bem sucedido. Estes princípios dizem respeito ao processo de software e ao produto final. Os princípios são colocações gerais e abstratas que descrevem propriedades desejáveis do processo de software e do produto final. Para aplicar os princípios precisamos de técnicas e metódos. Os métodos e técnicas ajudam a incorporar aos processos e aos produtos as propriedades (qualidades) desejadas. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Métodos são orientações gerais que governam a execução de alguma atividade. São abordagens rigorosas, sistemáticas e disciplinadas Técnicas, em geral, possuem uma aplicabilidade mais restrita. Metodologia = métodos + técnicas O objetivo da metodologia é promover uma certa abordagem para resolver um problema, através de uma escolha prévia dos métodos e técnicas a serem usados. Ferramentas suportam a aplicação de metodologias, métodos e técnicas. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Ferramentas Métododologias Métodos e técnicas Princípios UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[1] Rigor e Formalismo Existem vários níveis de rigor. O maior deles seria o formalismo. Ex.: A descrição de um programa pode ser feita através de uma linguagem natural ou por meio de uma descrição formal em uma linguagem com comandos lógicos. A vantagem do formalismo é que é a base do processo de automação. Tradicionalmente, a única fase do processo de desenvolvimento de software que possui uma abordagem formal é a de programação. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Deve-se aplicar rigor e formalismo em todas as fases do processo de desenvolvimento de software. Uma documentação rigorosa do processo de software ajuda no reuso do processo em outros projetos similares e também na manutenção do sistema. Além disso facilita a monitoração do processo (timeliness e produtividade) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[2] Separation of Concerns (separação das preocupações): permite que se lide com os diferentes aspectos individuais de um problema. Várias decisões devem ser tomadas no desenvolvimento de um produto de software relativas: i) às características desejáveis do produto, tais como: funções ofertadas, plataformas em que será executado o sw, eficiência em termos de tempo e espaço, tipos de interfaces com o usuário, etc. ii) ao processo de desenvolvimento: ambiente de desenvolvimemto, organização e estrutura das equipes, planejamento, procedimentos de controle, estratégias de projeto; iii) a aspectos econômicos e financeiros. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Separation of Concerns pode se dar de várias formas: i) no tempo – é a motivação subjacente ao ciclo de vida do software; ii) em termos das qualidades desejadas para o sw (ex.: primeiro assegura a correctness e então reestrutura o programa para garantir a eficiência); iii) diferentes visões do sistema (fluxo de dados entre as diferentes atividades X fluxo de controle que governa a sincronização das atividades); iv) diferentes partes do sistema  Modularidade; v) divisão de responsabilidades e tarefas; UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[3] Modularidade: este princípio procura subdividir um sistema em vários módulos. Benefícios da modularidade: permite que a separation of concerns seja aplicada em duas fases: Ao se lidar com cada módulo isoladamente (ignorando os detalhes dos outros módulos); Ao se lidar com as características gerais de cada módulo e suas relações com os outros módulos, de forma a integrá-los e a construir um sistema coerente. Bottom up x Top down design UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Modularidade é um princípio importante na engenharia, estando presente na maioria dos processos e produtos. O princípio da modularidade não apenas é um princípio desejável na fase de projeto; ele permeia toda a atividade de produção de software. As três metas da modularidade: A decomposição de sistemas complexos A composição de sistemas a partir de módulos A compreensão do sistema em partes (módulos) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Idealmente na produção de software seria desejável a montagem de novas aplicações a partir de módulos já disponíveis em bibliotecas. Para se alcançar as três metas da modularidade os módulos devem ter alta coesão e um baixo acoplamento. Um módulo possui alta coesão, quando os seus elementos estão fortemente relacionados. Acoplamento caracteriza a relação de um módulo com os outros módulos que compõem um sistema. Dinâmica de alta freqüência x Dinâmica de baixa freqüência UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[4] Abstração: é um processo em que identificamos os aspectos importantes de um fenômeno e ignoramos os detalhes. Uma abstração denota as características essenciais de um objeto, que o distingüe de todos os outros tipos de objetos e, assim, fornece fronteiras conceituais bem definidas, relativas à perspectiva do observador (Booch). UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[5] Antecipação a mudanças: é a habilidade de se projetar um sistema, já tendo em vista possíveis alterações futuras a serem incorporadas ao mesmo, de forma que estas alterações possam ser facilmente absovidas e implementadas. Basicamente, as alterações prováveis devem ser isoladas em partes (regiões) específicas do software, de modo que as alterações fiquem restritas a pequenas partes. É um princípio utilizado para se atingir a evolvability. Reusability pode ser vista como evolvability em baixa granuralidade, i.e. evolvability a nível de componente. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Antecipação a mudanças requer o uso de ferramentas adequadas para se gerenciar as diferentes configurações do sistema que co-existirão em um dado instante. Configuration management Capacidade para armazenar e recuperar documentação, módulos-fonte, módulos-objeto, etc. Antecipação a mudanças também afeta o processo de desenvolvimento de software (ex.: personnel turnover). UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[6] Generalidade: sempre que colocados frente a um problema específico devemos procurar descobrir a solução para um problema mais geral, do qual o problema que se procura solucionar é uma instância particular. A solução mais geral poderá ser reutilizada em outros contextos; Eventualmente poder-se-á encontrar um software off-the-shelf que seja a solução para o problema dado; A solução mais geral pode ser mais cara; Avaliar o trade-off: generalidade x (custo + eficiência) UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

[7] Incrementabilidade: caracteriza um processo que progride passo a passo, em incrementos. A meta desejada é alcançada por aproximações sucessivas cada vez mais próximas. Cada aproximação é alcançada através de um incremento à aproximação anterior. Significa que o software deve ser o produto final de um processo evolutivo. Uma forma de se aplicar este princípio consiste em se identificar, ainda no início, subsets da aplicação, que possam ser desenvolvidas e entregues aos usuários, de modo a se ter um feedback antecipado... UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A motivação para a incrementabilidade é que, na maior parte dos casos práticos, não há como se obter todos os requisitos de um sistema antes que a aplicação seja desenvolvida. Incrementabilidade e antecipação a mudanças estão interligadas e são as bases da evolvability. Estágios intermediários da aplicação podem ser vistos como protótipos. O desenvolvimento evolutivo de software requer cuidados especiais com a gerência da documentação, dos programas, dos dados de teste, etc. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Software Design (Projeto)...
O projeto de software é uma atividade fundamental no processo que progressivamente transforma os requisitos do sistema, através de vários estágios intermediários, em um produto final. Software Design é uma decomposição de um sistema em módulos, a descrição do que cada módulo deverá fazer e a descrição do tipo de relações existentes entre os módulos. O produto final do design é a arquitetura do software. Aplicam-se os vários princípios da Engenharia de Software UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Para se ter projetos de qualidade: Cuidadosa definição da estrutura modular e das relações existentes entre os módulos Escolha de critérios apropriados para se decompor um sistema em módulos. Um dos critérios é information hiding O Design é mapeado em programas, que correspondem à sua implementação. Não há receitas gerais que possam ser aplicadas em todas as circunstâncias. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Objetivos do Software Design...
A decomposição de um sistema em módulos pode se dar de diversas formas. Quando um módulo M é decomposto em outros módulos, diz-se que estes módulos implementam M. Top down design: A implementação é realizada através de uma decomposição recursiva em módulos, até que a implementação possa ser diretamente realizada em termos de uma linguagem de programação. Botton-up design: o processo de design consiste na definição de módulos que possam ser interativamente combinados para juntos formar um subsistema. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Metas importantes do Software Design
Antecipação a mudanças – a idéia é produzir um projeto de software que possa facilmente acomodar alterações futuras. A experiência prévia do engenheiro de software e um profundo entendimento do domínio do problema pelo usuário final são fundamentais na identificação de áreas em potencial sujeitas a mudanças e na futura evolução do sistema. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Antecipação a mudanças...
Mudanças de algoritmos – para aumentar a performance do sistema, ou lidar com um caso mais geral, etc. Ex.: algoritmo de sort – o melhor algoritmo a ser aplicado dependerá do tamanho da lista a ser classificada, da distribuição dos dados na lista, etc. Conseqüentemente a escolha do melhor algoritmo dependerá de dados experimentais a serem adquiridos após o sistema estar operacional. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Mudança da máquina virtual (abstrata): Máquina virtual: conjunto de serviços oferecidos em um determinado nível i de programação e que são utilizados por módulos de um nível mais elevado – i+1. Ex.: uso de novas versões de linguagens, sistemas gerenciadores de banco de dados, sistemas operacionais, etc. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Mudança de dispositivos periféricos: caso especial de alterações efetuadas em embedded systems em que existem diversos tipos de “dispositivos periféricos”. Mudanças no ambiente social: ex.: alterações em legislações específicas, na moeda, etc. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Famílias de Programas... Famílias de Programas – ao invés de se considerar as diferentes versões de um software produto como diferentes produtos, consideram-se estas versões como membros de uma mesma família de produtos com muito em comum e que são apenas parcialmente diferentes. Exs.: a) um software com versões em diferentes línguas. b) um sistema gerenciador de banco de dados distribuído para diferentes sistemas operacionais. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Técnicas de Modularização...
Módulo: fragmento de software que corresponde a mais que simplesmente uma rotina. Pode ser um conjunto de rotinas, de dados, de definição de tipos, ou uma combinação destes elementos. Um módulo pode ser visto como um fornecedor de recursos e/ou serviços computacionais. Existem relações de diversos tipos entre módulos: ordem de desenvolvimento, importância relativa, parte de, uso de facilidades providas por outros módulos, etc. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Seja S um sistema de software composto dos módulos M1, M2, ..., Mn. Uma relação r em S é um subconjunto de S x S. Se dois módulos Mi e Mj estão em S, representamos o fato de que o par < Mi, Mj > está em r, usando a notação infixa Mi r Mj. A relação r é irreflexiva, i.e., Mi r Mi não pode valer para qualquer módulo Mi em S. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

O fechamento transitivo (transitive closure) de uma relação r em S é uma relação em S, denotada por r+. Sejam Mi e Mj dois elementos de S. Então r+ pode ser recursivamente definida como se segue: Mi r+ Mj se e somente se (sss) Mi r Mj ou existe um elemento Mk em S, tal que Mi r Mk e Mk r+ Mj. O fechamento transitivo captura a noção intuitiva de relações diretas e indiretas. Para dois módulos A e B, A CALL+ B, implica que A CALL B diretamente ou através de uma cadeia de CALLs. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Uma relação pode ser representada como um grafo dirigido cujos nodos são elementos de S e em que um arco dirigido existe de um nodo Mi para um nodo Mj sss Mi r Mj. Uma relação é uma hierarquia sss não existem ciclos no grafo da relação (grafo dirigido acíclico – directed acyclic graph – dag). USES, IS_COMPONENT_OF, INHERITS_FROM UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Grafo Geral e dag M1 M1 M1,1 M1,2 M1,3 M2 M3 M1,2,1 M1,2,2 M4 M5 M1,2,1,1 M3 M3 M6 M4 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Relação USES... Dados dois módulos distintos Mi e Mj, diz-se que Mi USES Mj sss a correta execução de Mj é necessária para que Mi complete a tarefa descrita em sua especificação. Se Mi USES Mj, diz-se que Mi é um cliente de Mj, visto que Mi requer os serviços que Mj provê. A relação USES não é equivalente a conter chamadas a procedimentos Exs.: tasks que cooperam através troca de mensagens; módulos que compartilham uma mesma estrutura de dados; UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Relação USES... Uma boa restrição à relação USES é a de que seja uma hierarquia. Separation of concerns poderia ser aplicada ao “percorrer-se” a relação USES. Além disso, se a estrutura de USES não for hierárquica ter-se-á um ciclo e uma sitema em que “nada funciona, até que tudo funcione”. A restrição da estrutura de USES ser hierárquica define um sistema através de sucessivos níveis de abstração. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Relação USES... Def.: Nível de um módulo: O nível de um módulo que não é usado por nenhum outro módulo é zero, e o nível de qualquer outro módulo M é i, onde i é o comprimento do maior caminho no dag que conecta um módulo de nível zero ao nodo M. Conceito de Máquinas Virtuais (Abstratas) A relação entre módulos é definida estaticamente, i.e. é independente da execução do software. Ex.: M USES M1 e M USES M2 if cond then proc_1 else proc_2 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Relação USES... fan-in: número de arestas que incidem (entram) em um nodo fan-out: número de arestas que saem de um nodo Um alto fan-in seria um indicativo de um bom design, pois indicaria um alto grau de reuso de um módulo. O fan-out deve ser mantido baixo. A relação USES não é suficiente para avaliar a qualidade de um projeto (design). É preciso analisar-se a natureza da interação entre os módulos. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Relação IS_COMPONENT_OF...
Seja S um conjunto de módulos. Para quaisquer Mi e Mj em S, Mi IS_COMPONENT_OF Mj significa que Mj é realizado através da agregação de vários módulos, um deles sendo Mi. COMPRISES é definido como a relação inversa de IS_COMPONENT_OF. Para quaisquer dois elementos Mi e Mj em S, diz-se que Mi COMPRISES Mj sss Mj IS_COMPONENT_OF Mi. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

A Relação IS_COMPONENT_OF...
Seja MS,i um subconjunto de S definido como se segue: MS,i = {Mk | Mk está em S e Mk IS_COMPONENT_OF M} Então pode-se dizer que Mi IS_COMPOSED_OF MS,i e, alternativamente, que MS,i IMPLEMENTS Mi. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Information Hiding... As relações USES e IS_COMPONENT_OF fornecem apenas uma descrição grosseira da arquitetura de um software. Quando um módulo Mi que usa o módulo Mj é refinado em seus módulos constituintes Mi, 1, Mi, 2, ..., Mi, n é necessário esclarecer o que a relação USES entre o conjunto {Mi1, Mi,2, ..., Mi,n} e Mi significa. O ideal seria subdividir-se um sistema em componentes tal que cada componente pudesse ser projetado independentemente dos outros componentes. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Information Hiding... Interface: conjunto de serviços que um módulo disponibiliza aos seus clientes. Estes serviços são exportados pelo módulo e importados pelos clientes. Implementation: a forma pela qual estes serviços são realizados pelo módulo. A interface é uma abstração do módulo do ponto de vista de seus clientes. A implementação de um módulo é a decomposição do módulo em seus componentes pela relação IS_COMPONENT_OF, ou a sua codificação em uma LP. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Information Hiding... Information Hiding: o cliente conhece os serviços oferecidos apenas pela interface. A implementação é totalmente oculta. Um aspecto crucial da atividade de design é a decisão sobre o que deve ser visível em um módulo (interface) e o que deve permanecer oculto (implementation). Se a interface não se altera, pode-se realizar alterações na implementation sem afetar os clientes. UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias

Engenharia de Software

Apresentações semelhantes

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Engenharia de Software

Apresentações semelhantes

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback