A Fase de Anlise no Processo Unificado

Ricardo R. Gudwin
DCA-FEEC-UNICAMP
09/11/2010

Introduo
A fase de anlise, tambm chamada muitas vezes de anlise dos requisitos (no confundir com
especificao dos requisitos nem com a anlise de domnio), corresponde a uma fase onde faremos o
aprofundamento das investigaes acerca das especificaes dos requisitos. Assim, procederemos ao
detalhamento e refinamento dessas especificaes.
O grande objetivo desta fase a obteno de uma melhor compreenso dos requisitos, mantendo uma
descrico dos requisitos que seja compreensvel e auxilie no posterior design do sistema. Podemos dizer
que o que se faz na fase de anlise uma espcie de traduo das especificaes dos requisitos, que se
encontram na linguagem do cliente, para uma representao que use uma linguagem do desenvolvedor.
Assim, passamos de um modelo de casos de uso para um modelo de anlise. O modelo de casos de uso
corresponde a uma viso do sistema sob a ptica do cliente - ou seja - viesado para o que o cliente deseja
que seja implementado. O modelo de anlise corresponde a uma viso do mesmo sistema j sob um
ngulo diferente, ou seja, a descoberta e detalhamento do que o usurio necessita e sua descrio,
preparando o terreno para a fase de design que vir no futuro, onde sero assumidos compromissos com
relao s tecnologias que sero utilizadas para sua implementao.
Veremos que um dos principais desafios a serem vencidos na fase de anlise se manter um nvel
abstrato de investigao, sem entrar em questes de design do sistema.
O modelo de anlise permite o refinamento do modelo de casos de uso por meio da especificao dos
detalhes internos do sistema a ser construdo. Dessa forma, prov um melhor poder de expresso e um
formalismo mais refinado, principalmente para a descrio da dinmica do sistema. Entretanto, apesar
desse maior detalhamento, o modelo de anlise deve usar somente de abstraes, evitando a soluo
definitiva de alguns tipos de problemas, que devem ser postergadas para a fase de design.
Veremos que algumas estruturas desenvolvidas na fase de anlise nem sempre sero preservadas durante
o design. Essa uma das razes para que se mantenha estas estruturas de forma abstrata durante a anlise.
Estruturas muito amarradas podem se tornar um empecilho durante o design tendo que ser descartadas.
Estruturas mais abstratas podem ter seu escopo negociado e compromissado quanto a flexibilidade
quando se passar da anlise para o design.
De um modo geral, podemos comparar as fases de anlise e design no seguinte sentido. A fase de anlise
busca responder a seguinte pergunta: o qu ? O que o sistema deve fazer o que o sistema deve ser o
que o sistema realiza. A fase de design, ao contrrio, buscar responder a seguinte pergunta: como ?
Como o sistema far como o sistema ser como o sistema realiza. Assim, durante a fase de anlise,
a compreenso de quais so as responsabilidades do sistema mais importante do que como essas
responsabilidades sero futuramente implementadas.
Durante a fase de anlise, os principais artefatos de software desenvolvidos sero a Arquitetura de
Anlise, decomposta em diversos diagramas de classes que devem conter as classes e pacotes de anlise.
Alm da arquitetura, teremos as realizaes de casos de uso que sero modeladas por meio de
diagramas de interao e dos contratos regulando o significado das mensagens nesses diagramas.
Todos esses artefatos se integram, compondo a chamada viso do modelo de anlise. Essa viso
representa um ngulo por meio do qual podemos descrever o sistema, em termos de suas
responsabilidades, sem nos comprometermos com sua implementao. Durante a fase de design, uma
possvel implementao ser escolhida e planejada.

