MIT_Computacao_Aula_1_Introducao

Prévia do material em texto

Aula 1: Introdução
1.1 Do que se trata o curso 6170
De fato, o curso engloba três cursos em um só:
· curso de impacto em programação orientada a objetos
· projeto de software
· curso em laboratório de construção de softwares em equipe.
A ênfase é dada em projeto. A programação é incluída por se tratar de um pré-requisito; a execução
de um projeto é incluída, pois só se aprende realmente uma idéia quando se experimenta e se utiliza
esta idéia
Você irá aprender:
· como projetar software: poderosos mecanismos de abstração; padrões conhecidos por
funcionarem com sucesso na prática; como apresentar projetos de forma que você possa
comunicá-los e criticá-los de maneira eficiente
· como implementar em Java
· como fazer direito: software confiável e flexível.
Você também poderá aprender:
· como ser um arquiteto, não um simples programador de baixo nível
· como evitar perder tempo depurando código.
1.2 Administração e políticas
Equipe do curso:
· Aulas: Daniel Jackson e Rob Miller
· Professores Assistentes (PAs): você irá conhecê-los em breve
· Assistentes de Laboratório (ALs): você irá conhecer as equipes em breve
· Carga horária: consulte o site. As aulas não possuem carga horária fixa, mas os alunos são bem
vindos para conversar: apareça ou envie e-mail.
Material:
· texto do curso por Liskov, leia de acordo com o planejamento encontrado nas informações gerais
do curso
· notas de aula: normalmente publicadas no dia da aula
· Livro: ‘Gang of Four’ de padrões de projeto (recomendado)
· Livro: ‘Effective Java by Bloch’ (recomendado)
· Tutorial Java: detalhes nas informações gerais do curso.
Os textos recomendados são realmente muito bons; serão boas referências, e irão ajudá-lo a ser um
bom programador mais rapidamente. Bons preços podem ser conseguidos na aquisição de todo o
pacote.
Organização do curso:
· Primeira metade do período: aulas, exercícios semanais, revisões, provas
· Segunda parte do período: projeto em equipe. Detalhes serão fornecidos mais adiante.
Não é necessário se preocupar, por enquanto, com quem será sua equipe de projeto.
Revisões:
· Sessões semanais com os ALs serão utilizadas para revisão dos trabalhos dos estudantes
· Inicialmente, os ALs irão pegar fragmentos do seu trabalho nos quais as aulas de revisão irão
focar
· A sessão completa irá discutir de forma construtiva e colaborativa
· Parte absolutamente essencial do curso: é uma oportunidade de se ver como as idéias das aulas
são aplicadas na prática.
Aprendendo Java:
· Depende de você, mas nós tentaremos ajudar
· Utilize o tutorial Java da Sun e faça exercícios
· Haverá um ótimo time de Assistentes de Laboratório (AL) para auxiliar você.
Colaboração e política de trabalhos:
· consulte as informações gerais do curso
· resumindo: você pode discutir, mas os trabalhos escritos precisam ser de sua autoria, incluindo
especificações, projeto, código, testes, explicações
· você pode utilizar código de domínio público
· no trabalho de equipe, você pode colaborar em tudo.
Provas:
· duas provas em sala focando no material das aulas
Notas:
· 70% trabalho individual = 25% provas e 45% listas de exercícios
· 30% projeto final, todos da equipe recebem a mesma nota
· 10% pontuação extra por participação
· trabalhos atrasados não serão aceitos
1.3 Por que a engenharia de software é importante
Contribuições do mercado de software à economia americana (dados de 1996):
· maior superávit comercial das exportações
· 24 bilhões de dólares em softwares exportados, 4 bilhões importados, totalizando um saldo
positivo de 20 bilhões de dólares
· comparação de superávits: agricultura 26-14-12, indústria aeroespacial 11-3-8, indústria química
26-19-7, indústria automotiva 21-43-(22), bens manufaturados 200-265-(64)
(fonte Software Conspiracy, Mark Minasi, McGraw Hill, 2000).
Papel na infraestrutura:
· não apenas a Internet
· transporte, energia, medicina, finanças.
Os softwares estão se tornando cada vez mais presentes em dispositivos embutidos. Novos carros,
por exemplo, têm entre 10 e 100 processadores para gerenciar todo tipo de funções, desde música
até frenagem.
Custo do software:
· A razão entre o custo do hardware para o custo de obtenção do software é aproximadamente
zero
· Custo total de posse: 5 vezes o custo do hardware. O Gartner Group estima que o custo de se
manter um PC por 5 anos é de 7 a 14 mil dólares
Quão bom é o software norte-americano?
· desenvolvimento de software falho
· acidentes
· software de má qualidade
1.3.1 Falhas no desenvolvimento
Pesquisa IBM, 1994
· 55% dos sistemas custam mais do que o esperado
· 68% ultrapassam o cronograma do projeto
· 88% tiveram que ser substancialmente reprojetados.
Advanced Automation System (FAA, 1982-1994)
· a média industrial foi de U$100 por linha de código, esperando cerca de U$500 por linha de
código
· foram pagos, de fato, de U$700 a U$900 por linha de código
· 6 bilhões de dólares de trabalho desperdiçado.
Bureau of Labor Statistics (1997)
· para cada 6 novos sistemas colocados em operação, 2 são cancelados
· a probabilidade de cancelamento chega a 50% para os maiores sistemas
· na média, os projetos ultrapassam o cronograma em 50% do tempo
· os sistemas têm 3/4 de seu todo tidos como ‘falhas operacionais’.
1.3.2 Acidentes
“O modo mais provável do mundo ser destruído, como concorda a maioria dos especialistas, é
através de um acidente. É aí que nós entramos. Somos profissionais da computação. Nós causamos
acidentes”.
Nathaniel Borenstein, inventor do MIME, em: Programming as if People Mattered:Friendly
Programs, Software Engineering and Other Noble Delusions, Princeton University Press,
Princeton, NJ, 1991.
Therac-25 (1985-87)
· máquina de radioterapia com software controlador
· o dispositivo responsável por sincronizar o hardware é removido, mas o software não possui
sincronismo
· o software falha na tarefa de manter invariantes essenciais: o feixe de elétrons ou o feixe mais
forte de radiação e a chapa se interferem na geração de raios X
· diversas mortes em decorrência de queimaduras
· o programador não tinha experiência em programação concorrente
· detalhes: http://sunnyday.mit.edu/therac-25.html.
Você pode pensar que nós iríamos aprender com o ocorrido e que tal desastre nunca viria a
acontecer novamente.
Mas…
· A Agência Internacional de Energia Atômica declara ‘emergência radiológica’ no Panamá em
22 de Maio de 2001
· 28 pacientes super expostos; 8 morreram, 3 dos quais em decorrência direta do fato; espera-se
que 3/4 dos 20 sobreviventes desenvolvam ‘sérias complicações que em alguns casos podem vir
a ser fatais’
· Especialistas encontraram equipamentos radioterápicos ‘em perfeito funcionamento’; os dados
coletados pelo sistema não indicavam nenhuma situação de emergência
· Se dados são registrados para diversos blocos de blindagem contra radiação em uma única ação,
temos uma dose incorreta processada pelo sistema
· Finalmente o FDA concluiu que um dos fatores causadores da falha foi a ‘interpretação, por
parte do software, dos dados coletados dos blocos dos feixes de radiação’
· detalhes: http://www.fda.gov/cdrh/ocd/panamaradexp.html.
Ariane-5 (June 1996)
· Agência Espacial Européira
· perda total de um dos foguetes, descontrolado logo após a decolagem
· causado por exceção gerada pelo código Ada
· o código de erro não era nem mesmo necessário após a decolagem
· graças a alterações físicas do ambiente: suposições não documentadas causam uma situação de
violação
· detalhes: http://www.esa.int/htdocs/tidc/Press/Press96/ariane5rep.html.
O acidente da Ariane é um desastre de software mais típico do que o acidente das máquinas
radioterápicas. Raramente os bugs do código são a causa do acidente, normalmente, o problema
retorna à fase de análise de requisitos, neste caso uma falha na articulação e avaliação de suposições
ambientais importantes.
London Ambulance Service (1992)
· perda de chamadas, despachos duplos de chamadas duplicadas
·escolha ruim do desenvolvedor: experiência inadequada
· detalhes: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las.html.
O desastre das ambulâncias de Londres foi, realmente, um desastre gerencial. Os gerentes que o
produziram eram ingênuos e aceitaram uma oferta de uma companhia desconhecida que era muitas
vezes menor que as ofertas de outras companhias renomadas. Cometeram o terrível erro de tentar
colocar o sistema on-line abruptamente, sem o cuidado de executar o sistema velho e o novo ao
mesmo tempo por um pequeno período tempo.
Em um curto prazo, estes problemas se tornarão piores devido à crescente disseminação da
utilização de softwares na infra-estrutura civil. O relatório do órgão Norte-Americano denominado
PITAC (ver referência logo abaixo) reconhece este fato, e tem, com sucesso, argumentado em favor
do aumento dos fundos para a pesquisa em software:
“A demanda por software tem crescido muito mais rápido do que nossa capacidade de produzir
software. Além disso, a Nação (Norte-Americana) necessita de software que seja mais utilizável,
confiável e poderoso do que o que se produz atualmente. Nós nos tornamos perigosamente
dependentes de uma grande quantidade de sistemas cujo comportamento não é bem compreendido e
que muitas vezes falha em situações não previstas”.
Information Technology Research: Investing in Our Future, President’s Information Technology
Advisory Committee (PITAC) Report to the President, February 24, 1999
Disponível em http://www.ccic.gov/ac/report/
Fórum RISKS
· relatórios comparativos da imprensa a respeito de incidentes relacionados à computação
· Acesse: http://catless.ncl.ac.uk.
1.3.3 Qualidade de software
Uma medida: bugs/kloc - bugs por cada mil linhas de código (loc = lines of code)
· medidos após a entrega do sistema
· média industrial em torno de 10
· alta qualidade: 1 ou menos.
Praxis CDIS system (1993)
· sistema britânico de controle de tráfego aéreo para a área do terminal de pouso e decolagem
· utilizou-se de uma precisa linguagem de especificações, muito semelhante aos modelos de
objetos que iremos aprender
· sem acréscimos no custo da rede de desenvolvimento
· taxa de bugs bem menor: por volta de 0.75 defeitos/kloc
· ainda sim, oferecia garantias para o cliente!
É claro que qualidade não se refere apenas a bugs. Você pode testar um software e eliminar a
maioria dos bugs que causam a queda do sistema, mas acaba criando um programa que é impossível
de se utilizar e que falha na maioria das vezes que deve realizar o que você espera. Isto acontece
devido ao fato de que tal sistema possui um excessivo número de casos especiais. Para descrever
este problema, você deve construir o conceito de qualidade a partir do princípio.
1.4 Por que o projeto é importante
“Você sabe o que é necessário antes que consigamos um bom software? Os carros deste país (EUA)
tiveram uma melhora quando o Japão nos mostrou que carros podiam construídos de uma maneira
melhor. Alguém terá que mostrar à indústria que os softwares podem ser construídos de uma
maneira melhor”.
John Murray, FDA’s guru de qualidade em software, Citado em Software Conspiracy, Mark
Minasi, McGraw Hill, 2000
Esse alguém é você!
Nosso objetivo no curso 6170 é mostrar que ‘hackear código’* não é tudo que existe para a
construção de software. De fato, é apenas uma pequena parte. Não pense em código como parte da
solução; muitas vezes é parte do problema. Nós precisamos de maneiras alternativas e melhores
para falar a respeito de software, que não seja através de código. Maneiras que sejam menos
onerosas, mais diretas, e menos ligadas a tecnologias que rapidamente se tornarão obsoletas.
Papel do projeto e dos projetistas
· pensar antes sempre ajuda (e é barato!)
· não dá para acrescentar qualidade no final: há um contraste com a confiabilidade dos testes; mais
efetivo, mais barato
· torna o ato de delegar tarefas e o trabalho em equipe possível
· falhas de projeto afetam o usuário: softwares incoerentes, inflexíveis e difíceis de usar
· falhas de projeto afetam o desenvolvedor: interfaces pobres, bugs que se multiplicam, difícil
acrescentar novas funcionalidades.
É uma coisa engraçada o fato de que estudantes de ciência da computação são muitas vezes
relutantes à idéia de desenvolvimento de software como uma empresa de engenharia. Talvez eles
pensem que técnicas de engenharia eliminarão a mística do processo de programação, ou talvez que
tais técnicas não se ajustarão às suas ‘habilidades de hacker’. Pelo contrário, as técnicas que você
aprende no 6170 irão lhe permitir alavancar o talento que você possui de forma bem mais efetiva.
Mesmo programadores profissionais se iludem. Em um experimento realizado, 32 programadores
* o termo hackear código, no contexto do curso, diz respeito à utilização de artimanhas não convencionais e
engenhosas (ou não) para que o sistema realize operações não previstas pelo projeto
da NASA aplicaram 3 diferentes técnicas de testes para alguns pequenos programas. Eles foram
questionados para que avaliassem a proporção de bugs que acreditavam que cada método seria
capaz de encontrar. Na experiência, a intuição dos programadores mostrou-se errada. Eles pensaram
que a técnica de teste da caixa-preta, baseada em especificações, era a mais eficiente. No entanto, a
leitura de código foi mais eficiente (mesmo o código estando não comentado). Ao ler o código, eles
encontraram erros 50% mais rápido!
Victor R. Basili and Richard W. Selby. Comparing the Effectiveness of Software Testing Strategies.
IEEE Transactions on Software Engineering. Vol. SE-13, No. 12, December 1987, pp. 1278–1296.
Para softwares de infra-estrutura (como controle de tráfego de aeronaves), o projeto é muito
importante. Mesmo assim, muitos gerentes industriais não percebem a magnitude do impacto das
idéias que nós ensinamos no curso 6170. Veja o artigo que John Chapin (um ex-professor do curso
6170) e eu escrevemos explicando como nós reprojetamos um componente do CTAS, um novo
sistema de controle de tráfego de aeronaves, utilizando idéias do 6170:
Daniel Jackson and John Chapin. Redesigning Air-Traffic Control: An Exercise in SoftwareDesign.
IEEE Software, May/June 2000.
Disponível em: http://sdg.lcs.mit.edu/~dnj/publications
1.4.1 A estória da Netscape
Para o software de PC, há um mito de que proejto não é importante porque o tempo para que o
produto chegue ao mercado (time-to-market) é tudo o que importa. A morte da Netscape é uma
estória que merece ser revista a este respeito. A equipe original do NCSA Mosaic, da universidade
de Illinois, construiu o primeiro browser amplamente utilizado, no entanto eles fizeram um trabalho
rápido e sujo. Eles fundaram a Netscape, e entre Abril e Dezembro de 1994 construíram o
Navigator 1.0, compatível com três plataformas e que em pouco tempo se tornou o browser
dominante para Windows, Unix e Mac. A Microsoft iniciou a construção do Internet Explorer 1.0
em Outubro de 1994, e o lançou com o Windows 95 em Agosto de 1995.
No período do rápido crescimento da Netscape, de 1995 a 1997, os desenvolvedores trabalharam
duro para lançar novos produtos com novas funcionalidades, possuindo, portanto, pouco tempo para
se dedicarem ao projeto. A maioria das companhias no esmagador mercado de software (ainda)
acredita que o projeto pode ser prorrogado: acreditam que uma vez que você possua uma fatia do
mercado e um conjunto atraente de funcionalidades, você pode ‘refabricar’ o código e obter os
benefícios do projeto puro e limpo. A Netscape não foi uma exceção, e seus engenheiros eram,
provavelmente, mais talentosos do que muitos outros.
Enquanto isso, a Microsoft percebeu a necessidade de se construir sobre sólidos projetos. Ela
construiu a tecnologia NT a partir do zero e reestruturou o pacote do Office para que utilizasse
componentes compartilhados. A Microsoft se apressou para o mercado com o IE para competir com
a Netscape e depois despendeu tempo para reestruturar o IE 3.0. Esta reestruturaçãodo IE agora é
vista pela Microsoft como a decisão chave que os ajudou a cobrir a lacuna que os separava da
Netscape.
A Netscape apenas cresceu e cresceu. No Netscape 4.0 havia 120 desenvolvedores (dos 10 iniciais)
e 3 milhões de linhas de código (sobre um fator de 30). Michael Toy, então gerente de lançamentos,
disse:
‘Nós estamos em uma situação realmente ruim… Nós deveríamos ter parado de lançar produtos
baseados neste código há um ano atrás. Está morto... É como um grosseiro despertar... Nós estamos
pagando o preço de termos corrido’.
Interessante, o argumento a respeito do projeto modular da Netscape, em 1997, veio de um desejo
de se desenvolver em pequenas equipes. Sem interfaces limpas e simples, é impossível dividir o
trabalho em partes independentes uma da outra.
A Netscape reservou dois meses para re-arquitetar o browser, mas não foi suficiente. Então
decidiram reiniciar tudo de novo com o Communicator 6.0. Mas o 6.0 nunca foi terminado e seus
desenvolvedores foram redirecionados para o 4.0. A versão 5.0, Mozila, foi disponibilizada como
código livre, o que não ajudou muito: ninguém queria trabalhar com código espaguete.
Ao final, a Microsoft venceu a guerra dos browsers, e a AOL comprou a Netscape. Claro que esta
não é a estória toda de como o browser da Microsoft conseguiu dominar o browser na Netscape. As
práticas de negócios da Microsoft não ajudaram a Netscape. Além do mais, independência de
plataforma foi um ponto importante desde o princípio; o Navigator podia ser executado em
Windows, Mac e Unix desde a versão 1.0, e a Netscape trabalhou duro para manter o máximo
possível da independência de plataforma em seu código. Eles até planejaram migrar para uma
versão em Java puro (‘Javagator’), e construíram várias ferramentas Java próprias (as ferramentas
da Sun não estavam prontas). Mas em 1998 eles desistiram. Ainda sim, o Communicator 4.0 possui
1,2 milhões de linhas em Java.
Eu extrai esta sessão de um excelente livro sobre a Netscape, seus negócios e estratégias de
negócios. Você pode ler a estória completa lá:
Michael A. Cusumano and David B. Yoffie. Competing on Internet Time: Lessons from Netscape
and its Battle with Microsoft, Free Press, 1998. See especially Chapter 4, Design Strategy.
Perceba, a propósito, que foram necessários 2 anos para que a Netscape descobrisse a importância
do projeto. Não se surpreenda se você não está totalmente convencido depois de apenas um período
de curso; algumas coisas vêm apenas com experiência.
1.5 Advertência
Estratégia de curso
· não fique para trás: o ritmo é rápido!
· aproveite as aulas: o material não está todo no livro texto
· pense antes: não corra para o código
· de-sign, e não de-bug.
Eu não posso enfatizar toda a importância de se começar cedo e de se pensar com antecedência. É
claro que eu não espero que você resolva suas listas de exercício no mesmo dia em que elas são
entregues. Mas, em longo prazo, você irá economizar muito tempo e terá resultados muito melhores
se dedicar algum tempo ao seu trabalho logo no início. Primeiro, você terá o benefício do tempo
que se passa: você estará refletindo sobre os problemas subconscientemente. Segundo, você saberá
quais recursos adicionais você precisa, e será capaz de conseguir tais recursos enquanto ainda é
possível conseguí-los com menos esforço e em tempo hábil. Especificamente, aproveite-se da
equipe do curso – nós estamos aqui para ajudar! Nós agendamos horários com os ALs e com os
PA’s com o tempo disponível que tínhamos em mente, mas vocês podem esperar mais ajuda desde
que não se trate da noite anterior à entrega da lista de exercícios, quando todos necessitam de
ajuda...
Simplifique:
‘Eu dei avisos desesperados contra a incerteza, a complexidade, e a excessiva ambição do novo
projeto, mas meus avisos não foram ouvidos. Eu concluo que há duas formas de construir um
projeto de software: um jeito é fazê-lo tão simples de forma que, obviamente, não haja deficiências
e o outro jeito é fazê-lo tão complicado de forma que não haja deficiências óbvias’.
Tony Hoare, Turing Award Lecture, 1980 falando sobre o projeto da linguagem Ada, mas muito
relevante para o projeto de programas.
Como fazer: ‘Mantenha a simplicidade, estúpido’ (‘Keep it simple, stupid’ – KISS)
· evite esquiar onde o gelo é fino: evite artimanhas muito engenhosas, algoritmos e estruturas de
dados complexas
· não utilize as mais obscuras funções das linguagens de programação
· questione a complexidade
· não seja muito ambicioso: evite carregar o sistema com feições e características estéticas que
não agregam funcionalidade, mas que comprometem a elegância de um bom projeto.
· lembre-se que é fácil fazer alguma coisa complicada, mas é difícil fazer alguma coisa
verdadeiramente simples.
Regra de otimização
· Não faça
· Apenas para experts: não faça, ainda.
(Michael Jackson, Principles of Program Design, Academic Press, 1975).
1.6 Avisos extras
Lembretes:
· Complete o formulário de registro on-line
· Comece a aprender Java agora mesmo!
· O exercício 1 deve ser entregue na próxima aula
Confira este endereço:
· http://www.170systems.com/about/our_name.html