INTRODUÇÃO À ANÁLISE
E PROJETO DE SOFTWARE ORIENTADOS A OBJETO
CONSTRUINDO
ARQUITETURAS DE SOFTWARE: LIDANDO COM A COMPLEXIDADE
-
-
-
-
-
-
-
-
RESULTADO:
FAZER SOFTWARE É
CADA VEZ MAIS COMPLEXO, MAS HÁ FORMAS DE
"DOMAR A FERA":
CONTROLAR
A COMPLEXIDADE
MELHORAR
A FLEXIBILIDADE E FACILIDADE DE EXTENSÃO
PROMOVER
A REUSABILIDADE
-
-
-
-
-
PROGRAMAS NADA MAIS SÃO
DO QUE MODELOS EXECUTÁVEIS
-
-
-
DIFERENÇAS ENTRE
ANÁLISE E PROJETO: TEM MAIS DO QUE UMA DEFINIÇÃO
EMPREGADA NA LITERATURA
PRIMEIRA ALTERNATIVA:
A ANÁLISE MODELA
O PROBLEMA E CONSISTE DAS ATIVIDADES NECESSÁRIAS
PARA ENTENDER O DOMÍNIO DO PROBLEMA (O
QUE DEVE SER FEITO)
O PROJETO MODELA
A SOLUÇÃO E CONSISTE DE ATIVIDADES DE CRIAÇÃO
(COMO PODE SER FEITO)
SEGUNDA ALTERNATIVA:
A ANÁLISE
CONSISTE DE TODAS AS ATIVIDADES FEITAS COM OU
PARA O CONHECIMENTO DO CLIENTE. A INFORMAÇÃO
PRODUZIDA É AQUELA QUE O CLIENTE DEVE DISCUTIR E
APROVAR
O PROJETO INCLUI
AS ATIVIDADES QUE RESULTAM EM INFORMAÇÃO QUE
INTERESSA APENAS AO PROGRAMADOR
COM ESTA
DEFINIÇÃO, A ANÁLISE INVADE UM POUCO O
"LADO DA SOLUÇÃO", POIS O CLIENTE
DEVE DISCUTIR E APROVAR AS DIREÇÕES BÁSICAS DA
SOLUÇÃO, CHEGANDO ATÉ DISCUTIR ALGUNS TIPOS DE
INTERAÇÕES QUE OCORRERÃO NA INTERFACE DO
USUÁRIO, ETC.
NESTA DISCIPLINA, NÓS
ADOTAREMOS A ALTERNATIVA 2, POIS QUEREMOS ASSOCIAR AS
PALAVRAS "ANÁLISE" E "PROJETO" AOS DELIVERABLES
ENTREGUES NO FINAL DE CADA FASE
UM MODELO DE
ANÁLISE DEVE SER APROVADO PELO CLIENTE E PODE
INCLUIR ALGUMA (PEQUENA) DISCUSSÃO DA SOLUÇÃO,
PRINCIPALMENTE NO QUE DIZ RESPEITO A INTERFACE
COM USUÁRIO, ETC.
HÁ AINDA AUTORES QUE
INCLUEM O LEVANTAMENTO DE REQUISITOS NA FASE DE ANÁLISE.
ELES DIVIDEM A ANÁLISE EM:
ANÁLISE DE
REQUISITOS
ANÁLISE DE
DOMÍNIO
NÃO
ADOTAREMOS ESTA DEFINIÇÃO
APESAR DO NOME DESTA
DISCIPLINA, VAMOS VER TAMBÉM REQUISITOS, IMPLEMENTAÇÃO
E TESTES
intro1.htm programa