Classes de anlise representam abstraes de uma ou mais classes ou subsistemas que iro aparecer no
design do sistema. Podemos imagin-las como grnulos grossos ou de mais alto nvel por meio do qual
estaremos a descrever a funcionalidade do sistema que estamos desenvolvendo. Dentre outras
caractersticas, veremos que as classes de anlise focalizam nos requisitos funcionais do sistema,
postergando os requisitos no-funcionais (tais como os detalhes da interface, etc ) para a fase de
design. Assim, torna-se mais importante na fase de anlise a definio de interfaces em termos de
responsabilidades, que podero futuramente sofrer diferentes implementaes. Assim, deve-se preocupar
com a descoberta de atributos de alto nvel e relacionamentos conceituais.
Uma das maneiras de se manter esse nvel abstrato durante a anlise por meio da partio de nossas
classes em trs esteretipos: boundary, control e entity, conforme a figura abaixo:

Classes do tipo boundary so classes utilizadas para modelar a interao entre o sistema e os atores. Essa
interao envolve o recebimento e a apresentao de informaes. Podemos ento utilizar classes do tipo
boundary para modelar janelas grficas ou outros tipos de interface em que os atores enviem suas
mensagens na forma de eventos, e que o sistema possa mostrar seu desempenho na forma de
representaes visuais ou sonoras.
Classes do tipo control so classes que representam a coordenao, sequenciamento, transaes e controle
de outros objetos. Podem ainda realizar derivaes e clculos com informaes prprias ou oriundas de
outros objetos. Assim, as classes do tipo control so classes que fazem alguma coisa, que realizam
alguma atividade. Essa atividade pode envolver outros objetos de outras classes.
Por fim, classes do tipo entity so classes que modelam informaes (dados) de longa durao,
frequentemente dados que se desejam armazenar de maneira persistente (embora isso no seja
necessrio). Assim, classes do tipo entity so classes que comporo a estrutura de dados interna do
sistema, que devero ser manipulados por objetos de classes do tipo control, interagindo com o usurio
por meio de classes do tipo boundary.
Por meio da criao de classes do tipo boundary, control e entity, somos capazes de descrever o sistema
em um nvel bem abstrato, como o necessrio para os objetivos da fase de anlise.
A fase de anlise, em si, corresponde sequncia de atividades conforme pode ser visto na figura a
seguir:

Definio Inicial da Arquitetura de Anlise

O objetivo dessa fase gerar um outline da arquitetura de anlise, por meio da identificao de pacotes e
classes que possam servir de pinculo para a posterior anlise dos casos de uso. certo que a arquitetura
final de anlise somente poder ser concluda aps a anlise dos casos de uso. Entretanto, nessa etapa
visa-se criar um ponto de partida unificado por meio do qual todos os diferentes desenvolvedores
trabalhando individualmente sobre os casos de uso possam adotar um conjunto inicial de classes
padronizado, diminuindo o esforo posterior na etapa de integrao da arquitetura.
O resultado final que se espera dessa fase um esboo inicial do diagrama de classes estruturado que
constitui a Arquitetura de Anlise. Um diagrama de classes estruturado um conjunto de diagramas de
classes associados mutuamente por uma relao de hierarquia, formando uma rvore. Em sistemas mais
simples, esse diagrama ser simplesmente um nico diagrama de classes. Em sistemas mais complexos, a
partir do diagrama raiz da rvore, muitas vezes chamado de diagrama de pacotes, associam-se diagramas
subsequentes, um para cada pacote presente no diagrama raiz. Assim, sucessivamente, para cada pacote
presente em um diagrama, associa-se um outro diagrama de classes, que poder conter classes e/ou outros
pacotes.
Inicia-se essa fase consultando-se os diagramas de atividade gerados na especificao, e para cada
interface com o usurio identificada na especificao, gera-se uma classe do tipo boundary, que inserida
no diagrama de classes.
Aps o levantamento de todas as classes do tipo boundary, deve-se acrescentar classes do tipo control
controlando essas interfaces. Uma nica classe do tipo control pode controlar mais de uma classe do tipo
boundary. A escolha do nmero de classes do tipo control a serem inseridas uma deciso dos
desenvolvedores. Por fim, deve-se consultar o modelo conceitual de domnio, e dele extrair classes do
tipo entity que se mostrem apropriadas aos tipos de dados necessrios para a anlise dos casos de uso.
No necessrio ser exaustivo nessa fase. Qualquer classe que no tenha uma utilidade bvia no deve
ser includa.
medida que o nmero de classes vai aumentando, pode ser conveniente re-organiz-las em pacotes.
Pacotes permitem uma melhor organizao do modelo de anlise, dividindo-o em partes menores mais
fceis de serem gerenciadas. Essa diviso pode ser feita visando-se dividir o trabalho entre diferentes
integrantes da equipe de desenvolvimento. Entretanto, deve-se fazer essa diviso alocando-se casos de
usos com funcionalidades semelhantes em pacotes comuns, como por exemplo:
casos de uso que suportam processos organizacionais comuns
casos de uso que suportam um ator especfico
casos de uso relacionados por generalizaes, extenses ou incluses

