AD2 ES 2019-1 REE

Prévia do material em texto

Curso de Tecnologia em Sistemas de Computação 
Disciplina: Engenharia de Software 
AD2 1° semestre de 2019. 
Nome: Leila da Silva paulino 
Inscrição: 16113050087 
 
1. O que diferencia linguagens de programação interpretadas das linguagens de 
programação compiladas? De dois exemplos de cada tipo e indique para que 
categoria de software cada uma delas poderia ser mais adequada e por quê. 
(Valor: 1,5 ponto) 
Compilar do latim compilare (reunir; ajuntar) 
Interpretar do latim interpretar ( tornar claro o sentido de; explicar; traduzir; fazer juízo a 
respeito de). 
Na computação, a compilação é o processo que reúne o códigofonte e o transforma em 
algo que faça mais sentido para o computador. Do ponto de vista do código fonte, toda 
linguagem de programação é compilada. 
Programas interpretados são transformados em uma linguagem intermediária – em geral 
mais simples que a linguagem de programação em si – e executados em um 
interpretador ao invés de diretamente sobre uma plataforma computacional. Eles tendem 
a ter menor desempenho, dado que disputam processador com o próprio interpretador 
que lhes executa, mas podem ser executados em uma diversidade de plataformas 
computacionais, desde que estas tenham versões do interpretador. 
Programas construídos em uma linguagem compilada são transformados em código 
nativo de uma determinada plataforma computacional e podem ser executados 
diretamente nesta plataforma. Eles tendem a apresentar maior desempenho (pois são 
executados diretamente), mas também uma limitação de ser executados somente nesta 
plataforma. 
Exemplos linguagens de programação interpretadas: Java; PHP 
Exemplos linguagem de programação compiladas: Pascal/ Object Pascal;Delphi 
 
2. Quais são os componentes de um diagrama de atividades da UML? Mostre um 
diagrama de atividades e explique como estes componentes se relacionam e o 
quê cada um representa no diagrama. (Valor 1,5 ponto). 
Um diagrama de atividades é um caso particular de um diagrama de estados, no qual 
todos ou a maioria dos estados são estados de atividades e todas ou a maioria das 
transições são desencadeadas pela conclusão das atividades dos estados anteriores; 
uma atividade corresponde a uma execução não atômica dentro de uma máquina de 
estados, ou de outra forma, corresponde à execução de ações. 
É usado para mostrar uma sequência de atividades. 
Mostra o fluxo de trabalho (workflow) a partir de um ponto inicial até um ponto final, 
detalhando as decisões do caminho tomado durante a execução das tarefas. 
Este diagrama possui varias aplicações, desde a definição do fluxo básico de um 
programa ate a definição de um processo com as suas tomadas de decisões e ações. 
 
Vejamos abaixo um exemplo do uso do Diagrama de atividades. 
 
 
Podemos ainda ter partições: 
Elas ajudam a separar as ações em bloco; exemplo: Ações realizadas pelo departamento 
A e ações realizadas pelo departamento B. 
Podemos ter envio de objetos entre uma ação e outra; exemplo: Pedido 
 
3. O que representa o conceito de coesão em software. Como podemos observar coesão no 
software? Como medir coesão? Apresente um exemplo de falta de coesão em software. 
(Valor: 1,5 ponto). 
Os significados literários da palavra " coesão " são a consistência e organização das 
diferentes unidades. Na ciência da computação e engenharia de software , a coesão se 
refere ao nível de força e unidade com os quais diferentes componentes de um programa 
de software estão inter -relacionados uns com os outros . 
O conceito de coesão é introduzida para capturar a " qualidade ", " concisão " e 
características "eficácia" de um programa no domínio de engenharia de software. Este 
conceito faz com que seja fácil de determinar como estreitamente ligado cada módulo do 
programa é, o que indica a rapidez com que ele pode realizar diferentes tarefas que lhe 
são atribuídas. 
 
