ANÁLISE ORIENTADA A OBJETOS
Fev/2011
Professor Mário Dantas
Aula 02 - Agenda



Paradigmas de Programação
Processo de Desenvolvimento de Software
Ferramentas de Apoio
Software Deselegante



O software deselegante é aquele software feito
sem uma estrutura clara.
O software deselegante é aquele do qual não se
consegue reusar partes e que não se consegue
entender como funciona sem uma boa carga de
documentação (e muitas vezes nem assim).
É aquele no qual uma pequena modificação em
uma de suas características pode causar um não
funcionamento generalizado.
Software Elegante



O software elegante é o software cuja estrutura é
intrinsecamente mais fácil de compreender, é auto
documentado e pode ser compreendido em nível macro
ou em detalhes.
Ele é mais fácil de modificar: quando alguma de suas
características é mudada, ele continua funcionando.
Soluções para prover elegância -> Padrões de Projeto
– lições aprendidas ao longo dos anos em diferentes
projetos.
Orientação a Objetos



Orientação a objetos (OO) é uma abordagem de
programação que procura explorar nosso lado intuitivo.
Os objetos da computação são análogos aos objetos
existentes no mundo real.
No enfoque de OO, os átomos do processo de
computação são os objetos que trocam mensagens
entre si.
Essas mensagens resultam na ativação de métodos, os
quais realizam as ações necessárias.
Orientação a Objetos


Os objetos que compartilham uma mesma interface, ou
seja, respondem as mesmas
mensagens, são
agrupados em classes.
Objeto é algo dinâmico: é criado por alguém, tem
uma vida, morre ou é morto por alguém. Assim durante
a execução do sistema, os objetos podem:
Ser construídos
 Executar ações
 Ser destruídos
 Tornar-se inacessíveis

Problemas do paradigma procedural


Consideremos o clássico problema da validação de
um CPF.
Normalmente, temos um formulário, no qual
recebemos essa informação, e depois temos que
enviar esses caracteres para uma função que irá
validá-lo, como no pseudo-código abaixo:
cpf = formulario->campo_cpf
valida(cpf)
Problemas do paradigma procedural





Alguém te obriga a sempre validar esse CPF?
Você pode, inúmeras vezes, esquecer de chamar
esse validador.
Mais: considere que você tem 50 formulários e
precise validar em todos eles o CPF.
Se sua equipe tem 3 programadores trabalhando
nesses formulários, quem fica responsável por essa
validação?
Todos!
Problemas do paradigma procedural



A situação pode piorar: na entrada de um novo
desenvolvedor.
É nesse momento que nascem aqueles guias de
programação - às vezes, é um documento enorme.
Em outras palavras, todo desenvolvedor precisa
ficar sabendo de uma quantidade enorme de
informações, resultando um entrave muito grande!
Problemas do paradigma procedural


Outra situação é quando nos encontramos na
necessidade de ler o código que foi escrito por
outro desenvolvedor e descobrir como ele funciona
internamente.
Um sistema bem encapsulado não deveria gerar
essa necessidade. Em um sistema grande,
simplesmente não temos tempo de ler todo o
código existente.
Problemas do paradigma procedural

Considerando que você não erre nesse ponto e que sua
equipe tenha uma comunicação muito boa, ainda temos
outro problema:
imagine que, agora, em todo formulário, você também quer
que a idade do cliente seja validada - o cliente precisa ter
mais de 18 anos.
 Vamos ter de colocar um if... mas onde? Espalhado por todo
seu código... Mesmo que se crie outra função para validar,
precisaremos incluir isso nos nossos 50 formulários já
existentes.



Qual é a chance de esquecermos em um deles?
É muito grande.
Problemas do paradigma procedural



Melhor ainda seria se conseguíssemos mudar essa
validação e os outros programadores nem
precisassem ficar sabendo disso.
Eles criariam formulários e um único programador
seria responsável pela validação: os outros nem
sabem da existência desse trecho de código.
Impossível?
Não, o paradigma da orientação a objetos facilita
tudo isso.
Problemas do paradigma procedural


O problema do paradigma procedural é que não
existe uma forma simples de criar conexão forte
entre dados e funcionalidades.
No paradigma orientado a objetos é muito fácil ter
essa conexão através dos recursos da própria
linguagem.
Vantagens de OO



Abstração de dados: os detalhes referentes às
representações das classes serão visíveis apenas a seus
atributos;
Compatibilidade: as heurísticas para a construção das
classes e suas interfaces levam a componentes de
software que são fáceis de combinar;
Diminuição da complexidade: as classes delimitam-se
em unidades naturais para a alocação de tarefas de
desenvolvimento de software.
Vantagens de OO