Ao final dessa etapa, obtm-se uma verso inicial da arquitetura de anlise, que servir de ponto de
partida para que a anlise dos casos de uso possa ser iniciada.

Levantamento de Requisitos Especiais

Antes de proceder anlise de casos de uso, entretanto, necessria ainda uma outra etapa preliminar.
Nenhum projeto de software transcorre construindo-se o sistema todo da estaca zero. bastante normal a
reutilizao de partes do sistema oriundas de sistemas anteriores, ou de componentes especialmente
produzidos com a finalidade de serem reutilizados. Para uma srie de requisitos do sistema, existem j
solues de prateleira prontas, que evitam o retrabalho em questes vitais da confiabilidade de um
sistema. Requisitos especiais so aqueles que visam identificar a existncia de partes do sistema que
possam ser reutilizadas posteriormente no design. Dentre outros, requisitos especiais podem envolver
requisitos de:

persistncia
distribuio ou concorrncia
restries de segurana
tolerncia a falhas
gerenciamento de transaes
etc

Nessa fase, o grupo deve se reunir e deliberar sobre a existncia de requisitos dessa natureza no projeto
em desenvolvimento. Nesse momento, suficiente a identificao de sua relevncia para o sistema.
Posteriormente, na fase de design, a equipe deve decidir se esses requisitos sero desenvolvidos pelo
grupo ou se sero reutilizados de alguma maneira. Em alguns casos, os requisitos especiais s podero ser
encontrados durante a realizao dos casos de uso. Ao final dessa fase, o resultado esperado uma lista
dos requisitos especiais que podem existir para o projeto.

Desenvolvimento dos Diagramas de Interao para cada Caso de

Uso
O objetivo dessa atividade implementar a assim chamada Realizao dos Casos de Uso. Na fase de
especificao, o sistema visto sempre como uma unidade monoltica - o sistema. A grande mudana que
se processa na fase da anlise exatamente a decomposio desse sistema em partes menores. Dessa
forma, cada caso de uso detalhado por um diagrama de atividades deve agora ser realizado,
desenvolvendo-se um diagrama de interao. No UML, existem basicamente dois tipos de diagramas de
interao, os diagramas de comunicao (chamados tambm de diagramas de colaborao, no UML 1) e
os diagramas de sequncia. Esses dois diagramas, em princpio, so diagramas duais - um diagrama de
comunicao pode ser re-escrito na forma de um diagrama de sequncia e vice-versa. A escolha por um
diagrama de comunicao ou um diagrama de sequncia diz respeito somente ao nmero de objetos que
devem interagir e quantidade de mensagens que estes objetos devem trocar entre si. Caso haja um
grande nmero de objetos, trocando entre si um nmero reduzido de mensagens, os diagramas de
comunicao so mais adequados. Caso os mesmos objetos troquem entre si um grande nmero de
mensagens, os diagramas de sequncia mostram-se mais adequados.
Um exemplo de diagrama de comunicao mostrado a seguir:

