A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias1 Engenharia de Software Graduação em Engenharia de Sistemas e Computação Faculdade de Engenharia Universidade.

Apresentações semelhantes


Apresentação em tema: "UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias1 Engenharia de Software Graduação em Engenharia de Sistemas e Computação Faculdade de Engenharia Universidade."— Transcrição da apresentação:

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

2 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias2 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.

3 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias3 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. Engenharia de Software [2]

4 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias4 Engenharia de Software [3] Sistema de software Siste ma

5 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias5 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. Engenharia de Software [4]

6 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias6 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.

7 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias7 Profundas alterações no custo de hardware X custo de software Visão histórica da ES [2] HW (US$) SW (US$) t Custo Total do Sistema (US$)

8 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias8 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. Visão histórica da ES [3]

9 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias9 A abordagem de engenharia no desenvolvimento de software requer: –Gerência –Organização –Ferramentas –Teorias –Metodologias –Técnicas Visão histórica da ES [3]

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

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

12 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias12 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) Conhecimentos do ES [2]

13 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias13 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

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

15 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias15 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

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

17 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias17 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)

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

19 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias19 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.

20 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias20 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.

21 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias21 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.

22 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias22 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).

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

24 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias24 [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). Qualidades do Software [3]

25 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias25 [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 Qualidades do Software [4]

26 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias26 [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. Qualidades do Software [5]

27 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias27 [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. Qualidades do Software [6]

28 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias28 [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. Qualidades do Software [7]

29 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias29 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. Qualidades do Software [7]...

30 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias30 [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) Qualidades do Software [8]

31 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias31 [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. Qualidades do Software [9]

32 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias32 [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). Qualidades do Software [10]

33 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias33 [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. Qualidades do Software [11]

34 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias34 [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. Qualidades do Software [12]

35 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias35 [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. Qualidades do Software [13]

36 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias36 [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.) Qualidades do Software [14]

37 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias37 [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 Qualidades do Software [15]

38 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias38 Qualidades do Software [15]... tempo função Requisitos do usuário Sistema real t 0 t 1 t 2 t 3 t 4

39 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias39 [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 Qualidades do Software [16]

40 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias40 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. Qualidades do Software [16]...

41 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias41 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.

42 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias42 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. Princípios da Engenharia de Software...

43 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias43 Princípios da Engenharia de Software... Princípios Métodos e técnicas Métododologias Ferramentas

44 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias44 [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. Princípios da Engenharia de Software...

45 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias45 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) Princípios da Engenharia de Software...

46 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias46 [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. Princípios da Engenharia de Software...

47 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias47 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; Princípios da Engenharia de Software...

48 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias48 [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: 1.Ao se lidar com cada módulo isoladamente (ignorando os detalhes dos outros módulos); 2.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 Princípios da Engenharia de Software...

49 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias49 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) Princípios da Engenharia de Software...

50 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias50 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 Princípios da Engenharia de Software...

51 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias51 [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). Princípios da Engenharia de Software...

52 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias52 [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. Princípios da Engenharia de Software...

53 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias53 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). Princípios da Engenharia de Software...

54 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias54 [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) Princípios da Engenharia de Software...

55 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias55 [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... Princípios da Engenharia de Software...

56 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias56 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. Princípios da Engenharia de Software...

57 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias57 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

58 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias58 Software Design (Projeto)...

59 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias59 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. Software Design (Projeto)...

60 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias60 A decomposição de um sistema em módulos pode se dar de diversas formas. MQuando 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. Objetivos do Software Design...

61 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias61 Metas importantes do Software Design 1.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.

62 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias62 Antecipação a mudanças... a)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.

63 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias63 b)Mudança na representação de dados: Antecipação a mudanças...

64 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias64 c)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. Antecipação a mudanças...

65 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias65 d)Mudança de dispositivos periféricos: caso especial de alterações efetuadas em embedded systems em que existem diversos tipos de dispositivos periféricos. e)Mudanças no ambiente social: ex.: alterações em legislações específicas, na moeda, etc. Antecipação a mudanças...

66 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias66 Famílias de Programas... 2.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.

67 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias67 Famílias de Programas

68 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias68 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.

69 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias69 Seja S um sistema de software composto dos módulos M 1, M 2,..., M n. Uma relação r em S é um subconjunto de S x S. Se dois módulos M i e M j estão em S, representamos o fato de que o par está em r, usando a notação infixa M i r M j. A relação r é irreflexiva, i.e., M i r M i não pode valer para qualquer módulo M i em S. Técnicas de Modularização...

70 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias70 O fechamento transitivo (transitive closure) de uma relação r em S é uma relação em S, denotada por r +. Sejam M i e M j dois elementos de S. Então r + pode ser recursivamente definida como se segue: M i r + M j se e somente se (sss) M i r M j ou existe um elemento M k em S, tal que M i r M k e M k r + M j. 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. Técnicas de Modularização...

71 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias71 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 M i para um nodo M j sss M i r M j. 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 Técnicas de Modularização...

72 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias72 Grafo Geral e dag M1M1 M2M2 M3M3 M5M5 M4M4 M6M6 M1M1 M 1,1 M 1,2 M 1,3 M 1,2,1 M 1,2,2 M 1,2,1,1 M3M3 M3M3 M4M4

73 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias73 A Relação USES... Dados dois módulos distintos M i e M j, diz-se que M i USES M j sss a correta execução de M j é necessária para que M i complete a tarefa descrita em sua especificação. Se M i USES M j, diz-se que M i é um cliente de M j, visto que M i requer os serviços que M j 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;

74 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias74 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. A Relação USES...

75 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias75 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 M 1 e M USES M 2 if cond then proc_1 else proc_2 A Relação USES...

76 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias76 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. A Relação USES...

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

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

79 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias79 IS_COMPONENT_OF X COMPRISES M1M1 M2M2 M3M3 M5M5 M4M4 M6M6 M7M7 M8M8 M9M9 M1M1 M2M2 M3M3 M4M4 M5M5 M6M6 M7M7 M8M8 M9M9 IS_COMPONENT_OF COMPRISES

80 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias80 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 M i que usa o módulo M j é refinado em seus módulos constituintes M i, 1, M i, 2,..., M i, n é necessário esclarecer o que a relação USES entre o conjunto {M i1, M i,2,..., M i,n } e M i significa. O ideal seria subdividir-se um sistema em componentes tal que cada componente pudesse ser projetado independentemente dos outros componentes.

81 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias81 Information Hiding... Implementation Interface

82 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias82 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. Information Hiding...

83 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias83 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.

84 UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias84 Information Hiding...


Carregar ppt "UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias1 Engenharia de Software Graduação em Engenharia de Sistemas e Computação Faculdade de Engenharia Universidade."

Apresentações semelhantes


Anúncios Google