Análise e Projeto Orientado a Objetos

Contextualizando

Por que Análise e Projeto?

Análise versus Projeto

Análise e Projeto OO

Processo de Desenvolvimento de Software

Alguns Processos de Desenvolvimento

Um pouco de engenharia de software...:◦ Softwares estão presentes em todas as áreas e a

socidade é cada vez mais dependente deles. Em bancos, empresas de telecom, pesquisas médicas, produções cinematográficas, exploração espacial, etc.

◦ Analistas e desenvolvedores sofrem pressão por preço, prazo, qualidade, complexidade...

◦ Mais de 30% dos projetos são cancelados (alguns já nascem fadados ao fracasso – projetos “marcha da morte”);

◦ Custos superam até 3 vezes o que foi orçado;◦ Cronogramas executados ultrapassam facilmente

100% em relação ao planejado ou linha de base.

Para pensar nos riscos...:◦ Software Construção de casa

Você deixaria um pedreiro construir uma casa, sem planta?

Em que tipo de casa isso seria aceitável?

◦ Software Instalação elétrica

Você levaria a um eletricista do “meio de rua”, um transformador, sem o desenho do circuito?

Em que tipo de transformador isso seria aceitável?

◦ Software, simplesmente

Você deixaria o primo do vizinho do seu tio implementar um software, só com uma conversa?

Em que tipo de software isso seria aceitável?

Um carro!

Um avião!

Uma casa!

Construir um software sem realizar análise e projeto, é como construir uma casa sem ter plantas estruturais, hidráulicas, elétricas, arquitetônicas...

Pode ser aceitável para certos tipos de software de complexidade e risco baixos;

Nos demais casos, análise e projeto são a base para a construção de um software, trazendo a segurança do que exatamente está especificado e o que será implementado;

Análise e projeto oferecem recursos para garantir que melhoramentos na descrição de um sistema preservam o comportamento e funcionalidade do mesmo.

A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deve ser feito); É uma atividade investigativa e de levantamento;

O projeto/design enfatiza a proposta de uma solução que atenda ao identificado na análise(como pode ser feito); É uma atividade de criação.

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 ao programador;

Em alguns casos (fortemente em MDD) o cliente estará interessado em artefatos de projeto.

Pode-se dizer que o resultado da análise é o enunciado do problema, e que o projeto será a sua resolução;

Problemas mal enunciados podem até ser resolvidos, mas a solução não corresponderá às expectativas;

Análise e projeto bem-feitos são importantes!

Um erro verificado na fase de análise tem um custo; na fase de projeto tem um custo maior; na fase de implementação maior ainda, e na fase de implantação do sistema tem um custo incalculável.

Custos de correção de software, de acordo com as fases do projeto em que são descobertos:

Um novo paradigma de análise e projeto;

A perspectiva empregada é da abstração de objetos (coisas, conceitos ou entidades), tanto na análise quanto no projeto;

A ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema e entender suas relações;

Por exemplo, num sistema de informação para uma locadora de DVDs, alguns dos conceitos são: Locadora, Funcionário, Cliente, Locação, DVD;

Tais objetos podem ter atributos (características) e responsabilidades.

Testando outros cenários...◦ Farmácia

◦ Biblioteca

◦ Controle de Estacionamento

Nestes 3 casos acima, o domínio do problema parece ser amplamente conhecido.

E nos cenários abaixo:◦ Financiamentos Bancários

◦ Processos Judiciais

◦ Meteorologia

◦ Fiscalização Fazendária

◦ Emissão de Passaportes

Exemplo da Biblioteca e seus objetos, com a visáodetalhada do objeto Livro (atributos e operações).

As abstrações do mundo real são objetos que correspondem às coisas do domínio do problema:◦ Pensar em objetos é mais natural do que pensar apenas em

funções;

Os objetos servem de instrumentos para comunicação e entendimento do software que será desenvolvido;

Promovem decomposição do problema, flexibilidade e reutilização;

As abstrações e suas decomposições podem ser representadas por uma linguagem visual chamada UML (a ser vista a diante).

DISCIPLINA!

Define atividades, papéis, artefatos e um fluxo que tem como objetivo padronizar o ciclo de vida de um projeto de desenvolvimento de software.

Quem, O que, Quando e Como Objetivo.

Normalmente o objetivo é: ◦ Evoluir um software existente;

◦ Implementar um novo software;

◦ Com qualidade!

Atividades de análise e projeto estão no contexto dos processos de desenvolvimento de software.

Metodologias ≠ Processos ≠ Modelagem

Metodologias de desenvolvimento:◦ Estruturada, Orientada a Objetos e Ágil

Processos de desenvolvimento:/ Frameworks◦ RAD, UP, RUP, Scrum, XP, MDD, Crystal, Lean

Modelagem de software◦ Análise essencial, Análise estruturada, UML

Mas, podemos dizer que:

Metodologias = Processos + Modelagem

Algumas consultorias, vendedores de ferramentas ou marqueteiros vendem qualquer processo, para qualquer empresa, como a SOLUÇÃO DE TODOS OS PROBLEMAS de (falta de) qualidade dos softwares ou projetos fracassados.

Ao contrário do que dizem os “torcedores”

(que são diferentes dos marqueteiros...):

Não existe A MELHOR metodologia ou processo;

Existe a escolha certa para o cenário certo, e para a realidade da empresa, das equipes e seus projeto;

Optar por uma metodologia e processo no ciclo de vida de um projeto de software, não é garantia de sucesso e objetivos atingidos;

Ferramentas de apoio ao processo não necessariamente direcionam um projeto ao seus objetivos.

O importante não é escolher um processo porquê este está “na moda” ou lhe garante um certificado.

Identificar objetivos para aderência a um processo;

Relacionar boas práticas e a melhor forma de trabalho;

Relacionar ferramentas de apoio;

Envolver as pessoas.

RUP – Rational Unified Process O RUP é um processo de desenvolvimento que

descreve:◦ O que deve ser executado (atividades e disciplinas);

◦ Quem deve executar (papéis);

◦ Qual resultado deve ser gerado (artefatos).

O RUP prevê o desenvolvimento de sistemas de modo iterativo-incremental;

Requisitos funcionais são tratados como casos de uso.

XP – Extreme Programming O XP (Extreme Programming) busca menos

burocracia, mais produtividade e redução de custos;

Quatro elementos principais:◦ Comunicação;◦ Simplicidade;◦ Feedback;◦ Coragem.

XP também prevê o desenvolvimento iterativo-incremental;

Requisitos extraídos de user stories.

Scrum Iterativo-incremental e empírico;

Processo ágil e simples (poucas “regras”), que pode vem sendo aplicado na execução de qualquer projeto, inclusive de natureza complexa e incerta;

Entregas rápidas (em sprints de duas a quatro semanas) e contínuas, com valor agregado de negócio e novas ou melhoradas funcionalidades;

Times de desenvolvimento pequenos e auto-gerenciáveis;

Requisitos compõem um backlog do produto.

Outros...◦ Cleanroom - Processo estruturado “pesado”◦ RAD – Processo baseado em prototipagem “leve”◦ Kanban – Processo “mais-ágil”

Lembrando: não há processo ideal, há o melhor processo para uma realidade de projeto de software. Não existem “balas-de-prata” no desenvolvimento de software (termo de Fred Brooks em seu clássico The Mythical Man-Month).

Frederick Brooks

Robert Glass

Ed Yourdon - Death March

RUP

XP

Scrum das Trincheiras

Atribuição-Uso Não-Comercial 2.5 Brasil