Observe algumas peculiaridades desse diagrama. Por exemplo, todos os nomes esto grifados,
significando que se tratam de instncias das classes e no as classes em si como no diagrama de classes.
Como temos somente um objeto de cada classe no necessrio nome-los. Portanto, os nomes dos
objetos so omitidos, e temos somente nomes do tipo :NomeClasse. Caso houvesse dois ou mais objetos
de uma mesma classe, nomes poderiam ser acrescentados, resultando em algo como
Nome1:NomeClasse, Nome2:NomeClasse.
Observe tambm que entre os objetos fluem mensagens que so numeradas e podem conter parmetros.
Neste ponto, somente indicamos as mensagens. Entretanto, devemos estar conscientes que em uma
atividade subsequente, iremos especificar mais profundamente o significado destas mensagens por meio
de contratos individuais para cada mensagem.
Essa atividade deve ser executada de maneira concomitante com a atividade a seguir, o desenvolvimento
dos diagramas de classes para cada caso de uso. Muitas ferramentas CASE de edio de diagramas UML
no permitem que um objeto de uma classe seja inserido em um diagrama de interao, se ele no estiver
j definido em um diagrama de classes. Na prtica, isso significa que o diagrama de interao precisa ser
feito necessariamente em concomitncia com o diagrama de classes.

Desenvolvimento de Diagramas de Classes para cada Caso de

Uso
A realizao de um caso de uso, alm do diagrama de interao que o descreve, demanda tambm um
diagrama de classes representando as classes que so utilizadas em um diagrama de interao. Esses
diagramas de classes sero posteriormente integrados na arquitetura de anlise do sistema.
Dessa forma, da mesma maneira que fizemos inicialmente no levantamento inicial da arquitetura,
utilizaremos as idias dos esteretipos control, entity e boundary para tentar delinear um conjunto de
classes que dem conta de realizar o caso de uso em questo. Deve-se partir das classes j existentes na
arquitetura inicial de anlise, e ir se inserindo novas classes medida em que as mesmas mostrem-se
necessrias para a realizao do caso de uso.
Um exemplo de um diagrama de classes de anlise pode ser visto na figura a seguir:

H entretanto um desafio escondido aqui. Como os casos de uso so desenvolvidos individualmente, pode
haver redundncia na gerao de classes entre diferentes desenvolvedores. Essa redundncia precisar ser
solucionada posteriormente, durante a fase de integrao da arquitetura, quando os diagramas de classes
desenvolvidos nessa fase devem ser consolidados em uma nica arquitetura que integre todos os casos de
uso do sistema.

Elaborao dos Contratos para as Classes

O objetivo desta atividade compreende a identificao e formalizao das responsabilidades de uma
classe de anlise, baseadas em seu papel na realizao de um caso de uso.
A identificao de responsabilidades pode ser perpetrada por meio da descoberta dos papis que as
diferentes classes assumem em diferentes realizaes de casos de uso. Assim, as responsabilidades esto
associadas s mensagens que uma classe pode receber.
A descrio das responsabilidades ser formalizada por meio da elaborao dos chamados contratos.
Contratos descrevem as responsabilidades de uma determinada classe em termos de quais mudanas no
estado do objeto so realizadas quando este recebe mensagens (ou invocaes de mtodos). Esses
contratos devem descrever O QU o objeto deve fazer, sem explicar COMO ele o faz. Para cada
mensagem aparecendo em um diagrama de interao, deve haver um contrato correspondente.
Os contratos devem estar organizados por classe. Dessa forma, mesmo que uma mesma mensagem
aparea em mais de uma classe, deve haver um contrato diferente para cada classe onde a mensagem
aparece.
Um contrato est dividido em diversas sees. Cada seo prov informaes sobre uma parte especfica
do contrato. Nem todas as sees so obrigatrias, devendo aparecer somente quando necessrio. Um
contrato deve ter a seguinte estrutura:
-------------------------------------------------------------------------------------------Nome: nome da operao e eventualmente seus parmetros
Responsabilidades: uma descrio informal das responsabilidades que a operao deve implementar
Tipo:conceitual, classe de software ou interface
Referncias Cruzadas: outras classes que utilizam o mesmo contrato, etc.
Notas: informaes adicionais, algoritmos, etc.
Excees: casos excepcionais
Sadas Secundrias: sadas no relacionadas interface com o usurio, e.g. mensagens de erros, logs,
etc.
Pr-Condies: condies referentes ao estado do sistema antes da execuo da operao
Ps-Condies: estado do sistema aps a concluso da operao
-------------------------------------------------------------------------------------------Para fazer um contrato, devemos inicialmente identificar as operaes a serem reguladas por contratos, a
partir dos diagramas de colaborao. Para cada operao, devemos implementar um contrato. Comeamos
pela seo "Responsabilidades", descrevendo informalmente o propsito da operao. Em seguida, passase seo de "Ps-Condies", descrevendo declarativamente as mudanas no estado do objeto que
devem ocorrer em virtude da operao. Para descrever as ps-condies, devemos atentar para os
seguintes pontos:
Criao e destruio de instncias de outros objetos
Modificao de Atributos
Formao ou destruico de associaes
As ps-condies so a parte mais importante de um contrato. Por isso, devemos ter um cuidado todo
especial em sua elaborao. Particularmente, devemos ter muita ateno para no confundirmos as pscondies com as sadas secundrias. Outro ponto importante lembrarmos que as ps-condies no so
aes a serem executadas durante a operao, mas declaraes sobre o estado do objeto aps a concluso
da operao contratada. Algo que no podemos tambm esquecer que as ps-condies dizem respeito
ao modelo de anlise. Portanto, as classes dos objetos criados devem existir no diagrama de classes, do
mesmo modo que as associaes.
Uma pergunta que muitas vezes aparece a seguinte: quo completas devem ser as ps-condies.