É uma característica de um elemento que compõe o software que diz que respeito à 
diversidade de tarefas executadas por este elemento. Por exemplo, um módulo 
altamente coeso realiza uma única tarefa, sem precisar executar rotinas de outros 
módulos. 
Mede o grau de relação entre as atividades”comandos ” de um módulo, quando maior a 
coesão mais fácil será a reutilização do módulo. Os tipos de coesão são em ordem 
decrescente de intensidade. Os níveis de coesão são: Alto( Funcional, Sequencial, 
Comunicacional ) Baixo (Procedural,Temporal,Lógica e Coincidental.) 
Existem algumas métricas que tentam medir a coesão de uma classe. A mais famosa 
delas é conhecida por LCOM (Lack of Cohesion of Methods) em português Falta de 
coesão dos Métodos. Quanto maior o número que a métrica LCOM apontar, menos 
coesa é a classe. 
 
4. Explique o que é teste estrutural. Apresente três exemplos de critérios de 
teste que podem ser utilizados para projetar casos de teste para este tipo de 
teste. (valor: 1,5 ponto) . 
É um método de projeto de testes que usa a estrutura de controle do projeto 
procedimental para derivar casos de testes(Pressman, 2006) 
Baseia se num minucioso exame dos detalhes procedimentais exame dos detalhes 
procedimentais 
Caminhos lógicos do software são testados 
Não é viável testar todos os caminhos lógicos de um programa (teste exaustivo). 
Teste Estrutural ( caixa branca) toma por base a estrutura interna do software para 
planejar o teste. 
 Neste sentido, fluxo de controle ou de dados servem como critérios para estabelecer os 
casos de teste e roteiros de teste. Usualmente, a estrutura do software é visualizada 
através do grafo do programa ou grafo de fluxo de controle. 
Diferentes critérios podem ser utilizados: testar todos os nós do grafo, todos os arcos, 
todos os caminhos e outras opções. Quanto mais forte o critério (maior cobertura), 
maior o esforço do teste (planejamento e execução). 
 
 
 
