p



 

CONHECIMENTOS INICIAIS
 Existem vários processos que se propõem
serem adequados à construção de software. Antes
da p
tínhamos um processo, não formal, que se
resumia ao levantamento de requisitos, à definição
do Modelo Entidade Relacionamento (MER) e
assim iniciava-se a codificação. Mesmo os mais
decantados processos apresentam falhas ainda não
superadas.
A 

 da boa construção de software
ainda não foi desenvolvida, e isso ocorre em
detrimento de toda a tecnologia existente.
 i
 
!"
uando se pensa em construir uma casa,
prédio, navio, enfim qualquer obra de Engenharia
Civil, Naval ou Eletrônica inicia-se com uma
planta. Todos envolvidos no processo colocam à
disposição anos de trabalho e conseqüente
experiência. Nada se inicia, em termos de
construção, antes que a concepção do projeto
esteja terminada.
 No caso da construção civil, tudo é pensado e
arquitetado antes mesmo de ser cavado o primeiro
buraco duma determinada base.
Por anos, a TI tenta construir software tendo
como comparação a construção civil. O problema é
que os requisitos de um software sofrem mudanças.
 @
O que o Cliente de um software tem como certo é
sua necessidade, pois a idéia inicial está meio obscura
em sua mente por diversas razões, mas com freqüência
pela falta de conhecimento tecnológico ou mesmo
aversão inicial à tecnologia.
uando um engenheiro civil informa para um
cliente quais possibilidades de obras podem ser
concebidas num determinado terreno dificilmente se
discute sua sentença. O interessado passa a formar
uma imagem mental a partir destas informações
iniciais e isso facilita o trabalho inicial de concepção
do projeto.
 i#
Neste estágio o interessado deve aprovar uma idéia
abstrata do software. Documentos e diagramas são
entregues a eles que para compreensão requerem
conhecimento de nível superior e especializações.
Mesmo quando o público, neste caso, é da área de TI,
carece de conhecimento em subáreas que os softwares
atuais abarcam.
A visão que o interessado tem é de alto nível, porém
nada palpável existe para a tomada segura de decisão. A
idéia inicial do interessado ´mudaµ em relação ao 1°
estágio pois aquela idéia obscura foi melhorada com
ajuda do pessoal da construção do projeto.
 Na construção civil, quando a planta é
mostrada ao interessado, este fala mais à vontade
de sua aprovação ou recusa, por se tratar de
assuntos mais concretos. Ele sabe o que é 


  , então consegue abstrair, com
maior fluidez, o resultado final.
Muitos resultados indesejáveis, que viriam no
futuro, já são resolvidos nesse estágio, pela
simplicidade do interessado compreender a planta
da sua casa e solicitar as mudanças ao seu gosto que
são quase sempre definitivas neste caso.
 $%$


Aqui o detalhamento completo do software

desejado é escrito e novamente busca-se a
aprovação do interessado. Nada é construído,
apenas as funcionalidades são escritas.
Com isso a idéia inicial do Cliente se altera pois
seu nível de abstração melhorou.
 &@
Com a aprovação da idéia no 2° e 3° estágios a
construção tem seu início com o MER, para se planejar
o armazenamento dos dados. Esse a
de estratégia
aconteceu durante muitos anos!
Com a apresentação da interface gráfica o Cliente
´mudaµ sua idéia por ver, efetivamente, como sua
necessidade será atendida. Agora ele  algo mais
concreto.
Na construção civil o Cliente só mudará sua idéia
caso algo não corresponda absurdamente ao seu gosto
inicial, fora isso, quando as paredes estiverem
levantadas desejo alcançado.
 @
Aqui a premissa é de que tudo o que se necessitava
foi conversado e assinado.
No caso da demissão de um componente da equipe
problemas começam o aparecer por conta do
personalismo nos códigos fontes e também perde-se
muito tempo até o próximo profissional se adaptar com
o esquema já concebido e principalmente com os
´zilhõesµ de linhas de código feitas pelo colega anterior.
Na construção civil a visita do Cliente para avaliar o
andamento é feita com regularidade e caso alguém da
equipe saia o próximo vem e já continua seu trabalho
sem mais entraves.
 '