Devemos ter conscincia de que um conjunto de ps-condies completo e acurado muito improvvel e nem mesmo necessrio - durante a fase de anlise. Os detalhes maiores podero ser descobertos durante
a fase de design.
Agora voltemo-nos para as pr-condies. As pr-condies definem condies sobre o estado do sistema
que so necessrias para que a operao possa ser realizada. Por exemplo: coisas que se deve testar a
certo ponto da operao, ou coisas que no sero testadas, mas que so determinantes no sucesso da
operao. Tais pr-condies devem ser documentadas para auxiliar a futura implementao da operao
em fases futuras.
Aps a determinao dos contratos, podemos nos dedicar identificao de atributos. Os atributos
especificam propriedades de uma classe de anlise. Em princpio, devemos descrever, em uma classe de
anlise, somente os atributos que esto especificamente referenciados nos contratos. Por exemplo, caso
um contrato especifique que o valor de um determinado atributo deve ser modificado, este atributo deve
ser representado.
Podemos utilizar alguns guidelines para o levantamento de atributos. Por exemplo, sabemos que o nome
de um atributo deve ser um substantivo. Do mesmo modo o tipo do atributo deve ser abstrato (pois
estamos na anlise). Assim, devemos utilizar por exemplo um tipo como "quantidade" ao invs de coisas
como "inteiro". Devemos tentar reutilizar ao mximo os tipos utilizados. Devemos nos lembrar que os
atributos so atrelados a cada instncia do objeto e no classe. Se houver muitos atributos, alguns deles
devem ser transformados em classes. Por fim, devemos lembrar que nem sempre necessrio ter
atributos.
Que atributos devemos incluir ? Somente aqueles que forem realmente necessrios para satisfazer os
requisitos de informao relevantes para os casos de uso sendo analisados e/ou aqueles que devem ser
"lembrados" para serem utilizados em algum ponto de um caso de uso.
Algumas regras devem ser seguidas por exemplo, quando estivermos modelando quantidades,
devemos usar um conceito separado "unidade" para mensurar atributos. Isso facilitar o entendimento do
modelo e permitir sua modificao mais facilmente. Da mesma maneira, devemos evitar fazer referncia
a atributos de classes externas como atributos (uma prtica condenada batizada de uso de foreign-keys, ou
chaves externas). Veja o exemplo da figura abaixo:

Na primeira especificao da classe, colocamos o nome do cliente (CustomerName) como um atributo de

