UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias1 Engenharia de Software Graduação em...

UERJ - Setembro 2001

© Oscar Luiz Monteiro de Farias 1

Engenharia de Software

Graduação em Engenharia de Sistemas e Computação

Faculdade de Engenharia

Universidade do Estado do Rio de Janeiro



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.



• 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.





Sistema de software

Sistema



• 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.




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.



• Profundas alterações no custo de hardware X custo de software


HW (US$)

SW (US$)

t

Custo Total do Sistema (US$)



• 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.




• A abordagem de engenharia no desenvolvimento de software requer:

– Gerência– Organização– Ferramentas– Teorias– Metodologias– Técnicas




O Engenheiro de Software

• Precisa dominar:

Programming in the small

Programming in the large



Conhecimentos do ES [1]

Programming in the small

• Conhecimento de LPs• Estrutura de Informação• Algoritmos• Inteligência



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]



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



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 SWe Manutenção

Análise de Requisitos e Especificação



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



Engenharia de Software

Princípios de Engenharia

Diferentes produtos de software

10 passo: Discernir um conjunto de qualidades que caracterizam os produtos

Aplicados a

20 passo: Descobrir que princípios devem ser aplicados para se desenvolver sw com as qualidades desejadas.



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)



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)



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.



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.



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.



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



Qualidades do Software [2]...

Correctness

Reliability



• [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).




• [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




• [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.




• [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.




• [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.




• 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.




• [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)




• [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.




• [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).




• [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.




• [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.




• [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.




• [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.)




• [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





tempo

função

Requisitos do usuário

Sistema real

t0 t1 t2 t3

t4



• [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




• 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.




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.



• 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

Métodos e técnicas

Métododologias

Ferramentas



• [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.




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




• [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.




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




• [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




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




• 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




• [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).




• [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.




• 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).




• [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)




• [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...




• 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.




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



• 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.




• 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 MM.

• 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...



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.



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.



b) Mudança na representação de dados:




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.




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.




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.



Famílias de Programas...

1

2

3

1

2

3

4

5

1

2

3

4

5

6

7



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.



• 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.




• 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.




• 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




Grafo Geral e dag

M1

M2 M3

M5M4

M6

M1

M1,1 M1,2 M1,3

M1,2,1 M1,2,2

M1,2,1,1 M3M3

M4



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;



• 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...



• 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

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.

A Relação USES...



• 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.

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.

A Relação IS_COMPONENT_OF...



IS_COMPONENT_OF X COMPRISES

M1

M2 M3

M5

M4

M6M7 M8 M9 M1

M2 M3 M4

M5 M6M7 M8 M9

IS_COMPONENT_OF COMPRISES



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.




Implementation

Interface



• 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: 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 Farias1 Engenharia de Software Graduação em...

Documents

Transcript of UERJ - Setembro 2001 © Oscar Luiz Monteiro de Farias1 Engenharia de Software Graduação em...