Devido aos problemas de adaptação de
pessoal, tecnologia e política,   






 
   

 
 
 
 . (vi isso acontecer várias vezes
aqui rs)...
Não raro, quando o software é entregue numa
cerimônia com o principal investidos presente,
ouve-se a homérica frase: ´      

 

Na construção civil........
 (((
rancamente, se uma forma de construção de software for a
certa, ela ganhará rapidamente a 1ª página de diversos jornais
pelo mundo todo pois a forma depende de muitos fatores.
Todas outras áreas da engenharia já existem há séculos
enquanto a TI e, em particular, a engenharia de software existem
há poucas dezenas de anos.
Outro ponto interessante é que software versa sobre algo
intangível, por vezes, inimagináveis. O mesmo não ocorre com
as outras ciências citadas e ainda com o desconhecimento dos
requerentes dum software sobre as tecnologias à sua disposição.
Assim, conforme o software vai se concretizando, a idéia do
interessado se aprimora, ou seja, muda.
O que pode se levar em conta também é que um software
não é algo estanque como uma construção sólida. Em contra
partida as mudanças possíveis num software são incessantes pois
a mudança evolucionária em TI é incessante também.
  )p
(
Percebemos, logo à 1ª vista, que a UML não nos indica
como devemos fazer um software. Ela indica apenas as formas
que podem ser utilizadas para representar um software em
diversos estágios de desenvolvimento.
Podemos dizer que a UML é uma forma de comunicar uma
idéia.
A finalidade da UML é proporcionar um padrão para a
preparação de planos de arquitetura de projetos de sistemas,
incluindo aspectos conceituais, como processos de negócios e
funções de sistema, além de itens concretos, como as escritas em
determinada linguagem, esquemas de BDs e etc..
A UML 2.0 é composta de 13 diagramas e, ainda a descrição
dos Casos de Uso.
UML significa Unified Modeling Language. É uma
ferramenta que nos auxilia na modelagem de sistemas.
UML não é um processo de desenvolvimento de software e
sim a forma de comunicação que um processo pode utilizar.
 =p
Como processo de desenvolvimento, entre vários, temos o
Processo Unificado e suas principais características são:
. ÷    
p A
. 

 
: esta é preocupação de como vemos um
software como um todoA
. 



: uma versão do sistema liberada resulta numa
iteração concluída. Se uma entrega promoveu uma melhora, ela
incrementou algo no sistema, daí o chamamos de 




.

O Processo Unificado prevê quatro grandes fases: 


a  
 .
 =p

 é pensado na Visão do Software, em que o documento do
mesmo nome é construído, é avaliado a tecnologia que se apresenta,
relacionamos os riscos principais ou mais aparentes e é detectado a(s)
área(s) mais crítica(s) a ser(em) tratada(s).
Essa fase tem, tipicamente, uma iteração. Ela incrementa o
entendimento do software como um todo para todos os participantes
projeto.
a os requisitos (que aparecem no conjunto dos Casos de Uso)
das áreas mais críticas são levantados. Ela consolida a fase de
concepção, agregando valor a cada iteração-incremento que sofre.
  quando é pensado em protótipos e nos relacionamos com
campos de um banco de dados, quando funções e ou 
 


conversam com componentes em !

 ou a, estamos enfrentado
a fase de construção do Processo Unificado.
  quando parte do software sai da versão beta e pode ser avaliado
como versão de produção, significa que estamos na fase de transição,
em que os erros encontrados devem ser mínimos. Se chegarmos à
homologação da parte sendo avaliada, o ciclo terminou.
 *$=p
† "# conjunto de atividades com um objetivo comum.

  é necessário se obter todos ( ) os requisitos para a
formação de Casos de Uso bem escritosA
i
quando se identifica quem realizará um Caso de Uso ou um de
seus cenários principais, em termos de classes de forma conceitual,
estamos dentro do #"# de Análise.
$%
 quando saímos duma visão conceitual da construção de classes e
diagrama de seqüência, na abstração requerida, estamos dentro deste
#"#A
 

 este é encontrado quando estamos codificando e
compilando algum código. A transformação do diagrama de classes
em componentes, bem como o atendimento do diagrama de
seqüência, mostra que estamos nesse #"#.


A criação de um modelo de teste, ou seja, a descrição de por quais
testes uma implementação deve passar, relata esse #"#.
 +,(((
uando sua empresa estiver com pelo menos um projeto
concluído, utilizando o Processo Unificado, a UML e as técnicas de
gerenciamento de projetos, ela pode se candidatar a uma certificação
em CMM.
CMM þ & & 
' é uma certificação internacional
que atesta que sua empresa está madura no desenvolvimento de
software.
 p


 

DOCUMENTOS INICIAIS DE UM
SOTWARE
 Bons softwares têm documentação, ou seja, uma
ï  na qual podemos nos apoiar para entendê-los.

÷
 (  este documento é um relato resumido com
os principais tópicos que o negócio a ser automatizado
deve fornecer. Ele pode abordar aspectos de tecnologia
como, quais linguagens e BDs serão usados. Apesar disso,
ele é uma leitura de alto nível para aqueles que são os
contratantes do software. O diagrama de Caso de Uso de
nível 0 ou Pacote de <<sistema>> baseia-se nesse
documento.
O nascimento desse documento, normalmente se dá
na 1ª reunião com os clientes do software.
 $-- 
$
./ Locação de DVDs pela Internet
./
// 27 de maio de 2011

0 
Empresa Cliente
= @
Contato 1 ² e-mail ² fone
Contato 2 ² e-mail ² fone
Contato 3 ² e-mail ² fone

Este software tem o objetivo de disponibilizar a locação de DVDs,
via Internet, a clientes já cadastrados ou novos.
O software deve prever o cadastramento de usuários locadores,
com seus dados pessoais, principalmente, os dados de endereço, que
são tão importantes para a entrega como para a recuperação de
produtos alugados.
Atenderá a todas as cidades onde o cliente contratante tiver
depósito de DVD. Serão disponibilizados somente DVDs da cidade
onde o cliente locador reside, visando à entrega.
 O cliente locador deve informar o modelo de sue equipamento
de DVD, a fim de se avaliar se ele é ou não adequando a reproduzir
o filme.
O cliente locador terá, no máximo, cinco dias para a devolução
de um DVD alugado, sendo que esse período dependerá do tipo de
DVD, que pode ser: desde lançamento até DVDs antigos. O
processo de fidelizar o cliente locador leva em consideração tanto o
número de locações quanto as devoluções pontuais.
A não devolução de um DVD no prazo estipulado implica
pagamento de multa.
O cliente locador pode designar, desde que apresente a
documentação necessária, beneficiários capazes de efetivar um
aluguel de DVD.
As entregas serão feitas somente dentro da cidade em que o
locador reside.
Os administradores do site poderão, controlar Programa de
idelidade, de promoções, Preços e Marketing.
Os pagamentos serão feitos antecipadamente, pelo cartão de
crédito ou boleto bancário.
 @p1&#$2
3344
.!"   i pode ser uma pessoa, um sistema ou mesmo um
Entidade Externa. Pode ser também algo como um roteador. Ele
realiza uma atividade e sempre atua sobre um Caso de UsoA
. 
  
p  a elipse é a notação de um Caso de Uso que, por sua vez,
representa uma atividade. É a macro ação que o i realizaA
.i
i !
 indica relação de dependência que pode vir identificada, ou não,
por um nome significativo. A seta de dependência sempre parte do
Caso Uso que depende de outro em algum momento, apontando para o
Caso de Uso que fornece a necessidade desejada. Isto vale para  
e a
 A
Calcular idelidade Calcular Pontos
<<include>>
.inclusão de um Caso de Uso ou de parte dele em outro Caso de Uso. O
´Calcular Pontosµ utilizará integralmente a forma de cálculo de Pontos
de idelidade que se encontra documentada em ´Calcular idelidadeµ.
Isso serve para não termos que digitar duas vezes especificações que se
repetem em diferentes Casos de uso.
 @p1&#$2
3344
Calcular idelidade Calcular Bonificação
<<extend>>
.o formato anterior prevê que existe um cálculo em Calcular Bonificação, e
que esse cálculo irá se estender, ampliando o significado de uma
fórmula já existente no Caso de Uso Calcular idelidade.
 
$
Serve para criarmos um padrão único de pré e pós-
fixação para todos as palavras envolvidas em estrutura de
código, escrita de Caso de Uso ou mesmo criação de tabelas
de BDs.
Novos colaboradores que se juntarem à equipe deverão
se adequar a esse formato de escrita, que é o único permitido
no uso diário.
 5$!
Traduz, para alguém que não conhece o software, todas
os termos utilizados pelo usuário contratante e outros
"
ï
 . Deve ser disponibilizado na intranet da empresa,
a fim de permitir constates pesquisas.
A finalidade desse documento é agir como um tradutor
entre os participantes da análise, do desenho, da codificação,
dos testes e dos herdeiros do software, e o vocabulário
particular da empresa.
p


 

CASO DE USO
 O Caso de Uso é a parte mais importante da
construção de software orientado a objetos utilizado a
UML.
Em todas as iterações que vão ocorrendo na confecção
do novo software, o Caso de Uso é a ferramenta de
consulta, acerto, discussão, reuniões, alterações em
requisitos e alterações em desenho. Ele é a análise
intrínseca de um negócio, dentro do processo de
desenvolvimento de software, sugerido pelo processo
iterativo e por outras metodologias que se utilizam da
UML.
Começamos aqui a ver a diferenciação entre a UML e
o processo. Desde já, devemos saber que, no processo, a
UML é apenas a ferramenta.
  )@p(
†Conceito de AtorA
Um Caso de Uso pode ser explicado como uma
macroatividade que encerra diversas tarefas ou atividades.
Essas tarefas visam à consecução dessa macroatividade.
Um Caso de Uso pode ser, também, uma representação
descrita de variadas ações para a realização de uma
macroatividade.
 @p#
(
Um Caso de Uso deve ser bastante detalhado. Isso não
quer dizer que deve ser escrito um tratado maçante e longo
demais para ser lido. Por outro lado, a objetividade não deve
sacrificar a compreensão e a composição do detalhe
#6,@
p(
Tal extração somente é possível por duas vias - a
observação e a entrevista. A observação somente é possível
em casos onde a atividade é repetitiva, realizada por um
operador ou uma máquina. A entrevista somente é possível
entre humanos. Esta última é a forma mais comum de
extração de Casos de Uso.
Além da capacidade de comunicação interpessoal, o
analista de negócio deve conseguir escrever o que ouviu.
†uebrar o gelo.
†Escutar algo que interesse o interlocutor.
 @,@p(
÷  
   
p  usando um verbo no infinitivo facilitará a
sua classificação.
p 


 apenas relata qual o assunto de que aquele Caso de
Uso trata.
$) é qualquer ação ou reação de um subsistema ou ator que
$)
possibilite a esse Caso de Uso ter início.



 são separados por vírgula.
.


 $  descrição das tarefas que representem o mundo
perfeito.....
.


 i
 qq situação que represente uma exceção de uma
atividade do cenário principal

 

 são descrições que não cabem em nenhuma das
seções anteriores por serem mais precisas.
*
 
  relacione os dados encontrados enquanto escrever o
Caso de Uso.
*
 


 coloque informações do tipo lembretes, como ²
prever Caso de Uso ´xptoµ para abordar a situação tal, ou mesmo
lembretes para colegas....
 i@p
Analistas/programadores revoltam-se com o
entrevistado por causa de sua tendência em mudar o que já
havia si dito.
uando você mostrar a 1ª versão do seu Caso de Uso
para o seu interlocutor assinar, haverá mudanças. uando
você mostrar o protótipo de uma interface gráfica que
atende àquele Caso de Us, haverá mudanças.
Um cenário principal ou alternativo é um requisito e
requisitos mudam e devem mudar....
i$7 #@p(
Esse processo começa com o colega da baia ao lado.
Parece brincadeira mas não é. Jamais leve um Caso de Uso
para aprovação sem que antes um colega tenha lido o seu
conteúdo.
p@p
(
Não! Se você precisar de um gráfico, use-o! Se a inclusão
de um organograma favorecer o entendimento, inclua-o!
Isso pode acontecer se o Caso de Uso descrever coisas do
departamento de cargos e salários, por exemplo.