Invoice. Entretanto, esse tipo de representao pode nos causar problemas, pois existe uma entidade que
fregus (Customer) e o que queremos indicar o nome desse fregus. Assim, a segunda representao
mais conveniente, pois permite que mudemos a estrutura da classe Customer, sem termos que alterar
tambm Invoice.
Em seguida identificao dos atributos, podemos nos dedicar procura de associaes e agregaes.
Sabemos que os objetos de anlise interagem entre si por meio de conexes em diagramas de interao.
Estas conexes so normalmente instncias de associaes entre as classes correspondentes. Deve-se pois
estudar as conexes necessrias em um diagrama de interao de modo a determinar as associaes
necessrias no diagrama de classes, levando-se em conta que o nmero de relacionamentos entre classes
deve ser minizado o quanto possvel. Assim, devemos modelar somente os relacionamentos realmente
necessrios para se modelar a realizao dos casos de uso.
Por fim, podemos identificar generalizaes. Generalizaes devem ser utilizadas para extrair
comportamentos comuns ou compartilhados entre diferentes classes de anlise. Assim, devemos olhar
novamente as classes geradas anteriormente, tentando identificar comportamentos comuns que possam
ser generalizados. Havendo a possibilidade, devemos ento criar classes abstratas e apontar as
generalizaes possveis.
Os resultados dessa atividade, portanto, sero a determinao da estrutura interna de cada classe de
anlise, em termos de seus atributos e seus mtodos. Cada mtodo deve estar associado a um contrato que
descreve suas responsabilidades.

Integrao da Arquitetura
A assim chamada Anlise dos Casos de Uso (a soma das duas ltimas atividades) realizada de maneira
individual por cada desenvolvedor, que gera os diagramas de interao e os diagramas de classes
correpondentes para a realizao dos casos de uso. Entretanto, durante essa atividade, h um grande
potencial para redundncia, onde classes com finalidades semelhantes e nomes distintos so geradas. Da
mesma forma, pode ocorrer de classes com um mesmo nome, mas com propsitos distintos serem
geradas, o que poderia gerar grande confuso, caso essas classes fossem simplesmente acrescentadas
arquitetura de maneira cumulativa.
O objetivo desta atividade fazer uma integrao criteriosa dos diagramas de classes desenvolvidos na
etapa anterior arquitetura inicial de anlise desenvolvida no incio da fase de anlise, efetuando as
correes necessrias para que se possa definir de maneira definitiva a arquitetura de anlise.
Caso as classes estejam divididas em diversos pacotes, alm disso deve-se garantir a independncia entre
os diferentes pacotes, diminuindo o acoplamento entre eles, e aumentando a coeso entre as classes dentro
de um pacote.
Alguns guidelines podem ser utilizados para essa anlise de pacotes. Devemos inicialmente definir e
formalizar as dependncias entre os pacotes, dependendo das classes que estes contiverem e seu uso de
objetos de classes de outros pacotes. Essa dependncia deve ser indicada explicitamente por meio de
arcos do tipo dependncia entre os pacotes aparecendo em algum diagrama da arquitetura. Devemos
garantir que os pacotes contenham as classes corretas. Isso se faz mantendo-se os pacotes coesos, ou seja,
incluindo somente objetos que estejam funcionalmente correlacionados. Devemos ainda tentar limitar as
dependncias entre pacotes. Assim, devemos considerar a relocao de classes que criem muitas
dependncias entre pacotes. Tais classes devem ser por exemplo transferidas para outros pacotes de tal
forma que essas dependncias diminuam.
Ao final desta atividade, os diagramas de classes levantados individualmente durante a anlise dos casos
de uso so descartados, e as classes correspondentes so ento integradas arquitetura de anlise do
sistema.
Ao final da fase de anlise, os documentos gerados sero portanto os seguintes:
Arquitetura do Sistema - composta por um diagrama de classes estruturado em diversos subdiagramas
Diagramas de Interao - Realizao dos Casos de Uso
Contratos - agrupados para cada classe da arquitetura
Lista de Requisitos Especiais