Reutilização: o encapsulamento dos métodos e
representação dos dados para a construção de classes
facilitam o desenvolvimento de software reutilizável,
auxiliando na produtividade de sistemas;
Extensibilidade: facilidade de estender o software devido
a duas razões:



Herança: novas classes são construídas a partir das que já
existem;
As classes formam um estrutura fracamente acoplada, o que
facilita alterações;
Manutenibilidade: a modularização natural em classes
facilita a realização de alterações no software.
Vantagens de OO


Maior dedicação à fase de análise, preocupandose com a essência do sistema;
Mesma notação é utilizada desde a fase de análise
até a implementação.
Frente a essas vantagens, a abordagem OO tem se
mostrado “popular” e eficaz.
Classes
Classes e Objetos
PROCESSO DE DESENVOLVIMENTO
Ago/2010
Processo de Desenvolvimento

O que é um processo de desenvolvimento?



É a definição de quem faz o que, quando e como, para atingir
um certo alvo.
UML é uma linguagem de modelagem, não é uma
metodologia. Não se consegue fazer uma boa
modelagem sem conhecer processos.
Linguagem de modelagem + processo de
desenvolvimento = método (ou metodologia) de
desenvolvimento.
Processo de Desenvolvimento

As grandes fases de qualquer processo de
desenvolvimento são:
 Planejamento
e elaboração
 Planejamento,
definição de requisitos, construção de
protótipos (opcional)
 Construção
do sistema (inclui codificação e testes)
 Implantação (colocar em produção, treinar usuários, ...)
Processo de Desenvolvimento


UML não depende de processo. Você deve escolher
o que for adequado ao seu projeto.
Existem diversos modelos, e esse modelos são
influenciados por alguns fatores como:
 Tipo
de software que será desenvolvido (real-time,
sistema de informação, etc.)
 Escala (Um desenvolvedor, equipe pequena, etc.)
Processo de Desenvolvimento







Modelo em Cascata
Modelo de Prototipagem
Modelo Evolucionário
Desenvolvimento Baseado em Componentes
Modelo de Métodos formais
Programação Extrema
Processo Unificado
Processo em cascata
Processo Unificado


O processo unificado (PU) de desenvolvimento de
software é o conjunto de atividades necessárias
para transformar requisitos do usuário em um
sistema de software.
É fundamental na visão de que o avanço de um
projeto deve estar baseado na construção de
artefatos de software, e não apenas em
documentação.
Processo Unificado


A motivação para o uso da abordagem de Craig
Larman ao Processo Unificado deve-se ao fato de
que este é um processo bastante conciso e eficiente
para análise e projeto de sistemas orientado a
objetos
Neste método, cada artefato (documento ou
diagrama) tem uma razão muito clara para existir
e as conexões entre os diferentes artefatos são
muito precisas.
Processo Unificado

Principais Características:
 Dirigido
por casos de uso.
 Descrições
de casos de uso e seus diagramas embasam a
construção do software.
 Centrado
na arquitetura.
O
documento visão, diagrama de componentes e
implantação, diagrama de interação e diagrama de classes
(modelo de dados) fornecem a perspectivas da arquitetura
do software.
 Iterativo
e incremental.
Dirigido por casos de uso


Um caso de uso é uma seqüência de ações,
executadas por um ou mais atores e pelo próprio
sistema, que produz um ou mais resultados de valor
para um ou mais atores.
O PU é dirigido por casos de uso, pois utiliza-os
para dirigir todo o trabalho de desenvolvimento,
desde a captação inicial e negociação dos
requisitos até a aceitação do código (testes).
Dirigido por casos de uso

Os casos de uso são centrais ao PU e a outros
métodos iterativos, pois:
 Os
requisitos
funcionais
são
preferencialmente por meio deles;
 Eles ajudam a planejar as iterações;
 Eles podem conduzir o projeto;
 O teste é baseado neles.
registrados
Centrado na arquitetura


Arquitetura é a organização fundamental do
sistema como um todo. Inclui elementos estáticos,
dinâmicos, o modo como trabalham juntos e o estilo
arquitetônico total que guia a organização do
sistema.
A arquitetura também se refere a questões como
desempenho, escalabilidade, reuso e restrições
econômicas e tecnológicas.
Centrado na arquitetura



No PU, a arquitetura do sistema em construção é o
alicerce fundamental sobre o qual ele se erguerá.
Deve ser uma das preocupações da equipe de
projeto.
A arquitetura, juntamente com os casos de uso, deve
orientar a exploração de todos os aspectos do
sistema.
Centrado na arquitetura

A arquitetura é importante porque:
 Ajuda
a entender a visão global;
 Ajuda a organizar o esforço de desenvolvimento;
 Facilita as possibilidades de reuso;
 Facilita a evolução do sistema;
 Guia a seleção e exploração dos casos de uso.
