MAC 413/5715 - Tópicos de Programação
Orientada
a Objetos
Aula 5 - 22/8/6
Padrões de Análise (continuação)
Especialização e Generalização de
Conceitos de Observação
- Em medicina é útil definir uma hierarquia de
observações. Se um supertipo é considerado
ausente,
então todos os subtipos são considerados ausentes. Se um
subtipo
é considerado presente então o seu supertipo
também
é presente.
- Exemplo: Diabetes é um conceito de
observação com dois subtipos: diabetes tipo I e diabetes
tipo II. Uma observação da ocorrência do tipo I
implica na ocorrência de diabetes. Uma
observação da ausência de diabetes implica na
ausência do tipo I e II.
Protocolo
- Uma informação importante no domínio
do conhecimento é o protocolo utilizado para realizar
observações.
- Exemplo: Existem várias formas de medir a temperatura
do corpo: tipos diferentes de termômetro e lugares diferentes do
corpo onde podemos colocar o termômetro. O diagnóstico de
febre pode variar dependendo de como a temperatura foi tomada.
- O protocolo pode também definir a precisão da
medida (p.ex., balança caseira vs. balança do
médico , relógio de pulso vs. cronômetro
ótico vs. relógio atômico).
- Figura 3.10
Registro Duplo de Tempo
- Para cada observação pode haver um período
de tempo (com começo e fim) durante o qual ela foi válida.
- Exemplo: numa consulta médica no dia 15/9/2002,
o Manuel da Silva diz ao seu médico que seis meses atrás
ele teve uma dor no peito que durou uma semana. O médico registra isso como
uma observação da presença de uma observação do conceito de dor no peito. O
período de aplicabilidade da observação da dor no peito inicia-se em 15/3/2002
e termina em 22/3/2002. O instante do registro de observação é
15/9/2002. (Note que neste exemplo, seria interessante ter a possibilidade de
representar instantes de tempo aproximados).
- Figura 3.11
Observação Rejeitada
- Às vezes percebemos que fizemos observações erradas.
- Não podemos simplesmente apagar estas observações
- um médico pode ter administrado um certo
remédio por causa da observação
- por questões de auditoria, essa informação
deve ser mantida
- Portanto, neste caso, a modelagem deve incluir a possibilidade
de rejeitar uma observação. Neste caso, a
observação
se torna uma observação rejeitada e deve ser associada
à
observação que a rejeitou.
- Exemplo: Gumercindo faz um exame de sangue que indica
um volume corpuscular médio aumentado. Isso é indicativo
ou
de anemia ou de abuso de álcool. Gumercindo diz que bebe muito
pouco
e portanto o médico registra uma observação de
anemia
e prescreve tratamento. Seis meses depois, Gumercindo dá entrada
no
hospital em estado de coma alcoólico e descobre-se que ele bebe
exageradamente
há muitos anos. Esta informação indica que a
observação de que ele tinha anemia estava errada e deve
ser rejeitada. Mas deve ser mantida no histórico do paciente
para justificar o tratamento para anemia.
- Figura 3.12
Observação Ativa, Hipótese e Projeção
- observações ativas são observações que o médico assume como verdadeiras
- Hipóteses são observações que podem
ou não ser verdadeiras, em geral exigem mais testes (exames
clínicos)
- Projeções são observações que o médico acha que poderão ocorrer no futuro
- Figura 3.13
Observação Associada
- extensão do modelo para permitir a modelagem das
associações entre as observações.
- Exemplo: a observação carro não liga
em conjunção com a observação farol
muito
fraco implica na observação bateria arriou
- as duas primeiras observações estão ligadas
à terceira através de uma função associativa
- Figura 3.14
Processo de Observação
- Modelagem de como é a dinâmica dos processos envolvendo as observações.
- Composto de diagramas de eventos ou de interações descrevendo a dinâmica do modelo.
Novidades
A crise permanente(?) da Engenharia de Software
- A Triste Realidade do Desenvolvimento de Software (fonte: pesquisa com
centenas de projetos [J. Johnson 95], o famoso Chaos Report do Standish Group):
- Aproximadamente 1/3 dos projetos de software são cancelados.
- 2/3 dos projetos de software custam mais do que 200% do que o
planejado inicialmente.
- Mais do que 80% dos projetos de desenvolvimento de software
são considerados fracassados em algum aspecto.
- Felizmente, o Chaos Report de 2000 e 2003 mostraram avanços, no
geral as coisas melhoraram nos últimos 10 anos; ou seja, para alguma coisa a
Engenharia de Software serviu :-)
- Em 2003, dados de 13.522 projetos foram coletados
- Projetos cancelados: 31% em 1994, 15% em 2003
- Projetos considerados de sucesso: 16% em 1994, 34% em 2003
- Estouro médio dos custos: 180% em 1994, 43% em 2003
- Estouro médio do tempo para conclusão: 222%(?) em 1994, 67% em 2000 e
82% em 2003
- Somente 52% das funcionalidades necessárias chegam ao produto final
(em 2003) contra 67% em 2000.
- Motivos:
- É uma área nova (apenas 1/2 século; apenas
20 anos com OO; < 10 anos com padrões) ??
- Os desenvolvedores não possuem educação
apropriada para implementar sistemas de forma correta ??
- Os gerentes não possuem educação
apropriada para administrar projetos de software ??
- Volto a bater na tecla da flexibilidade:
- Adaptabilidade é a qualidade mais importante do software.
- Mais da metade do custo do software se deve a mudanças
nos requisitos e na necessidade de implementar extensões a
sistemas existentes [Horowitz 93].
- Ao contrário do que muitos pensam (e ensinam),
desempenho
(velocidade) NÃO é o fator mais importante em software;
aliás, hoje em dia, em 90% dos casos, é um fator
irrelevante.