5. Atividade de pesquisa I (não vale copiar e colar! Você deve pesquisar e explicar com 
suas palavras. Indique fontes alternativas que usar!): (valor 2,0 pontos) O que diz o 
Código de ética do Profissional de Informática da Sociedade Brasileira de Computação 
(http://www.sbc.org.br/institucional-3/codigo-de-etica)? Como ele se compara ao Código 
de ética e de Prática Profissional da Engenharia de Software, segundo as 
recomendações da ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and 
Professional Practices 
(https://www.computer.org/cms/Computer.org/professionaleducation/pdf/doc.pdf)? 
Quais a consequências em não seguirmos um código de ética em nossos projetos de 
engenharia de software? 
Um código de ética consiste também em um conjunto de diretrizes que esclarecem as 
circunstâncias em que cada um dos mandamentos se aplica, ou pode haver um conjunto 
de casos para estudo comparativo, auxiliando na resolução de novas situações. 
O código da SBC consiste em um conjunto de doze artigos que descrevem quais são os 
deveres profissionais da informática e o código ACM/IEEE CS em um conjunto de oito 
artigos. 
Existem alguns compromissos que devem ser seguidos em relação ao software para que 
se mantenha um relacionamento sadio entre cliente, usuário e desenvolvedores, e estes 
compromissos estão expostos no código de ética para a prática do profissional (da IEEE 
e ACM).Pode ser citado a ACM e também o Instituto para Ética da Computação alguns 
mandamentos, ao qual podemos chamar de “Um pequeno Código de Conduta para Área 
da informática”. 
Apesar de difícil, já podemos começar a delinear as possibilidades de usos maliciosos 
de software, de forma a definir o que é ético e o que não é. Em primeiro lugar, tenha 
consciência do que está contido no código de ética de engenharia de softaware. Esse é 
um bom primeiro parâmetro para saber aquilo que pode fazer e o que deve ser evitado. 
Sendo assim, estude o documento e verifique quais trechos estão relacionados com seu 
fazer laboral. Outro ponto é ter consciência do que falamos nos tópicos anteriores:o 
principio básico da ética na área de desenvolvimento é prezar pelo interesse publico, 
sem esquecer dos demais pontos do trabalho(como a atenção ás necessidades do 
cliente). Também atente ás pressões do trabalho:muitas pessoas acabam se 
submetendo a algumas situações por medo de não conseguirem cumprir prazos ou de 
perderem seus empregos. Com isso, cedem a situações antiéticas. Porém, lembre se é o 
seu nome profissional que está em jogo. 
É essencial que os colaboradores dessa área se destinem a buscar sempre as melhores 
condutas, que permitirão se tornar um melhor desenvolvedor de software, bem como 
evitar problemas que possam prejudicar sua carreira . 
Apesar de tantas objeções, a SBC assume que a regulamentação da profissão é 
inevitável, e cedo ou tarde algum projeto de lei, como o do deputado Silvio de Abreu 
(PDT/MG), que regulamenta a profissão de analista de sistemas, será aprovado. Portanto, 
ela toma a frente, criando sua própria proposta bem ao estilo do copyleft do projeto 
GNU, dando ampla liberdade para o exercício profissional, utilizando de um artifício legal 
e citando inclusive artigos da Constituição para justificar sua posição. Mas não apóia a 
criação de qualquer conselho para proteger seu código. 
 Com ou sem regulamentação, a sociedade necessita de um conjunto de normas 
para serem seguidas não só pelos profissionais de informática como por qualquer 
aventureiro que se atreva a experimentar o poder da computação e verificar o quão 
frágeis são as pessoas frente ao computador. Esse normativo precisa ser dinâmico para 
acompanhar a constante aceleração das mudanças que ocorrem no contexto da ética na 
informática. 
 
 
https://www.devmedia.com.br/etica-em-informatica/14636 
 
http://compesociety.blogspot.com/2016/09/sbc-e-o-codigo-de-etica-profissional.html 
 
 
 
6. Atividade de pesquisa II (não vale copiar e colar! Você deve pesquisar e respondem com 
suas palavras. Indique fontes alternativas que usar!): (valor 2,0 pontos) 
 A percepção da qualidade do produto de software tem evoluído ao longo do tempo. 
Abordagens clássicas e ainda muito importantes, observam a qualidade externa do produto 
através, por exemplo, da presença de defeitos. Entretanto, a evolução dos processos de 
desenvolvimento tem trazido preocupações com a evolução dos produtos. Ciclos 
interativos e incrementais dependem não apenas da qualidade externa, mas, 
principalmente, da qualidade interna do produto. Neste sentido o conceito de Dívida 
Técnica (Technical Debt) tem sido atualmente tratado. Portanto, o que é Divida Técnica? 
Como ela pode ser observada e/ou medida no produto? Quais são seus efeitos na 
evolução do produto? Toda Dívida deve ser paga? Por quê? 
Dívida técnica é uma opção, deve ser discutida e a equipe deve ter consciência dos 
ganhos e perdas, riscos e oportunidades envolvidos, acima de tudo é preciso ter clareza 
de que não é grátis, tem um custo que deve ser aos poucos suavizado. A prioridade e 
investimento para manter a dívida técnica sob controle é para ser uma decisão coletiva, 
precisa estar constantemente no radar e a cada sprint deve ser negociado, atentando 
à busca contínua pelo equilíbrio entre valor entregue e qualidade de engenharia. 
A metáfora dívida técnica, cunhada por Ward Cunningham em 1992, representa o 
comprometimento da qualidade de um código ao serem utilizadas práticas imaturas no 
desenvolvimento de software, justificadas por vários motivos. O perigo de contrair tais 
dívidas não está no fato de serem adquiridas, mas sim, na ausência de seus 
pagamentos, ou seja, quando elas não são pagas e acabam esquecidas no código. 
A dívida técnica é similar à dívida financeira. Assim como a dívida financeira, a dívida 
técnica exige o pagamento de juros. Nós podemos optar por continuar pagando estes 
juros ou quitar de uma vez a dívida fazendo uma refatoração, transformando um design 
de baixa qualidade em um design melhor. Apesar dos custos para saldar a dívida, 
ganhamos reduzindo os juros no futuro. 
Para que esses objetivos fossem alcançados, a presente pesquisa se propôs a definir o 
estado da arte buscando trabalhos relacionados a dívida. A presente pesquisa buscou 
ainda difundir a cultura da dívida técnica no caso estudado, sugerir formas de 
monitoramento de dívida técnica e identificar o impacto das sugestões dentro da equipe. 
Ao final o mesmo foi validado através de entrevistas onde identificou-se que o modelo 
auxiliou a equipe a refletir sobre os problemas de qualidade existentes no código bem 
como a criar um forma de geri-los. 
Ela pode ser observada quando uma empresa quer crescer muito depressa, existindo 
assim uma grande tentação para resolver as solicitações dos consumidores ou dos 
colaboradores o mais rápido possível. Quando uma empresa decide construir ou investir 
em software ou hardware para obter resultados em curto prazo, sem considerar as 
aplicações e custos que poderão ocorrer em longo prazo. 
Os motivos que justificam a existência de uma dívida são fáceis de enumerar. Por 
exemplo, quando se inicia um projeto de software com uma equipe com um nível de 
competência inferior. Embora esta escolha tenha um custo de implementação menor, 
pode também ter um impacto negativo na escolha da arquitetura, das tecnologias a 
utilizar e na qualidade final da programação, o que pode implicar custos adicionais na 
manutenção e evolução da solução. 
Existem dois tipos principais de dívida técnica: a dívida incorrida por decisão estratégica 
e a dívida incorrida de forma inconsciente. 
Uma das formas de lidar com a dívida técnica é definir claramente o que é o produto final 
desejado, ou seja, clarificar a relação entre a dívida técnica permitida e a qualidade do 
produto. Assim, quando se estabelecem alterações ou novas funcionalidades para o 
produto a equipe envolvida sabe qual é a qualidade mínima esperada. Por vezes, 
assumir a dívida técnica pode ser a estratégia mais confortável,mas é importante que, 
para os projetos ao longo prazo. 
É que a divida técnica não é apenas uma questão técnica, é acima de tudo uma questão 
de negócio. Bem como uma dívida comum a dívida técnica pode ser paga num curto 
prazo e, geralmente, o pagamento deste tipo de dívida técnica é feito para suprir as 
necessidades imediatas. Outra característica desse tipo de dívida é que ela é paga com 
certa frequência a fim de reabilitar o crédito para aquisição de novas dívidas. 
O desenvolvedor possui em suas mãos tanto o problema como a solução para a dívida 
técnica. Não há necessidade de se preocupar ou ter vergonha do passado. Em vez disso, 
deve-se ficar orgulhoso do que foi feito e usar o que tiver a seu alcance para fazer 
alguma coisa sobre isso − tomar uma dura decisão de parar de escrever código de 
baixíssima qualidade. Isso irá iniciar uma cadeia de eventos positivos e provavelmente 
prosseguirá no longo prazo. 
A responsabilidade que um devedor assume quando solicita o credito não é obrigado a 
pagar por esse credito. Quem pede dinheiro no banco não é obrigado a pagar pela 
dívida, pois a responsabilidade numa operação de crédito esta em quem concede o 
dinheiro,ou seja, o financiador , a financeira ou banco. 
Relação de crédito é uma relação de confiança, por isso quem esta devendo não é 
considerado um criminoso (alguém em falta com a sociedade). Porém não sendo um 
criminoso ou em falta com a sociedade à pessoa que não honra com seus 
compromissos não consegue assumir novas dívidas no futuro. Por isso honrar sua 
dívidas é algo que tem que ser da vontade das pessoas.Por mais que existam 
possibilidades de deixar isso de lado, de abandonar, alguns dizem que a ideia de 
caducar (o que não existe, não é verdade). 
Fazer um esforço adicional para que tenhamos o cachê necessário para liquidar sua 
divida porque apesar do bem fisicamente não existir o compromisso, a dívida é sua. E 
você mesmo não sendo enfaticamente cobrado por isso, você em algum momentono 
futuro perderá oportunidade de obter outras formas de crédito ou pagará muito mais 
caro por outras formas de crédito por ter um histórico de não honradez dos 
compromissos. Mesmo negociando, solicitando descontos, propondo, fazendo contra 
propostas para reduzir a dívida que você honre o compromisso assumido de preferência 
no prazo assumido para que tenha um histórico de crédito interessante e possa ter 
benefícios disso nas futuras operações. 
 
https://rd.uffs.edu.br/bitstream/prefix/1007/1/PERONDI.pdf