Desenvolvimento Iterativo


O desenvolvimento de um software dividido em
vários ciclos de iteração, cada qual produzindo um
sistema testado, integrado e executável.
Em cada ciclo ocorrem as atividades de análise de
requisitos, projeto, implementação e teste, bem
como a integração dos artefatos produzidos com os
artefatos já existentes.
Desenvolvimento Iterativo


Planejar quantos ciclos de desenvolvimento serão
necessários para alcançar os objetivos do sistema.
As partes mais importantes devem ser priorizadas e
alocadas nos primeiros ciclos.
A primeira iteração estabelece os principais riscos e o
escopo inicial do projeto, de acordo com a funcionalidade
principal do sistema.
 Partes mais complexas do sistema devem ser atacadas já
no primeiro ciclo, pois são elas que apresentam maior risco
de inviabilizar o projeto.

Desenvolvimento Iterativo

O tamanho de cada ciclo pode variar de uma
empresa para outra e conforme o tamanho do
sistema.
 Por
exemplo, uma empresa pode desejar ciclos de 4
semanas, outra pode preferir 3 meses.
 Produtos entregues em um ciclo podem ser colocados
imediatamente em operação, mas podem vir a ser
substituídos por outros produtos mais complexos em
ciclos posteriores.
Trabalhadores


Trabalhadores: Um trabalhador é alguém que
desempenha um papel e é responsável pela
realização de atividades para produzir ou
modificar um artefato.
Exemplos: analista de sistemas, programador,
testador, etc.
Atividades

Atividades: tarefa que um trabalhador executa a
fim de produzir ou modificar um artefato.
Processos do PU



Descreve as seqüências das atividades que
produzem algum resultado significativo e mostra as
interações entre os participantes
São realizadas a qualquer momento durante o ciclo
de desenvolvimento (Fases do PU)
Ex.:
 Requisitos,
Análise, Projeto, Implementação e Teste
Processos do PU

Conjunto de atividades (e artefatos relacionados):
Modelagem de Negócio
 Requisitos
 Projeto
 Implementação
 Teste
 Implantação
 Gestão de Configuração e Mudanças
 Gerenciamento de projeto
 Ambiente

Fases do Processo Unificado

Cada um dos ciclos de desenvolvimento do PU é
dividido em quatro fases:
 Concepção;
 Elaboração;
 Construção;
 Transição.
Fases do PU: Concepção





Estabelece-se a viabilidade de implantação do
sistema.
Definição do escopo do sistema.
Estimativas de custos e cronograma.
Identificação dos potenciais riscos que devem ser
gerenciados ao longo do projeto.
Esboço da arquitetura do sistema, que servirá como
alicerce para a sua construção.
Fases do PU: Elaboração

Visão refinada do sistema:
 definição
dos requisitos funcionais;
 detalhamento da arquitetura criada na fase anterior;
 gerenciamento contínuo dos riscos envolvidos.

Estimativas realistas feitas nesta fase permitem um
plano para orientar a construção do sistema.
Fases do PU: Construção

O sistema é efetivamente desenvolvido e, em geral,
tem condições de ser operado, mesmo que em
ambiente de teste, pelos clientes.
Fases do PU: Transição



O sistema é entregue ao cliente para uso em
produção.
Testes são realizados e um ou mais incrementos do
sistema são implantados.
Defeitos são corrigidos, se necessário.
Fases do Processo Unificado
• Visão do Software
• Tecnologia
• Riscos
• Áreas críticas
Concepção
Elaboração
• Requisitos em
detalhes
• Protótipos
• Codificação
• Banco de Dados
Construção
Transição
• Avaliação do
software
• Versão de
Produção
Processos do PU



Avaliando-se as fases do PU, pode-se ter a impressão
de que cada ciclo de iteração comporta-se como o
modelo em cascata.
Mas isso não é verdade: paralelamente às fases do PU,
as atividades de trabalho, denominados Processos do
PU, são realizadas a qualquer momento durante o ciclo
de desenvolvimento.
Processos do PU entrecortam todas as fases do PU,
podendo ter maior ênfase durante certas fases e
menor ênfase em outras, mas podendo ocorrer em
qualquer uma delas.
Processos do PU
Requisitos
Testes
Implementação
Análise
Projeto
Processo Unificado
Os Artefatos do PU



Cada uma das disciplinas do PU pode gerar um ou
mais artefatos, que devem ser controlados e
administrados corretamente durante o desenvolvimento
do sistema.
Artefatos são quaisquer dos documentos produzidos
durante o desenvolvimento, tais como modelos,
diagramas, documentos de especificação de requisitos,
código fonte ou executável, planos de teste, etc.
Muitos dos artefatos são opcionais, produzidos de
acordo com as necessidades específicas de cada
projeto.
Os Artefatos do PU
Disciplina
Modelagem de
Negócio
Requisitos
Análise
Implementação
Artefato
Interação
Modelo Conceitual ou
Documento Visão
Diagrama de Caso de Uso
Concepção Elaboração Construção
Transição
P
P
R
Descrição de Caso de Uso
P
R
Diagrama de Seqüência
P
R
Contratos para operações
P
R
Glossário
Diagrama de Classes
P
R
P
R
Diagrama de Colaboração
P
R
Diagrama de Pacotes
P
R
Documento de Arquitetura do
Software
Código Fonte
P
R
P
P = produzir
R
R = revisar
FERRAMENTAS DE APOIO
Ago/2010
Ferramentas



O que são Ferramentas CASE?
A sigla CASE significa “Computer-Aided Software
Engineering”.
Traduzindo para um bom português: “Engenharia
de Software Auxiliada por Computador”.
Ferramentas

1.
2.
3.
As ferramentas se dividem em três categorias. São
elas:
Lower CASE - ferramentas de codificação (frontend);
Upper CASE - ferramentas de análise, projeto e
implementação;
Integrated CASE - união de Upper e Lower CASE.
Ferramentas



Como escolher a ferramenta?
O primeiro passo é saber qual será o uso da
ferramenta na sua empresa. Isto é, ferramenta
para codificação ou ferramenta para análise.
Outro fator importante é que a ferramenta deve
ser aderente ao conceitos de trabalho na sua
empresa.Como estes conceitos e técnicas evoluem
no tempo.
Ferramentas

Questões importantes para escolha da ferramenta:
1.
2.
3.
O time de desenvolvimento está preparado
tecnicamente para trabalhar com ferramentas case?
Preciso capacitar os recursos humanos de minha
empresa?
A metodologia de desenvolvimento em minha
empresa está “amadurecida”?
Ferramentas

Na prática, as ferramentas existentes no mercado
possuem as características das quais destacam-se os
seguintes pontos:
Desenvolvidas
sobre
uma
arquitetura
inteligente
(customizável);
 Possuem
"facilitadores" para auxiliar nas tarefas
repetitivas;
 Verificação da consistência através de regras específicas;
 Geração de relatórios para acompanhamento do trabalho;
 Interfaces com outros aplicativos de desenvolvimento.

Ferramentas
“Uma ferramenta CASE não é a solução para todos
os problemas da organização. A organização deve
ter certeza de estar pronta para a nova ferramenta.
Desta forma uma ferramenta só deveria ser
selecionada após a definição do processo de
desenvolvimento, dos métodos e de ter sido utilizada
num projeto piloto.” (Reid).
Ferramentas

Comerciais e “Free Editions”
 MagicDraw
($ 1,599,00)
 Together Architect ( $ 11.500,00)
 Poseidon ($ 875,00 )
 Enterprise Architect ($ 2.500,00)
 Rose Technical Developer ($6,880.00)
 Jude/Astah ($280,00 1usuário/1ano)
 Omondo Eclipse UML ($ 84,900.00 / 20 usuários)
 Visual Paradigm ($ 699)
Fonte: http://www.objectsbydesign.com/tools/umltools_byPrice.html
Ferramentas

Livres (BSD e GPL)
 Umbrello
 ArgoUML
 Dia
 BOUML
 Fajuba
 StarUML



Dia é um programa baseado em gtk+ para criação
do diagrama, liberado sob a licença GPL.
É parte do projeto Gnome.
Atualmente tem objetos especiais de lógica,
entidade e relacionamento, diagramas UML,
fluxogramas, diagramas da rede, e circuitos simples
entre outros.
ArgoUML



ArgoUML é uma ferramenta CASE baseada na
notação UML (Unified Modeling Language).
Foi
desenvolvido
pela
comunidade
de
desenvolvedores de código livre Tigris vinculada a
Universidade da California, Berkeley.
Sua interface é bem completa o que a torna um
pouco complexa de manipular.


Umbrello e um Software de Modelagem UML, que
e integrado ao projeto KDE.
Este Software é utilizado para modelar o próprio
projeto do KDE por a grande de seus
desenvolvedores que utilizam UML.



JUDE é uma ferramenta profissional de modelagem
para sistemas a qual suporta UML, diagrama entidade
relacionamento, Flowchart, CRUD, Mini Mapas e
Diagrama de Fluxo de Dados.
Permite também a conversão entre modelos UML, ER
Diagramas, Flowcharts, fluxo de dados e mini mapas.
O nome do programa é um acrônimo de Java and UML
Developers
Environment
(Ambiente
para
Desenvolvedores UML e Java).