1

1 Introduo Engenharia de
Software
Jair C Leite
Departamento de Informtica e Matemtica Aplicada
Universidade Federal do Rio Grande do Norte
Campus Universitrio - Lagoa Nova
59072-970 - Natal - RN- Brazil
e-mail: jair@dimap.ufrn.br
Fone: +55(84) 215-3814

Objetivos
Apresentar as motivaes pela qual a disciplina e a profisso de engenharia de software fazse necessria. Veremos algumas definies e uma viso geral da rea. Discutiremos o que
software, diferenciando-o de programa e vendo-o como um artefato conceitual.
Discutiremos ainda as diferenas entre programao e engenharia de software.
Algumas questes devero ser discutidas:
Qual o contexto de um software?
Software e programa so a mesma coisa?
Engenharia de Software o mesmo que programao?

1.1 Sistemas baseados em computador

Um sistema baseado em computador aquele que automatiza ou apia a realizao de
atividades humanas atravs do processamento de informaes.
Um sistema baseado em computador caracterizado por alguns
elementos fundamentais.
Hardware
Software
Informaes
Usurios
Tarefas
Documentao
O hardware corresponde s partes eletrnicas e mecnicas (rgidas) que possibilitam a
existncia do software, o armazenamento de informaes e a interao com o usurio. A
CPU, as memrias primria e secundria, os perifricos, os componentes de redes de
computadores, so exemplos de elementos de hardware. Um nico computador pode
possibilitar a existncia de diversos sistemas e um sistema pode requisitar diversos
computadores.
O software a parte abstrata do sistema computacional que funciona
num hardware a partir de instrues codificadas numa linguagem de

2
programao. Estas instrues permitem o processamento e
armazenamento de informaes na forma de dados codificados e podem
ser controladas pelo usurio. Este controle, bem como a troca de
informaes entre o usurio e o sistema feita atravs da interface de
usurio, composta por hardware e software.
A informao um componente fundamental nos sistemas baseados em
computador. Por isto eles podem tambm ser chamados de sistemas
baseados em informao. Sistemas processam e armazenam dados
que so interpretados como informaes pelos usurios atravs da
interface. So os dados que representam elementos do domnio que
tornam o sistema til para os usurios.
Os usurios so tambm elementos centrais no desenvolvimento de
um sistema baseado em computador. As metas de cada usurio, de
acordo com o papel que cada um desempenha no domnio, devem poder
ser satisfeita pelo sistema.
As tarefas ou procedimentos compreendem as atividades que o sistema
realiza ou permite realizar. As tarefas caracterizam a funcionalidade do
sistema e devem permitir aos usurios satisfazer as suas metas.
A documentao do sistema envolve os manuais de usurio, que
contm informaes para o usurio utilizar o sistema (documentao do
sistema) que descrevem a sua estrutura e o funcionamento. Estes
ltimos so fundamentais durante o desenvolvimento do sistema para a
comunicao entre a equipe de desenvolvimento e para a transio
entre as suas diversas etapas e durante a manuteno de um sistema
em sua fase operacional.
Um sistema baseado em computador funciona num determinado
domnio de aplicao que corresponde a um tipo de ambiente ou
organizao onde o sistema utilizado.

Exemplos de sistemas baseados em computador

Sistema de Automao Bancria

Sistema de Folha de Pagamento
Sistema de Controle Acadmico
Sistema de Biblioteca
Sistema de Controle de Trfego Urbano
Sistema de Controle de Elevadores
Sistema de Editorao de Jornais e Revistas

Engenharia de Sistemas baseados em computador

O desenvolvimento do sistema deve ser pensado como um todo. Os problemas que o
sistema deve resolver devem ser analisados e uma soluo envolvendo todos os
componentes deve ser proposta. O desenvolvimento de cada componente do sistema pode
ser conduzido utilizando uma "engenharia" especfica. importante ressaltar que o termo
engenharia est sendo utilizado de forma imprecisa.

Engenharia de Hardware - construo dos diversos equipamentos de hardware,

engenharia de redes, etc.
Engenharia de Software - desenvolvimento dos diversos componentes de software
que compe o sistema
Engenharia de Informaes - modelagem e estruturao das informaes para que
possam ser armazenadas na forma de dados relacionados entre si.
Engenharia de Usabilidade (ou de Fatores Humanos) - Os fatores humanos
devem ser analisados para que as atividades humanas sejam desempenhadas com
qualidade.
Engenharia de Procedimentos ou Mtodos - Novas tarefas dos usurios devem
surgir e outras podem ser extintas. Outras atividades podem ser automatizadas pelo
sistema

Todas estas "engenharias" devem ser concebidas de forma integrada uma vez que os seus
elementos esto bastante relacionados entre si. A nfase em apenas um dos aspectos pode
levar a deficincias do sistema em alguns outros componentes.
Na construo de um sistema no podemos nos concentrar apenas na
engenharia de software. preciso considerar que o hardware, bem como
as informaes e os procedimentos do domnio precisam ser analisados
e construdos de forma integrada ao sistema.

Os trs nveis de um sistema baseado em computador

Podemos identificar trs nveis distintos de visualizao de um sistema baseado em
computador:
Nvel do domnio ou da organizao
No nvel do domnio todos o componentes podem ser visualizados de forma integrada.
Pode-se observar como cada um deles esto relacionados. Neste nvel o hardware e o
software so visto como um componente nico que interage com os diversos usurios de
maneira a permitir que as tarefas do domnio possam ser realizadas. Neste nvel avalia-se o
quanto o sistema resolve os problemas da organizao.
Neste nvel podemos identificar duas perspectivas distintas. Nas
perspectivas de automao os componentes hardware/software e
usurios so vistos como agentes das tarefas que o sistema pode
realizar. Na perspectiva de mdia o sistema visto como a plataforma
de suporte s atividades de comunicao entre os usurios atravs do
apoio no processamento, armazenamento e veiculao das informaes.
Enquanto a primeira perspectiva considera usurios como processadores
de informao ao lado do computador, na segunda eles so
considerados seres inteligentes e a funo do computador aumentar a
sua capacidade.
Nvel da interao usurio-computador
Neste nvel a nfase est nas atividades que os usurios devem fazer e na forma como as
informaes so percebidas ou produzidas pelos usurios. Neste nvel, as tarefas do

4
domnio devem determinar metas para cada usurio que devem poder ser realizadas
utilizando o sistema. Hardware e software so vistos atravs da interface de usurio que
pode ser compostas por elementos como, tela, teclado, mouse, menus, comandos, cones,
etc.
neste nvel que se avalia a usabilidade do sistema - facilidade de uso e
de aprendizado, produtividade, satisfao, etc.
Tambm podemos distinguir duas perspectivas. Na antropomrfica
busca-se construir um sistema que tenha caractersticas cognitivas
humanas. Neste caso o sistema deveria interagir na mesma lngua do
usurio e ter um comportamento inteligente. A outra perspectiva a de
ferramenta intelectual que considera que o sistema deve expandir a
capacidade cognitiva do usurio, apoiando-o em suas atividades.
O nvel da computao
Este o nvel da tecnologia. A nfase est no hardware e software do sistema. preciso
definir como os procedimentos podem ser automatizados e como as informaes podem ser
codificadas. Neste nvel podemos identificar os elementos de hardware - CPU, memrias,
perifricos - e de software - sistema operacional, sistemas de janelas e aplicao (ou
aplicativo) de software. Este ltimo compreende o software que implementa uma
funcionalidade que pode ser aplicada num certo domnio.
Neste nvel importante avaliar a qualidade dos diversos elementos do
computador: confiabilidade, segurana, eficincia, etc.
Diferentes perspectivas podem ser identificadas. A perspectiva
orientada-a-funes enfatiza nas funes que o sistema deve realizar. A
perspectiva orientada-a-dados centraliza todo o sistema na codificao,
estruturao, armazenamento e processamento dos dados. Por ltimo, a
perspectiva orientada-a-objetos considera que o sistema deve ser
composto por objetos que encapsulam dados e funes.

1.2 O Software
Existem problemas que podem ser resolvidos por um algoritmo. Algoritmo uma
seqncia de operaes bem-definidas de uma mquina (abstrata ou real) que a partir de
dados de entrada pra e pode fornecer resultados (sada).
Um programa um conjunto de solues algortmicas que operam
sobre estruturas de dados codificadas numa linguagem de programao.
Um programa pode est num estado esttico e dinmico - programa
executando num computador.
Um programa esttico pode estar em diferentes formas. O programa
fonte aquele escrito por um programador na linguagem de
programao antes de ser traduzido para o cdigo de mquina que a
linguagem vai executar. O programa executvel o conjunto de
instrues em um cdigo que pode ser executado diretamente pelo
processador. Temos ainda o programa em cdigo objeto que aquele
compilado a partir do programa fonte e antes de ser associado a
bibliotecas estticas.

5
O software normalmente visto como um programa que pode ser
executado num computador. Entretanto esta viso limitada.
Precisamos ressaltar a importncia de que o software mais do que um
programa. Embora em sua essncia software e programa sejam a
mesma coisa, podemos adquirir uma nova viso para o seu
desenvolvimento se considerarmos as diferenas que podem ser
identificadas.
O software deve ser visto como um artefato virtual e como tal ele
um produto a ser aplicado com utilidade num certo domnio, sendo
chamado de aplicao de software. Neste sentido, o software como
produto algo que possui um modelo conceitual prprio - a sua
funcionalidade e a sua interatividade. A funcionalidade determina
aquilo que ele faz e que o torna til para resolver problemas dos
usurios. A interatividade determina a maneira como o usurio dever
utilizar o software. O software , portanto, um produto conceitual ou
lgico.
Precisamos tambm chamar a ateno para uma diferena de
perspectiva. Num programa a perspectiva est em como um certa
soluo resolvida por algoritmos. A perspectiva de aplicao de
software, o software como produto, est em como ele pode resolver os
problemas do usurio.
Um outro importante aspecto que diferencia programa de software a
complexidade. Um software pode ser composto por diversos programas
que interagem entre si, bem como podem acessar arquivos de dados e
utilizar bibliotecas dinmicas. Por fim, a atividade de construir
programas requer tcnicas e ferramentas distintas daquelas que so
necessrias para construir um software.

Exemplo de um software como artefato virtual

Para exemplificar esta perspectiva de software como artefato, vejamos o exemplo de um
programa trivial que, com pequenas alteraes no programa, mas sem alterar a essncia do
algoritmo, pode ser visto como aplicaes de software de distintas.
Vejamos o seguinte trecho de interao entre o usurio (U) e o sistema
(S).
S: Fornea um nmero:
U: 5.3
S: Voc deve digitar apenas nmeros inteiros:
U: 5
S: Fornea outro nmero:
U: 8
S: O resultado -3

Observando a interao do usurio com o sistema podemos concluir que

o software realizou uma subtrao. Assim, a funcionalidade deste
software realizar subtraes de dois nmeros inteiros. Vejamos, agora
o algoritmo que est por trs deste software.
escreva("Fornea um Nmero:");

6
leia A;
enquanto A no for inteiro faa
escreva(Voc deve digitar apenas nmeros inteiros:)
leia A;
escreva("Fornea outro Nmero:");
leia B;
C = A - B;
escreva("O resultado ", C);

Vejamos agora o que acontece se modificarmos as linhas 1, 6 e 9 deste algoritmo para

escreva("Fornea o valor de venda");
escreva("Fornea o valor de compra");
escreva("O lucro ",C);

Para o programador muito pouca coisa mudou, mas para o usurio deste
sistema este software agora visto como uma aplicao de clculo de
lucros de vendas. As alteraes no programa foram bastante pequenas,
mas produziu um efeito significativo. A perspectiva de software como
artefato deve considerar como o usurio v a aplicao. Os modelos
conceituais da funcionalidade do software so distintos. Desta forma,
temos software distintos com aplicaes em domnios distintos. O
programa nos fornece uma viso de funcionamento. O usurio possui
apenas a viso de funcionalidade.
Podemos modificar as mesmas linhas do programa para:
escreva("Salrio Bruto");
escreva("Descontos");
escreva("Salrio lquido,C);

que produz um novo software.

Como este exemplo podemos entender melhor que embora o software
seja um programa, ele precisa ser considerado como um artefato.
Nestes exemplos, temos artefatos virtuais diferentes para programas
com um mesmo algoritmo.

Componentes do Software
O software pode ser visto no estado dinmico e esttico. No estado esttico podemos ver o
software formado por componentes lgicos como variveis de dados, funes,
procedimentos, mdulos, classes, etc., que podem variar dependendo da linguagem que foi
utilizada na sua implementao. Estes componentes podem estar na forma de programa
fonte, objeto, executvel ou em bibliotecas estticas a serem ligadas ao cdigo objeto.
No estado dinmico os componentes que formam um software podem
ser objetos, agentes, processos, arquivos de dados e outros, que so
gerenciados por sistemas operacionais ou sistemas de middleware.
Estes componentes podem est agrupados em arquivos executveis,
bibliotecas de ligao dinmica ou outros. Estes componentes podem
interagir por chamada de funo, troca de mensagens, acesso
compartilhado.

7
A viso de software formado por componentes interconectados entre si
caracteriza a arquitetura do software.

Evoluo do software
Para que um software possua uma ampla utilidade ele necessita de centenas ou milhares de
algoritmos. Atualmente os softwares so bastante complexos e podem ser formados por
diversos programas.
O software evoluiu bastante na segunda metade do sculo 20 quando
surgiram os primeiros computadores. Nos primeiros anos, de 1950 a
meados dos anos 60, os softwares eram executados em computadores
de baixa capacidade (embora ocupassem salas enormes), com o
processamento de dados em lote (sem interao com o usurio no
decorrer da interao), e feitos para clientes especficos com distribuio
limitada.
Na segunda era, de meados dos 60's a meados dos 70's surgiram
sistemas de grande porte multi-usurios e aplicaes de banco de
dados. Comeou-se a comercializar software genricos que atendiam as
necessidades de diversos clientes. Surgiram tambm os sistemas de
tempo-real. No Brasil, software com estas caractersticas, foram
utilizados at meados dos anos 80. Linguagens de programao de altonvel facilitou em parte a construo de software nesta segunda era.
A terceira era comeou em meados dos anos 70 com o surgimento de
hardware de baixo custo baseados em microprocessadores e estendeuse at incio dos anos 90. Com o hardware mais barato, mini e
microcomputadores foram adquiridos por diversas empresas e,
conseqentemente, houve uma grande demanda por software. A falta
de mo-de-obra especializada, de tcnicas e ferramentas de
desenvolvimento de software, e de planejamento e gerenciamento do
processo para atender a este impacto de consumo levaram crise do
software. Este crise do software levou ao surgimento de tcnicas de
programao como modularizao e refinamentos sucessivos e
metodologias para desenvolvimento de software como a Anlise e
Projeto Estruturados e o Mtodo de Jackson que buscavam resolver os
problemas de desenvolvimento de software.
A quarta era, a partir de meados dos anos 80, caracteriza-se pelo
surgimento de estaes de trabalho "desktop" bastante poderosas
interligadas em redes e de baixo custo - os sistemas distribudos.
Grandes empresas optaram por trocar computadores de grande porte
por sistemas distribudos num fenmeno denominado de downsize. A
tecnologia de orientao-a-objetos e a de interfaces grficas baseadas
em janelas caracterizam a produo de software nesta era. A
popularizao dos microcomputadores de baixo custo levou ao
surgimento de inmeros softwares aplicativos "de prateleira" comprados
por pequenas e micro-empresas e tambm por usurios comuns.

8
O surgimento da World Wide Web, no incio da dcada de 90,
popularizou bastante a utilizao da Internet e vem causando uma
revoluo na forma como as aplicaes so desenvolvidas, utilizadas e
comercializadas. O surgimento de linguagens voltadas para estes
ambientes, como Java, e de plataformas de interoperabilidade para
sistemas de software distribudos, como CORBA, vem indicando que
estamos entrando numa nova era.

Tamanho do software
Muitas pessoas no tm noo da complexidade de um software, do seu tamanho e da
quantidade de pessoas envolvidas no seu desenvolvimento. A tabela abaixo classifica
diferentes tamanhos de software.
Durao
do Tamanho em linhas
desenvolvimento
de cdigo
trivial
1
1-4 semanas
500 linhas
pequeno
1
1-6 meses
1000 a 2000 linhas
mdio
2-5
1-2 anos
5K a 50K
grande
5-20
2-3 anos
50K a 100 K
muito grande
100-1000
4-5 anos
1M
extremamente grande 2000-5000
5-10 anos
1M a 10M
O Windows 95 da Microsoft foi desenvolvido por uma equipe de 200 pessoas e possui 11
milhes de linhas de cdigo fonte.
Categoria

Tamanho da equipe

Qualidades do software
O software como um produto deve ter qualidade. Diversas so as qualidades do software a
serem avaliadas. preciso avaliar tanto a qualidade do produto em si com a do processo de
desenvolvimento. Vejamos algumas das qualidades que podem ser avaliadas.
Corretude - um software precisa funcionar corretamente. Um software correto
aquele que satisfaz a sua especificao e que no possui falhas ou erros.
Validade - um software vlido aquele cuja especificao satisfaz aos requisitos
dos usurios e da organizao, isto , est de acordo com as necessidades dos
usurios.
Robustez - o software deve prever que o usurio de agir de forma no esperada e
deve ser capaz de resistir a estas eventuais situaes incomuns sem apresentar
falhas.
Confiabilidade - um software correto e robusto ganha a confiana dos usurios
uma vez que ele deve se comportar como esperado e no falha em situaes
inesperadas.
Eficincia - o software deve realizar suas tarefas em um tempo adequando
complexidade de cada uma delas. A utilizao dos recursos de hardware (memria,
disco, trfego de rede) tambm deve ser feita de forma eficiente.

Usabilidade - o software precisa ser fcil de aprender e de usar, permitir maior

produtividade do usurio, flexibilidade de utilizao, flexibilidade de aplicao e
proporcionar satisfao de uso.
Manutenibilidade - todo software precisa de manuteno, seja para corrigir erros
ou atender a novos requisitos. O software deve ser fcil de manter para que estas
correes ou atualizaes sejam feitas com sucesso.
Evolutibilidade - todo software precisa evoluir para atender novos requisitos, para
incorporar novas tecnologias ou para expanso de sua funcionalidade.
Portabilidade - o software deve poder ser executado no maior nmero possvel de
equipamentos de hardware.
Interoperabilidade - software em diferentes plataformas devem poder interagir
entre si. Esta qualidade essencial em sistemas distribudos uma vez que o software
pode estar sendo executado em diferentes computadores e sistemas operacionais.
interessante que diferentes elementos de software distintos possam ser utilizados em
ambos. Por exemplo, um certo arquivo com uma imagem feita num aplicativo deve
poder ser vista em outros aplicativos.
Reusabilidade - diversos componentes de um software devem poder ser
reutilizados por outras aplicaes. O reuso de funes e objetos facilita bastante o
desenvolvimento de software.

Existem diversas outras qualidades do software que podem avaliadas. Nosso objetivo foi
apenas introduzir algumas delas, mesmo que de maneira superficial. Para um estudo inicial
veja alguns livros na nossa bibliografia.

1.3 Engenharia de Software

Vimos nas sees anteriores que, embora o software seja um programa em sua essncia, ele
precisa ser visto como um artefato virtual que tem associado a si um modelo conceitual.
Vamos discutir agora as diferenas entre construir um programa, isto , programar, e o que
vem a ser engenharia de software.

Programar engenharia?
O desenvolvimento de um software requer pelo menos a construo de um programa.
Programar envolve as atividades de codificar um algoritmo numa determinada linguagem
de programao. O resultado disto o programa ou cdigo fonte. Este programa precisa ser
traduzido por um interpretador ou compilador em linguagem de mquina (cdigo
executvel) para que possa ser executado pelo processador. Um programa pode reutilizar
ou no funes de bibliotecas disponveis pelo tradutor. No processo de compilao, o
cdigo fonte traduzido em um cdigo objeto para em seguida ser "ligado" a eventuais
funes de bibliotecas (processo de linking) quando ento gerado o programa executvel
em linguagem de mquina. Alguns sistemas operacionais permitem que funes (ou
classes, no caso de programas orientados a objetos) possam ser ligadas durante a execuo
do programa. Estas funes so armazenadas em bibliotecas de ligao dinmica (DLL).
Entretanto, a viso do software como artefato requer algo mais que
programao. preciso pensar no software considerando os requisitos

10
dos usurios e a viso que ele ter deste produto. A interface com o
usurio um componente essencial do software junto com o modelo
conceitual que determina a sua funcionalidade e a interatividade. (Para
maiores detalhes sobre estes conceitos veja Conceitos Bsicos. Eles
tambm sero discutidos posteriormente no captulo 4).
Com esta perspectiva temos que considerar que o desenvolvimento de
software algo mais do que programar. pensar na aplicao do
programa na resoluo dos problemas dos usurio. incorporar no
programa elementos do domnio onde ele est inserido, representandoos como informaes e oferecendo funes para que os usurios possam
utiliz-las.
Alm destas consideraes, para que este desenvolvimento possa ser
considerado uma engenharia outros fatores precisam ser considerados.

O que engenharia?
O desenvolvimento de um artefato pode ser conduzido de forma artesanal, por um
processo de tentativa-e-erro, manipulando-se diretamente o material com o qual o produto
ser construdo.
Os erros so identificados atravs da avaliao experimental da
qualidade do produto. A avaliao deve verificar se o produto est
funcionando adequadamente, se ele til aos seus usurios, e vrias
outras qualidades.
Este processo artesanal pode evoluir atravs da utilizao de
ferramentas especficas e de tcnicas desenvolvidas a partir de
experincias anteriores.
Este processo pode ainda evoluir e incorporar outras atividades. O
design (desenho ou projeto) consiste na atividade de conceber e
descrever o produto a ser construdo. O design permite uma visualizao
antecipada do produto final permitindo que se possa fazer alguma
avaliao antes da sua construo.
Para que o produto tenha sucesso ele deve estar adequado s
necessidades do usurio. Atividades de anlise de requisitos devem
anteceder o design e a construo do artefato para que estes objetivos
sejam atingidos.
Com tantas atividades preciso um modelo do processo que descreva
em qual momento cada uma ser realizada. Anlise, especificao,
design, implementao e avaliao devem ser realizadas no momento
adequado. Para cada etapa do processo mtodos devem descrever com
detalhes como estas atividades devem ser realizadas.
Cada uma destas atividades requer pessoal com conhecimento
especializado. Diversos princpios e modelos tericos so
conhecimentos indispensveis para o desempenho das atividades do
desenvolvimento.

11
Os especialistas nas diversas atividades devem atuar em equipe.
Existem diversas maneiras de estruturar e gerenciar uma equipe de
desenvolvimento.
A alocao de tarefas especficas que foram determinadas pelos
mtodos do modelo de desenvolvimento para os membros da equipe em
um determinado perodo de tempo faz parte do processo de
planejamento. O planejamento requer ainda que sejam estimados os
custos e prazos de cada uma destas atividades. Tudo o que foi
estimado e planejado deve ser gerenciado para que possa ser
cumprido.
Quando o desenvolvimento de um artefato incorpora as atividades de
anlise, design, implementao e avaliao de acordo com princpios,
modelos, tcnicas, ferramentas e mtodos especficos, realizados por
uma equipe de especialistas e obedecendo a um planejamento e
gerenciamento de custos e prazos, podemos caracteriz-lo como uma
engenharia.
Veremos, a seguir, as caractersticas destas atividades no
desenvolvimento de software.

Objetivos da Engenharia de Software

A engenharia de software tem por objetivos a aplicao de teoria, modelos,

formalismos e tcnicas e ferramentas da cincia da computao e reas afins para o
desenvolvimento sistemtico de software.
Associado ao desenvolvimento, preciso tambm aplicar mtodos, tcnicas e
ferramentas para o gerenciamento do processo de desenvolvimento.
Finalmente, a engenharia de software visa a produo da documentao formal do
software, do processo de desenvolvimento e do gerenciamento destinada a
comunicao entre os membros da equipe de desenvolvimento bem como aos
usurios finais.

Definies de Engenharia de Software

Os autores apresentam diversas definies para engenharia de software. Vamos apresentar
trs que consideramos complementares.
A engenharia de software a disciplina envolvida com a produo e manuteno
sistemtica de software que so desenvolvidos com custos e prazos estimados.
Disciplina que aborda a construo de software complexo - com muitas partes
interconectadas e diferentes verses - por uma equipe de analistas, projetistas,
programadores, gerentes, "testadores", etc.
O estabelecimento e uso de princpios de engenharia para a produo
economicamente vivel de software de qualidade que funcione em mquinas reais.
A primeira destas definies enfatiza que a engenharia visa no apenas o desenvolvimento,
mas tambm a manuteno do produto. Alm disso, ela ressalta a importncia da estimativa
de custos e prazos de desenvolvimento. A segunda definio enfatiza a complexidade do

12
produto e do processo. O software formado por diversos componentes interconectados e o
seu desenvolvimento realizado por uma equipe que precisa ser gerenciada. A terceira
ressalta que o desenvolvimento de software deve seguir os princpios de uma engenharia e
deve visar a qualidade.

Mitos do Software
Segundo [Pressman], diversos mitos difundidos entre programadores escondem a
importncia de um desenvolvimento de software de acordo com os princpios de uma
engenharia. Vejamos algumas delas:
O estabelecimento de objetivos gerais suficiente para se comear a escrever
programas.
Uma vez que o programa esteja escrito e funcionando, nosso trabalho est feito.
Mudanas no software podem ser feitas facilmente porque ele "flexvel".
D a uma pessoa tcnica um bom livro de programao e voc ter um
programador.
At que o programa esteja "rodando" no possvel verificarmos a sua qualidade.
Um projeto bem sucedido se conseguirmos um programa funcionando
corretamente.

13

2.
O
Processo
de
Desenvolvimento de Software
Objetivos:
Este captulo aborda as diversas maneiras de como um software deve ser desenvolvido.
Veremos o conceito de ciclo de vida, identificando suas principais fases e as atividades do
ciclo de vida do software. Finalizaremos com o estudo de diversas propostas e modelos
para o processo de desenvolvimento de software.

2.1 Processo de desenvolvimento

Vimos na introduo que uma engenharia de software requer que as atividades para
desenvolver o software sejam feitas de forma planejada, gerenciada, com pessoal
capacitado, custos e prazos estimados e utilizando teorias, mtodos, tcnicas e ferramentas
adequadas.
Elaborar um processo de desenvolvimento de software significa
determinar de forma precisa e detalhada quem faz o que, quando e
como. Um processo pode ser visto como uma instncia de um mtodo
com suas tcnicas e ferramentas associadas, elaborado durante a etapa
de planejamento, no qual as atividades que o compem foram alocadas
aos membros da equipe de desenvolvimento, com prazos definidos e
mtricas para se avaliar como elas esto sendo realizadas (veja
conceitos bsicos).
Enquanto um mtodo algo terico, o processo deve determinar aes
prticas a serem realizadas pela equipe como prazos definidos. O
processo o resultado do planejamento e precisa ser gerenciado no
decorrer de sua execuo.
No objetivo deste captulo a elaborao de processos de
desenvolvimento. Apenas podemos faz-lo aps estudar tcnicas de
planejamento e gerenciamento. Neste captulo vamos nos limitar a
estudar alguns modelos de processo que nos indique como as diversas
etapas e atividades do desenvolvimento podem ser estruturadas.

2.2 O ciclo de vida do software

O ciclo de vida de um artefato diz respeito s diversas fases pelas quais ele passa desde o
seu surgimento at a o momento no qual ele no ser mais til. No sistema computacional
todos os componentes possuem um ciclo de vida prprio. Embora eles sejam relacionados
entre si, eles possuem ciclos de vida independentes. O hardware pode continuar existindo
mesmo que o software seja destrudo. O software, em sua forma esttica, pode tambm

14
continuar existindo mesmo que um computador especfico torne-se inoperante. Quando o
software construdo para um hardware especfico que o ciclo de vida de ambos pode ser
mesmo. Neste curso, vamos nos limitar a estudar e discutir o ciclo de vida do software.
No ciclo de vida do software identificamos trs fases:
Definio
Desenvolvimento
Operao
Na fase de definio os requisitos do software so determinados, a sua viabilidade
estudada e o planejamento das atividades elaborado.
Na fase de desenvolvimento so realizadas as atividades destinadas a
produo do software. Ela envolve atividades de concepo,
especificao, design da interface, prototipao (do ingls prototyping,
traduzido tambm por prototipagem), design da arquitetura, codificao
e verificao, dentre outras.
Na fase de operao o sistema dever efetivamente ser utilizado pelos
seus usurios produzindo os resultados desejados. Nesta fase devem
ocorrer as atividades de manuteno, seja para que se faam correes,
ou seja para a sua evoluo, isto , para que o software satisfaa novos
requisitos.
Nas prximas sees, vamos descrever algumas das principais
atividades do ciclo de vida do software. O nosso objetivo
essencialmente didtico. Vamos apresent-las para que possamos
compreender os diferentes modelos do processo que sero apresentados
na prxima seo. Algumas destas atividades podem ou no aparecer
em um determinado modelo, bem como pode existir alguma atividade
especifica de um certo modelo que no ser mencionada aqui.
Optamos por a apresentar as atividades do desenvolvimento
classificando-as por fase do ciclo de vida. Entretanto, dependendo do
modelo de processo algumas atividades tambm podem estender-se por
mais de uma fase do ciclo de vida.

2.2.1 As atividades da fase de definio

Como normalmente o software est inserido num contexto mais amplo - o sistema - a fase
de definio do software est inserida na definio do sistema. Definir o sistema definir
todos os seus componentes (ver captulo 1).
Na fase de definio so tomadas as decises de construir ou no o
software. Nela so definidos os requisitos do software, determinandose o que o cliente quer, o que a organizao necessita, quais os
problemas nas atividades dos usurios, etc. O cliente pode, por exemplo,
necessitar de um software que faa o controle de vendas e compras da
sua empresa. Um cliente de uma empresa de publicidade pode
necessitar de um software de editorao eletrnica para a Web.
Tambm devem ser definidas algumas restries ao software. Um
exemplo de restrio tcnica : "o software deve ser executado no

15
ambiente Unix/XWindow, uma vez que esta a plataforma instalada na
empresa". Outro caso seria: "o software deve ser executado num
sistema remotamente distribudo uma vez que a empresa possui
diversos pontos de venda". Existem restries econmicas: "o
oramento de desenvolvimento no pode ultrapassar R$ 10.000,00".
A definio dos requisitos denominada de anlise e especificao
de requisitos indicando que existe uma atividade de observao e uma
descrio rigorosa dos problemas e da proposta de solues. Alguns
autores argumentam que devido sua complexidade esta atividade
deve ser considerada uma engenharia de requisitos. O objetivo
deles tambm ressaltar que os requisitos devem ser gerenciados
durante todo o ciclo de vida do software.
O termo especificao est associado a diversas atividades do ciclo de
vida: especificao de requisitos, especificao do software,
especificao da arquitetura, especificao de dados e algoritmos, etc. e
se refere a descrio, atravs de alguma notao, de algo que foi
concebido ou idealizado. A especificao de requisitos tem por objetivo
descrever aquilo que clientes ou futuros usurios necessitam e que ser
resolvido pela construo de um software. Como esta especificao
precisa ser validada por clientes e usurios, normalmente ela feita
atravs de uma notao informal, como a linguagem natural, ou usando
uma linguagem grfica semi-formal como UML, DFD, DER, etc. Uma
tcnica bastante utilizada para especificao informal de requisitos so
os cenrios (ver captulo 3).
O resultado desta atividade a descrio dos requisitos funcionais que dizem respeito quilo que se quer que o software faa - e os nofuncionais - que dizem respeito a requisitos de ordem tcnica,
econmica, da organizao, etc.
Nesta fase tambm deve haver um estudo de viabilidade do software.
Este estudo visa verificar se o software vivel tcnica e
economicamente, e se os benefcios trazidos sero compensadores. O
estudo de viabilidade requer que tenham sido definidos alguns requisitos
para que se possa ter idia do que ser o sistema. Conforme veremos
mais adiante, alguns modelos de processo podem determinar que o
estudo de viabilidade seja feito apenas aps a anlise completa dos
requisitos. Em outros, ele pode ser realizado simultaneamente ou num
processo iterativo.
Associada a esta atividade devem ser realizadas estimativas de
custos e prazos e a anlise de riscos. A primeira visa determinar
gastos e prazos aproximados a partir de dados de experincias
anteriores. A anlise de riscos visa verificar se existem possibilidades de
que algo possa sair errado, como por exemplo, o oramento estourar ou
se haver dificuldades tcnicas.
O resultado do estudo de viabilidade a deciso de que o software deve
ou no ser construdo com base nos requisitos, nas restries tcnicas,

16
nas estimativas de custos e anlise de riscos, dentre outros fatores, em
relao aos benefcios que o sistema dever proporcionar.
Tambm na fase de definio, caso o software seja vivel, deve ser feito
o planejamento de como o desenvolvimento ser conduzido, isto ,
deve-se elaborar um processo de desenvolvimento. O planejamento no
necessariamente precisa ser feito completamente nesta fase. Veremos
modelos do processo no qual o planejamento revisto diversas vezes ao
longo do desenvolvimento. O resultado do planejamento uma
descrio precisa do processo de desenvolvimento de software.
Existem diversas propostas sobre quem deve realizar as atividades na
fase de definio. Na maior parte dos casos a definio dos requisitos
iniciais conduzida por analistas de sistemas como parte da definio
do sistema. Isto significa que a fase de definio do software pode ser
considerada como parte da anlise de sistema que visa definir o sistema
computacional do qual o software parte. Para contribuir como
definies mais especficas sobre o software, como estimativas de
custos e prazos e o planejamento do desenvolvimento de software,
engenheiros de software e analistas de sistemas devem trabalhar
conjuntamente. Em diversas empresas analistas de sistemas realizam
mais do que a definio dos requisitos do sistemas. Eles tambm
definem e projetam o software.

2.2.2 Atividades da fase de desenvolvimento

Um modelo do processo de desenvolvimento ou mtodo compreende algumas atividades.
Cada proposta de modelo apresentado na literatura acadmica ou elaborado por empresas
de desenvolvimento devem determinar quais as atividades compem o mtodo. Embora
estas atividades variem de uma proposta para outra, algumas so comuns a vrios mtodos.
Alm disso, em alguns modelos de processo, algumas atividades da fase de definio
tambm podem estar inseridas nesta fase para que possam ser revisadas. Existem modelos
que propem ciclos cujas atividades da fase de desenvolvimento so alternadas com
atividades da definio.
Design
Design a atividade de concepo e especificao de um produto. A concepo a
atividade mental de criao do produto que satisfaa aos requisitos. Aquilo que foi
concebido deve ser concretizado na forma de uma especificao. Muitos autores utilizam o
termo especificao no sentido de design. Design pode ser traduzido como projeto ou como
desenho. Consideramos que ambas no so tradues ideais e vamos optar por usar a
palavra em ingls.
Diversos autores argumentam que se o software deve ser visto como um
produto a atividade de design de software imprescindvel [Winograd
96]. Assim, design de software atividade do desenvolvimento na
qual o software deve ser concebido e especificado do ponto de vista do
usurio e no do desenvolvedor. O foco est na viso externa do

17
software que a aquela que ser percebida pelos usurios. Fazendo
uma analogia com a engenharia civil, o design de software seria uma
atividade equivalente arquitetura de uma edificao.
O design deve determinar o que o software deve fazer - a sua
funcionalidade - e como o usurio ir interagir como ele - a sua
interatividade ou modelo de interao. Estes dois elementos compem
o modelo conceitual da aplicao. Desta forma o design de software
envolve a concepo e especificao da funcionalidade e do modelo de
interao.
O design toma como base a especificao de requisitos elaborada na
fase definio. importante ressaltar que, dependendo do processo de
desenvolvimento, a especificao dos requisitos pode estender-se pela
fase de desenvolvimento, como veremos mais adiante. Enquanto que a
especificao dos requisitos visa descrever o que clientes, usurios e
organizao necessitam, o design de software visa especificar o que ele
oferecer para satisfazer estas necessidades.
Existem decises importantes que so tomadas durante o design de
software que fogem ao escopo de uma especificao de requisitos. Por
exemplo, para o requisito funcional de "o software deve realizar o
clculo do total de vendas e do lucro obtido", o designer do software
deve decidir os dois clculos sero feitos simultaneamente por uma
nica funo ou se por duas funes independentes. Ele deve decidir se
o usurio fornece os dados todos inicialmente e apenas ao final os
clculos so feitos ou se os dados so fornecidos para cada clculo que
se deseja fazer.
Uma vez que o designer tenha especificado a funcionalidade e o modelo
de interao ele pode apresentar aos clientes e usurios para as suas
opinies ou rever os requisitos. Quando os requisitos so refinados a
partir da especificao do software as atividades de especificao de
requisitos e de software se confundem. Nestas condies nas quais o
design realizado com a participao dos clientes e usurios ele
chamado de design participativo.
A engenharia de software tradicionalmente enfatiza apenas na
especificao da funcionalidade. A proposta de design centrado no
usurio visa chamar a ateno para o modelo de interao e para a
interface de usurio como elementos importantes na qualidade de um
software.
O design da interface de usurio visa a concepo e especificao
da parte do software que possibilita que o usurio interaja com o
sistema de acordo com o modelo de interao especificado. Enquanto o
modelo de interao determina os protocolos de comunicao entre o
usurio e o sistema, a interface deve apresentar os menus, janelas,
cones, botes que permitem as aes do usurio de acordo com o
modelo. O design da interface a concretizao de um modelo de
interao especificado durante o design do software.

18
A maioria dos autores de engenharia de software utilizam o termo de
design do software para se referir especificao da arquitetura de
software, isto , da configurao de componentes do software - funes,
classes, objetos e suas interconexes. Neste caso, estamos realizando
design do ponto de vista do desenvolvedor e chamaremos de design da
arquitetura do software. O design da arquitetura visa determinar de
maneira abstrata como a funcionalidade ser implementada.
O design da arquitetura deve resultar na especificao da abstrata da
macro-estrutura dos componentes do software e de como eles
interagem entre si, sem preocupao com detalhes a respeito dos
algoritmos que descrevero o funcionamento de cada componente. No
design arquitetural importante que se especifique o que cada
componente deve fazer - especificao funcional de componentes.
O design de algoritmos e dados , tambm chamado de design
detalhado, tem por objetivo a concepo e especificao das estruturas
de dados e dos algoritmos que realizam aquilo que foi especificado para
cada componente do software. A especificao funcional dos
componentes deve se feita a nvel do que chamamos de problemas
algortmicos, isto que podem ser resolvidos pela construo de um
algoritmo. As solues algortmicas so normalmente encontradas na
literatura especializada em design de algoritmos e de estruturas de
dados.
Em alguns casos, pode-se encontrar componentes de software j
desenvolvidos em cdigo fonte ou executvel - em bibliotecas, por
exemplo - e incorpor-los durante a programao.
O resultado de todas as atividades de design so especificaes da
funcionalidade, do modelo de interao, da interface de usurio, da
arquitetura de software e dos algoritmos e estruturas de dados.
Prototipao
Uma outra forma de concretizar a concepo de um software a atravs de um prottipo.
Um prottipo um produto construdo utilizando materiais mais baratos e com dimenses
reduzidas. A prototipao (ou prototipagem) atividade de construir prottipos. Existem
modelos de processo de desenvolvimento que so baseados em prototipao como veremos
a seguir.
Um prottipo do software construdo utilizando ferramentas que
permitem que apenas partes do software sejam construdas com o
objetivo de verificar suas qualidades antes que o produto final venha a
ser construdos.
A prototipao, uma tcnica usada freqentemente nas engenharias,
tem sido adotada na engenharia de software para aperfeioar as
previses e diminuir os riscos envolvidos no desenvolvimento de um
novo projeto. Os termos prottipos e prototipao tm sido usados na
literatura com diversos significados e no se definiu uma classificao
ou critrios para tal, de maneira convincente.

19
Programao
A programao consiste na atividade de construo de um programa que implementa uma
determinada soluo para um problema algortmico. Esta soluo pode ser descrita na
forma de especificao de algoritmos e estruturas de dados e deve ento ser codificada uma
linguagem de programao. Especialistas em programao podem escrever a soluo
algortmica diretamente na linguagem de programao.
Esta atividade tambm chamada de implementao, construo ou
codificao do software. A codificao enfatiza a que o software deve ser
construdo utilizando uma linguagem de programao. Alm da
codificao propriamente, a programao deve envolver ainda a sua
traduo num cdigo de mquina executvel.
A programao deve resultar num programa que implemente tudo o que
foi especificado durante o design. No caso de software formado por
vrios componentes, estes devem ser implementados a partir da
especificao de cada componente e integrados (interconectados)
conforme a arquitetura interna do software.

Avaliao ou Verificao
A avaliao ou verificao visa assegurar algumas das principais qualidades do software.
Dentre as atividades de avaliao vamos destacar a correo, validao e usabilidade do
software.
O software considerado correto quando o programa implementado
satisfaz sua especificao. Existem diversas formas de verificarmos se
um software est correto. Elas so o teste de programa, a inspeo e
a prova de programas.
O teste de programa permite identificarmos se um programa tem
erros a partir da execuo do programa de acordo com tcnicas
especficas.
A inspeo pode ser feita pela anlise do cdigo fonte e a sua execuo
mental com o auxlio de lpis e papel (rastreamento). Outra forma de
inspeo utilizando o debbuger que permite acompanhar passo a
passo a execuo de cada instruo do programa e verificar o estado
das variveis de dados.
A prova de programa utiliza tcnicas de lgica matemtica que
permite provar se um programa est correto em relao especificao
formal deste programa. Em um software complexo, se a sua arquitetura
for especificada formalmente pode-se provar que cada componente
individualmente est correto e que a sua integrao tambm est
correta.
A avaliao da validao do software visa determinar se a
especificao do software (funcionalidade, arquitetura, interface, etc)
satisfaz aos requisitos do usurio. Ela deve ser realizada durante toda a

20
fase de desenvolvimento na medida que as especificaes forem
elaboradas.
A avaliao da usabilidade visa identificar as qualidades relacionadas
com a interao entre o usurio e o software. Dentre estas qualidades
esto a facilidade de aprendizado, facilidade de uso, produtividade, etc.
A usabilidade verificada de forma emprica atravs de testes de
usabilidade que analisam o comportamento do usurio durante a
interao.
Outras propriedades do software tambm precisam ser verificadas tais
como desempenho e robustez e devem ser estudadas na literatura
especializada.

2.2.3 As atividades da fase de operao

Durante a fase de operao do ciclo de vida o software deve ser instalado, utilizado e feita a
sua manuteno.
A instalao e configurao a atividade visa implantar o software no
computador para que ele possa ser utilizado pelos usurios. A instalao
requer que o software seja armazenado no lugar correto e que os drivers
de dispositivos de hardware sejam configurados adequadamente para
que o software funcione corretamente. Esta atividade pode ser realizada
tanto por usurios como pelos engenheiros ou programadores do
software.
A utilizao a atividade fim do software, uma vez que ele foi
construdo para auxiliar pessoas na realizao de suas tarefas. A
utilizao deve seguir o modelo de interao especificado durante o seu
design que deve est descrito no manual de usurio.
A manuteno a atividade destinada a assegurar a qualidade do
software durante a fase de operao. A manuteno se faz necessria
para que o software possa ser transportado para outras plataformas de
hardware e de sistemas operacionais, para satisfazer a novos requisitos
dos usurios ou para corrigir eventuais erros. Ela pode envolver a
correo de erros no detectados durante os testes, o re-design da
funcionalidade, da interface de usurio, da arquitetura do software ou
dos algoritmos de forma que novos requisitos sejam satisfeitos, e vrias
outras atividades.

2.3
Modelos
do
desenvolvimento

processo

de

Um modelo para um processo de desenvolvimento uma proposta terica que junto com o
planejamento deve determinar quais atividades devem ser realizadas, quando, como e por
quem. Nesta seo vamos apresentar alguns dos mais conhecidos modelos do processo de

21
desenvolvimento. Eles so o modelo Cascata, o modelo Evolutivo ou Incremental, o
modelo Espiral e o modelo Transformao.
A escolha de um destes modelos envolve diversos fatores. Um deles o
tipo de software - se um software de banco de dados, um software de
tempo-real, um software embutido, um sistema especialista. Outro fator
importante se a equipe de desenvolvimento uma empresa de
desenvolvimento (software house) ou se a equipe de engenheiros da
prpria organizao que utilizar o produto. A maneira como o produto
ser vendido e instalado um outro fator importante - se o software
para ser vendido para um pblico amplo ou se ser instalado em uma
nica empresa, sob encomenda.
Para cada uma das atividades mtodos especficos devem ser
elaborados. Um conjunto de mtodos relacionados entre si num
esquema comum de acordo com um modelo chamado de
metodologia de desenvolvimento.

O Modelo Cascata
O modelo cascata tornou-se conhecido na dcada de 70 e referenciado na maioria dos
livros de engenharia de software ou manuais de padres de software. Nele as atividades do
processo de desenvolvimento so estruturadas numa cascata onde a sada de uma a
entrada para a prxima. As suas principais atividades so:
estudo de viabilidade
anlise e especificao de requisitos
design e especificao
codificao e testes de componentes
teste do sistema e integrao
entrega e instalao
manuteno
Existem muitas variantes deste modelo propostas por diferentes
pesquisadores ou empresas de desenvolvimento e adaptadas a
diferentes tipos de software. A caracterstica comum um fluxo linear e
seqencial de atividades semelhantes a descritas anteriormente. A
figura a seguir, mostra uma variante do modelo em cascata.

22

Este modelo, quando proposto, introduziu importantes qualidades ao

desenvolvimento. A primeira chama a ateno de que o processo de
desenvolvimento deve ser conduzido de forma disciplinada, com
atividades claramente definidas, determinada a partir de um
planejamento e sujeitas a gerenciamento durante a realizao. Outra
qualidade define de maneira clara quais so estas atividades e quais os
requisitos para desempenh-las. Por fim, o modelo introduz a separao
das atividades da definio e design da atividade de programao que
era o centro das atenes no desenvolvimento de software.
O modelo Cascata tambm criticado por ser linear, rgido e monoltico.
Inspirados em modelos de outras atividades de engenharia, este modelo
argumenta que cada atividade apenas deve ser iniciada quando a outra
estiver terminada e verificada. Ele considerado monoltico por no
introduzir a participao de clientes e usurio durante as atividades do
desenvolvimento, mas apenas o software ter sido implementado e
entregue. No existe como o cliente verificar antecipadamente qual o
produto final para detectar eventuais problemas.
Caractersticas particulares do software (ser conceitual, por exemplo) e a
falta de modelos tericos, tcnicas e ferramentas adequadas mostram
que necessrio haver maior flexibilidade neste fluxo seqencial,
permitindo volta atrs para eventuais modificaes. Veremos mais
adiante modelos que propem maior flexibilidade no fluxo de execuo.
As mtricas utilizadas nas estimativas de prazos e recursos humanos
so ainda bastante imprecisas e quase sempre o planejamento de
atividades precisa ser revisto. Normalmente os prazos no so
cumpridos pois o planejamento, neste modelo, feito nas etapas iniciais
do desenvolvimento. A estrutura seqencial e rgida tambm no
permite que o planejamento seja refeito para corrigir falhas nas
atividades de desenvolvimento.

O Modelo Evolutivo
O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de
forma a evoluir a partir de prottipos iniciais. Para entender melhor este modelo

23
importante entender o que prototipao. A prototipao tambm aparece em outros
modelo de processo.
O processo de desenvolvimento pode evoluir de diversas maneiras. Uma
destas formas consiste em ir desenvolvendo partes funcionais de um
software, isto , que funcionam, mas no atendem a todos os requisitos
por completo, e ir incrementando com novos pedaos at que todos os
requisitos sejam atendidos. Para cada novo componente incorporado, as
qualidades do prottipo devem ser verificadas experimentalmente.
Outra forma de evoluo iniciar o desenvolvimento com um prottipo
rudimentar no funcional e torn-lo funcional ao longo do processo
atravs do refinamento de seus componentes.

O fluxo de atividades do modelo evolutivo caracteriza-se por ser cclico

ou iterativo. Ele comea com o design e desenvolvimento de um
prottipo inicial, que deve ser mostrado aos usurios e avaliado. Durante
a avaliao novos requisitos so definidos e alteraes e incrementos ao
prottipo inicial devem ser feitas. Este ciclo deve ser repetido em
direo ao produto final.
A grande vantagem deste modelo est em permitir a verificao
antecipada do produto final por engenheiros, clientes e usurios,
permitindo a correo dos problemas detectados.
A extrema flexibilidade deste modelo e a falta de rigor leva a software
que embora satisfaa aos requisitos dos usurios tm deficincias de
desempenho, portabilidade, manuteno e outras qualidades internas.
Embora a prototipao tenha enormes vantagens e deva ser
incentivada, basear o desenvolvimento no incremento de prottipos
pode levar a software mal documentados e com arquiteturas mal
definidas. Como os requisitos esto sempre sendo revistos a cada ciclo
de desenvolvimento, torna-se praticamente impossvel estimar custos e
prazos e planejar as atividades de desenvolvimento.
A prototipao mais adequada como mtodo auxiliar anlise de
requisitos e ao design do software, pois permite a validao antecipada
do produto. Entretanto, no se deve deixar de lado o design da

24
arquitetura de software e dos algoritmos para que ele possa ser
construdo utilizando uma linguagem de programao mais adequada.

Prototipao
Prototipao uma abordagem baseada numa viso evolutiva do desenvolvimento de
software, afetando o processo como um todo. Esta abordagem envolve a produo de
verses iniciais - "prottipos" - de um sistema futuro com o qual pode-se realizar
verificaes e experimentaes para se avaliar algumas de suas qualidades antes que o
sistema venha realmente a ser construdo.

Tipos de Prottipos
O relacionamento entre um prottipo e as atividades do processo de desenvolvimento incio do projeto e anlise de requisitos, design da interface e da aplicao, e
implementao - permite a identificao de quatro tipos de prottipos:
Prottipo de Apresentao - oferece suporte ao incio do projeto e usado para
convencer o cliente de que o futuro sistema vivel e que a interface do usurio se
adequa aos requisitos. Na maioria dos casos usado para mostrar viso que o
usurio tm do sistema e revelar aspectos importantes da interface.
Prottipo Autntico - um sistema de software provisrio e funcional, geralmente
projetado para ilustrar aspectos especficos da interface de usurios ou parte da
funcionalidade, ajudando na compreenso dos problemas envolvidos.
Prottipo Funcional -- derivado do modelo do domnio do problema ou da
especificao do software e serve para ajudar equipe de desenvolvimento
compreender questes relacionadas com a construo do sistema. Esse prottipo
no interessa aos usurios.
Sistema Piloto - usado no apenas com propsitos ilustrativos, mas como um
ncleo bsico operacional do sistema. Esse sistema deve ser instalado no ambiente
de aplicao e experimentado com os usurios.
Objetivos da Prototipao

25
Num projeto de software vrias questes podem ser respondida com a construco de
prottipos. Nas situaes tpicas de desenvolvimento podemos distinguir entre diferentes
objetivos na prototipao:
Exploratria - quando o prottipo usado para ajudar a esclarecer requisitos dos
usurios com respeito ao sistema futuro. Uma prototipao tambm exploratria
quando se busca examinar uma variedade de opes de design de maneira a evitar a
escolha de uma abordagem especfica no adequada. Com esses objetivos os
desenvolvedores adquirem informaes sobre o domnio, os usurio e tarefas. Os
usurios podem emitir informaes e sugestes mais precisas, tornando-se parceiro
das decises que envolvem o desenvolvimento.

Experimental - quando a prototipao foca aspectos tcnicos do

desenvolvimento, oferecendo aos desenvolvedores resultados experimentais para
tomada de decises de design e implementao. Um aspecto essencial a
viabilizao de uma base de comunicao entre os usurios e desenvolvedores para
solues de problemas tcnicos de viabilidade e usabilidade, dentre outros. As
principais vantagens para os desenvolvedores so a verificao e validao das
decises tomadas e solues apresentadas.

Evolutiva - A prototipao pode ser aplicada de maneira bastante proveitosa num

processo de reengenharia em organizaes, para avaliar o impacto que a introduo
de novas tecnologias pode trazer. Nesse caso o prottipo no visto apenas como
uma ferramenta em projetos individuais, mas como parte de um processo contnuo
de evoluo dos processos organizacionais. Os desenvolvedores no so mais os
protagonistas da prototipao, mas consultores que trabalham em cooperao com
os usurios no processo de reengenharia.

Tcnicas de prototipao
Do ponto de vista tcnico, a prototipao pode ser conduzida segundo duas abordagens,
relacionadas com tcnicas especficas de construo. Experincias em desenvolvimento de
software tm apontado inmeras qualidades no design e implementao em diversas
camadas. Essas camadas podem ir desde a interface de usurio camadas mais bsicas
como uma base de dados e o sistema operacional. Dessa forma, podemos identificar duas
formar de subdividir a prototipao.
Prototipao horizontal - Apenas uma camada especfica do sistema construda.
Por exemplo, a interface do usurio com suas janelas e widgets, ou camadas da
aplicao como as funes para transao em bancos de dados.
Prototipao vertical - Uma parte da funcionalidade do sistema escolhida para ser
implementada completamente. Esta tcnica apropriada quando aspectos da
funcionalidade ainda esto em aberto.
Um outro critrio para se classificar prottipo de acordo com o relacionamento entre o
prottipo e o sistema final. Em certos casos, o prottipo serve apenas para propsitos de
especificao do sistema final e no ser usado como parte integrante do sistema final. Ele
jogado fora. Um outro caso, quando o prottipo vai sendo incrementado e se torna parte

26
integrante (building block) do sistema. Por fim, o prottipo pode ser construdo apenas para
a compreenso de certos problemas que envolvem determinados interesses. No existe a
inteno de transform-lo num sistema.

O Modelo Transformao
Um programa uma descrio formal, isto , ele descrito por uma linguagem de
programao cuja sintaxe e semntica so definidos formalmente. Apenas desta forma
que temos a garantia de que o programa ser sempre executado da mesma forma pelo
computador.
O modelo Tranformao tem suas razes na abordagem de mtodos
formais para o desenvolvimento de software. A idia que o
desenvolvimento deve ser visto como uma seqncia de passos que
gradualmente transforma uma especificao formal num programa. O
passo inicial transformar os requisitos informais numa especificao
funcional formal. Esta descrio formal ento transformada numa
outra descrio formal mais detalhada, e assim, sucessivamente, at
chegar no ponto em que se tenha componentes de programas que
satisfaam a especificao. Durante este processo de transformaes
sucessivas - chamado de otimizao - as especifio formais produzidas
podem ser executadas por um processador abstrato, permitindo uma
verificao formal da sua validao antes mesmo que o programa venha
a ser implementado. Antes de serem transformadas cada especificao
formal deve ser verificada em relao s expectativas dos clientes e
usurios.
As transformaes devem ser realizadas pelo engenheiro de software. A
natureza formal da transformao possibilitam a aplicao de
verificaes matemticas como prova, consistncia e completude da
especificao. As transformaes podem ser realizadas de maneira
automtica por ferramentas que traduzem especificaes formais mais
abstratas em especificaes mais detalhadas.
Este modelo prev que o engenheiro de software deve ter a sua
disposio uma biblioteca de componentes reutilizveis que satisfaa
especificaes formais. Na otimizao, medida que as especificaes
de mais baixo nvel vo sendo obtidas verifica-se quais componentes da
biblioteca implementam parte desta especificao. Um ambiente
automatizado de desenvolvimento (uma ferramenta CASE - Computer
Aided Software Engineering) pode auxiliar este processo armazenando o
histrico de decises dos engenheiros de software.

O Modelo Espiral
O objetivo do modelo espiral prover um metamodelo que pode acomodar diversos
processos especficos. Isto significa que podemos encaixar nele as principais caractersticas
dos modelos vistos anteriormente, adaptando-os a necessidades especficas de
desenvolvedores ou s particularidades do software a ser desenvolvido. Este modelo prev

27
prototipao, desenvolvimento evolutivo e cclico, e as principais atividades do modelo
cascata.
Sua principal inovao guiar o processo de desenvolvimento gerado a
partir deste metamodelo com base em anlise de riscos e um
planejamento que realizado durante toda a evoluo do
desenvolvimento. Riscos so circunstncias adversas que podem surgir
durante o desenvolvimento de software impedindo o processo ou
diminuindo a qualidade do produto. So exemplos de riscos: pessoas que
abandonam a equipe de desenvolvimento, ferramentas que no podem
ser utilizadas, falha em equipamentos usados no desenvolvimento ou
que sero utilizados no produto final, etc. A identificao e o
gerenciamento de riscos hoje uma atividade importantssima no
desenvolvimento de software devido imaturidade da rea e falta de
conhecimento, tcnicas e ferramentas adequadas.
O modelo espiral descreve um fluxo de atividades cclico e evolutivo
constitudo de quatro estgios.
No estgio 1 devem ser determinados objetivos, solues alternativas e restries.
No estgio 2, devem ser analisados os riscos das decises do estgio anterior.
Durante este estgio podem ser construdos prottipos ou realizar-se simulaes do
software.
O estgio 3 consiste nas atividades da fase de desenvolvimento, incluindo design,
especificao, codificao e verificao. A principal caracterstica que a cada
especificao que vai surgindo a cada ciclo - especificao de requisitos, do
produto, da arquitetura, da interface de usurio e dos algoritmos e dados - deve ser
feita a verificao apropriadamente.
O estgio 4 compreende a reviso das etapas anteriores o planejamento da prxima
fase. Neste planejamento, dependendo dos resultados obtidos nos estgios anteriores
- decises, anlise de riscos e verificao, pode-se optar por seguir o
desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformao. Por
exemplo, se j no primeiro ciclo, os requisitos forem completamente especificados e
validados pode-se optar por seguir o modelo Cascata. Caso contrrio, pode-se optar
pela construo de novos prottipos, incrementando-o, avaliando novos riscos e replanejando o processo.

28

29

3. Anlise e Especificao de
Requisitos
Os objetivos deste captulo so:
Definir o que so requisitos de software
Introduzir os objetivos da Engenharia de Requisitos
Apresentar tcnicas de comunicao para obter informaes dos clientes e usurios
Apresentar tcnicas para descrever o domnio, usurios e tarefas.
Especificar requisitos funcionais utilizando Casos de Uso
Especificar requisitos no funcionais

3.1 Introduo
Vimos que o software parte de um sistema computacional mais abrangente e que a
Anlise de Sistemas a atividade de identificar os problemas do domnio, apresentar
alternativas de solues e o estudo da viabilidade de cada uma delas. Uma vez que se tenha
feito a anlise do sistema computacional, e delimitado o escopo do software, os requisitos
do software devem ser analisados e especificados.
A anlise e especificao de requisitos de software envolve as
atividades de determinar os objetivos de um software e as restries
associadas a ele. Ela deve tambm estabelecer o relacionamento entre
estes objetivos e restries e a especificao precisa do software.
A anlise e especificao dos requisitos de software deve ser vista como
uma sub-atividade da anlise de sistemas. Normalmente ela iniciada
juntamente com a anlise do sistema, podendo se estender aps a
elaborao do documento de especificao do sistema e do
planejamento do desenvolvimento, quando sero refinados os requisitos
do software.
Anlise e especificao so atividades inter-dependentes e devem ser
realizadas conjuntamente. A anlise o processo de observao e
levantamento dos elementos do domnio no qual o sistema ser
introduzido. Deve-se identificar as pessoas, atividades, informaes do
domnio para que se possa decidir o que dever ser informatizado ou
no. Pessoas e as atividades que no sero informatizadas devero ser
consideradas entidades externas ao software.
A especificao a descrio sistemtica e abstrata do que o software
deve fazer, a partir daquilo que foi analisado. Ela apresenta a soluo de
como os problemas levantados na anlise sero resolvidos pelo software
do sistema computacional. Visa descrever de maneira sistemtica quais
as propriedades funcionais so necessrias para resolver o problema do
domnio. A especificao tambm a forma de comunicao sistemtica
entre analistas e projetistas do software.

30
O objetivo da definio dos requisitos especificar o que o sistema
dever fazer e determinar os critrios de validao que sero utilizados
para que se possa avaliar se o sistema cumpre o que foi definido.

3.2 O que so requisitos?

Como sistemas computacionais so construdos para terem utilidade no mundo real.
Modelar uma parte do mundo real, o domnio de aplicao uma atividade extremamente
importante para se compreender a necessidade e a importncia do sistema a ser construdo e
definir os requisitos que tornam o sistema til.
Requisitos so objetivos ou restries estabelecidas por clientes e
usurios do sistema que definem as diversas propriedades do sistema.
Os requisitos de software so, obviamente, aqueles dentre os requisitos
de sistema que dizem respeito a propriedades do software.
Um conjunto de requisitos pode ser definido como uma condio ou
capacidade necessria que o software deve possuir (1) para que o
usurio possa resolver um problema ou atingir um objetivo ou (2) para
atender as necessidades ou restries da organizao ou dos outros
componentes do sistema.
Tradicionalmente, os requisitos de software so separados em requisitos
funcionais e no-funcionais. Os requisitos funcionais so a descrio
das diversas funes que clientes e usurios querem ou precisam que o
software oferea. Eles definem a funcionalidade desejada do software. O
termo funo usado no sentido genrico de operao que pode ser
realizada pelo sistema, seja atravs comandos dos usurios ou seja pela
ocorrncia de eventos internos ou externos ao sistema.
So exemplos de requisitos funcionais:
"o software deve possibilitar o clculo dos gastos dirios, semanais, mensais e
anuais com pessoal".
"o software deve emitir relatrios de compras a cada quinze dias"
"os usurios devem poder obter o nmero de aprovaes, reprovaes e
trancamentos em todas as disciplinas por um determinado perodo de tempo.
A especificao de um requisito funcional deve determinar o que se espera que o software
faa, sem a preocupao de como ele faz. importante diferenciar a atividade de
especificar requisitos da atividade de especificao que ocorre durante o design do
software. No design do software deve-se tomar a deciso de quais a funes o sistema
efetivamente ter para satisfazer quilo que os usurios querem.
Requisitos no-funcionais so as qualidades globais de um software,
como manutenibilidade, usabilidade, desempenho, custos e vrias
outras. Normalmente estes requisitos so descritos de maneira informal,
de maneira controversa (por exemplo, o gerente quer segurana mas os
usurios querem facilidade de uso) e so difceis de validar.
So exemplos de requisitos no-funcionais:
"a base de dados deve ser protegida para acesso apenas de usurios autorizados".

31

"o tempo de resposta do sistema no deve ultrapassar 30 segundo".

"o software deve ser operacionalizado no sistema Linux"
"o tempo de desenvolvimento no deve ultrapassar seis meses".

A necessidade de se estabelecer os requisitos de forma precisa crtica na medida que o

tamanho e a complexidade do software aumentam. Os requisitos exercem influncia uns
sobre os outros. Por exemplo, o requisito de que o software deve ter grande portabilidade
(por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho
no seja satisfeito (programas em Java so, em geral, mais lentos).

3.3 A Engenharia de Requisitos

Os diversos relacionamento e restries que os requisitos exercem uns sobre os outros so
muito difceis de ser controlados. Principalmente se considerarmos que algumas decises
de design que afetam um ou mais requisitos s sero tomadas mais adiante do
desenvolvimento. Por exemplo, a deciso de implementar em Java pode ser decidida apenas
aps o design da arquitetura. Desta forma, os requisitos precisam ser gerenciados durante
todo o desenvolvimento.
A importncia e complexidade desta atividade levaram ao surgimento,
no incio dos anos 90, da Engenharia de Requisitos. O objetivo desta
denominao ressaltar que o processo de definir os requisitos de
software uma atividade extremamente importante e independente das
outras atividades da engenharia de software. Ela requer fundamentao
e processos prprios, e que devem ser planejados e gerenciados ao
longo de todo o ciclo de vida.
Os objetivos da Engenharia de Requisitos podem ser categorizados em
trs grupos principais [Zave]:
Investigao de objetivos, funes e restries de uma aplicao de software
o Ultrapassar as barreiras de comunicao
o Gerar estratgias para converter objetivos vagos em propriedades ou
restries especficas
o Compreender prioridades e graus de satisfao
o Associar requisitos com os vrios agentes do domnio
o Estimar custos, riscos e cronogramas
o Assegurar completude
Especificao do software
o Integrar representaes e vises mltiplas
o Avaliar estratgias de solues alternativas que satisfaam os requisitos
o Obter uma especificao completa, consistente e no ambgua
o Validar a especificao - verificar que ela satisfaz aos requisitos
o Obter especificaes que sejam apropriadas para as atividades de design e
implementao
Gerenciamento da evoluo e das famlias do software
o Reutilizao de requisitos durante o processo de evoluo
o Reutilizao de requisitos no desenvolvimento de software similares

32
o

Reconstruo de requisitos

A Engenharia de Requisitos deve envolver a documentao das funes, do desempenho,

interfaces externas e internas e atributos de qualidade do Software.
Esta rea inerentemente abrangente, interdisciplinar e aberta. Ela lida
com a descrio de observaes do mundo real atravs de notaes
apropriadas.
Os benefcios da Engenharia de Requisitos so:
Concordncia entre desenvolvedores, clientes e usurio sobre o trabalho a ser feito e
quais os critrios de aceitao do sistema.
Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas
e equipamentos)
Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
Atingir os objetivos com o mnimo de desperdcio
Uma boa especificao de requisitos deve ser:
Clara e no-ambgua
Completa
Correta
Compreensvel
Consistente
Concisa
Confivel
(Veja mais em Dorfman, Merlin - Requirements Engineering)

3.4 Modelos de documentos de

especificao de requisitos
O resultado final da anlise e especificao de requisitos e das outras atividades da fase de
defino devem ser apresentados aos clientes para que eles possam valid-lo. Este
documento oferece a concordncia entre clientes, analistas e desenvolvedores sobre o que
deve ser desenvolvido. utilizando este documento que as atividades da fase de
desenvolvimento (design e programao) sero validadas.
Cada desenvolvedor utiliza um modelo especfico para elaborar este
documento. A sua estrutura muitas vezes depende do mtodo que est
sendo utilizado. Em linhas gerais este modelo deve ser basicamente
textual, utilizando o mnimo de termos tcnicos, e ilustrados como
modelos grficos que demonstrem mais claramente a viso que os
analistas tiveram dos problemas e dos requisitos para o futuro sistema.
Vamos apresentar a seguir dois modelos de documentos encontrados na
literatura. Estes modelos descrevem no apenas a especificao dos
requisitos, mas os resultados do estudo de viabilidade e o processo de
desenvolvimento.

33
Pressman apresenta o seguinte documento de especificao de
requisitos de software:
I. Introduo
1. Referncias do Sistema
2. Descrio Geral
3. Restries de projeto do software
II. Descrio da Informao
1. Representao do fluxo de informao
a. Fluxo de Dados
b. Fluxo de Controle
2. Representao do contedo de informao
3. Descrio da interface com o sistema
III Descrio Funcional
1. Diviso funcional em parties
2. Descrio funcional
a. Narativas
b. Restries/limitaes
c. Exigncias de desempenho
d. Restries de projeto
e. Diagramas de apoio
3. Descrio do controle
a. Especificao do controle
b. Restries de projeto
IV. Descrio Comportamental
1. Estados do Sistema
2. Eventos e aes
V. Critrios de Validao
1. Limites de desempenho
2. Classes de testes
3. Reao esperada do software
4. Consideraes especiais
VI. Bibliografia
VII Apndice
Uma proposta alternativa a de Farley. De acordo com ele, um
documento de especificao de requisitos deve possui as seguintes
sees:
Viso geral do produto e Sumrio
Ambientes de desenvolvimento, operao e manuteno
Interfaces Externas e Fluxo de Dados
Requisitos Funcionais
Requisitos de Desempenho
Tratamento de Excees
Prioridades de Implementao
Antecipao de mudanas e extenses
Dicas e diretrizes de Design
Critrios de aceitao

34

ndice Remissivo
Glossrio

3.5 Tcnicas de comunicao com clientes

e usurios
Um dos objetivos da Engenharia de Requisitos ultrapassar barreiras de comunicao entre
os clientes e usurios e os analistas para que os requisitos possam capturados e modelados
corretamente
Dentre as tcnicas mais importantes para a comunicao podemos citar
trs:
Entrevistas
Observao in loco
Encontros
Estas trs tcnicas so complementares e podem todas ser usadas numa mesma anlise de
requisitos. A entrevista normalmente a primeira tcnica utilizada. Analistas entrevistam
clientes para definir os objetivos gerais e restries que o software dever ter. A entrevista
deve ser feita de forma objetiva visando obter o mximo de informaes do cliente.
Diversas sees de entrevistas podem ser marcadas.
Na observao in loco os analista devem estar inseridos na rotina de
trabalho da organizao tentando entender e descrever as principais
atividades que so realizadas. Na observao devem ser identificadas
quais as atividades podem ser automatizadas, quem so os potenciais
usurios, quais tarefas eles querem realizar com a ajuda do novo
sistema, etc. A observao deve ser complementada com entrevistas
especficas com os futuros usurios.
Os encontros so reunies envolvendo analistas, clientes e usurios
destinadas exclusivamente ao levantamento de informaes, descrio
dos problemas atuais e de metas futuras. Os encontros devem ser
realizados em um local neutro (fora da organizao) e normalmente
duram poucos alguns dias. Nos encontros as informaes que vo sendo
levantadas vo sendo afixadas em paineis na sala de encontro para que
possam ser analisadas e validadas pelos clientes e usurios. Ao final do
encontro os analistas devem elaborar um relatrio descrevendo os
requisitos analisados.

3.6 Usando Cenrios para Anlise do

Domnio
Do ponto de vista de usabilidade, o desenvolvimento de um novo sistema implica na
transformao das tarefas e prticas atuais dos usurios e da organizao. Conhecer a
situao atual e antecipar o impacto que um novo sistema deve ter fundamental para o seu
sucesso. Isso ocorre porque quando se introduz novas tecnologias, parte do contexto de

35
tarefa de uma organizao alterado. Nessa reengenharia, novas tarefas e prticas so
incorporadas enquanto que outras so eliminadas.
O levantamento de informaes sobre as tarefas e os usurios pode ser
melhor realizado quando os analistas procuram descrever situaes do
processo de trabalho. Os mtodos baseados em cenrios consistem de
uma coleo de narrativas de situaes no domnio que favorecem o
levantamento de informaes, a identificao de problemas e a
antecipao das solues. Cenrios so uma maneira excelente de
representar, para clientes e usurios, os problemas atuais e as
possibilidades que podem surgir.
Os cenrios tm como foco as atividades que as pessoas realizam nas
organizaes possibilitando uma perspectiva mais ampla dos problemas
atuais onde os sistema sero inseridos, explicando porque eles so
necessrios. Eles proporcionam um desenvolvimento orientado a tarefas
possibilitando maior usabilidade do sistema.
No objetivo dos cenrios oferecer uma descrio precisa, mas
provocar a discusso e estimular novos questionamentos. eles permitem
tambm documentar o levantamento de informaes a respeito dos
problemas atuais, possveis eventos, oportunidades de aes e riscos.
Por sua simplicidade, cenrios so um meio de representao de fcil
compreenso para os clientes e usurios envolvidos (muitas vezes de
formao bastante heterognea) que podem avaliar, criticar e fazer
sugestes, proporcionando a reorganizao de componentes e tarefas
do domnio. Cenrios oferecem um "meio-intermedirio" entre a
realidade e os modelos que sero especificados possibilitando que
clientes, usurios e desenvolvedores participem do levantamento das
informaes e especificao dos requisitos. Em resumo, os cenrios
permitem compreenso dos problemas atuais pelos analistas e
antecipao da situao futura pelo clientes e desenvolvedores.

Elaborando Cenrios
Como toda atividade de anlise e especificao de requisitos, a descrio do domnio
atravs de cenrios requer tcnicas de comunicao e modelagem.
A descrio de cenrios deve ser apoiada pelas trs tcnicas de
comunicao vistas anteriormente. Antes de descrever os cenrios, os
analistas devem entrevistar clientes para entender os problemas e
requisitos iniciais. A entrevista com usurios permite que cada um
descreva as suas tarefas e os problemas associados a cada uma delas. A
observao direta in loco fundamental para que os analistas possam
descrever a situao de uso como ela realmente vem ocorrendo na
prtica.
Aps a elaborao dos cenrios, clientes, usurios e analistas podem
participar de encontros para que possam discutir cada um destes
cenrios. Eles podem ser afixados em quadros na parede onde os

36
participantes possa analis-los e fazer comentrios, possivelmente
afixando pequenos pedaos de papel a cada uma das cenas.
Cenrios podem ser descritos em narrativas textuais ou atravs de
storyboards. As narrativas textuais podem ser descritas livremente,
identificando os agentes e as aes que eles participam. possvel
utilizar notaes para descrever roteiros de cinemas ou notaes mais
precisas como aquelas utilizadas pela Inteligncia Artificial para
representao de conhecimento.
Uma tcnica que est bastante relacionada com cenrios, por permitir
descrever situaes de uso, o storyboarding. Essa tcnica envolve a
descrio atravs de quadros com imagens que ilustram as situaes do
domnio. Cada quadro deve apresentar a cena que descreve a situao,
os atores e as aes que cada um deve desempenhar. Abaixo de cada
quadro devem estar descritas aes que os atores desempenham. Os
storyboards so bastante utilizados em cinemas como forma de
comunicao entre roteiristas, diretores, atores e tcnicos.
Existem ferramentas computacionais que podem ser utilizadas para a
descrio de cenrios como o Scenario's Browser [Rosson 99].

Exemplos de cenrios
Como exemplo vamos considerar o domnio de uma locadora de fitas de vdeo.
Cena 1: Cliente procura uma fita com uma certa atriz
Agentes: Cliente, Atendente, Balconista
Aes:
Cliente entra na loja e dirige-se at a atendente.
Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Antendente: - Algum especfico?
Cliente: - No, mas que no seja policial ou ao.
Atendente: Voc sabe o nome dela?
Cliente: No.
A atendente pergunta balconista.
Antendente: - Voc sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. um nome bem complicado. S sei que comea com G e o
sobrenome algo parecido com Paltrow.
Cliente: isto mesmo.
A atendente ento procura no fichrio de atrizes as que comeam com G. No
encontra nenhum nome parecido com o que a balconista falou. Ela ento lembra-se
de consultar uma revista especializada com os ganhadores do Oscar 99 e l descobre
o nome correto da atriz. Entretanto, no existe realmente ficha alguma com os
filmes estrelados por esta atriz. O fichrio est desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime
Perfeito e Seven e mostra-os ao cliente. O cliente recusa-se dizendo que no gosta
do gnero destes filmes e pergunta pelo filme vencedor do Oscar.

37

A antendente responde: - Shakespeare Apaixonado? Ainda no saiu em vdeo.

Cena 2: O cliente procura por filmes de um certo gnero
Agentes: Cliente, Atendente, Balconista
Aes:
Cliente: - Eu gostaria de comprar um filme de ao.
Atendente: - Ns apenas alugamos.
Cliente: - Tudo bem. Ento, por favor, me d algumas dicas de filmes de ao.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dvida se j
assistiu outros trs. Ele tambm pergunta atendente se os outros dois filmes so
bons. Aps conversar durante alguns minutos com a atendente que entende muito do
gnero, decide ficar com seis fitas. A atendente encaminha o cliente balconista
para calcular o valor da locao e o prazo de devoluo. Aps consultar as tabelas
de preos e prazos, a balconista apresenta trs planos de pagamento.
Balconista: - Se voc devolver em um dia, paga apenas R$ 6,00. Se devolver em
seis dias paga R$ 12,00 e se devolver em uma semana paga R$ 15,00. Aps este
prazo paga mais R$ 2,00 por fita, por dia.
Cena 3: Cliente procura por filme usando o sistema de consulta
Agentes: Cliente e Sistema de Consulta
Aes:
Joo gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e,
chegando l, utiliza um sistema de consulta. Ele no lembra o ttulo nem o diretor,
mas sabe que se passava na guerra do Vietn e lembra bastante da trilha sonora.
Utilizando o sistema ele solicita as opes de filmes de guerra. Os sistema oferece a
ele as possibilidades de escolher os filmes por local da guerra ou por poca. Joo
escolhe a sua opo (guerra) e obtem uma lista com dezenas de filmes sobre o
vietnam. Ele pode organizar esta lista, por diretor, atores e ttulo. Na tela do sistema
aparecem a ilustrao com o cartaz de divulgao do filme e uma opo para ele
visualizar o trailler. O sistema, entretanto, no possibilita ele ouvir a trilha sonora.
Aps analisar algumas opes ele finalmente encontra o filme
desejado, mas uma informao na tela do sistema indica que o
filme est alugado. Joo quer saber quando o filme ser devolvido,
mas esta informao no consta no sistema. Ele entretanto pode
reservar e o sistema enviar para ele um e-mail avisando quando
o filme estiver disponvel. Ele sai da loja pensando "Que tempo
perdido. Seria melhor que eu pudesse consultar o sistema de
casa".

Obtendo informaes dos cenrios atravs do

Questionamento Sistemtico

38
A descrio de informaes do domnio atravs de narrativas s efetivamente realizada se
o processo de compreenso por parte dos analistas e projetista for realizado de maneira
sistemtica [J. Carroll et al. 94].
O questionamento sistemtico uma tcnica psico-lingustica que
permite a psiclogos e lingistas examinar o contedo e a estrutura de
informaes contidas numa narrativa. Uma narrativa um sumrio de
um conjunto de eventos e aes envolvendo agentes e objetos do
mundo. Nem todas as informaes integrantes do contexto so
passadas atravs da narrativa. Muitas dessas informaes so inferidas
do conhecimento cultural de cada indivduo. Outras, entretanto,
precisam ser obtidas diretamente na fonte, isto , junto ao autor da
narrativa. Essa tcnica foi desenvolvida para se entender melhor o
processo de compreenso de estrias em narrativas. O objetivo
compreender tudo o que envolve o contexto daquilo que est sendo
passado na narrativa.
Aplicando essa tcnica no processo de anlise de domnios, os
especialistas devem descrever em narrativas seu conhecimento do
domnio. Entretanto esse conhecimento muito mais abragente. O
questionamento sistemtico permite obter todo o conhecimento que
est alm do que foi comunicado na narrativa. Assim, analistas e
projetista podem utilizar essa tcnica para adquirir mais eficazmente
conhecimento sobre o domnio e inferir objetos e interaes que no
esto descritos na narrativa. Isto ocorre usando-se cada sentena ou
afirmao da narrativa como ponto de entrada na complexidade do
problema.
Nessa tcnica, cada questo uma ponte entre uma idia e outra. Uma
resposta a uma questo sobre um componente da narrativa revela
outras conexes que so crticas para o seu entendimento. Realizando,
sistematica e exaustivamente muitos tipos de questes sobre
componentes da narrativa e iterativamente fazendo perguntas sobre as
respostas geradas, o analista elabora um mapa conceitual (rede de
proposies) que representa as estruturas do conhecimento do domnio.
Os passos do mtodo consistem de:
1. Gerao do cenrio - as narrativas que compe o cenrio devem ser decritas
pelo especialista no domnio. O analista pode motiv-lo fazendo perguntas como
num processo convencional de entrevista (questes de elicitao do cenrio).
2. Elaborao da rede de proposies - as narrativas devem ser simplificadas e
expressas
atravs
de
proposies.
3. Anlise - a partir das proposies pode-se determinar as tarefas (aes e objetos)
e
usurios
(agentes
das
aes).
4. Questionamento sistemtico - novas proposies podem ser elaboradas atravs
de questes que so feitas sobre elementos das proposies anteriores, num
processo iterativo.
Nos passos iniciais obtem-se informaes sobre agentes, interaes e objetos abstratos do
domnio. Usando a tcnica, pode-se chegar a um conhecimento mais profundo do domnio
que permite aos analistas e projetista a elaborao de modelos funcionais do sistema.

39
Exemplo
Considere o seguinte cenrio sobre um caixa eletrnico.
Questo de elicitao do cenrio:
Como posso sacar R$ 100,00 do caixa eletrnico?
Cenrio:
Primeiro ponha o seu carto do banco no caixa eletrnico, digite a sua senha e
pressione o boto "saque rpido". Depois pegue o dinheiro.
As duas sentenas do cenrio acima contm quatro proposies:
CLIENTE -- pe -- CARTO
CLIENTE -- digita -- SENHA
CLIENTE -- pressiona -- BOTO-DE-SAQUE-RPIDO
CLIENTE -- pega -- DINHEIRO
A partir dessas proposies, o analista determina que o carto e o cliente so agentes de
aes. Numa anlise voltada para a elicitao de requisitos da interao, seria determinado
como usurio do sistema, o cliente. A aes so portanto: digita, pressiona e pega. So
objetos da interao a senha, o boto e o dinheiro. Outros objetos so o caixa eletrnico e o
carto. preciso determinar que tipo de objetos so esses. Uma outra dvida a respeito do
carto ser objeto ou agente.
Obviamente, como esse exemplo bastante simples e a aplicao
tambm muito conhecida, parece desnecessrio obter mais
conhecimentos a respeito. Entretanto, como o objetivo aqui
exemplificar a tcnica, mostraremos como pode-se questionar a respeito
dessa aplicao.
O analista deve ento realizar uma srie de questes sobre as
proposies. Nesse questionamento o analista precisa determinar qual o
relacionamento entre a resposta e a proposio que originou a pergunta.
As questes da categoria por que, visam responder "razes" (metas) e
"causas" a respeito de eventos da narrativa. As questes da categoria
como oferecem maiores detalhes a respeito de determinados eventos,
permitindo determinar sub-tarefas e maiores detalhes sobre a interao.
Questes da categoria o que podem ser feitas sobre objetos, e revelam
atributos e hieraquias de objetos. Perguntas de verificao podem ser
feitas para se saber se as proposies esto sendo entendidas
corretamente. As perguntas de verificao so as que tm resposta
sim/no. Uma taxonomia mais completa ainda est sendo pesquisada
pelos autores do mtodo.
Continuando o exemplo anterior a tabela abaixo descreve uma seo de
questionamento sistemtico:
Questes "por que"
Por que o carto entra no caixa eletrnico?
_ Para iniciar. (evento conseqente)
_ E ento a mquina saber quem o cliente. (estado conseqente)
Por que o cliente digita sua senha?
_ Para provar que ele o usurio autorizado. (meta)

40
Por que o cliente pressiona o boto de saque rpido?
_ Porque o boto para saques de R$ 100,00 (critrio de descriminao).
_ Para evitar a digitao (cenrio alternativo).
_ Porque ele est com pressa (causa)
Questes "como"
Como o cliente pe o carto?
_ O cliente tira o carto de sua bolsa e
_ insere no local apropriado no caixa eletrnico..
Como o cliente digita a senha?
_ Pressionando os botes adequados.
Como o cliente pressiona o boto de saque rpido?
_ Colocando o seu dedo nele.
Questes "o que"
O que um boto de saque rpido?
_ um tipo de boto que se pode pressionar.
O que um boto?
_ um dispositivo de controle no painel do caixa eletrnico.
Observe que se o analista estivesse utilizando essa tcnica para num mtodo orientado a
objetos, outras questes poderiam ser realizadas com outros objetivos de acordo com as
necessidades do mtodo, como, por exemplo, para determinar classes e hierarquia de
classes.
Aps os cenrios estarem desenvolvidos, os analistas devem trabalhar
em conjunto com os usurios para avali-los e refin-los. Isto pode ser
feito, por exemplo, colocando-se posters numa sala pela qual os
usurios podem circular livremente e observar os diversos cenrios.
Cada cenrio deve apresentar quadros (desenhos, grficos, fotografias,
etc.), usando storyboards por exemplo, e uma descrio narrativa da
tarefa. Os usurios, munidos de papeis e lpis, podem fazer anotaes
(crticas e sugestes) e anex-las a cada poster.

Consideraes finais sobre cenrios

O resultado da modelagem atravs de cenrios uma base para a compreenso de quem so
os usurios, quais a tarefas envolvidas e quais funes a interface e a aplicao devem
prov, de maneira que, j se possa ter meios de garantir a usabilidade do sistema.
A idia de cenrios em anlise no est necessariamente associada
tcnica de questionamento sistemtico. Os cenrios so extremamente
teis para descrio do domnio. A tcnica sistematiza o processo de
compreenso do conhecimento adquirido.
Os mtodos em geral, e esse no deve fugir regra, devem ser usados,
no como uma camisa-de-fora que limite o processo de anlise, mas
como ferramentas que orientam os analistas e aumentam sua
capacidade intelectual.

41

3.7 Anlise de Usurios

Para que o sistema seja construdo como uma ferramenta de apoio s atividades de usurios
no domnio de aplicao, preciso conhecer quem so os usurios e quais as suas
necessidades, isto quais tarefas eles necessitam realizar. A anlise de usurios deve
determinar quem eles so e quais tarefas eles normalmente fazem no domnio. Ela envolve
a descrio dos diferentes papis de usurios e qual o conhecimento, capacidade e cultura
possuem os futuros usurios do sistema.

3.7.1 Anlise de Perfis de Usurios

A anlise do perfil dos diversos usurios do sistema descreve as vrias caractersticas que
podem influenciar as decises dos projetistas no desenvolvimento do sistema. Os objetivos
so assegurar que certas propriedades do sistema estejam adequadas ao conhecimento,
cultura e capacidades do usurio, e que potenciais deficincias sejam levadas em
considerao. Por exemplo, para um software de acompanhamento de pacientes em
hospital, certos termos especficos da medicina devem ser includos nas telas do sistema e
devem ser evitados termos tcnicos de informtica ( fornea informaes patolgicas ao
invs de entrar dados da doena). Para usurios com alguma deficincia fsica ou motora,
elemento da interface devem ser modificados, como por exemplo, tela de maior tamanho e
letras maiores para deficientes visuais.
Os perfil do usurio pode ser analisado atravs de formulrios do tipo:

Perfil do Usurio
Nome do Sistema:
____________________________________________________________________
Funo do Usurio:
___________________________________________________________________
Conhecimento e Experincia do Usurio
Nvel educacional
Lngua Nativa
Nvel de leitura e expresso
( ) Ensino fundamental
( ) Portugus
( ) Ensino mdio
( ) Ingls
( ) Excelente
( ) Graduao
( ) outra:
( ) Bom
( ) Ps-Graduao
___________________
( ) Regular
( ) Ruim
Experincia com
Experincia com sistema
Conhecimento sobre o
computadores
similar
domnio
( ) Iniciante
( ) Utiliza bastante um similar ( ) Elementar
( ) Intermedirio
( ) J utilizou um similar
( ) Intermedirio
( ) Experiente
( ) Nunca utilizou um similar ( ) Especialista no domnio
Caractersticas Fsicas
Manipulao
Deficincias
( ) Canhoto
( ) Auditiva

42
( ) Destro
( ) Ambidestro

( ) Visual
( ) Corporal
( ) Vocal

O perfil deve dar as informaes necessrias que os desenvolvedores

precisam para tomar as suas decises. A anlise do perfil pode ser
adaptada de acordo com as caractersticas do sistema e com as
necessidades de analistas e desenvolvedores. Por exemplo, pode ser
interesse dos designers saber se os usurios tm algumas experincia
com interfaces grficas e qual o padro (Windows, Motif, Macintosh,
etc.) eles esto acostumados a utilizar.

3.7.2 Papis de Usurios

O papel (ou funo ) especfico de cada usurio definido pelas tarefas que eles realizam.
Numa organizao, as pessoas trabalham juntas, de maneira estruturada. A estrutura da
organizao define relacionamentos entre as pessoas. A implicao imediata dos diferentes
papis de cada usurio so as diferentes tarefas que eles iro realizar. Algumas tarefas
podem ser comuns a diferentes papis de usurios, enquanto outras podem ser exclusivas de
papis especficos.
O conceito de papel de usurio permite abstrairmos as caractersticas
especficas de um usurio e enfatizar nas diferentes necessidades
associadas a funo que ele exerce. Para cada papel devemos associar
um conjunto de funes, como veremos mais adiante.
No domnio do departamento de informtica da UFRN podemos
identificar como papis de usurios: secretrio do departamento, chefe,
coordenador de graduao, secretrio da coordenao, coordenador de
ps-graduao, professor, aluno, funcionrio de administrao de
laboratrios e usurio externo.

3.8 Anlise e Modelagem de Tarefas

Os cenrios permitem o levantamento e a descrio mais global das informaes, das
tarefas e dos problemas do domnio. O perfil de usurio descreve as caractersticas de
usurios em termo de conhecimento, cultura, capacidades e limitaes. A anlise de tarefas
visa determinar quais as atividades que os usurios (ou cada papel de usurio) devem
realizar. Esta informao essencial para se especificar os requisitos funcionais,
determinando a funcionalidade do software. Para que o sistema possa ser construdo para
que estes problemas sejam resolvidos, ele deve ser uma ferramenta auxiliar na realizao
das tarefas de cada usurio.
Uma tarefa , genericamente, uma atividade na qual um ou mais
agentes tentam atingir uma meta especificada, atravs de uma
mudana de estado em uma ou mais entidades do mundo. Num domnio
de aplicao, as tarefas so as atividades que modificam estados de
elementos deste domnio. A construo de um sistema computacional

43
em um certo domnio tem por objetivo apoiar a realizao de algumas
destas atividades. Durante o processo de anlise, deve-se determinar
quais as do domnio e identificar quais delas podem ser auxiliadas pelo
sistema.
A anlise e modelagem de tarefas visa descrever as principais as tarefas
que cada usurio do sistema ter de realizar para que os projetistas
possam elaborar quais funes o sistema deve oferecer para que elas
possam ser desempenhadas. Estas tarefas so descritas em termos de
metas e um planejamento de possveis atividades necessrias para
atingi-las. As tarefas podem ser descritas a partir das informaes
obtidas nos cenrios e devem ser agrupadas por papis de usurio.
A anlise de tarefas pode ser utilizadas nas diversas fases do ciclo de
vida do software. Na fase de anlise de requisitos ela pode ser utilizada
para identificar problemas na maneira de como as tarefas vm sendo
realizadas. Os modelos de tarefas tambm podem descrever quais
tarefas podem ser realizadas com o auxlio do sistema e como os
usurios gostariam que ela fosse realizada. A anlise de tarefa tambm
utilizada na avaliao do sistema para se determinar se como os
usurios esto utilizando o sistema e se os objetivos foram atingidos.
Nestes casos, a anlise de tarefas ajuda ao projetista da interface ter
uma viso da aplicao sob a perspectiva do usurio, isto , um modelo
das tarefas do usurio quando executando sesses da aplicao.

3.8.1 Modelo de tarefas como base para a especificao

de requisitos funcionais
A anlise e modelagem de tarefas pode ser utilizada como base para a especificao de
requisitos funcionais. Para isto preciso descrever as metas associadas a cada papel de
usurio, que permitiro saber o que os usurio querem.
Resultados da psicologia cognitiva mostram que as pessoas realizam
tarefas estabelecendo metas e elaborando um plano para cada uma
delas. O planejamento consiste numa decomposio hierrquica de
metas em sub-metas at que elas possam ser atingidas por
operaes. O plano ou mtodo , portanto, uma estrutura de submetas e operaes para se atingir um certa meta. As operaes
correspondem a aes bsicas humanas, isto , aquelas que qualquer
pessoa pode e sabe como realizar. So exemplos de operaes escrever
uma palavra ou frase, ler uma informao, falar uma palavra ou frase,
andar, relembrar, mover um objeto, pressionar um boto de controle e
vrias outras.

44
Por exemplo, suponhamos que uma pessoa tem como meta avisar a um
amigo, atravs de uma carta, que sua filha nasceu. Para atingir seu
objetivo a pessoa deve estabelecer duas sub-metas: Escrever a carta e
Coloc-la no correio. A sub-meta escrever carta pode ser atingida pelo
mtodo: Conseguir papel e lpis e Escrever mensagem. Escrever
mensagem j pode ser considerada uma operao, enquanto que
conseguir papel e lpis requer um novo planejamento que determine as
seguintes operaes: ir at o escritrio, abrir o armrio, pegar o papel e
o
lpis,
lev-los
at
a
mesa.
O gro de refinamento do que podemos considerar com sendo uma
operao bastante subjetivo. Vai depender das dificuldades de quem
realiza o plano. Na prtica o plano necessrio quando a pessoa que vai
realizar as aes no sabe ainda qual o mtodo. Com a experincia o
mtodo torna-se automtico e podemos considerar uma sub-meta como
uma operao
Na utilizao de um sistema computacional, os usurios realizam tarefas
com o objetivo de atingir certas metas. Uma meta um determinado
estado do sistema ou de objetos do sistema ao qual o usurio quer
chegar. Ao estabelecer a meta o usurio deve realizar um planejamento
decompondo a meta em sub-metas at que ele saiba que existe uma
determinada funo do sistema que permita que sua meta seja atingida.
O caso agora um pouco diferente do planejamento anterior, pois no
o usurio quem vai realizar a operao desejada, mas o sistema. A
decomposio deve ocorrer at que ele identifique que o sistema tem
uma determinada funo que quando executada realiza a operao
necessria para que sua meta seja atingida. Chamamos estas operaes
que o sistema executa para satisfazer as metas do usurio de funo
da aplicao. O conjunto de funes da aplicao determina a
funcionalidade do sistema.
Vejamos um exemplo. Suponha que o usurio esteja escrevendo uma
carta utilizando um editor de texto e tenha como meta formatar um
documento.Para atingir esta meta ele estabelece as seguintes submetas: Formatar pgina, Formatar pargrafos, Formatar fontes. Para
cada uma destas sub-metas ele estabelece novas sub-metas at que ele
identifique no software funes que o sistema pode realizar que
permitam que as sub-metas sejam atingidas. Por exemplo, formatar
pgina pode ser decomposta na funo da aplicao especificar
tamanho da pgina e na sub-meta definir margens. Esta ltima por sua
vez pode ser atingida pelas operaes especificar valor da margem
superior, especificar valor da margem inferior, especificar valor da
margem esquerda e especificar valor da margem direita.
Vejamos o plano deste usurio
META: Formatar documento
PLANO:
Formatar pgina (sub-meta)

45
especificar tamanho da pgina (funo da aplicao )
Definir margens (sub-meta)
especificar valor da margem superior (funo da
aplicao)
especificar valor da margem inferior (funo da
aplicao)
especificar valor da margem esquerda (funo da
aplicao)
especificar valor da margem direita (funo da
aplicao)
Formatar pargrafos (sub-meta)
selecionar pargrado (funo da aplicao)
Especificar atributos do pargrafo (sub-meta)
especificar espaamento (funo da aplicao)
especificar recuos (funo da aplicao)
...
Formatar fontes (sub-meta)
...
O modelo de tarefas extremamente til para determinarmos as metas dos usurios e quais
funes da aplicao eles gostariam que o sistema oferecesse. Por exemplo, a especificao
dos requisitos pode determinar que deve existir uma funo da aplicao para formatar
documento de maneira que a meta do usurio pudesse ser atingida pelo sistema sem a
necessidade de planejamento algum.
importante ressaltar que uma meta pode ser satisfeita por uma nica
ou por vrias funes da aplicao e que tambm mais de um mtodo
pode ser atingido uma mesma funo da aplicao.Por exemplo, ao
utilizar o Word 7.0, o usurio pode ter como meta formatar um estilo. Ao
construir o seu plano o usurio em determinado momento pode
estabelecer a sub-meta Especificar atributos do pargrafo. Esta submeta requer as mesmas funes de aplicao do plano para a meta
formatar pargrafo. Assim, temos um grupo de funes da aplicao que
so utilizadas para duas (ou mais) metas distintas.
Para que o usurio solicite ao sistema que execute uma determinada
funo de usurio, ele deve realizar operaes que correspondam a um
comando de funo. Por exemplo, para o usurio solicitar ao sistema
operacional que realize a funo de copiar um arquivo de um diretrio
para outro ele deve escrever um comando do tipo copy nome1 dir1
dir2 ou se estiver numa interface grfica, mover o cone correspondente
ao arquivo da janela do diretrio para a do outro diretrio. Ao realizar o
comando, o usurio precisa realizar operaes com os dispositivos de
interface do sistema, como pressionar mouse, digitar nmero, teclar
enter, etc.
Apenas com a descrio das operaes do usurio que um plano para
atingir uma meta fica completo. Quando o sistema est pronto, o plano
tem que determinar exatamente as operaes necessrias para

46
comandar a funo e, conseqentemente, ter a meta atingida com o
auxlio do sistema.
Na especificao de requisitos suficiente decompor as metas que o
usurio quer atingir nas correspondentes sub-metas. Caber ao designer
do software determinar qual o conjunto de funes que permita atingir o
maior nmero possvel de metas para cada papel de usurio e quais
devem ser os comandos de interface para cada uma das funes.

3.8.2 Modelagem de Tarefas usando GOMS

Neste curso, utilizaremos a anlise de tarefas na especificao de requisitos para determinar
as tarefas que os usurios necessitam realizar com o sistema a ser construdo. Para isto
utilizaremos um mtodo especfico que utiliza o modelo GOMS simplificado. O modelo
GOMS (Goals, Operators, Methods, and Selection Rules) oferece uma abodagem de
anlise da tarefa baseada num modelo do comportamento humano que possui trs
subsistemas de interao: o perceptual (auditivo e visual), o motor (movimentos braomo-dedo e cabea-olho), e cognitivo (tomadas de deciso e acesso a memria). O modelos
GOMS descreve o comportamento dinmico da interao com um computador,
especificando-se:
Metas - Uma aplicao desenvolvida para auxiliar os usurios atingirem metas
especficas. Isso requer uma srie de etapas. Dessa forma, uma meta pode ser
decomposta em vrias submetas, formando uma hierarquia.
Operadores - So as aes humanas bsicas que os usurios
executam.
perceptual - operaes visuais e auditivas (olhar a tela, escutar um beep).
motor - movimentos brao-mo-dedo e cabea-olho
(pressionar uma tecla).
cognitivo - tomadas de deciso, armazenar e relembrar um
item da memria de trabalho.
Mtodos - Um mtodo uma sequncia de passos para se atingir uma meta.
Dependendo do nvel da hierarquia, os passos num mtodo podem ser submetas,
operadores ou a combinao de ambos.
Regras de Seleo - Pode existir mais de um mtodo para se
atingir uma meta. Uma regra de seleo especifica certas
condies que devem ser satisfeitas antes que um mtodo possa
ser aplicado. Uma regra de seleo uma expresso do tipo
"condio-ao".
O GOMS permite que se construa modelos de tarefas bem mais complexos e detalhados do
que o necessrio numa tarefa de anlise para a especificao de requisitos. Usaremos uma
verso simplificada do GOMS, pois:
o modelo da tarefa no dever descrever informaes de design da interface,
uma vez que ela ainda no foi construda;
o analista no um especialista em psicologia cognitiva;
o modelo simplificado pode ser expandido para o original, o que bastante
til.

47
1. Diretrizes do Modelo de Tarefas Simplificado
Uma vez que a hierarquia de metas representa um aumento no nvel de detalhe, se nos
limitarmos descrio de metas e submetas de mais alto nvel, nenhuma deciso de design
ser envolvida.
Faa a anlise "top-down" - comece das metas mais gerais em direo as
mais especficas.
Use termos gerais para descrever metas - no use termos especficos da
interface.
Examine todas as metas antes de descer para um nvel mais baixo - isso
facilita reuso de metas.
Considere todas as alternativas de tarefas - as regras de seleo
possibilitam representar alternativas.
Use sentenas simples para especificar as metas - estruturas complexas
indicam a necessidade de decomposio da meta em submetas.
Retire os passos de um mtodo que sejam operadores - os operadores so
dependentes da interface.
Pare a decomposio quando as descries estiverem muito detalhadas quando os mtodos so operadores ou envolvem pressuposies de design.
1. Modelagem da Tarefa para aplicaes com mltiplas funes de usurios.
Se, para uma determinada aplicao, a funo do usurio for um
fator crtico dominante na anlise de usurios, deveremos ter
modelos de tarefas diferentes para cada funo de usurio. No
GOMS simplificado, veremos como representar as tarefas para
cada usurio num s modelo. Antes de estudarmos a notao do
modelo, vejamos algumas regras para modelos com mltiplas
funes de usurios:
Inicie especificando metas de alto nvel para cada funo de usurio.
Se mais de um compartilham a mesma meta, agrupe-os sob uma s.
Se todos compartilham a mesma meta, retire as referncias a funes de
usurio.
2. Notao
o
o
o

1.

Notao para Funes de Usurios.

Funes de usurios distintas sero denotadas pelo smbolo FU seguido por

um nmero.

ex.: Gerente de vendas (FU1), balconista (FU2), caixa (FU3)

A descrio de cada funo de usurio a primeira parte do modelo de
tarefas.

48

ex.: Gerente de vendas (FU1): responsvel pela vendas nas lojas.

Tem acesso a todos os dados do sistema.
Um ponto-e-vrgula (;) usado para separar o smbolo da funo do usurio
do restante da notao do modelo de tarefas.

ex.: FU1;...
Se uma meta usada para mais de uma funo de usurio, elas devem ser
separadas por uma vrgula (,).

ex.: FU1, FU2; ...

Um asterisco (*) usado se uma meta aplicada a todas as funes de
usurios.

ex.: *;...
1. Notao para especificao de metas

Cada passo num mtodo numerado numa ordem seqencial, com cada
nvel de decomposio separado por um ponto (.), e com a endentao
apropriada para reforar a noo de hierarquia. Aps o ltimo nmero usa-se
dois-pontos (:).
ex.: FU2; 2.1: Anotar correes.
Um comentrio comea com duas barras inclinadas para direita (//) e acaba
ao final da linha.
ex.: // Para fazer as anotaes o balconista dever examinar as
// listagens produzida durante as vendas do dia.
FU2; 2.1: Anotar correes

Notao para Mtodos e Regras de Seleo

Se uma meta possui mais de um mtodo para ser atingida, uma letra do
alfabeto usada de forma ordenada aps o nmero que descreve a meta.
ex.:
FU2; 2: Fazer relatrio de vendas (meta)
FU2; 2A: ... (mtodo A)
FU2; 2B: ... (mtodo B)

As regras de seleo e o mtodo associado so descritos como pares

"condio-ao", logo aps a notao numrica da meta.

ex.: FU2; 2A: se (dia de hoje for sbado)

ento (fazer relatrio semanal)
1. Reutilizando Metas

49
Um aspecto importante dessa notao que pode-se
reutilizar metas, simplesmente usando o mesmo nmero de
uma meta preexistente.
ex.:
FU2; 2.1: Anotar correes. (meta preexistente)
...
FU1, FU3; 3: Modificar livro-caixa.
FU1, FU3; 3.1: Procurar lotes em aberto.
FU1, FU3; 2.1: Anotar correes. (meta reusada)
FU1, FU3; 3.3: Recalcular valores.
2. Diretrizes adicionais

Delimite os passos de um mtodo entre chaves: {}.

Em aplicaes com apenas uma funo de usurio, no necessrio incluir a
notao de funo usurio antes de cada meta.
Num nvel de decomposio onde todas as metas tm o mesmo nmeroprefixo, apenas o nmero que indica a seqncia naquele nvel necessrio.
A diretriz anterior se aplica tambm notao de funo de usurio.
Ao reutilizar uma meta anterior necessrio usar a notao completa para
ela.
ex.: FU1, FU3; 3: Modificar livro-caixa.
1: Procurar lotes em aberto.
2.1: Anotar correes. (meta
reusada)
3: Recalcular valores.

3.9 Especificando Requisitos utilizando

Casos de Uso
Aps saber quais as tarefas associadas a cada papel de usurio, hora de elaborar os casos
de uso (use cases) que permitem definir as funes de aplicao que o sistema dever

50
oferecer para o usurio. Os casos de uso podem ser utilizadas durante a anlise e
especificao dos requisitos para descrever a funcionalidade do sistema.
Os casos de uso foram definidos como parte da metodologia de
Jacobson: Object-oriented Analysis and Design - The User Case Driven
Approach. A linguagem de modelagem UML (Unified Modeling Language)
apresenta notaes para a representao de casos de uso.
Um caso de uso especifica o comportamento do sistema a ser
desenvolvido sem, no entanto, especificar com este comportamento
ser implementado. Os comportamentos descrevem as funes da
aplicao que caracterizam a funcionalidade do sistema. Um caso de uso
representa o que o sistema faz e no como o sistema faz,
proporcionando uma viso externa e no interna do sistema.
Cada caso de uso define um requisito funcional do sistema. Por
exemplo, num sistema bancrio, consulta de saldo, emprstimos e
saques de dinheiro so exemplos de casos de uso.
O caso de uso descreve um conjunto de seqncias de aes que o
sistema desempenha para produzir um resultado esperado pelo usurio.
Cada seqncia representa a interao de entidades externas e o
sistema. Estas entidades so chamadas de atores e que podem ser
usurios ou outros sistemas. No caso de usurios, um ator representa na
verdade uma funo de usurios.
Os casos de uso podem ser compostos por outros casos de uso mais
especficos. Esta estrutura deve estar em conformidade com o
particionamento do sistema em sub-sistemas. Desta forma tanto
possvel descrever casos de uso que aplicam-se ao sistema global,
quanto casos que so especficos para cada uma das partes do sistema.
Casos de uso tambm podem ser especializados, por exemplo uma
consulta pode ser especializada em consulta de saldo e consulta de
extrato, que por sua vez podem ser especializados, cada um , em
consultas a conta-corrente ou a conta-poupana.
Ao definir os requisitos funcionais, o caso de uso define o
comportamento, as respostas esperadas e os casos de testes que
devem validar a implementao do sistema.

3.9.1 A representao de casos de uso usando UML

A notao UML ser utilizada neste curso como linguagem de especificao para a maioria
das atividades do ciclo de vida do sistema. A partir de agora vamos introduzir esta notao
necessria para representar casos de uso. Ao longo do curso outros aspectos da linguagem
sero introduzidos.
Um caso de uso representado por uma elipse. Cada caso de uso
disntigue-se de um outro por um nome que normalmente um verbo
seguido do seu objeto.
Um ator que pode ser uma ou mais funo de usurio representado
por uma figura simples de um indivduo (um boneco-de-palitos).

51
Os atores so conectados a casos de uso por uma associao
representadas por uma linha.
O comportamento associado a cada caso de uso pode ser descrito como
um cenrio. Cada cenrio descreve textualmente o fluxo de eventos ou
seqncia que caracteriza o comportamento do ator e as respostas do
sistema. Um cenrio uma instncia do caso de uso.
Por exemplo num caixa eletrnico bancrio, o caso de uso validar cliente
pode ser descrito pelo seguinte cenrio:
Fluxo de eventos principal: O casos de uso inicia quando o sistema solicita
ao cliente (do banco) a sua senha. O cliente fornece os nmeros atravs do
teclado. O cliente confirma a senha pressionando a tecla entre. O sistema
checa este nmero e verifica se ele vlido.
Fluxo de evento excepcional: O cliente pode cancelar a
transao a qualquer momento pressionando o boto
cancele, reiniciando o caso de uso. No feita nenhuma
mudana na conta do usurio.
Fluxo de evento excepcional: O cliente pode corrigir a senha
a qualquer momento antes de confirmar com a tecla entre.
Fluxo de evento excepcional: Se o cliente fornece um
nmero de senha invlido o caso de uso reiniciado. Se isto
acontecer trs vezes seguidas, o sistema cancela o caso de
uso e bloqueia por at uma hora.
Os casos de uso tambm podem ser descritos de maneira mais estruturada e formal, por
exemplo, usando pr- e ps-condies. Diversas tcnicas e notaes para especificaes
formais permitem descrever o comportamento da funes da aplicao em termos de pr- e
ps-condies. As pr-condies estabelecem as condies que devem estar satisfeita antes
que a funo seja executada pelo sistema, enquanto que as ps-condies determinam o que
deve ser vlido ao final da execuo. Estes estados iniciais e finais do sistema descrevem o
comportamento independente de como ser implementado, isto , quais os algoritmos,
estrutura de dados e linguagem de programao a serem utilizados. As especificaes
formais no so abordadas neste curso.
Os casos de uso podem ainda ser descritos atravs de outros diagramas
UML. Os diagramas de atividades descrevem os diversos estados e as
transies entre cada um deles. Os diagramas de interao permitem
descrever as interaes entre o ator e o componente do sistema que
implementa o caso de uso. Estes diagramas sero estudados mais
adiante no captulo 4.
Veja o exemplo acima especificado atravs de diagramas de estados e
de atividades na seo 4.2.7.

3.9.2 Diagrama de Casos de Uso em UML

A UML permite elaborar diversos diagramas para visualizao, especificao, construo e
documentao de diversas partes do sistema em diversas etapas do ciclo de vida. Existem
cinco tipos de diagramas que permitem modelar aspectos dinmicos do sistema atravs da

52
UML. O diagrama de casos de uso um destes diagramas e pode ser utilizado para
visualizao, especificao e documentao de requisitos do sistema.
A especificao dos requisitos visa descrever o que o sistema deve fazer
para satisfazer as metas dos usurios (requisitos funcionais) e quais
outras propriedades desejvel que o sistema possua (requisitos nofuncionais). Vimos que casos de usos, individualmente, descrevem
requisitos funcionais. Acrescentandos Notas aos diagramas de casos de
uso podemos especificar tambm os requisitos no-funcionais.
Um diagrama de casos de uso contm:
Casos de Uso
Atores
Relacionamentos de dependncia, generalizao e associaes
Podem ser acrescentadas Notas com em qualquer outro diagrama UML.

Para modelar os requisitos de software de um sistema podemos seguir

as seguintes regras.
Estabelea o contexto do sistema identificando os atores (usurios e sistemas
externos) associados a ele.
Para cada ator, considere o comportamento que cada um deles espera ou requer que
o sistema possua, para que as suas metas sejam satisfeitas.
Considere cada um destes comportamentos esperados como casos de uso, dando
nomes para cada um deles.
Analise os casos de uso tentando identificar comportamentos comuns a mais de um
deles. Defina esta parte comum como caso de uso genrico, estabelecendo um
relacionamento de generalizao. Tente identificar outros relacionamentos, como
a dependncia entre casos de uso que incluem o comportamento de outros .
Modele estes casos de uso, atores e seus relacionamentos em diagramas de casos
de uso.
Complemente estes casos de uso com notas que descrevam requisitos nofuncionais.

53
Alm destas regras bsicas, algumas dicas ajudam a construir diagramas mais claros.
D nomes que comuniquem o seu propsito.
Quando existirem relacionamentos, distribua os casos de uso de maneira a
minimizar os cruzamentos de linhas.
Organize os elementos espacialmente de maneira que aqueles que descrevem
comportamento associados fiquem mais prximos.
Use notas para chamar a ateno de caractersticas importantes - as notas no so
apenas para os requisitos no funcionais.
No complique o diagrama, coloque apenas o que essencial para descrever os
requisitos. O diagrama deve ser simples sem deixar de mostrar o que relevante.

54

4. Anlise e Especificao de
Requisitos
Os objetivos deste captulo so:
Definir o que so requisitos de software
Introduzir os objetivos da Engenharia de Requisitos
Apresentar tcnicas de comunicao para obter informaes dos clientes e usurios
Apresentar tcnicas para descrever o domnio, usurios e tarefas.
Especificar requisitos funcionais utilizando Casos de Uso
Especificar requisitos no funcionais

4.1 Engenharia de Requisitos

Vimos que o software parte de um sistema computacional mais abrangente e que a
Anlise de Sistemas a atividade de identificar os problemas do domnio, apresentar
alternativas de solues e o estudo da viabilidade de cada uma delas. Uma vez que se tenha
feito a anlise do sistema computacional, e delimitado o escopo do software, os requisitos
do software devem ser analisados e especificados.
A anlise e especificao de requisitos de software envolve as
atividades de determinar os objetivos de um software e as restries
associadas a ele. Ela deve tambm estabelecer o relacionamento entre
estes objetivos e restries e a especificao precisa do software.
A anlise e especificao dos requisitos de software deve ser vista como
uma sub-atividade da anlise de sistemas. Normalmente ela iniciada
juntamente com a anlise do sistema, podendo se estender aps a
elaborao do documento de especificao do sistema e do
planejamento do desenvolvimento, quando sero refinados os requisitos
do software.
Anlise e especificao so atividades inter-dependentes e devem ser
realizadas conjuntamente. A anlise o processo de observao e
levantamento dos elementos do domnio no qual o sistema ser
introduzido. Deve-se identificar as pessoas, atividades, informaes do
domnio para que se possa decidir o que dever ser informatizado ou
no. Pessoas e as atividades que no sero informatizadas devero ser
consideradas entidades externas ao software.
A especificao a descrio sistemtica e abstrata do que o software
deve fazer, a partir daquilo que foi analisado. Ela apresenta a soluo de
como os problemas levantados na anlise sero resolvidos pelo software
do sistema computacional. Visa descrever de maneira sistemtica quais
as propriedades funcionais so necessrias para resolver o problema do
domnio. A especificao tambm a forma de comunicao sistemtica
entre analistas e projetistas do software.

55
O objetivo da definio dos requisitos especificar o que o sistema
dever fazer e determinar os critrios de validao que sero utilizados
para que se possa avaliar se o sistema cumpre o que foi definido.

4.1.1 O que so requisitos?

Como sistemas computacionais so construdos para terem utilidade no mundo real.
Modelar uma parte do mundo real, o domnio de aplicao uma atividade extremamente
importante para se compreender a necessidade e a importncia do sistema a ser construdo e
definir os requisitos que tornam o sistema til.
Requisitos so objetivos ou restries estabelecidas por clientes e
usurios do sistema que definem as diversas propriedades do sistema.
Os requisitos de software so, obviamente, aqueles dentre os requisitos
de sistema que dizem respeito a propriedades do software.
Um conjunto de requisitos pode ser definido como uma condio ou
capacidade necessria que o software deve possuir (1) para que o
usurio possa resolver um problema ou atingir um objetivo ou (2) para
atender as necessidades ou restries da organizao ou dos outros
componentes do sistema.
Tradicionalmente, os requisitos de software so separados em requisitos
funcionais e no-funcionais. Os requisitos funcionais so a descrio
das diversas funes que clientes e usurios querem ou precisam que o
software oferea. Eles definem a funcionalidade desejada do software. O
termo funo usado no sentido genrico de operao que pode ser
realizada pelo sistema, seja atravs comandos dos usurios ou seja pela
ocorrncia de eventos internos ou externos ao sistema.
So exemplos de requisitos funcionais:
"o software deve possibilitar o clculo dos gastos dirios, semanais, mensais e
anuais com pessoal".
"o software deve emitir relatrios de compras a cada quinze dias"
"os usurios devem poder obter o nmero de aprovaes, reprovaes e
trancamentos em todas as disciplinas por um determinado perodo de tempo.
A especificao de um requisito funcional deve determinar o que se espera que o software
faa, sem a preocupao de como ele faz. importante diferenciar a atividade de
especificar requisitos da atividade de especificao que ocorre durante o design do
software. No design do software deve-se tomar a deciso de quais a funes o sistema
efetivamente ter para satisfazer quilo que os usurios querem.
Requisitos no-funcionais so as qualidades globais de um software,
como manutenibilidade, usabilidade, desempenho, custos e vrias
outras. Normalmente estes requisitos so descritos de maneira informal,
de maneira controversa (por exemplo, o gerente quer segurana mas os
usurios querem facilidade de uso) e so difceis de validar.
So exemplos de requisitos no-funcionais:
"a base de dados deve ser protegida para acesso apenas de usurios autorizados".
"o tempo de resposta do sistema no deve ultrapassar 30 segundo".

56

"o software deve ser operacionalizado no sistema Linux"

"o tempo de desenvolvimento no deve ultrapassar seis meses".

A necessidade de se estabelecer os requisitos de forma precisa crtica na medida que o

tamanho e a complexidade do software aumentam. Os requisitos exercem influncia uns
sobre os outros. Por exemplo, o requisito de que o software deve ter grande portabilidade
(por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho
no seja satisfeito (programas em Java so, em geral, mais lentos).

4.1.2 A Engenharia de Requisitos

Os diversos relacionamento e restries que os requisitos exercem uns sobre os outros so
muito difceis de ser controlados. Principalmente se considerarmos que algumas decises
de design que afetam um ou mais requisitos s sero tomadas mais adiante do
desenvolvimento. Por exemplo, a deciso de implementar em Java pode ser decidida apenas
aps o design da arquitetura. Desta forma, os requisitos precisam ser gerenciados durante
todo o desenvolvimento.
A importncia e complexidade desta atividade levou ao surgimento, no
incio dos anos 90, da Engenharia de Requisitos. O objetivo desta
denominao ressaltar que o processo de definir os requisitos de
software uma atividade extremamente importante e independente das
outras atividades da engenharia de software. Ela requer fundamentao
e processos prprios, e que devem ser planejados e gerenciados ao
longo de todo o ciclo de vida.
Os objetivos da Engenharia de Requisitos podem ser categorizados em
trs grupos principais [Zave]:
Investigao de objetivos, funes e restries de uma aplicao de software
o Ultrapassar as barreiras de comunicao
o Gerar estratgias para converter objetivos vagos em propriedades ou
restries especficas
o Compreender prioridades e graus de satisfao
o Associar requisitos com os vrios agentes do domnio
o Estimar custos, riscos e cronogramas
o Assegurar completude
Especificao do software
o Integrar representaes e vises mltiplas
o Avaliar estratgias de solues alternativas que satisfaam os requisitos
o Obter uma especificao completa, consistente e no ambgua
o Validar a especificao - verificar que ela satisfaz aos requisitos
o Obter especificaes que sejam apropriadas para as atividades de design e
implementao
Gerenciamento da evoluo e das famlias do software
o Reutilizao de requisitos durante o processo de evoluo
o Reutilizao de requisitos no desenvolvimento de software similares
o Reconstruo de requisitos

57
A Engenharia de Requisitos deve envolver a documentao das funes, do desempenho,
interfaces externas e internas e atributos de qualidade do Software.
Esta rea inerentemente abrangente, interdisciplinar e aberta. Ela lida
com a descrio de observaes do mundo real atravs de notaes
apropriadas.
Os benefcios da Engenharia de Requisitos so:
Concordncia entre desenvolvedores, clientes e usurio sobre o trabalho a ser feito e
quais os critrios de aceitao do sistema.
Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas
e equipamentos)
Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
Atingir os objetivos com o mnimo de desperdcio
Uma boa especificao de requisitos deve ser:
Clara e no-ambgua
Completa
Correta
Compreensvel
Consistente
Concisa
Confivel
(Veja mais em Dorfman, Merlin - Requirements Engineering)

4.1.3 Tcnicas de levantamento de requisitos

Um dos objetivos da Engenharia de Requisitos ultrapassar barreiras de comunicao entre
os clientes e usurios e os analistas para que os requisitos possam capturados e modelados
corretamente
Dentre as tcnicas mais importantes para a comunicao podemos citar
trs:
Entrevistas
Observao in loco
Encontros
Estas trs tcnicas so complementares e podem todas ser usadas numa mesma anlise de
requisitos. A entrevista normalmente a primeira tcnica utilizada. Analistas entrevistam
clientes para definir os objetivos gerais e restries que o software dever ter. A entrevista
deve ser feita de forma objetiva visando obter o mximo de informaes do cliente.
Diversas sees de entrevistas podem ser marcadas.
Na observao in loco os analista devem estar inseridos na rotina de
trabalho da organizao tentando entender e descrever as principais
atividades que so realizadas. Na observao devem ser identificadas
quais as atividades podem ser automatizadas, quem so os potenciais
usurios, quais tarefas eles querem realizar com a ajuda do novo

58
sistema, etc. A observao deve ser complementada com entrevistas
especficas com os futuros usurios.
Os encontros so reunies envolvendo analistas, clientes e usurios
destinadas exclusivamente ao levantamento de informaes, descrio
dos problemas atuais e de metas futuras. Os encontros devem ser
realizados em um local neutro (fora da organizao) e normalmente
duram poucos alguns dias. Nos encontros as informaes que vo sendo
levantadas vo sendo afixadas em paineis na sala de encontro para que
possam ser analisadas e validadas pelos clientes e usurios. Ao final do
encontro os analistas devem elaborar um relatrio descrevendo os
requisitos analisados.

4.1.4 Modelos de documentos de especificao de

requisitos
O resultado final da anlise e especificao de requisitos e das outras atividades da fase de
defino devem ser apresentados aos clientes para que eles possam valid-lo. Este
documento oferece a concordncia entre clientes, analistas e desenvolvedores sobre o que
deve ser desenvolvido. utilizando este documento que as atividades da fase de
desenvolvimento (design e programao) sero validadas.
Cada desenvolvedor utiliza um modelo especfico para elaborar este
documento. A sua estrutura muitas vezes depende do mtodo que est
sendo utilizado. Em linhas gerais este modelo deve ser basicamente
textual, utilizando o mnimo de termos tcnicos, e ilustrados como
modelos grficos que demonstrem mais claramente a viso que os
analistas tiveram dos problemas e dos requisitos para o futuro sistema.
Vamos apresentar a seguir dois modelos de documentos encontrados na
literatura. Estes modelos descrevem no apenas a especificao dos
requisitos, mas os resultados do estudo de viabilidade e o processo de
desenvolvimento.
Pressman apresenta o seguinte documento de especificao de
requisitos de software:
I. Introduo
1. Referncias do Sistema
2. Descrio Geral
3. Restries de projeto do software
II. Descrio da Informao
1. Representao do fluxo de informao
a. Fluxo de Dados
b. Fluxo de Controle
2. Representao do contedo de informao
3. Descrio da interface com o sistema
III Descrio Funcional
1. Diviso funcional em parties
2. Descrio funcional

59
a. Narativas
b. Restries/limitaes
c. Exigncias de desempenho
d. Restries de projeto
e. Diagramas de apoio
3. Descrio do controle
a. Especificao do controle
b. Restries de projeto
IV. Descrio Comportamental
1. Estados do Sistema
2. Eventos e aes
V. Critrios de Validao
1. Limites de desempenho
2. Classes de testes
3. Reao esperada do software
4. Consideraes especiais
VI. Bibliografia
VII Apndice
Uma proposta alternativa a de Farley. De acordo com ele, um
documento de especificao de requisitos deve possui as seguintes
sees:
Viso geral do produto e Sumrio
Ambientes de desenvolvimento, operao e manuteno
Interfaces Externas e Fluxo de Dados
Requisitos Funcionais
Requisitos de Desempenho
Tratamento de Excees
Prioridades de Implementao
Antecipao de mudanas e extenses
Dicas e diretrizes de Design
Critrios de aceitao
ndice Remissivo
Glossrio

4.2 Especificando Requisitos utilizando

Casos de Uso
Aps saber quais as tarefas associadas a cada papel de usurio, hora de elaborar os casos
de uso (use cases) que permitem definir as funes de aplicao que o sistema dever
oferecer para o usurio. Os casos de uso podem ser utilizadas durante a anlise e
especificao dos requisitos para descrever a funcionalidade do sistema.
Os casos de uso foram definidos como parte da metodologia de
Jacobson: Object-oriented Analysis and Design - The User Case Driven
Approach. A linguagem de modelagem UML (Unified Modeling Language)
apresenta notaes para a representao de casos de uso.

60
Um caso de uso especifica o comportamento do sistema a ser
desenvolvido sem, no entanto, especificar com este comportamento
ser implementado. Os comportamentos descrevem as funes da
aplicao que caracterizam a funcionalidade do sistema. Um caso de uso
representa o que o sistema faz e no como o sistema faz,
proporcionando uma viso externa e no interna do sistema.
Cada caso de uso define um requisito funcional do sistema. Por
exemplo, num sistema bancrio, consulta de saldo, emprstimos e
saques de dinheiro so exemplos de casos de uso.
O caso de uso descreve um conjunto de seqncias de aes que o
sistema desempenha para produzir um resultado esperado pelo usurio.
Cada seqncia representa a interao de entidades externas e o
sistema. Estas entidades so chamadas de atores e que podem ser
usurios ou outros sistemas. No caso de usurios, um ator representa na
verdade uma funo de usurios.
Os casos de uso podem ser compostos por outros casos de uso mais
especficos. Esta estrutura deve estar em conformidade com o
particionamento do sistema em sub-sistemas. Desta forma tanto
possvel descrever casos de uso que aplicam-se ao sistema global,
quanto casos que so especficos para cada uma das partes do sistema.
Casos de uso tambm podem ser especializados, por exemplo uma
consulta pode ser especializada em consulta de saldo e consulta de
extrato, que por sua vez podem ser especializados, cada um , em
consultas a conta-corrente ou a conta-poupana.
Ao definir os requisitos funcionais, o caso de uso define o
comportamento, as respostas esperadas e os casos de testes que
devem validar a implementao do sistema.

4.2.1 A representao de casos de uso usando UML

A notao UML ser utilizada neste curso como linguagem de especificao para a maioria
das atividades do ciclo de vida do sistema. A partir de agora vamos introduzir esta notao
necessria para representar casos de uso. Ao longo do curso outros aspectos da linguagem
sero introduzidos.
Um caso de uso representado por uma elipse. Cada caso de uso
disntigue-se de um outro por um nome que normalmente um verbo
seguido do seu objeto.
Um ator que pode ser uma ou mais funo de usurio representado
por uma figura simples de um indivduo (um boneco-de-palitos).
Os atores so conectados a casos de uso por uma associao
representadas por uma linha.
O comportamento associado a cada caso de uso pode ser descrito como
um cenrio. Cada cenrio descreve textualmente o fluxo de eventos ou
seqncia que caracteriza o comportamento do ator e as respostas do
sistema. Um cenrio uma instncia do caso de uso.

61
Por exemplo num caixa eletrnico bancrio, o caso de uso validar cliente
pode ser descrito pelo seguinte cenrio:
Fluxo de eventos principal: O casos de uso inicia quando o sistema solicita
ao cliente (do banco) a sua senha. O cliente fornece os nmeros atravs do
teclado. O cliente confirma a senha pressionando a tecla entre. O sistema
checa este nmero e verifica se ele vlido.
Fluxo de evento excepcional: O cliente pode cancelar a
transao a qualquer momento pressionando o boto
cancele, reiniciando o caso de uso. No feita nenhuma
mudana na conta do usurio.
Fluxo de evento excepcional: O cliente pode corrigir a senha
a qualquer momento antes de confirmar com a tecla entre.
Fluxo de evento excepcional: Se o cliente fornece um
nmero de senha invlido o caso de uso reiniciado. Se isto
acontecer trs vezes seguidas, o sistema cancela o caso de
uso e bloqueia por at uma hora.
Os casos de uso tambm podem ser descritos de maneira mais estruturada e formal, por
exemplo, usando pr- e ps-condies. Diversas tcnicas e notaes para especificaes
formais permitem descrever o comportamento da funes da aplicao em termos de pr- e
ps-condies. As pr-condies estabelecem as condies que devem estar satisfeita antes
que a funo seja executada pelo sistema, enquanto que as ps-condies determinam o que
deve ser vlido ao final da execuo. Estes estados iniciais e finais do sistema descrevem o
comportamento independente de como ser implementado, isto , quais os algoritmos,
estrutura de dados e linguagem de programao a serem utilizados. As especificaes
formais no so abordadas neste curso.
Os casos de uso podem ainda ser descritos atravs de outros diagramas
UML. Os diagramas de atividades descrevem os diversos estados e as
transies entre cada um deles. Os diagramas de interao permitem
descrever as interaes entre o ator e o componente do sistema que
implementa o caso de uso. Estes diagramas sero estudados mais
adiante no captulo 5.
Veja o exemplo acima especificado atravs de diagramas de estados e
de atividades na seo 5.2.7.

4.2.3 Diagrama de Casos de Uso em UML

A UML permite elaborar diversos diagramas para visualizao, especificao, construo e
documentao de diversas partes do sistema em diversas etapas do ciclo de vida. Existem
cinco tipos de diagramas que permitem modelar aspectos dinmicos do sistema atravs da
UML. O diagrama de casos de uso um destes diagramas e pode ser utilizado para
visualizao, especificao e documentao de requisitos do sistema.
A especificao dos requisitos visa descrever o que o sistema deve fazer
para satisfazer as metas dos usurios (requisitos funcionais) e quais
outras propriedades desejvel que o sistema possua (requisitos nofuncionais). Vimos que casos de usos, individualmente, descrevem

62
requisitos funcionais. Acrescentandos Notas aos diagramas de casos de
uso podemos especificar tambm os requisitos no-funcionais.
Um diagrama de casos de uso contm:
Casos de Uso
Atores
Relacionamentos de dependncia, generalizao e associaes
Podem ser acrescentadas Notas com em qualquer outro diagrama UML.

Para modelar os requisitos de software de um sistema podemos seguir

as seguintes regras.
Estabelea o contexto do sistema identificando os atores (usurios e sistemas
externos) associados a ele.
Para cada ator, considere o comportamento que cada um deles espera ou requer que
o sistema possua, para que as suas metas sejam satisfeitas.
Considere cada um destes comportamentos esperados como casos de uso, dando
nomes para cada um deles.
Analise os casos de uso tentando identificar comportamentos comuns a mais de um
deles. Defina esta parte comum como caso de uso genrico, estabelecendo um
relacionamento de generalizao. Tente identificar outros relacionamentos, como
a dependncia entre casos de uso que incluem o comportamento de outros .
Modele estes casos de uso, atores e seus relacionamentos em diagramas de casos
de uso.
Complemente estes casos de uso com notas que descrevam requisitos nofuncionais.
Alm destas regras bsicas, algumas dicas ajudam a construir diagramas mais claros.
D nomes que comuniquem o seu propsito.
Quando existirem relacionamentos, distribua os casos de uso de maneira a
minimizar os cruzamentos de linhas.

63

Organize os elementos espacialmente de maneira que aqueles que descrevem

comportamento associados fiquem mais prximos.
Use notas para chamar a ateno de caractersticas importantes - as notas no so
apenas para os requisitos no funcionais.
No complique o diagrama, coloque apenas o que essencial para descrever os
requisitos. O diagrama deve ser simples sem deixar de mostrar o que relevante.

4.3 Tcnicas complementares para anlise

de requisitos
Definir casos a partir do nada pode ser bastante difcil. Antes de
comear a pensar em casos de uso o analista pode descrever cenrios
com situaes do domnio. Estes cenrios contm informaes que
podem ser extradas mais detalhadamente com o objetivo de detalhar
os cenrios. Alm dos cenrios, a anlise do perfil dos usurio e das
tarefas que eles executam permitem um maior conhecimento do
domnio, possibilitando uma melhor especificao dos requisitos.

4.3.1 Cenrios
Do ponto de vista de usabilidade, o desenvolvimento de um novo sistema implica na
transformao das tarefas e prticas atuais dos usurios e da organizao. Conhecer a
situao atual e antecipar o impacto que um novo sistema deve ter fundamental para o seu
sucesso. Isso ocorre porque quando se introduz novas tecnologias, parte do contexto de
tarefa de uma organizao alterado. Nessa reengenharia, novas tarefas e prticas so
incorporadas enquanto que outras so eliminadas.
O levantamento de informaes sobre as tarefas e os usurios pode ser
melhor realizado quando os analistas procuram descrever situaes do
processo de trabalho. Os mtodos baseados em cenrios consistem de
uma coleo de narrativas de situaes no domnio que favorecem o
levantamento de informaes, a identificao de problemas e a
antecipao das solues. Cenrios so uma maneira excelente de
representar, para clientes e usurios, os problemas atuais e as
possibilidades que podem surgir.
Os cenrios tm como foco as atividades que as pessoas realizam nas
organizaes possibilitando uma perspectiva mais ampla dos problemas
atuais onde o sistema ser inserido, explicando porque ele necessrio.
Eles proporcionam um desenvolvimento orientado a tarefas
possibilitando maior usabilidade do sistema.
No objetivo dos cenrios oferecer uma descrio precisa, mas
provocar a discusso e estimular novos questionamentos. eles permitem
tambm documentar o levantamento de informaes a respeito dos
problemas atuais, possveis eventos, oportunidades de aes e riscos.
Por sua simplicidade, cenrios so um meio de representao de fcil
compreenso para os clientes e usurios envolvidos (muitas vezes de

64
formao bastante heterognea) que podem avaliar, criticar e fazer
sugestes, proporcionando a reorganizao de componentes e tarefas
do domnio. Cenrios oferecem um "meio-intermedirio" entre a
realidade e os modelos que sero especificados possibilitando que
clientes, usurios e desenvolvedores participem do levantamento das
informaes e especificao dos requisitos. Em resumo, os cenrios
permitem compreenso dos problemas atuais pelos analistas e
antecipao da situao futura pelo clientes e desenvolvedores.
Elaborando Cenrios
Como toda atividade de anlise e especificao de requisitos, a descrio do domnio
atravs de cenrios requer tcnicas de comunicao e modelagem.
A descrio de cenrios deve ser apoiada pelas trs tcnicas de
comunicao vistas anteriormente. Antes de descrever os cenrios, os
analistas devem entrevistar clientes para entender os problemas e
requisitos iniciais. A entrevista com usurios permite que cada um
descreva as suas tarefas e os problemas associados a cada uma delas. A
observao direta in loco fundamental para que os analistas possam
descrever a situao de uso como ela realmente vem ocorrendo na
prtica.
Aps a elaborao dos cenrios, clientes, usurios e analistas podem
participar de encontros para que possam discutir cada um destes
cenrios. Eles podem ser afixados em quadros na parede onde os
participantes possa analis-los e fazer comentrios, possivelmente
afixando pequenos pedaos de papel a cada uma das cenas.
Cenrios podem ser descritos em narrativas textuais ou atravs de
storyboards. As narrativas textuais podem ser descritas livremente,
identificando os agentes e as aes que eles participam. possvel
utilizar notaes para descrever roteiros de cinemas ou notaes mais
precisas como aquelas utilizadas pela Inteligncia Artificial para
representao de conhecimento.
Uma tcnica que est bastante relacionada com cenrios, por permitir
descrever situaes de uso, o storyboarding. Essa tcnica envolve a
descrio atravs de quadros com imagens que ilustram as situaes do
domnio. Cada quadro deve apresentar a cena que descreve a situao,
os atores e as aes que cada um deve desempenhar. Abaixo de cada
quadro devem estar descritas aes que os atores desempenham. Os
storyboards so bastante utilizados em cinemas como forma de
comunicao entre roteiristas, diretores, atores e tcnicos.
Existem ferramentas computacionais que podem ser utilizadas para a
descrio de cenrios como o Scenario's Browser [Rosson 99].
Exemplos de cenrios
Como exemplo vamos considerar o domnio de uma locadora de fitas de vdeo.

65
Cena 1: Cliente procura uma fita com uma certa atriz
Agentes: Cliente, Atendente, Balconista
Aes:
Cliente entra na loja e dirige-se at a atendente.
Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Atendente: - Algum especfico?
Cliente: - No, mas que no seja policial ou ao.
Atendente: Voc sabe o nome dela?
Cliente: No.
A atendente pergunta balconista.
Atendente: - Voc sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. um nome bem complicado. S sei que comea com G e o
sobrenome algo parecido com Paltrow.
Cliente: isto mesmo.
A atendente ento procura no fichrio de atrizes as que comeam com G. No
encontra nenhum nome parecido com o que a balconista falou. Ela ento lembra-se
de consultar uma revista especializada com os ganhadores do Oscar 99 e l descobre
o nome correto da atriz. Entretanto, no existe realmente ficha alguma com os
filmes estrelados por esta atriz. O fichrio est desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime
Perfeito e Seven e mostra-os ao cliente. O cliente recusa-se dizendo que no gosta
do gnero destes filmes e pergunta pelo filme vencedor do Oscar.
A atendente responde: - Shakespeare Apaixonado? Ainda no saiu em vdeo.
Cena 2: O cliente procura por filmes de um certo gnero
Agentes: Cliente, Atendente, Balconista
Aes:
Cliente: - Eu gostaria de comprar um filme de ao.
Atendente: - Ns apenas alugamos.
Cliente: - Tudo bem. Ento, por favor, me d algumas dicas de filmes de ao.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dvida se j
assistiu outros trs. Ele tambm pergunta atendente se os outros dois filmes so
bons. Aps conversar durante alguns minutos com a atendente que entende muito do
gnero, decide ficar com seis fitas. A atendente encaminha o cliente balconista
para calcular o valor da locao e o prazo de devoluo. Aps consultar as tabelas
de preos e prazos, a balconista apresenta trs planos de pagamento.
Balconista: - Se voc devolver em um dia, paga apenas R$ 6,00. Se devolver em
seis dias paga R$ 12,00 e se devolver em uma semana paga R$ 15,00. Aps este
prazo paga mais R$ 2,00 por fita, por dia.
Cena 3: Cliente procura por filme usando o sistema de consulta
Agentes: Cliente e Sistema de Consulta
Aes:
Joo gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e,
chegando l, utiliza um sistema de consulta. Ele no lembra o ttulo nem o diretor,
mas sabe que se passava na guerra do Vietn e lembra bastante da trilha sonora.

66
Utilizando o sistema ele solicita as opes de filmes de guerra. Os sistema oferece a
ele as possibilidades de escolher os filmes por local da guerra ou por poca. Joo
escolhe a sua opo (guerra) e obtem uma lista com dezenas de filmes sobre o
vietnam. Ele pode organizar esta lista, por diretor, atores e ttulo. Na tela do sistema
aparecem a ilustrao com o cartaz de divulgao do filme e uma opo para ele
visualizar o trailler. O sistema, entretanto, no possibilita ele ouvir a trilha sonora.
Aps analisar algumas opes ele finalmente encontra o filme
desejado, mas uma informao na tela do sistema indica que o
filme est alugado. Joo quer saber quando o filme ser devolvido,
mas esta informao no consta no sistema. Ele entretanto pode
reservar e o sistema enviar para ele um e-mail avisando quando
o filme estiver disponvel. Ele sai da loja pensando "Que tempo
perdido. Seria melhor que eu pudesse consultar o sistema de
casa".

4.3.2 Questionamento Sistemtico

A descrio de informaes do domnio atravs de narrativas s
efetivamente realizada se o processo de compreenso por parte dos
analistas e projetista for realizado de maneira sistemtica [J. Carroll et
al. 94]. O questionamento sistemtico uma tcnica que permite ao
analista obter, a partir dos cenrios, uma rede de proposies na qual
identifica-se agentes (atores), aes (processos de casos de uso),
e objetos (informaes).
O questionamento sistemtico uma tcnica psico-lingustica que
permite a psiclogos e lingistas examinar o contedo e a estrutura de
informaes contidas numa narrativa. Uma narrativa um sumrio de
um conjunto de eventos e aes envolvendo agentes e objetos do
mundo. Nem todas as informaes integrantes do contexto so
passadas atravs da narrativa. Muitas dessas informaes so inferidas
do conhecimento cultural de cada indivduo. Outras, entretanto,
precisam ser obtidas diretamente na fonte, isto , junto ao autor da
narrativa. Essa tcnica foi desenvolvida para se entender melhor o
processo de compreenso de estrias em narrativas. O objetivo
compreender tudo o que envolve o contexto daquilo que est sendo
passado na narrativa.
Aplicando essa tcnica no processo de anlise de domnios, os
especialistas devem descrever em narrativas seu conhecimento do
domnio. Entretanto, esse conhecimento muito mais abrangente. O
questionamento sistemtico permite obter todo o conhecimento que
est alm do que foi comunicado na narrativa. Assim, analistas e
projetista podem utilizar essa tcnica para adquirir mais eficazmente
conhecimento sobre o domnio e inferir objetos e interaes que no
esto descritos na narrativa. Isto ocorre usando-se cada sentena ou
afirmao da narrativa como ponto de entrada na complexidade do
problema.

67
Nessa tcnica, cada questo uma ponte entre uma idia e outra. Uma
resposta a uma questo sobre um componente da narrativa revela
outras conexes que so crticas para o seu entendimento. Realizando,
sistematica e exaustivamente muitos tipos de questes sobre
componentes da narrativa e iterativamente fazendo perguntas sobre as
respostas geradas, o analista elabora um mapa conceitual (rede de
proposies) que representa as estruturas do conhecimento do domnio.
Os passos do mtodo consistem de:
1. Gerao do cenrio - as narrativas que compe o cenrio devem ser decritas
pelo especialista no domnio. O analista pode motiv-lo fazendo perguntas como
num processo convencional de entrevista (questes de elicitao do cenrio).
2. Elaborao da rede de proposies - as narrativas devem ser simplificadas e
expressas atravs de proposies.
3. Anlise - a partir das proposies pode-se determinar as tarefas (aes e objetos)
e usurios (agentes das aes).
4. Questionamento sistemtico - novas proposies podem ser elaboradas atravs
de questes que so feitas sobre elementos das proposies anteriores, num
processo iterativo.
Nos passos iniciais obtem-se informaes sobre agentes, interaes e objetos abstratos do
domnio. Usando a tcnica, pode-se chegar a um conhecimento mais profundo do domnio
que permite aos analistas e projetista a elaborao de modelos funcionais do sistema.
Exemplo
Considere o seguinte cenrio sobre um caixa eletrnico.
Questo de elicitao do cenrio:
Como posso sacar R$ 100,00 do caixa eletrnico?
Cenrio:
Primeiro ponha o seu carto do banco no caixa eletrnico, digite a sua senha e
pressione o boto "saque rpido". Depois pegue o dinheiro.
As duas sentenas do cenrio acima contm quatro proposies:
CLIENTE -- pe -- CARTO
CLIENTE -- digita -- SENHA
CLIENTE -- pressiona -- BOTO-DE-SAQUE-RPIDO
CLIENTE -- pega -- DINHEIRO
A partir dessas proposies, o analista determina que o carto e o cliente so agentes de
aes. Numa anlise voltada para a elicitao de requisitos da interao, seria determinado
como usurio do sistema, o cliente. A aes so portanto: digita, pressiona e pega. So
objetos da interao a senha, o boto e o dinheiro. Outros objetos so o caixa eletrnico e o
carto. preciso determinar que tipo de objetos so esses. Uma outra dvida a respeito do
carto ser objeto ou agente.
Obviamente, como esse exemplo bastante simples e a aplicao
tambm muito conhecida, parece desnecessrio obter mais
conhecimentos a respeito. Entretanto, como o objetivo aqui
exemplificar a tcnica, mostraremos como pode-se questionar a respeito
dessa aplicao.

68
O analista deve ento realizar uma srie de questes sobre as
proposies. Nesse questionamento o analista precisa determinar qual o
relacionamento entre a resposta e a proposio que originou a pergunta.
As questes da categoria por que, visam responder "razes" (metas) e
"causas" a respeito de eventos da narrativa. As questes da categoria
como oferecem maiores detalhes a respeito de determinados eventos,
permitindo determinar sub-tarefas e maiores detalhes sobre a interao.
Questes da categoria o que podem ser feitas sobre objetos, e revelam
atributos e hieraquias de objetos. Perguntas de verificao podem ser
feitas para se saber se as proposies esto sendo entendidas
corretamente. As perguntas de verificao so as que tm resposta
sim/no. Uma taxonomia mais completa ainda est sendo pesquisada
pelos autores do mtodo.
Continuando o exemplo anterior a tabela abaixo descreve uma seo de
questionamento sistemtico:
Questes "por que"
Por que o carto entra no caixa eletrnico?
_ Para iniciar. (evento conseqente)
_ E ento a mquina saber quem o cliente. (estado conseqente)
Por que o cliente digita sua senha?
_ Para provar que ele o usurio autorizado. (meta)
Por que o cliente pressiona o boto de saque rpido?
_ Porque o boto para saques de R$ 100,00 (critrio de descriminao).
_ Para evitar a digitao (cenrio alternativo).
_ Porque ele est com pressa (causa)
Questes "como"
Como o cliente pe o carto?
_ O cliente tira o carto de sua bolsa e
_ insere no local apropriado no caixa eletrnico..
Como o cliente digita a senha?
_ Pressionando os botes adequados.
Como o cliente pressiona o boto de saque rpido?
_ Colocando o seu dedo nele.
Questes "o que"
O que um boto de saque rpido?
_ um tipo de boto que se pode pressionar.
O que um boto?
_ um dispositivo de controle no painel do caixa eletrnico.
Observe que se o analista estivesse utilizando essa tcnica para num mtodo orientado a
objetos, outras questes poderiam ser realizadas com outros objetivos de acordo com as

69
necessidades do mtodo, como, por exemplo, para determinar classes e hierarquia de
classes.
Aps os cenrios estarem desenvolvidos, os analistas devem trabalhar
em conjunto com os usurios para avali-los e refin-los. Isto pode ser
feito, por exemplo, colocando-se posters numa sala pela qual os
usurios podem circular livremente e observar os diversos cenrios.
Cada cenrio deve apresentar quadros (desenhos, grficos, fotografias,
etc.), usando storyboards por exemplo, e uma descrio narrativa da
tarefa. Os usurios, munidos de papeis e lpis, podem fazer anotaes
(crticas e sugestes) e anex-las a cada poster.

Consideraes finais sobre cenrios

O resultado da modelagem atravs de cenrios uma base para a compreenso de quem so
os usurios, quais a tarefas envolvidas e quais funes a interface e a aplicao devem
prover, de maneira que, j se possa ter meios de garantir a usabilidade do sistema.
A idia de cenrios em anlise no est necessariamente associada
tcnica de questionamento sistemtico. Os cenrios so extremamente
teis para descrio do domnio. A tcnica sistematiza o processo de
compreenso do conhecimento adquirido.
Os mtodos em geral, e esse no deve fugir regra, devem ser usados,
no como uma camisa-de-fora que limite o processo de anlise, mas
como ferramentas que orientam os analistas e aumentam sua
capacidade intelectual.

4.4 Anlise de Usurios

Para que o sistema seja construdo como uma ferramenta de apoio s atividades de usurios
no domnio de aplicao, preciso conhecer quem so os usurios e quais as suas
necessidades, isto quais tarefas eles necessitam realizar. A anlise de usurios deve
determinar quem eles so e quais tarefas eles normalmente fazem no domnio. Ela envolve
a descrio dos diferentes papis de usurios e qual o conhecimento, capacidade e cultura
possuem os futuros usurios do sistema.

4.4.1 Anlise de Perfis de Usurios

A anlise do perfil dos diversos usurios do sistema descreve as vrias caractersticas que
podem influenciar as decises dos projetistas no desenvolvimento do sistema. Os objetivos
so assegurar que certas propriedades do sistema estejam adequadas ao conhecimento,
cultura e capacidades do usurio, e que potenciais deficincias sejam levadas em
considerao. Por exemplo, para um software de acompanhamento de pacientes em
hospital, certos termos especficos da medicina devem ser includos nas telas do sistema e
devem ser evitados termos tcnicos de informtica ( fornea informaes patolgicas ao
invs de entrar dados da doena). Para usurios com alguma deficincia fsica ou motora,
elemento da interface devem ser modificados, como por exemplo, tela de maior tamanho e
letras maiores para deficientes visuais.

70
Os perfil do usurio pode ser analisado atravs de formulrios do tipo:

Perfil do Usurio

Nome do Sistema:
____________________________________________________________________
Funo do Usurio:
___________________________________________________________________
Conhecimento e Experincia do Usurio
Nvel educacional
Lngua Nativa
Nvel de leitura e expresso
( ) Ensino fundamental
( ) Portugus
( ) Ensino mdio
( ) Ingls
( ) Excelente
( ) Graduao
( ) outra:
( ) Bom
( ) Ps-Graduao
___________________
( ) Regular
( ) Ruim
Experincia com
Experincia com sistema
Conhecimento sobre o
computadores
similar
domnio
( ) Iniciante
( ) Utiliza bastante um similar ( ) Elementar
( ) Intermedirio
( ) J utilizou um similar
( ) Intermedirio
( ) Experiente
( ) Nunca utilizou um similar ( ) Especialista no domnio
Caractersticas Fsicas
Manipulao
Deficincias
( ) Canhoto
( ) Auditiva
( ) Destro
( ) Visual
( ) Ambidestro
( ) Corporal
( ) Vocal
O perfil deve dar as informaes necessrias que os desenvolvedores
precisam para tomar as suas decises. A anlise do perfil pode ser
adaptada de acordo com as caractersticas do sistema e com as
necessidades de analistas e desenvolvedores. Por exemplo, pode ser
interesse dos designers saber se os usurios tm algumas experincia
com interfaces grficas e qual o padro (Windows, Motif, Macintosh,
etc.) eles esto acostumados a utilizar.

4.4.2 Papis de Usurios

O papel (ou funo ) especfico de cada usurio definido pelas tarefas que eles realizam.
Numa organizao, as pessoas trabalham juntas, de maneira estruturada. A estrutura da
organizao define relacionamentos entre as pessoas. A implicao imediata dos diferentes
papis de cada usurio so as diferentes tarefas que eles iro realizar. Algumas tarefas
podem ser comuns a diferentes papis de usurios, enquanto outras podem ser exclusivas de
papis especficos.
O conceito de papel de usurio permite abstrairmos as caractersticas
especficas de um usurio e enfatizar nas diferentes necessidades
associadas a funo que ele exerce. Para cada papel devemos associar
um conjunto de funes, como veremos mais adiante.

71
No domnio do departamento de informtica da UFRN podemos
identificar como papis de usurios: secretrio do departamento, chefe,
coordenador de graduao, secretrio da coordenao, coordenador de
ps-graduao, professor, aluno, funcionrio de administrao de
laboratrios e usurio externo.

4.5 Anlise e Modelagem de Tarefas

Os cenrios permitem o levantamento e a descrio mais global das informaes, das
tarefas e dos problemas do domnio. O perfil de usurio descreve as caractersticas de
usurios em termo de conhecimento, cultura, capacidades e limitaes. A anlise de tarefas
visa determinar quais as atividades que os usurios (ou cada papel de usurio) devem
realizar. Esta informao essencial para se especificar os requisitos funcionais,
determinando a funcionalidade do software. Para que o sistema possa ser construdo para
que estes problemas sejam resolvidos, ele deve ser uma ferramenta auxiliar na realizao
das tarefas de cada usurio.
Uma tarefa , genericamente, uma atividade na qual um ou mais
agentes tentam atingir uma meta especificada, atravs de uma
mudana de estado em uma ou mais entidades do mundo. Num domnio
de aplicao, as tarefas so as atividades que modificam estados de
elementos deste domnio. A construo de um sistema computacional
em um certo domnio tem por objetivo apoiar a realizao de algumas
destas atividades. Durante o processo de anlise, deve-se determinar
quais as do domnio e identificar quais delas podem ser auxiliadas pelo
sistema.
A anlise e modelagem de tarefas visa descrever as principais as tarefas
que cada usurio do sistema ter de realizar para que os projetistas
possam elaborar quais funes o sistema deve oferecer para que elas
possam ser desempenhadas. Estas tarefas so descritas em termos de
metas e um planejamento de possveis atividades necessrias para
atingi-las. As tarefas podem ser descritas a partir das informaes
obtidas nos cenrios e devem ser agrupadas por papis de usurio.
A anlise de tarefas pode ser utilizadas nas diversas fases do ciclo de
vida do software. Na fase de anlise de requisitos ela pode ser utilizada
para identificar problemas na maneira de como as tarefas vm sendo
realizadas. Os modelos de tarefas tambm podem descrever quais
tarefas podem ser realizadas com o auxlio do sistema e como os
usurios gostariam que ela fosse realizada. A anlise de tarefa tambm
utilizada na avaliao do sistema para se determinar se como os
usurios esto utilizando o sistema e se os objetivos foram atingidos.
Nestes casos, a anlise de tarefas ajuda ao projetista da interface ter
uma viso da aplicao sob a perspectiva do usurio, isto , um modelo
das tarefas do usurio quando executando sesses da aplicao.

72

4.5.1 Modelo de tarefas como base para a especificao

de requisitos funcionais
A anlise e modelagem de tarefas pode ser utilizada como base para a especificao de
requisitos funcionais. Para isto preciso descrever as metas associadas a cada papel de
usurio, que permitiro saber o que os usurio querem.
Resultados da psicologia cognitiva mostram que as pessoas realizam
tarefas estabelecendo metas e elaborando um plano para cada uma
delas. O planejamento consiste numa decomposio hierrquica de
metas em sub-metas at que elas possam ser atingidas por
operaes. O plano ou mtodo , portanto, uma estrutura de submetas e operaes para se atingir um certa meta. As operaes
correspondem a aes bsicas humanas, isto , aquelas que qualquer
pessoa pode e sabe como realizar. So exemplos de operaes escrever
uma palavra ou frase, ler uma informao, falar uma palavra ou frase,
andar, relembrar, mover um objeto, pressionar um boto de controle e
vrias outras.
Por exemplo, suponhamos que uma pessoa tem como meta avisar a um
amigo, atravs de uma carta, que sua filha nasceu. Para atingir seu
objetivo a pessoa deve estabelecer duas sub-metas: Escrever a carta e
Coloc-la no correio. A sub-meta escrever carta pode ser atingida pelo
mtodo: Conseguir papel e lpis e Escrever mensagem. Escrever
mensagem j pode ser considerada uma operao, enquanto que
conseguir papel e lpis requer um novo planejamento que determine as
seguintes operaes: ir at o escritrio, abrir o armrio, pegar o papel e
o lpis, lev-los at a mesa.
O gro de refinamento do que podemos considerar com sendo uma
operao bastante subjetivo. Vai depender das dificuldades de quem
realiza o plano. Na prtica o plano necessrio quando a pessoa que vai
realizar as aes no sabe ainda qual o mtodo. Com a experincia o
mtodo torna-se automtico e podemos considerar uma sub-meta como
uma operao
Na utilizao de um sistema computacional, os usurios realizam tarefas
com o objetivo de atingir certas metas. Uma meta um determinado
estado do sistema ou de objetos do sistema ao qual o usurio quer
chegar. Ao estabelecer a meta o usurio deve realizar um planejamento
decompondo a meta em sub-metas at que ele saiba que existe uma
determinada funo do sistema que permita que sua meta seja atingida.
O caso agora um pouco diferente do planejamento anterior, pois no
o usurio quem vai realizar a operao desejada, mas o sistema. A
decomposio deve ocorrer at que ele identifique que o sistema tem
uma determinada funo que quando executada realiza a operao
necessria para que sua meta seja atingida. Chamamos estas operaes
que o sistema executa para satisfazer as metas do usurio de funo
da aplicao. O conjunto de funes da aplicao determina a
funcionalidade do sistema.

73
Vejamos um exemplo. Suponha que o usurio esteja escrevendo uma
carta utilizando um editor de texto e tenha como meta formatar um
documento.Para atingir esta meta ele estabelece as seguintes submetas: Formatar pgina, Formatar pargrafos, Formatar fontes. Para
cada uma destas sub-metas ele estabelece novas sub-metas at que ele
identifique no software funes que o sistema pode realizar que
permitam que as sub-metas sejam atingidas. Por exemplo, formatar
pgina pode ser decomposta na funo da aplicao especificar
tamanho da pgina e na sub-meta definir margens. Esta ltima por sua
vez pode ser atingida pelas operaes especificar valor da margem
superior, especificar valor da margem inferior, especificar valor da
margem esquerda e especificar valor da margem direita.
Vejamos o plano deste usurio
META: Formatar documento
PLANO:
Formatar pgina (sub-meta)
especificar tamanho da pgina (funo da aplicao )
Definir margens (sub-meta)
especificar valor da margem superior (funo da
aplicao)
especificar valor da margem inferior (funo da
aplicao)
especificar valor da margem esquerda (funo da
aplicao)
especificar valor da margem direita (funo da
aplicao)
Formatar pargrafos (sub-meta)
selecionar pargrado (funo da aplicao)
Especificar atributos do pargrafo (sub-meta)
especificar espaamento (funo da aplicao)
especificar recuos (funo da aplicao)
...
Formatar fontes (sub-meta)
...
O modelo de tarefas extremamente til para determinarmos as metas dos usurios e quais
funes da aplicao eles gostariam que o sistema oferecesse. Por exemplo, a especificao
dos requisitos pode determinar que deve existir uma funo da aplicao para formatar
documento de maneira que a meta do usurio pudesse ser atingida pelo sistema sem a
necessidade de planejamento algum.
importante ressaltar que uma meta pode ser satisfeita por uma nica
ou por vrias funes da aplicao e que tambm mais de um mtodo
pode ser atingido uma mesma funo da aplicao.Por exemplo, ao
utilizar o Word 7.0, o usurio pode ter como meta formatar um estilo. Ao
construir o seu plano o usurio em determinado momento pode
estabelecer a sub-meta Especificar atributos do pargrafo. Esta submeta requer as mesmas funes de aplicao do plano para a meta

74
formatar pargrafo. Assim, temos um grupo de funes da aplicao que
so utilizadas para duas (ou mais) metas distintas.
Para que o usurio solicite ao sistema que execute uma determinada
funo de usurio, ele deve realizar operaes que correspondam a um
comando de funo. Por exemplo, para o usurio solicitar ao sistema
operacional que realize a funo de copiar um arquivo de um diretrio
para outro ele deve escrever um comando do tipo copy nome1 dir1
dir2 ou se estiver numa interface grfica, mover o cone correspondente
ao arquivo da janela do diretrio para a do outro diretrio. Ao realizar o
comando, o usurio precisa realizar operaes com os dispositivos de
interface do sistema, como pressionar mouse, digitar nmero, teclar
enter, etc.
Apenas com a descrio das operaes do usurio que um plano para
atingir uma meta fica completo. Quando o sistema est pronto, o plano
tem que determinar exatamente as operaes necessrias para
comandar a funo e, conseqentemente, ter a meta atingida com o
auxlio do sistema.
Na especificao de requisitos suficiente decompor as metas que o
usurio quer atingir nas correspondentes sub-metas. Caber ao designer
do software determinar qual o conjunto de funes que permita atingir o
maior nmero possvel de metas para cada papel de usurio e quais
devem ser os comandos de interface para cada uma das funes.

4.5.2 Modelagem de Tarefas usando GOMS

Neste curso, utilizaremos a anlise de tarefas na especificao de requisitos para determinar
as tarefas que os usurios necessitam realizar com o sistema a ser construdo. Para isto
utilizaremos um mtodo especfico que utiliza o modelo GOMS simplificado. O modelo
GOMS (Goals, Operators, Methods, and Selection Rules) oferece uma abodagem de
anlise da tarefa baseada num modelo do comportamento humano que possui trs
subsistemas de interao: o perceptual (auditivo e visual), o motor (movimentos braomo-dedo e cabea-olho), e cognitivo (tomadas de deciso e acesso a memria). O modelos
GOMS descreve o comportamento dinmico da interao com um computador,
especificando-se:
Metas - Uma aplicao desenvolvida para auxiliar os usurios atingirem metas
especficas. Isso requer uma srie de etapas. Dessa forma, uma meta pode ser
decomposta em vrias submetas, formando uma hierarquia.
Operadores - So as aes humanas bsicas que os usurios
executam.
perceptual - operaes visuais e auditivas (olhar a tela, escutar um beep).
motor - movimentos brao-mo-dedo e cabea-olho
(pressionar uma tecla).
cognitivo - tomadas de deciso, armazenar e relembrar um
item da memria de trabalho.

75
Mtodos - Um mtodo uma sequncia de passos para se atingir uma meta.
Dependendo do nvel da hierarquia, os passos num mtodo podem ser submetas,
operadores ou a combinao de ambos.
Regras de Seleo - Pode existir mais de um mtodo para se
atingir uma meta. Uma regra de seleo especifica certas
condies que devem ser satisfeitas antes que um mtodo possa
ser aplicado. Uma regra de seleo uma expresso do tipo
"condio-ao".
O GOMS permite que se construa modelos de tarefas bem mais complexos e detalhados do
que o necessrio numa tarefa de anlise para a especificao de requisitos. Usaremos uma
verso simplificada do GOMS, pois:
o modelo da tarefa no dever descrever informaes de design da interface,
uma vez que ela ainda no foi construda;
o analista no um especialista em psicologia cognitiva;
o modelo simplificado pode ser expandido para o original, o que bastante
til.
1. Diretrizes do Modelo de Tarefas Simplificado
Uma vez que a hierarquia de metas representa um aumento no nvel de detalhe, se nos
limitarmos descrio de metas e submetas de mais alto nvel, nenhuma deciso de design
ser envolvida.
Faa a anlise "top-down" - comece das metas mais gerais em direo as
mais especficas.
Use termos gerais para descrever metas - no use termos especficos da
interface.
Examine todas as metas antes de descer para um nvel mais baixo - isso
facilita reuso de metas.
Considere todas as alternativas de tarefas - as regras de seleo
possibilitam representar alternativas.
Use sentenas simples para especificar as metas - estruturas complexas
indicam a necessidade de decomposio da meta em submetas.
Retire os passos de um mtodo que sejam operadores - os operadores so
dependentes da interface.
Pare a decomposio quando as descries estiverem muito detalhadas quando os mtodos so operadores ou envolvem pressuposies de design.
1. Modelagem da Tarefa para aplicaes com mltiplas funes de usurios.
Se, para uma determinada aplicao, a funo do usurio for um
fator crtico dominante na anlise de usurios, deveremos ter
modelos de tarefas diferentes para cada funo de usurio. No
GOMS simplificado, veremos como representar as tarefas para
cada usurio num s modelo. Antes de estudarmos a notao do
modelo, vejamos algumas regras para modelos com mltiplas

76
funes de usurios:

o
o
o

Inicie especificando metas de alto nvel para cada funo de usurio.

Se mais de um compartilham a mesma meta, agrupe-os sob uma s.
Se todos compartilham a mesma meta, retire as referncias a funes de
usurio.

2. Notao
1.

Notao para Funes de Usurios.

Funes de usurios distintas sero denotadas pelo smbolo FU seguido por

um nmero.

ex.: Gerente de vendas (FU1), balconista (FU2), caixa (FU3)

A descrio de cada funo de usurio a primeira parte do modelo de
tarefas.
ex.: Gerente de vendas (FU1): responsvel pela vendas nas lojas.
Tem acesso a todos os dados do sistema.
Um ponto-e-vrgula (;) usado para separar o smbolo da funo do usurio
do restante da notao do modelo de tarefas.

ex.: FU1;...
Se uma meta usada para mais de uma funo de usurio, elas devem ser
separadas por uma vrgula (,).

ex.: FU1, FU2; ...

Um asterisco (*) usado se uma meta aplicada a todas as funes de
usurios.

ex.: *;...
1. Notao para especificao de metas

Cada passo num mtodo numerado numa ordem seqencial, com cada
nvel de decomposio separado por um ponto (.), e com a endentao
apropriada para reforar a noo de hierarquia. Aps o ltimo nmero usa-se
dois-pontos (:).
ex.: FU2; 2.1: Anotar correes.
Um comentrio comea com duas barras inclinadas para direita (//) e acaba
ao final da linha.

77
ex.: // Para fazer as anotaes o balconista dever examinar as
// listagens produzida durante as vendas do dia.
FU2; 2.1: Anotar correes

Notao para Mtodos e Regras de Seleo

Se uma meta possui mais de um mtodo para ser atingida, uma letra do
alfabeto usada de forma ordenada aps o nmero que descreve a meta.
ex.:
FU2; 2: Fazer relatrio de vendas (meta)
FU2; 2A: ... (mtodo A)
FU2; 2B: ... (mtodo B)

As regras de seleo e o mtodo associado so descritos como pares

"condio-ao", logo aps a notao numrica da meta.

ex.: FU2; 2A: se (dia de hoje for sbado)

ento (fazer relatrio semanal)
1. Reutilizando Metas
Um aspecto importante dessa notao que pode-se
reutilizar metas, simplesmente usando o mesmo nmero de
uma meta preexistente.
ex.:
FU2; 2.1: Anotar correes. (meta preexistente)
...
FU1, FU3; 3: Modificar livro-caixa.
FU1, FU3; 3.1: Procurar lotes em aberto.
FU1, FU3; 2.1: Anotar correes. (meta reusada)
FU1, FU3; 3.3: Recalcular valores.
2. Diretrizes adicionais

Delimite os passos de um mtodo entre chaves: {}.

Em aplicaes com apenas uma funo de usurio, no necessrio incluir a
notao de funo usurio antes de cada meta.
Num nvel de decomposio onde todas as metas tm o mesmo nmeroprefixo, apenas o nmero que indica a seqncia naquele nvel necessrio.

78

A diretriz anterior se aplica tambm notao de funo de usurio.

Ao reutilizar uma meta anterior necessrio usar a notao completa para
ela.
ex.: FU1, FU3; 3: Modificar livro-caixa.
1: Procurar lotes em aberto.
2.1: Anotar correes. (meta
reusada)
3: Recalcular valores.

79

5. Design Conceitual de
Software
Neste captulo discutiremos:
O que design de software?
O Modelo Conceitual da Aplicao
O Modelo de Interao com a Aplicao

5.1 O que design de software?

No captulo anterior vimos como especificar os requisitos de software. Os requisitos
funcionais determinam quais funes os usurios necessitam que o sistema oferea. Vimos
tambm como estas funes de aplicao podem ser especificadas como Casos de Usos na
linguagem UML.
Para que os casos de uso tornem-se funes do software preciso
determinar como o usurio ir interagir com elas e como elas devem ser
implementadas em um programa. Por exemplo, vamos considerar que o
clculo do lucro de venda um caso de uso que faz parte dos requisitos
funcionais de um sistema comercial qualquer. O caso de uso deve
descrever, por exemplo, que o usurio deve fornecer o valor de compra
e o valor de venda, acionar a funo de clculo e o sistema deve ento
fornecer o resultado calculado. Para que este (e outros) caso de uso seja
concretizado numa funo de aplicao do software preciso projetar e
implementar como os usurios fornecero os valores e obtero os
resultados e quais so os algoritmos que realizam tudo isto. No captulo
1, mostramos o exemplo de um software bastante simples para o clculo
do lucro de vendas. L apresentamos como este caso de uso ocorre num
software descrevendo a interface com a qual o usurio deve interagir e o
algoritmo que implementa este programa.
A partir de agora vamos comear a estudar como a especificao de
requisitos pode ser transformada na especificao do software. Devemos
determinar como casos de uso devem ser transformados em funes da
aplicao com as quais os usurios possam interagir e que possam ser
implementadas atravs de uma linguagem de programao. A esta
atividade de criar o software que satisfaz os requisitos dos usurios
denominamos de design de software.
Design compreende as atividades de concepo, especificao e
prototipao de um artefato. O software como um produto - um artefato
virtual - precisa ser concebido, especificado e prototipado. Precisamos
trazer para o desenvolvimento de software a atividade de design que
realizada no desenvolvimento de qualquer produto industrial.
Design poderia ser traduzido tanto por projeto como por desenho.
Entretanto, estes dois termos no expressam exatamente o que

80
design. Projeto um termo mais abrangente do que design, pois se
aplica a projeto de pesquisa, projeto de desenvolvimento de um produto
e envolve planejamento, metodologia, cronograma, recursos, etc.
Desenho uma traduo utilizada no sentido de Desenho Industrial
(industrial design), mas leva a conotao de que a atividade resume-se
a elaborar os diagramas que descrevem os modelos do produto. Por
estes motivos vamos utilizar o termo em ingls: design. Para quem faz o
design, vamos usar os termos designer, projetista ou desenhista.
Segundo David Liddle,
"o design de software o ato de determinar a experincia do usurio com
um pedao de software. No tem nada a ver sobre como o cdigo opera
internamente ou se ele grande ou pequeno. A tarefa do designer
especificar de forma completa e no ambgua a experincia global do
usurio". [David Liddle, Design of The Conceptual Model, em Winograd,
T.]
O design de software compreende a concepo, especificao e prototipao da partes
"externas" e "internas" do software. A parte externa compreende o modelo conceitual da
aplicao e a interface de usurio. A parte interna compreende a arquitetura de
componentes de software e os algoritmos e estruturas de dados que implementam estes
componentes.
O design de software envolve as atividades de concepo, especificao
e prototipao:
do modelo conceitual da aplicao,
da interface de usurio,
da arquitetura de componentes de software e
dos algoritmos e estruturas de dados

81
A concepo e especificao da arquitetura dos componentes de
software determinar toda a estrutura interna do software: os objetos,
funes e estruturas de dados. Eles so responsveis pelo
funcionamento do software.
Este e o prximo captulo abordam o design da parte "externa" do
software: o modelo conceitual e a interface de usurio. O design da
parte "interna", a arquitetura de componentes de software e os
algoritmos e estruturas de dados sero vistos no captulo 6.

5.2 Modelo Conceitual da Aplicao

Vimos que o software deve ser visto como um artefato virtual que compreende as solues
que foram concebidas para resolver os problemas dos usurios, isto , auxili-los na
realizao de suas tarefas no domnio. Este artefato virtual uma entidade abstrata que
existe na mente dos usurios quando eles esto interagindo com o usurio.
A esta entidade virtual que os usurios imaginam damos o nome de
Modelo Conceitual da Aplicao que ele adquire. Este modelo
conceitual determina, para o usurio, quais os conceitos (ou objetos
do domnio) que esto representados no software, o que ele pode fazer
com a aplicao - a funcionalidade - e como ele pode interagir com a
aplicao - o modelo de interao.
A idia de modelo conceitual da aplicao denominado diferentemente
por diversos autores. Ele chamado de virtualidade, modelo conceitual
do usurio, modelo de usabilidade, metfora de interface e vrias outras
denominaes.
Num editor de documentos como o MS Word, por exemplo, temos
diversos conceitos que permitem ao usurio entender como est
estruturado um documento e o que ele pode fazer com ele. No Word
encontramos os conceitos de pgina, bordas de pgina, margens,
pargrafos, recuos de pargrafos, espaamento entre linhas, distnciada-primeira-linha, distncia-antes-do-pargrafo, tamanho da letra, estilo
da letra e diversos outros. Mais adiante apresentaremos um exemplo de
um modelo conceitual para um editor de texto.
A elaborao de um modelo conceitual fator determinante no sucesso
de uma aplicao. O modelo conceitual precisa ser concebido e
especificado adequadamente pelo designer, de acordo, com as
necessidades, capacidade e limitaes dos usurio. Para que o modelo
seja adequado aos usurios, a especificao dos requisitos
fundamental. Nela encontramos, os papis de usurios, o modelo de
tarefas, os casos de uso, os conceitos do domnio e outras informaes.
A partir delas temos condies de elaborar um modelo conceitual que
seja adequado aos requisitos dos usurios.
Para que a aplicao seja utilizada adequadamente preciso que o
usurio conhea o modelo conceitual da aplicao que foi elaborado
pelo designer. Para isto preciso que ele seja comunicado
adequadamente ao usurio. Uma das formas de comunicar este modelo

82
atravs dos manuais de usurio ou de treinamento feito por pessoas
especializadas. A outra forma tentar expressar os conceitos atravs da
interface de usurio. A interface quem oferece a imagem externa do
sistema e que deve ser interpretada de maneira correta pelo usurio. Ela
deve comunicar para o usurio quais os objetos do domnio esto
representados, o que ele pode fazer (a funcionalidade) com este
conceitos e como ele pode interagir (o modelo de interao) com esta
funcionalidade. No captulo 5 veremos como o design da interface de
usurio deve ser feito para expressar o modelo conceitual da aplicao.

5.2.1 Exemplo: o modelo conceitual de um sistema

operacional
Ao utilizarmos um sistema operacional como o MS DOS sabemos que podemos construir,
armazenar e organizar arquivos de software. Um arquivo na verdade uma seqncia de
bits como comeo e fim definidos. Para o usurio o arquivo algo conceitual (um conceito
da aplicao) que se refere a documentos, programas, dados, etc. Esta entidade conceitual
surge na mente do usurio por que ele tem um nome, um tipo, uma data de criao e uma
tamanho em bytes. Arquivos so armazenados em discos em trilhas e setores e podem ser
localizados a partir de uma tabela que associa o seu nome ao local fsico. Para o usurio,
arquivos so colocados "dentro" de uma outra entidade conceitual: o diretrio.
Arquivos e diretrios so os conceitos da aplicao e podem ser criados,
destrudos ou modificados por diversas funes da aplicao. Estas
funes so, por exemplo, copiar arquivo, apagar arquivos, construir
diretrios, remover diretrios, colocar arquivos em um diretrio, mover
arquivo de um diretrio para outro, etc. Esta funes so tambm
entidades virtuais representadas por uma nome que devem indicar, para
o usurio, o que o sistema faz. Por exemplo, o sistema operacional no
coloca arquivos dentro de um diretrio. Isto s existe na mente do
usurio. O que o sistema faz trocar o endereo fsico do arquivo na
tabela de arquivos e diretrios. Entretanto, a viso de que diretrios so
recipientes que armazenam arquivos muito mais til para o usurio.
Ela permite ao usurio criar na sua mente conceitos da aplicao que
permitem a ele entender o que fazer com o sistema e raciocinar melhor
sobre ele.
O sucesso de uma aplicao vai depender justamente da criao deste
modelo conceitual. Quanto mais claros forem o conceitos e as operaes
que se pode fazer com eles, mais o usurio vai saber como aplic-los na
resoluo de seus problemas. O sucesso de sistemas como o Macintosh
ou o MSWindows (que copiou o primeiro) deve-se construo de
modelos conceituais mais familiares para o usurio. Os conceitos de
pastas e objetos e a representao deles atravs de janelas e cones
permite ao usurio criar imagens mentais mais claras e que so
familiares as atividades que eles realizam num escritrio. O conceito de
pasta como recipiente mais claro que o de diretrio (que na verdade
uma lista). No ambiente Windows o usurio move objetos (documentos,

83
aplicativos, figuras, etc.) de uma pasta para outra e para o topo-demesa (desktop) como faria no seus escritrio.
No MS DOS, o usurio adquire este modelo conceitual (as noes sobre
diretrios e arquivos) ao ler o manual de usurio. No sistema Unix, da
mesma forma, o manual do usurio quem mostra para o usurio quais
os conceitos da aplicao. Veja como exemplo um trecho do manual do
Unix onde so apresentados os conceitos de arquivos e diretrios.
A interface de usurio fundamental para que este modelo conceitual
seja comunicado ao usurio. Ela o melhor meio para que expressar os
conceitos da aplicao e as funes que podem ser utilizadas. No MS
DOS, a interface muito pouco expressiva. Na interface o conceito de
diretrio visualizado por ele como uma lista de nomes, tipos,
tamanhos e datas, que representam cada arquivo do diretrio. Cada
arquivo referenciado individualmente pelo seu nome. No Windows 95,
o modelo conceitual representado por desenhos grficos que
representam os conceitos da aplicao de maneira mais clara.
A interface de usurio tambm tem o papel de permitir ao usurio
interagir com o sistema, comandando as funes da aplicao e
visualizando o estado dos conceitos do domnio. No caso do MS DOS, a
interface oferece comandos como copy, del, mkdir e vrios outros para
que o usurio possa interagir com os conceitos do domnio atravs das
funes da aplicao.
A concepo do modelo conceitual como vimos fundamental para o
sucesso da aplicao. A criao de uma interface de usurio que
expresse uma imagem deste modelo tambm outro fator
importantssimo para que usurios compreendam melhor o que podem
fazer com o sistema. No captulo 5, veremos como realizar o design de
interfaces que expressem melhor o modelo conceitual da aplicao

5.2.2 Um modelo conceitual bsico para sistemas

interativos
Qualquer artefato quando utilizado por algum permite que ele elabore mentalmente um
modelo conceitual do artefato. Mesmo que este modelo no tenha sido especificado
explicitamente, o usurio, ao utiliz-lo, cria na sua mente os conceitos a respeito daquela
aplicao. tarefa do designer, ao fazer o design de um produto, determinar quais os
conceitos que esto associados a ele. Alguns produtos tm conceitos que so comuns a
maioria deles. Os conceitos de volume, brilho, cor e canal so comuns a televisores.
Encher, lavar, enxaguar e centrifugar so conceitos que se referem a operaes que podem
ser feitas em mquinas de lavar. Entretanto, no existe um obrigao de que todos os
produtos possuam os mesmos conceitos.
Nos sistemas computacionais interativos o modelo conceitual da
aplicao formado por alguns tipos de conceitos que so comuns a
maioria deles. Evidentemente, cabe ao designer determinar quais os
conceitos so teis para a aplicao que ele est projetando. Vamos
utilizar alguns tipos pr-definidos de conceitos. Eles so os objetos e

84
as funes da aplicao e os comandos de funo. Os conceitos do
domnio como objetos, propriedades e relacionamentos devem ser
representados no sistema para que os usurios possam operar sobre
eles. Estas operaes - as funes da aplicao - permitem que os
conceitos sejam criados, transformados, destrudos, etc. Os comandos
de funes permitem ao usurio controlar a execuo de uma funo
pelo computador.
O conceito de objeto da aplicao refere-se s representaes abstratas
das diversas coisas que podemos distinguir num domnio e que so
utilizadas pelos usurios para realizar as suas atividades. Num domnio
de biblioteca so exemplos de objetos do domnio os livros, as revistas,
o ttulo do livro, os autores, o assunto, os nmeros e volumes das
revistas, o nmero de cadastro do livro, o nome do usurio, o nmero de
cadastro do usurio e diversos outros. Num domnio de edio de textos
estes conceitos podem ser documento, pgina, pargrafo, fonte, etc. Os
objetos do domnio possui propriedades que os caracterizam e podem
estar relacionados entre si.
Ao fazermos o design de um software devemos determinar quais os
objetos do domnio que sero representados como objetos da aplicao
e quais novos podero ser criados. Um sistema de biblioteca deve poder
representar os objetos do domnio biblioteca listados acima. O objeto
livro pode ser representado pelos conceitos da aplicao informaesde-livro de ttulo, autor, assunto e nmero de referncia.
Ateno! Na especificao do modelo conceitual no estamos
interessados ainda em como eles vo ser representados
computacionalmente, isto , qual estrutura de dados ser utilizada para
representar o conceito numa linguagem de programao. Isto s dever
ser feito no design da arquitetura e dos componentes do software.
Tambm no vamos representar ainda como o conceito ser visto pelos
usurio - se na forma de um cone, de uma tabela, de uma lista, etc. Por
enquanto estamos interessado em fazer uma especificao abstrata dos
conceitos.
As funes da aplicao so responsveis por operaes com os
conceitos do domnio. Elas devem determinar quais transformaes
ocorrem no sistema e quais so os conceitos que so modificados,
criados ou destrudos. A funes modificam o estado do sistema. Um
determinada funo da aplicao FA1 pode levar o sistema de um
estado E1 de para um estado E2. Os estado inicial que o sistema est
antes que uma determinada funo seja executado tambm chamado
de pr-condio. O estado final, isto , aps a funo da aplicao ter
sido executada chamado de ps-condio.
Por exemplo, a funo da aplicao armazenar nome-do-cliente na listade-nomes deve ter como pr-condio que o nome-do-cliente tenha sido
fornecido e que a lista-de-nomes no possua o nome-do-cliente j
armazenado. A ps-condio que nome-do-cliente esteja armazenado
na lista-de-nomes ao final da operao.

85
A execuo de cada funo da aplicao deve ser controlada por
comandos de funo. Este conceito refere-se ao conjunto de aes
que o usurio deve desempenhar para que uma determinada funo
seja iniciada, interrompida ou cancelada, por exemplo. As aes que o
usurio deve fazer so aquelas que ele desempenha com os dispositivos
da interface de usurio, como pressionar tecla X, escrever um nome
com o teclado, pressionar com o mouse, mover com o mouse, etc.
Existem diferentes formas de interao que determinam comandos de
funo de diversas natureza. No MS DOS, os comandos so elaborados
pela digitao de sentenas. Este estilo chamado de linguagem de
comando. No Windows 95/98, os comandos so desempenhados pelo
acionamento de objetos da interface num estilo chamado de
manipulao direta.
Veremos, a seguir, como especificar os conceitos do domnio. Mais
adiante veremos a especificao de funes da aplicao e na seo 5.3
veremos a especificao do modelo de interao que inclui os comandos
de funo.

5.2.3 Especificando o modelo conceitual da aplicao

utilizando a UML
Modelos conceituais podem representar qualquer sistema na natureza. No sistema solar
temos os conceitos de planetas, rbita, fora gravitacional e outros. A fsica utiliza de
notaes matemticas para representar os conceitos que descrevem o sistema solar. A lngua
portuguesa tambm pode ser utilizada para descrever conceitos de um domnio. Na
biologia, os conceitos referentes a espcies, gnero, famlia, classes, ordem, filo e reino dos
seres vivos so descritos em portugus e latim.
No existem muitas tcnicas ou notaes especficas para o design do
modelo conceitual de sistemas interativos. Neste modelo o que estamos
querendo representar so os conceitos que se formam na mente do
usurio ao utilizar o sistema. Algumas das tcnicas e notaes de
inteligncia artificial como redes semnticas, frames e scripts podem ser
utilizadas. Seria interessante que a linguagem utilizada permitisse-nos
construir um modelo que pudesse ser "traduzido" tanto em elementos
da interface como em componentes de programao.
Utilizaremos a notao UML (Linguagem de Modelagem Unificada) como
forma de representar conceitos de objetos e relaes da aplicao. Com
os diagramas de classes tambm podemos mostrar como os objetos
esto associados com as funes da aplicao - que haviam sido
representadas de maneira simplificada como casos de uso na UML.
Classes
Tradicionalmente, representamos um objeto dando-lhe um nome e descrevendo as
propriedades ou atributos que os distinguem de outros objetos. As classes em UML
permitem representar conceitos descrevendo o seu nome, seus atributos e relacionamentos.

86
A classe descreve o conceito abstraindo os valores de propriedades especficos, permitindo
a referncia genrica a objetos do domnio. A noo de classes como o agrupamento de
objetos est presente em nossa linguagem e em diversas cincias. O processo de
classificao estudado desde a filosofia da Grcia antiga.
Em computao existem diversas metodologias para anlise e design
orientado-a-objetos que permitem a representao de classes. Elas so
bastante parecidas entre si. A UML apresenta sua prpria notao para a
representao de classes atravs de diagramas de classes. Estas
notaes tem por objetivo a modelagem de programas orientados-aobjeto. Entretanto, na atividade de design utilizaremos diagramas de
classes como propsito de modelar objetos da aplicao da forma como
so vistos pelo usurio e no da forma como so implementados.

Uma classe uma descrio de abstrata de objetos que possuem

atributos comuns ou esto relacionadas a outros objetos. Cada classe
possui um nome que a distingue de outras classes. Este nome
qualquer seqncia de letras, de preferncia um termo do vocabulrio
do domnio.
Um atributo o nome dado a uma propriedade do conceito
representado pela classe. Cada objeto que pertence a uma determinada
classe possui valores especficos para os atributos que so comuns a
uma determinada classe. Por exemplo, a classe cliente possui os
atributos nome, endereo, telefone e data-de-nascimento. Um certo
cliente (um objeto do domnio) representado pelos valores especficos
dos atributos que descrevem as propriedades. Os clientes Joo da Silva,
R. Salgado Filho, 2126666, 12/2/55 e Joo da Silva, R. Hermes da
Fonseca, 2122121, 29/2/65 so distintos, pois possuem valores
especficos para os atributos que caracterizam a classe cliente. Nos
diagramas de classes os atributos (o nome da propriedade) so
identificados por um nome enquanto que os seus valores podem ser

87
representados por nmeros, nomes, caracteres especiais e outros
smbolos que forem apropriados.
Um conceito pode ser representado por uma classe simples, isto , que
no possui algum atributo especfico. A identificao numrica nica de
um aluno um conceito que pode ser representado simplesmente pela
classe matrcula-do-aluno sem nenhum atributo. Este conceito pode,
eventualmente, ser um atributo de uma outra classe (a classe que
representa o conceito aluno, por exemplo). Entretanto, podemos
representar tambm a identificao por uma classe cujos atributos
sejam ano de ingresso, semestre, nmero do centro, nmero do curso,
nmero pessoal e os valores sejam, respectivamente 92-1-8-62-2321.
Ateno! Os diagramas de classes da linguagem UML so mais
genricos do que precisamos para representar classes e objetos da
aplicao. Eles foram projetados para permitir tambm a modelagem de
classes de uma linguagem orientada a objetos como C++, Smalltalk ou
Java. Por enquanto utilizaremos este diagrama apenas para representar
objetos da aplicao. Utilizaremos diagramas de classes para
representar classes de linguagens de programao mais adiante quando
estivermos modelando a arquitetura de componentes de software.
Objetos
Objetos so instncias de classes. Objetos possuem existncia num
domnio. No exemplo visto anteriormente, Joo da Silva, R. Salgado
Filho, 2126666, 12/2/55 um objeto da classe cliente. Os valores de
atributos representam a existncia de um cliente especfico. Joo da
Silva, R. Hermes da Fonseca, 2122121, 29/2/65 um outro objeto e
representado pelos valores de suas propriedades diferenciais.
Na UML um objeto representado por retngulo, com o nome do objeto
seguido por um ":"(dois pontos) e o nome da classe ao qual ele
pertence.
Relacionamento
Uma classe pode estar relacionada com outras classes. Isto significa que os objetos
representados pela classe esto relacionados de alguma forma com os objetos da outra
classe. Uma relao genrica representada por uma associao. Cada associao
identificada por um nome. As classes que esto ligadas a uma associao assumem papis
especficos. Por exemplo, a relao entre os conceitos pessoa e empresa pode ser
representada pela associao trabalha-em. Nesta associao a pessoa assume o papel de
empregado e a empresa o papel de empregador. Numa associao preciso especificar a
multiplicidade. Por exemplo, uma pessoa pode trabalhar-em uma nica empresa (1) e uma
empresa pode empregar uma ou mais pessoas (1 . . *).

88

Um importante tipo de relacionamento entre conceitos, bastante comum na maioria dos

modelos, a generalizao. A generalizao relaciona um conceito mais genrico a um
conceito que seja mais especfico. O primeiro chamado de superclasse enquanto o
conceito mais especfico a subclasse. A generalizao tambm conhecida como -umtipo-de. Por exemplo, um retngulo -um-tipo-de figura. A figura a superclasse e o
retngulo a subclasse. Crculo e polgono so conceitos que tambm so subclasses do
conceito figura. Quadrado uma subclasse de retngulo e, conseqentemente, tambm
subclasse de figura. A relao especializao oposta a generalizao. Ela indica que uma
subclasse uma especializao da superclasse. Quadrado uma especializao de figura.

Um outro relacionamento bastante comum a agregao, tambm conhecida como

parte/todo. Esta relao ocorre entre conceitos que so parte de um outro (o todo) e pode
ser representado pela associao -parte-de ou pela sua relao inversa tem. Por exemplo, a
roda -parte-de carro ou, usando a associao inversa, carro tem roda. Nesta associao os
papis desempenhados pelas classes relacionados so, justamente, parte e todo. A

89
multiplicidade tambm pode ser representada na associao de agregao. Uma empresa
tem (0 . . *) departamentos, isto uma empresa pode ter nenhum ou vrios departamentos.
Um departamento -parte-de (1) empresa, significa que o departamento pertence a uma
nica empresa.

5.2.4 Especificando Funes da Aplicao usando

Diagramas de Atividades
Os diagramas de casos de uso descrevem quais as funes da aplicao so de interesse de
cada papel de usurio. Veremos agora como os diagramas de atividades permitem
descrever o comportamento de cada funo da aplicao. mais adiante mostraremos como
os diagramas de classes permitem representar como as funes da aplicao esto
relacionadas com os objetos da aplicao.
O diagrama de atividades mais um diagrama da UML. Ele permite
modelar aspectos dinmicos de um sistema. Em particular, ele um
grfico de fluxo (flowchart) que permite mostrar o fluxo de controle de
atividade para atividade descrevendo a seqncia de passos no
processo computacional.

Graficamente, um diagrama de atividades um grafo composto por ns

e vrtices. Eles so utilizados para:
Modelar uma funo ou operao
Modelar um fluxo de trabalho (workflow)
Por enquanto, vamos utilizar os diagramas para modelar apenas as funes da aplicao.
Normalmente, um diagrama de atividades composto por:
Estados de atividades e estados de aes
Transies
Objetos

90
Um diagrama de atividades visa mostrar com as coisas acontecem no sistema. Um estado
de ao representa uma situao na qual o sistema encontra-se quando est realizando
computaes. Cada estado de ao representado por uma figura especfica com uma
descrio da computao realizada. Esta descrio o predicado de uma sentena do tipo
calcule valor, imprima documento, etc.
Estados de ao so atmicos, isto , eles no podem ser decompostos.
Isto significa que quando a ao esta sendo executada ela no pode ser
interrompida. Considera-se que o tempo de execuo da ao
insignificante.
J os estados de atividades podem ser decompostos e,
eventualmente, representados em diagramas de atividades
independentes se for necessrio (normalmente por questes de clareza).
Os estados de atividades no so atmicos e podem ser interrompidos
durante a ocorrncia de eventos. O sistema permanece num estado de
atividade durante um certo intervalo de tempo.
Um estado de atividade composto por outros estados de atividades ou
de aes. O estado de aes , portanto, um estado de atividade
atmico que no pode ser mais decomposto. O diagrama de atividades
descreve o fluxo de controle do sistema nos diversos estados de
atividade e aes.
A figura para representar o estado de atividade a mesma do estado de
ao, exceto que o primeiro pode ter partes adicionais tal como aes
de entrada e sada (aes que esto envolvidas quando se entra ou sai
do estado) e especificao de sub-mquinas.
Quando a ao ou atividade de um estado termina o fluxo de controle
passa imediatamente para o prximo estado de ao ou de atividade.
Este fluxo especificado atravs de transies que mostram o caminho
de uma ao ou atividade para o prximo estado de ao ou de
atividade. Na UML, a transio representada por uma linha com uma
seta indicando a direo do fluxo.
Num diagrama de atividade existe uma transio que identifica a
passagem do estado inicial para um estado de ao ou de atividade e
uma outra que identifica a passagem para o estado final. O estado inicial
identificado por uma bola pequenina de cor preta e o estado final
representado por um crculo um pouco maior com a bola preta no seu
interior.
A transio seqencial entre os estados nem sempre ocorre por um
caminho nico. Caminhos alternativos so representados por uma
deciso (branching). Na UML a bifurcao representada por um
losngulo conectando linhas que representam as transies. No
diagrama uma expresso lgica pode ser acrescentada para indicar em
quais condies cada caminho pode ser seguido.
Dois estados de ao ou atividades podem ocorrer simultaneamente.
Para indicar a simultaneidade ou concorrncia a UML oferece as
estruturas bifurcao e juno. Eles so representados por uma barra
de sincronizao que indicam quando uma transio se divide em duas

91
ou mais ou quando duas ou mais juntam-se em uma. Uma bifurcao
possui uma transio chegando e duas ou mais saindo. A juno, por sua
vez, possui duas ou mais transies chegando e uma saindo para um
outro estado de ao ou atividade.
Conceitualmente a bifurcao e a juno permitem representar dois
estados de atividades ou aes simultneos, isto , sendo executando
ao mesmo tempo. Na implementao esta concorrncia pode ser real ou
uma simulao com processos intercalados.
Raias so utilizadas para agrupar estados de atividades ou de aes de
maneira a representar de quem a responsabilidade por aquela
ao.Cada raia representa um locus de atividade e identificada por um
nome.
Para modelar uma funo da aplicao (ou uma operao) usando
diagrama de estados voc deve:
Identificar os conceitos que esto envolvidos com esta funo. Isto inclui os
parmetros da funo e os atributos da classes que est associada funo. Os
conceitos envolvidos com a funo so denominados de operandos.
Identificar as pr-condies no estado inicial da funo e as ps-condies no seu
estado final. Tambm identifique os invariantes, isto , as condies que
permanecem constantes durante a realizao das atividades.
Comece identificando as atividades iniciais que o sistema deve realizar para a
funo que est sendo modelada. Represente cada atividade que o sistema deve
desempenhar como um estado de atividade, se ela puder ser decomposta, ou de ao
se ela for atmica.
Use deciso (branching) se necessrio para especificar caminhos alternativos e
repeties (loop).
Use bifurcao e juno para especificar fluxos de controles paralelos (atividades
simultneas), se for necessrio.
O diagrama de atividades um tipo de mquina de estados. Ele tem por objetivo descrever
os estados de atividades e o fluxo de controle, isto , os caminhos para passar por cada um
dos estados. A mquina de estados tem por objetivo descrever como o sistema (ou uma
funo em particular) muda de estados na ocorrncia de eventos externos a ele. No
diagrama de atividades descreve-se como o sistema muda de um estado de atividade para
outro quando termina a atividade que est sendo realizada, independente da ocorrncia de
um evento externo.

5.2.5 Especificando funes da aplicao usando

Diagrama de Estados
Uma mquina de estados permite modelar os aspectos dinmicos de um sistema. Ela
mostra o comportamento do sistema em termos de estados pelos quais ele passa ao longo de
sua existncia. A mquina de estados mostra com o sistema reage a eventos externos. Alm
disso, ela mostra a ordem na qual o sistema assume determinados estados.
Mquinas de estados podem ser utilizadas para modelar o
comportamento de componentes individuais de software, funes de

92
aplicao (ou casos de uso, como so chamadas na UML) ou um sistema
inteiro.
A mquina de estados uma abstrao bastante utilizada em
computao. A teoria da computao nos mostra como descrever
matematicamente uma mquina de estados. Tambm podem ser
encontradas notaes com o mesmo potencial em diversas metodologia
de desenvolvimento de software.
A UML proporciona uma representao grfica para mquinas de
estados: o diagrama de estados. Esta notao permite representar
estados, transies, eventos e aes utilizando smbolos especficos,
como mostra a figura.

Uma desvantagem do diagrama de estado ter de definir todos os

possveis estados de um sistema. Isto no problema quando se est
modelando uma nica funo, mas quando se descreve o sistema
completo quando o sistema assume dezenas ou at centenas de
possveis estado o diagrama pode se tornar invivel. Neste cursos
vamos usar mquinas de estados para representar o comportamento de
cada funo da aplicao ou caso de uso.
Um estado uma condio ou situao na qual um objeto do sistema
(ou o prprio sistema) est durante o seu tempo de "vida". O sistema
pode permanecer num estado at que ocorra um evento externo, at
que uma determinada atividade que ele esteja executando termine ou
que alguma condio seja satisfeita. O sistema normalmente passa por
diversos estados. Graficamente um estado representado por um
retngulo com as bordas arredondadas.
Um estado tem vrias partes:
Nome - uma palavra ou sentena simples que distingue um estado de outro.
Aes de entrada e sada - as aes que so executadas quando o sistema entra e
sai, respectivamente, de um estado.

93

Sub-estados - Um estado pode ter sub-estados aninhados em sua estrutura. Eles

podem ser concorrente ou seqenciais.
Transies internas - transies entre os sub-estados internos que no mudam o
estado.

Cada mquina de estado tem um estado inicial que indica o estado no qual o sistema
encontra-se quando a funo iniciada. Quando se est modelando funes, este estado
inicial tambm chamado de pr-condio. Uma mquina de estado pode ter um ou mais
estados finais que indica as situaes, tambm chamada de ps-condies, na qual o
sistema deve estar para considerarmos que a funo foi executada como esperado.
Um evento a especificao de uma ocorrncia significante no espao
e no tempo. No contexto de mquina de estados o evento uma
ocorrncia que leva a uma transio. A ocorrncia pode ser externa ao
sistema, interna (outra parte do sistema) ou um instante de tempo
atingido.
Uma transio um relacionamento entre dois estados indicando que
o sistema quando est num determinado estado ir para um outro
estado na ocorrncia de um certo evento e realizar uma certa ao. A
transio representa a mudana de estado.
Uma transio tem cinco partes (algumas em comum com os estados):
Estado origem - o estado no qual o sistema est antes que a transio seja
percorrida
Estado destino - o estado para o qual o sistema vai quando a transio percorrida
Evento de ativao - a ocorrncia que faz com que a transio seja ativada
indicando a mudana de estado
Condio de guarda - uma expresso booleana que avaliada quando a transio
ativada. Se a expresso for avaliada como verdadeira a transio realizada, caso
contrrio o evento ignorado e o sistema permanece no mesmo estado.
Ao - a ao que deve ser executada pelo sistema na ocorrncia do evento.
Normalmente, a execuo da ao leva ao sistema ficar no estado "executando a
ao". Em outro casos, quando a ao tem um tempo curto e quando acaba o
sistema vai direto para um outro estado no preciso representar este estado de
execuo das aes.
Uma ao ou atividade uma execuo realizada pelo sistema. A ao uma computao
atmica, indivisvel, enquanto a atividade pode ser sub-dividida em outras atividades ou
aes.

5.2.6 Exemplo: especificando uma funo da aplicao

No captulo 4, apresentamos a especificao informal de um caso de uso validar cliente.
Vejamos agora como a funo da aplicao que implementa este caso pode ser especificada
usando diagrama de atividades e de estados.
As figuras abaixo mostram os diagramas de estados que descrevem o
comportamento do sistema em decorrncia dos eventos do usurio. Na
primeira figura esto descritos os estados de ler e de verificar a senha.

94
Na figura imediatamente abaixo apresentamos os sub-estados do estado
lendo senha do diagrama de cima. importante ressaltar que estes no
so os nicos diagramas possveis.

A prxima figura mostra o diagrama de atividades para a funo validar

cliente.

A seguir, mostraremos um diagrama alternativo para a funo validar

cliente cujas atividades ler senha e pesquisar senha usurio so
realizadas em paralelo.

95

Estes diagramas podem ser modificados. Voc pode fazer o seu prprio
design e modelar do jeito que voc quiser. Como exerccio, experimente
modelar o fato de que cada cliente poder apenas fazer trs tentativas.

5.2.7 Associando Funes da Aplicao a Objetos do

Domnio usando Diagramas de Classes.
Vimos que uma Funo da Aplicao opera sobre objetos, modificando seu estado ou
comportamento. As classes e os relacionamentos permitem elaboramos um modelo dos
objetos do domnio com um potencial equivalente aos Diagramas Entidade-Relacionamento
utilizados nas metodologias estruturadas e no projeto de banco de dados. Os diagramas de
classes, entretanto, permitem representarmos tambm as operaes ou funes que so
associadas a uma classe. Com isto podemos descrever quais as funes da aplicao que
podem ser realizadas com os objetos representados por uma classe.
Na modelagem conceitual pretendemos representar como as funes da
aplicao (os casos de uso) esto associados com alguns dos objetos da
aplicao representados como classes. Por exemplo, num editor de texto
podemos modelar as pginas de um documento atravs da classe
pgina, cujos atributos so tamanho e margem direita, esquerda,
superior e inferior. Para que o usurio possam modificar as propriedades
da pgina do documento o editor de texto deve oferecer as funes
definir tamanho e definir distncia das margens.
Usando o diagrama de classes podemos representar a classe pgina, da
seguinte forma:

96

importante ressaltar que no modelo conceitual nosso objetivo definir

quais funes o sistema oferece para o usurio modificar o objeto
representado pela classe. A funo definir tamanho permite ao usurio
modificar tamanho da pgina. Da mesma forma definir distncia das
margens modifica a distncia entre a borda e a rea onde o texto vai ser
escrito. Na modelagem conceitual devemos representar numa classe
apenas as funes da aplicao que podem ser controladas pelo usurio
e que modificam os objetos da classe qual ela est relacionada.

5.3 O Modelo de Interao Usurio-Sistema

Vimos que o modelo conceitual da aplicao deve especificar de maneira abstrata o modelo
de interao e de funcionalidade do sistema. Na seo 5.2 mostramos como especificar o
modelo conceitual de uma aplicao em termos de conceitos do domnio e funes de
aplicao. Este modelo deve ser derivado da especificao de requisitos como forma de
garantir que a aplicao satisfaz as necessidades dos usurios. Os casos de uso so um
ponto chave neste processo. Eles associam as tarefas que os usurios querem realizar para
atingir as suas metas s funes da aplicao que so oferecidas pelo software. Estas
funes da aplicao operam sobre conceitos do domnio. A especificao das funes e
dos objetos da aplicao determinam a funcionalidade do software. Vimos como ela pode
ser especificada atravs da UML (Linguagem de Modelagem Unificada) que permite
descrever o comportamento de cada caso de uso atravs de diagramas de estados e de
atividades, bem como outros diagramas que no foram estudados.
Entretanto, a especificao da funcionalidade do software que determina
o que se pode fazer com o sistema ainda no suficiente. preciso
ainda especificar como o usurio vai interagir com o sistema. Esta
especificao tambm deve ser feita de maneira conceitual e abstrata
da mesma forma que na funcionalidade. Neste caso, estamos
especificando a forma como o usurio interage com o sistema
independente de uma interface de usurio especfica.

97
Nesta seo vamos mostrar como especificar o modelo de interao da
aplicao. Para cada caso de uso vamos descrever o processo de
interao entre o usurio e o sistema.

5.3.1 O processo de interao usurio-sistema

Vimos que as metas do usurio so satisfeitas pela execuo de tarefas pelo usurio que
faam o sistema executar cada funo da aplicao. O modelo de tarefas, visto no captulo
3, mostram os planos do usurio para atingir cada uma das suas metas. Na especificao
dos requisitos os modelos de tarefas descrevem as hierarquias de sub-metas at o caso de
uso -- a funo da aplicao que o sistema deve oferecer. Ao detalharmos mais ainda este
plano, descreveremos as aes (ou operaes, como so chamadas no GOMS) que o
usurio deve realizar com o sistema. Este conjunto de aes denominado de comando de
funo.
A figura abaixo ilustra a associao entre os casos de uso, o modelo de
tarefa e os diagramas utilizados para descrever o comportamento de
cada funo da aplicao. Ela tambm situa o que estamos falando em
todo o contexto do desenvolvimento de software que temos abordado
desde a etapa de anlise e especificao de requisitos. Vimos que
precisamos analisar as metas dos usurios e elaborar o modelo de
tarefas para decidir quais casos de uso o sistema deve oferecer para o
usurio. Cada caso de uso determina uma funo da aplicao. O
conjunto de funes da aplicao definem a funcionalidade do sistema e
podem ser especificados em diagramas de classes, de estados, de
atividades e outros diagramas. Mais adiante veremos como modelar a
interao a atravs de diagramas de seqncias.

O modelo de interao composto pelo conjunto de comandos de

funes necessrios para o controle de cada funo da aplicao
determinada pelos casos de uso. Ele deve tambm determinar quais as

98
aes que o sistema deve fazer apresentar as informao ou resultados
ao usurio associados com cada funo da aplicao.
Por exemplo, se a meta do usurio de um editor de texto for Formatar
documento, vimos no captulo 3 que o modelo de tarefas especifica submetas como formatar pgina, formatar pargrafo e formatar fonte, que
por sua vez podem ser decompostas, cada uma, em outras sub-metas. A
sub-meta definir tamanho da pgina pode ser atingida diretamente pela
funo da aplicao de mesmo nome, caracterizando um caso de uso.
At ento no dissemos o que o usurio tem que fazer para mandar o
sistema executar esta funo.
O usurio, neste caso, tem que fornecer o valor do tamanho da pgina e
mandar o sistema modificar o tamanho atual para o tamanho desejado.
Ele pode fazer isto, por exemplo, digitando o valor do tamanho da
pgina desejado numa caixa de texto e acionando um boto de
modificar tamanho. O comando de funo seria formado por estas duas
aes bsicas. Ele tambm poderia elaborar um comando do tipo
"modifique tamanho para A4".

O comando de funo deve determinar quais as aes que o usurio

deve fazer para que uma funo da aplicao seja executada pelo
sistema. Podemos identificar alguns tipos de aes bsicas que o
usurio costuma realizar ao interagir com o sistema. Elas so chamadas
de interaes bsicas e podem ser:
Digitar valores de informao
Escolher uma informao de uma lista
Acionar um boto fsico ou imagem na tela (widget)
Mover um boto fsico ou imagem na tela (widget)
Visualizar uma informao
Escutar uma informao

99
Na especificao conceitual do modelo de interao o designer pode limitar-se a uma
descrio informal, como mostrado acima.
importante ressaltar que estamos chamando de comando as
interaes necessrias para um nico comando. Existe uma associao
direta de um comando para cada funo da aplicao. O comando
requer um conjunto de interaes para que uma certa funo seja
controlada. Ele pode ter diversos efeitos sobre a funo como veremos
mais adiante. Se para uma determinada meta que o usurio tenha ele
necessite de vrias funes da aplicao, ele precisar realizar as
interaes de cada comando de funo.
As diversas interaes que o usurio tem de realizar normalmente so
composies de interaes bsicas. Ele pode realizar, por exemplo, uma
seqncia de acionamentos para comandar uma determinada funo.
Em outra situao o comando de funo poderia ser composto pela
repetio de uma digitao de valor mais o acionamento de um widget.
Podemos identificar alguns tipos de estruturas de interaes. So
elas:
Seqncia - quando as interaes bsicas so realizadas numa seqncia especfica
Seleo - quando o usurio seleciona uma dentre vrias opes de interao
Repetio - quando as interaes bsicas so realizadas de forma repetitiva
Agrupamento - quando as interaes bsicas podem ser realizadas em qualquer
ordem de seqncia
Combinao - quando as interaes bsicas devem ser realizadas de forma
interdependente ou simultnea (dependncia temporal)
A seqncia uma das estruturas mais utilizadas. Ela determina que o usurio deve seguir
uma seqncia especfica de interaes. Por exemplo, se para acionar a funo definir
tamanho da pgina o usurio precisa informar primeiro o tamanho e depois mandar iniciar
a execuo o designer pode especificar que o comando tem uma estrutura sequencial
composta pelas interaes digitar tamanho e acionar boto iniciar.
A seleo pode ser utilizada quando o designer quer dar ao usurio a
opo de escolher alguma interao. Para a funo do exemplo anterior
o usurio poderia ter a opo de escolher entre acionar o boto iniciar e
acionar o boto cancelar no comando de funo.
A repetio deve ser utilizada quando o comando requer que uma
interao ou uma estrutura de interaes seja repetida para que a
funo seja executada. O exemplo mais comum a repetio do clique
com o mouse (duplo clique). Um outro exemplo de repetio seria um
comando para a funo definir margens no qual o usurio tivesses que
repetir a interao digitar distncia para cada uma das quatro margens
da pgina.
O agrupamento ocorre quando o usurio tem a sua disposio diversas
interaes e ele pode realiz-las sem preocupar com a ordem. Por
exemplo, para um comando para a funo imprimir o usurio pode fazer
as interaes digitar nmero de cpias e digitar o nome do documento,
em qualquer ordem.

100
A combinao determina, por exemplo, que o usurio deve ter que
realizar as interaes pressionar tecla SHIFT e mover o mouse para
comandar uma funo.
Ateno! A grande maioria das aplicaes existentes foram concebidas
e especificadas sem estas noes em mente. Estamos aqui fazendo uma
proposta de como as coisas poderiam ser para que o modelo conceitual
da aplicao fosse melhor estruturado e mais lgico, possibilitando que
os sistemas pudessem ser mais facilmente utilizados e aprendidos.

5.3.2 A interao com funes da aplicao

O nosso modelo de interao descrito em funo dos casos de uso. Para cada caso de uso
temos associada a ele uma funo da aplicao que deve ser implementada pelo software. A
funo da aplicao uma entidade conceitual que pode ser implementada por um ou mais
componentes de software -- funes, procedimentos, mtodos de objetos ou qualquer forma
de implementao computacional. A funo da aplicao algo que o sistema oferece para
que o usurio realize uma determinada tarefa para atingir as suas metas.
A funo da aplicao deve estar sob o controle do usurio. ele quem
deve tomar a iniciativa de quando a execuo da funo deve ser
iniciada, interrompida, cancelada, terminada e outras opes de
controle operacional. O designer deve determinar a maneira como o
usurio pode controlar cada funo e quais as opes de controle sero
fornecidas. So exemplos de controle operacional iniciar, interromper,
continuar, concluir, cancelar, desistir e outros.
Iniciar refere-se a ativao da funo.
Interromper usado quando possvel fazer uma pausa na execuo e o continuar
permite que a execuo seja continuada do ponto em que foi interrompida.
Concluir (ou finalizar) pode ser usado em funes que ficam repetidamente
executando algo at que o usurio deseje terminar.
Desistir usado para permitir ao usurio desistir da execuo da funo, antes que
ela seja iniciada.
Cancelar usado para o usurio cancelar a execuo. (Ateno! No Windows o
cancelar no usado com este propsito, mas como desistir).
O designer pode especificar outros controles que sejam convenientes para a funo da
aplicao que ele esteja projetando. Ele deve ainda determinar como cada uma destas
opes ele deve ser controlada pelo usurio, isto , qual ao o usurio deve fazer.
Por exemplo, na funo da aplicao sacar dinheiro o usurio pode ter as
opes de iniciar ou desistir, antes de iniciar e cancelar aps ele ter
mandado iniciar. Estas opes podem ser acionadas atravs de teclas ou
de botes.
Alm do controle operacional, o usurio deve fornecer as informaes
necessrias para a execuo da funo. Estas informaes so os
operandos da funo da aplicao. Existem diversas formas do usurio
fornecer informaes (os operandos) para cada funo da aplicao. O

101
designer deve verificar quais operandos so necessrios e de que
maneira o usurio ir fornecer cada informao.
So exemplos de operandos senha do cliente e o nmero da conta e o
valor de saque na funo sacar dinheiro. Os valores de vendas e compra
necessrios para o clculo de lucro so tambm exemplos de operandos.
Cada funo da aplicao pode estar em um ou mais estados como
vimos na seo anterior. O designer pode optar por mostrar ao usurio
cada estado no qual a funo est. O resultado final produzido por cada
funo tambm deve ser mostrado ao usurio.

5.3.3 Exemplo de especificao de modelos de interao

Utilizando os conceitos introduzidos acima, vamos fazer a especificao de comandos para
trs funes da aplicao. Esta especificao ser feita de maneira informao utilizando os
conceitos de comando de funo e interao, estruturas de interao. Cada uma das
especificaes apenas uma possibilidade dentre vrias possveis. Ela reflete a deciso do
projetista.
a. Comando para a funo da aplicao consultar livro para um sistema
de biblioteca.
Para o usurio consultar um livro ele deve primeiro fornecer informaes
sobre o autor, o ttulo e o cdigo ISBN. Estas informaes so os
conceitos do domnio necessrios para que a busca seja realizada. Eles
so os operandos da funo.
Aps fornecer os valores dos operandos, o usurio pode escolher entre
comandar o incio da busca, desistir de fazer a consulta, ou interromper
a busca na base de dados.
Utilizando as estruturas vistas acima e algumas da interaes bsicas,
podemos descrever este comando informalmente como:
Comando Consultar Livro {
Seqncia {
Agrupamento {
Fornecer informao Autor
Fornecer informao Ttulo
Fornecer informao ISBN
}
Seleo {
Acionar Iniciar
Acionar Desistir
Acionar Parar
}
}
}
Na seo 5.3, veremos como este modelo de interao pode ser traduzido em diferentes
interfaces.
b. Comando para a funo imprimir arquivos para um gerenciador de
arquivos.

102
Para comandar a funo que imprime arquivos (num suposto
gerenciador de arquivo) o usurio deve fornecer os operandos da funo
para em seguida selecionar o controle de execuo da funo. Isto deve
ser feito em seqncia. O projetista inicialmente optou por enviar uma
mensagem direta para o usurio indicando o que ele fazer (Veja). A
seqncia e a mensagem so estruturados num agrupamento, pois no
importa a ordem que o usurio faa isto.
O comando requer que o usurio fornea o nome do arquivo a ser
impresso, o nome da impressora e o nmero de cpias. O usurio deve
poder escolher dentre as impressoras disponveis e tambm configurla. O designer decidiu que o usurio apenas pode realizar os comandos
de controle aps ter fornecidos os dados. Neste caso os grupos de
interaes para fornecimentos dos dados e controle operacional devem
estar estruturados com uma seqncia. O fornecimento dos dados pode
ser realizado em qualquer ordem (agrupamento). Para fornecer o nome
do arquivo o usurio pode escolher entre digitar o nome diretamente ou
selecionar de uma lista de nomes de arquivos (seleo). Para configurar
uma impressora necessrio escolh-la para ativar a mensagem de
comando configurar impressora. Esta dependncia entre as duas aes
do usurio requer a utilizao da estrutura combinao. O nmero de
cpias deve ser fornecido diretamente.
Aps ter fornecido os dados, o usurio pode escolher o controle
operacional da funo desejado. A funo imprimir permite os controles
iniciar, parar, interromper, continuar e desistir. O usurio deve selecionar
(seleo) cada controle e acionar a opo correspondente.
Comando de funo Imprimir
Agrupamento {
Veja Para imprimir voc deve fornecer os dados, e, em seguida selecionar o
controle da funo que voc deseja acionar.
Sequencia {
Agrupamento {
Seleo {
Fornecer Informao Nome do Arquivo
Seleo Informao Nome do Arquivo
}
Combinao {
Seleo Informao Nome da impressora
Acione Mostrar Comando de Funo Configurar impressora
}
Fornecer Informao Nmero de cpias
}
Seleo {
Acione Iniciar
Acione Parar
Acione Interromper

103
Acione Continuar
Acione Desistir
}
}
}
Tambm na seo 5.3 apresentaremos uma interface que satisfaa esta especificao.

5.3.4 Especificando o modelo de interao com diagrama

de interao UML simplificado
O diagrama de interao mais um dos diagramas da UML (Linguagem de Modelagem
Unificada) que utilizaremos. Para a especificao do modelo de interao usurio-sistema
utilizaremos uma verso simplificada que poder ser extendida mais adiante quando
quisermos expressar a interao entre os componentes (internos) do software. Na verso
simplificada, modelaremos apenas a interao (externa) entre usurio e as funes da
aplicao.
Alm disto, utilizaremos apenas o diagrama de seqncia de
interao que uma das duas formas de diagramas de interao. O
outro, o diagrama de colaborao, desnecessrio para a interao
usurio-sistema uma vez que eles so apenas os dois nicos agentes
colaboradores.
O diagrama de seqncia de interao tem por objetivo descrever, como
o prprio nome indica, a seqncia de interaes entre o usurio e o
sistema ao longo do tempo. Podemos utilizar o diagrama para descrever
a seqncia de interaes bsicas que compem um comando de
funo, bem como para modelar toda a interao com as diversas
funes da aplicao.
Uma limitao do diagrama de seqncia no permtir descrever a
estrutura de interaes que vimos na seo 5.3.1. Tambm no
possvel diferenciar as formas de mensagens que o sistema envia para o
usurio. possvel fazer adaptaes no diagrama para especificar as
estruturas.
O diagrama representa o "tempo de vida" de cada uma dos agentes por
uma linha de tempo vertical. A interao entre os dois agentes (usurio
e sistema) representada por setas na direo da informao que
enviada.
Por exemplo, o comando de funo para definir tamanho, composto pela
seqncia de interaes bsica digitar tamanho e acionar (boto) OK. No
diagrama estas duas interaes so representadas por setas na direo
do usurio para o sistema. No diagrama estamos representando por uma
barra vertical o "tempo de vida" do sistema.

104

6 Design de Interfaces de
Usurio
6.1 Interfaces de Usurio
Antes de estudarmos como conceber e projetar as interfaces de usurio de um sistema
computacional, preciso conhecermos alguns conceitos importantes relacionados com a
rea. Esta seo define o que so as interfaces de usurio, seus objetivos e apresenta alguns
estilos de interao que podem ser utilizados para concretizarmos o modelo conceitual de
interao visto na seo anterior.

6.1.1 Para que serve a Interface de Usurio?

O termo interface aplicado normalmente quilo que interliga dois sistemas.
Tradicionalmente, considera-se que uma interface homem-mquina a parte de um artefato
que permite a um usurio controlar e avaliar o funcionamento do mesmo atravs de
dispositivos sensveis s suas aes e capazes de estimular sua percepo. No processo de
interao usurio-sistema a interface o combinado de software e hardware necessrio para
viabilizar e facilitar os processos de comunicao entre o usurio e a aplicao. A interface
entre usurios e sistemas computacionais diferencia-se das interfaces de mquinas
convencionais por exigir dos usurios um maior esforo cognitivo em atividades de
interpretao e expresso das informaes que o sistema processa [Norman 86].
Segundo Moran, a interface de usurio deve ser entendida como sendo a
parte de um sistema computacional com a qual uma pessoa entra em
contato fsica, perceptiva e conceitualmente [Moran 81]. Esta definio
de Moran caracteriza uma perspectiva para a interface de usurio como
tendo um componente fsico, que o usurio percebe e manipula, e outro
conceitual, que o usurio interpreta, processa e raciocina. Moran e
outros denominam este componente de modelo conceitual do usurio.
A interface tanto um meio para a interao usurio-sistema, quanto
uma ferramenta que oferece os instrumentos para este processo
comunicativo. Desta forma a interface um sistema de comunicao.
Quando se considera a aplicao como mquina(s) virtual(is), a interface
pode ser considerada ainda como um ambiente virtual para aes.

6.1.2 Objetivos das Interfaces de Usurio

Para que o usurio possa utilizar o sistema com sucesso ele deve saber quais as funes da
aplicao so oferecidas pelo sistema e como ele pode interagir com cada uma delas, isto ,
qual o modelo conceitual da aplicao o designer concebeu para ele.
A interface de usurio tem dois objetivos fundamentais:

105
1. Determinar como o usurio pode efetivamente interagir com o sistema,
desenvolvendo uma interface que permita ao usurio interagir de acordo com o
modelo (conceitual) de interao.
2. Mostrar para o usurio o que ele pode fazer, isto , quais as funes da aplicao o
sistema oferece, e quais os comandos de funes e mensagens auxiliares que
compem o modelo de interao.
O design de interfaces de usurio um dos pontos da rea de pesquisa Interao HumanoComputador (Human-Computer Interaction). Tradicionalmente, os pesquisadores desta
rea preocupam apenas com o primeiro destes dois objetivos. Existe uma abordagem
completar, chamada de Engenharia Semitica, que se preocupa em como comunicar o
modelo de interao para o usurio.
Para atingir estes dois objetivos, o design de interfaces de usurio a
etapa do desenvolvimento de software que deve:
1. traduzir o modelo de interao - os comandos de funo e mensagens auxiliares - de
cada funo de aplicao numa interface de usurio.
2. comunicar a funcionalidade e o modelo de interao associado a cada funo da
aplicao atravs da interface de usurio
A seguir vamos apresentar diretrizes para o design de interfaces de maneira que estes dois
objetivos possam ser atingidos. Antes, porm, vamos discutir as diferentes maneiras de
interao entre o usurio e o sistema.

6.1.3 Software e Hardware da Interface

A interface possui componentes de software e hardware. Os componentes de hardware
compreendem os dispositivos com os quais os usurios realizam as atividades motoras e
perceptivas. Entre eles esto a tela, o teclado, o mouse e vrios outros. com o hardware
da interface que o usurio entra em contato direto. Alguns dipositivos destinam-se a
veicular mensagens do sistema para o usurio e so chamados de dispositivos de sada. Os
dispositivo de entrada permitem ao usurio fornecer mensagens para o sistema.
O software da interface a parte do sistema que implementa os
processos computacionais necessrios para:
controle dos dispositivos de hardware,
construo dos objetos de interfaces (os widgets) com os quais o usurio tambm
pode interagir,
gerao dos diversos smbolos e mensagens que representam as informaes do
sistema, e
interpretao dos comandos dos usurios.
As interfaces grficas, tambm chamadas de GUI (Graphical User Interface)ou de WIMP
(Windows, Icons, Menus, Pointer), requerem rotinas de software bastante complexas para
que os widgets possam ser desenhados e as aes do usurio movendo e clicando com o
mouse sobre a tela possam ser implementadas. Os programas que implementam estas
interfaces grficas podem ser construdos com ferramentas de interfaces.

106
O principal exemplo de ferramentas de interfaces so os sistemas de
janelas. Eles so os responsveis, junto com o sistema operacional, a
controlar os dispositivos de hardware e fazer o gerenciamento das
janelas. o gerenciador de janelas que controlam a sobreposio de
janelas que exibem diversas aplicaes independentes. O usurio pode
minimizar ou maximizar, trazer para frente ou enviar para trs. Quem
desenvolveu cada aplicao no precisa ficar se preocupando com isto.
O gerenciador controla estas tarefas. Ele tambm o responsvel em
verificar se ocorreram eventos nos dispositivos de entrada e repassar
cada ocorrncia para a aplicao especfica.
Um outro exemplo de ferramenta so as rotinas de bibliotecas (classes
ou funes) que fazem o desenho de botes, janelas, menus, cones,
texto e diversos outros widgets de interfaces. Estas rotinas devem
tambm interpretar as aes que o usurio realiza e dar o tratamento
adequado a elas. Estas bibliotecas, chamadas de toolkits, so
ferramentas de programao. O programadores precisam conhecer a
Interface com o Programa da Aplicao (API) para utilizar as
diversas classes, funes e estruturas de dados disponveis e incorporlas ao programa
Existem ferramentas mais avanadas que permitem ao usurio montar
os widgets arrastando-os para janelas da interface. Com estas
ferramentas de design o projetista no precisa programar a interface
diretamente. A ferramenta gera o cdigo a ser executado.
A utilizao de ferramentas permite que as interfaces mantenham a
mesma aparncia e comportamento mantendo o mesmo padro, como
veremos na prxima seo.
A figura abaixo mostra a arquitetura global de um sistema interativo.
Nela podemos observar o hardware e o software da interface e como
eles interagem com o restante do sistema.

Para maiores detalhes sobre ferramentas de software de interfaces de

usurio veja notas de aula do curso de projeto de interfaces de usurio cap 3.

107

6.1.4 Estilos de interao

Existem diversas maneiras pela qual o usurio pode interagir com o sistema e diversos tipos
de interfaces que podem viabilizar estes modelo de interao. Na literatura estas diferenas
so chamadas de estilos ou paradigmas de interao. Diversos estilos so identificados
pela literatura.

Linguagens de comandos
A interfaces baseadas em linguagens de comandos proporcionam ao usurio a possibilidade
de enviar instrues diretamente ao sistema atravs de comandos especficos. As linguagens
de comandos foram o primeiro estilo de interao a ser usado amplamente. Este estilo
caracteriza-se por possibilitar ao usurio construir comandos atravs do teclado (hardware
da interface) que devem poder ser interpretados pelo software da interface para que funes
especficas da aplicao sejam ativadas. Os comandos podem ser produzidos pelo
acionamento de teclas de funes especiais, ou pelo acionamento de uma tecla de caractere,
ou pela estruturao delas. Um tipo de estruturao especial aquele no qual teclas so
acionadas para produzir palavras de comandos que podem ser combinadas em sentenas de
acordo com a gramtica que define a linguagem. Este estilo de interao visa possibilitar
que a linguagem de comandos aproxime-se daquela falada pelos usurios.
As linguagens de comandos podem ser extremamente simples ou ter complexidade
equivalente a de linguagens de programao. Linguagens de comandos elementares
associam um vocabulrio de comandos a funes especficas do sistema sem permitir
combinaes dos mesmos. Um exemplo de linguagem de comando elementar a do editor
de texto vi, mostrado na figura abaixo.

Para permitir uma maior flexibilidade e um maior poder expressivo os comandos podem ser
estruturados de acordo com regras de gramticas regulares, livre-de-contexto, sensvel ao
contexto ou irrestritas. O grau de expressividade do usurio diretamente proporcional
capacidade do software da interface de interpretar estes comandos de acordo com a
gramtica e a semntica que define a linguagem. A interface com o sistema operacional

108
Unix atravs do shell exemplo deste estilo no qual a linguagem de comandos bastante
sofisticada permitindo ao usurio construir comandos que podem ser combinados de
maneira bastante flexvel. A figura abaixo ilustra a utilizao de comandos do shell do
Unix.

As linguagens de comandos determinam apenas qual devem ser os comandos que o usurio
deve utilizar para interagir com o sistema sem especificar como deve ser o estilo de
interao a ser utilizado pelo sistema para se comunicar com o usurio. Esta comunicao
sistema-usurio feita atravs da tela do computador (hardware da interface) que
possibilita tambm um feedback imediato das aes do usurio. Nas interfaces baseadas em
linguagens de comandos o usurio quem toma a iniciativa da interao cabendo ao
sistema fornecer o resultados dos comandos.
As linguagens de comandos so poderosas em oferecer acesso direto funcionalidade do
sistema e em permitir maior iniciativa do usurio e uma maior flexibilidade na construo
dos comandos atravs da variao de parmetros e combinao de palavras e sentenas.
Contudo, este poder e flexibilidade implicam em uma maior dificuldade dos iniciantes em
aprender e utilizar o sistema. Os comandos e a sintaxe da linguagem precisam ser
relembrados e erros de digitao so comuns mesmo nos mais experientes. A falta de
padronizao nos diversos sistemas um fator importante na dificuldade de utilizao deste
estilo. Usurios especialistas, no entanto, conseguem maior controle do sistema e
produtividade atravs de interfaces baseadas em linguagens de comandos.

Menus
Nas interfaces orientadas por menus o conjunto de comandos de funes oferecidas pela
aplicao mostrada ao usurio atravs da tela e cabe ao usurio selecionar uma delas
atravs do mouse, de teclas alfanumricas ou de teclas especiais. Como as funes e a
maneira de acion-las esto visveis na forma de opes para o usurio selecionar existe
uma demanda maior pelo processo de reconhecimento ao invs de recordao com no caso
das interfaces baseadas em comandos.

109

Normalmente o nmero de opes de comandos grande o suficiente para ser mostrado de

uma nica vez na tela da interface. Existem diversas tcnicas para se agrupar e apresentar
as opes de menus. A mais comum a categorizao hierrquica na qual as opes so
agrupadas em categorias de maneira hierrquica. A escolha dos nomes dos grupos e de cada
opo do menu fundamental para que o usurio possa escolher aquelas que permite-o
atingir as suas metas.
As interfaces orientadas por menus podem ser textuais ou grficas. Nas
interfaces textuais (ou baseadas em caracteres) as opes so descritas
atravs de palavras na linguagem do usurio que representem as
funes do sistema correspondentes ao comandos. O comando
acionado atravs de uma tecla ou nmero associado opo do menu.
Nas interfaces grficas os menus podem ser compostos por palavras ou
por signos grficos especficos. Existem alguns tipos especficos de
menus nas interfaces grficas como menus de barra, pull-down, e popup. Discutiremos estes estilos mais adiante quando apresentarmos os
principais tipos de widgets.
Na medida que aumenta a funcionalidade de um sistema aumentam o
nmero de opes que devem ser colocadas num menu. A estratgia do
designer para evitar que os menus fiquem muito saturados de opes
subdividi-los e organiz-los em grupos. Os menus podem ser
organizados de maneira hierrquica, linear ou em rede. Uma das
principais desvantagens do uso de menus nestes casos que o usurio
pode ficar perdido ao navegar por inmeras estruturas de menus.

Linguagem Natural
Linguagem Natural (LN) a expresso utilizada para se referir de maneira genrica
lngua que o usurio domina, podendo ser o portugus, o francs, o ingls ou qualquer das
linguagens existentes. Atravs de interfaces em linguagem natural o usurio pode interagir

110
com o sistema na sua prpria linguagem. Ao contrrio das linguagens por comandos
quando o usurio tem que aprender uma linguagem artificial que seja mais facilmente
processada por computadores, nas interfaces que processam linguagem natural o maior
esforo fica a cargo do computador que deve interpretar e gerar sentenas na linguagem
natural do usurio.
A interao em LN bastante atrativa para usurio com pouco ou
nenhum conhecimento em computao. Entretanto ela no se aplica a
todos os tipos de sistemas. Sistemas de consulta a informaes e
sistemas baseados em conhecimento so exemplos onde a utilizao de
interfaces em LN bastante interessante. No primeiro caso por
possibilitar que usurio no especialistas possam fazer consultas em sua
prpria lngua. No segundo caso para que o sistema gere explicaes a
partir da sua base de conhecimento, uma vez que a LN expressiva o
suficiente para a descrio do raciocnio artificial do programa, o que
no seria possvel com outros estilos de interao.
Um programa que processa linguagem natural bastante complexo.
Esta justamente uma das maiores limitaes deste tipo de interface. O
exemplo mostrado na figura abaixo apresenta um trecho de interao
onde o usurio faz referncias anafricas e utiliza-se de elipses
dificultando a interpretao e a gerao das respostas.

A maioria das interfaces em LN existentes tm sido utilizadas para

alguns sistemas especficos de maneira que o escopo do vocabulrio e
das sentenas seja bastante limitado, reduzindo a complexidade do
processo de interpretao e gerao das sentenas.
Menus podem ser associados LN na construo de interfaces mais
simples. Nestes casos, menus de palavras so apresentados ao usurio
de maneira que ele possa ir construindo sentenas em LN. Isto garante
que usurio forme apenas as sentenas que possam ser interpretadas
pelo sistema. Alm disso, os menus motivam o usurio a formular suas

111
perguntas apresentando termos especficos do domnio que o usurio
possa no ter memorizado.
Uma importante desvantagem deste estilo de interao est na
impreciso e na ambigidade da prpria LN que dificulta a sua aplicao
em sistemas onde se necessita de preciso e determinismo na interao
com o usurio.

Preenchimento de formulrio
Interfaces no estilo de preenchimento de formulrio so utilizadas principalmente para
entrada de dados em sistemas de informao. Estas interfaces apresentam para o usurio
uma tela que lembra um formulrio em papel solicitando informaes especfica do
domnio da aplicao. Nestes casos o modelo de interao bsico o fornecimento de
dados para os campos ou registros de uma base de dados. Os modelos de formulrios
muitas vezes esto baseados nos formulrios em papel que os usurio estavam acostumados
a utilizar antes da implantao do sistema, facilitando o aprendizado do modelo de
interao.
Este estilo de interao tambm pode ser utilizado para consulta a base de informaes,
onde o usurio preenche um formulrio que serve como mscara para a busca de dados na
base.

Estas interfaces so, em geral, fceis de aprender e no requerem flexibilidade na

funcionalidade. Os aspectos principais que vo influenciar na usabilidade do sistema so a
produtividade do usurio, a sua satisfao e o esforo fsico provocado pelo sistema, uma
vez que estes sistemas so projetados para que os usurios forneam um grande nmero de
dados ao longo de um dia de trabalho. Estas interfaces devem facilitar a correo de erros
de digitao e a verificao dos dados digitados atravs de tcnicas como dgitos
verificadores e totalizao de valores.

Manipulao Direta

112
Interfaces de manipulao direta so aquelas que permitem ao usurio interagir diretamente
com os objetos da aplicao (dados ou representaes de objetos do domnio) sem a
necessidade de comandos de uma linguagem especfica. Na manipulao direta os
comandos so aes que o usurio desempenha diretamente com objeto do sistema.
As interfaces grficas que se utilizam da metfora do desktop, como as
do Apple Macintosh, baseada no Xerox Star, e o Microsoft Windows
proporcionam um estilo no qual os usurios podem interagir com o
gerenciador de arquivos do sistema operacional atravs de manipulao
de cones que representam arquivos, diretrios, discos e outros
componentes computacionais. O usurio comanda atravs de aes de
arrastar e soltar (drag-and-drop) os cones utilizando o mouse ou outro
dispositivo equivalente.

Embora os primeiros exemplos do que convencionou-se a se chamar de

manipulao direta surgiram com a tecnologia de interfaces grficas e
dispositivos apontadores como o mouse, a manipulao direta pode
ocorrer em interfaces com tecnologias de telas de caracteres.

WIMP - (Windows, Icons, Menus e Pointers)

O estilo de interao WIMP, um acrnimo em ingls para Janelas, cones, Menus e
Apontadores, permite a interao atravs de componentes de interao virtuais denominado
de Widgets. Este estilo implementado com o auxlio das tecnologias de interfaces
grficas, que proporcionam o desenho de janelas e do controle de entrada atravs do teclado
e do mouse em cada uma destas janelas. Os softwares de interfaces que implementam estes
estilos permitem a construo de cones que permite a interao atravs do mouse,
comportando-se como dispositivos virtuais de interao.

113

O WIMP no deve ser considerado um nico estilo, mas a juno de uma tecnologia de
hardware e software, associado aos conceitos de janelas e de widgets que permite a
implementao de vrios estilos. Nas interfaces WIMP possvel ter os estilos de menus,
manipulao direta, preenchimento de formulrio e linguagem de comandos. WIMP pode
ser considerado um modelo ou um framework de interface apoiado pela tecnologia de
interfaces grficas (GUI).
possvel implementar o estilo WIMP usando tecnologia de telas no
grficas. Entretanto, tm-se a limitao de no se poder cones grficos
e se ter um baixo nvel de resoluo que limita a quantidade de objetos
de interface que pode ser mostrada para o usurio.

Padres para Interfaces WIMP

Padres de interfaces so um conjunto de normas e regras que foram propostas de maneira
a se uniformizar e aumentar a consistncia da aparncia e comportamento (look and feel)
das interfaces grficas WIMP.
A aparncia e o comportamento das interfaces WIMP a expresso
utilizada para o padro visual que cada widget de um interface deve
obedecer de maneira que eles possam ser facilmente interpretados pelo
usurio. Por exemplo, um boto de acionamento deve ter a mesma
aparncia em todas as instncias de interfaces. Da mesma maneira,
cada widget deve obedecer a um comportamento padro, ou seja, para
cada tipo de acionamento do usurio ou evento do sistema ele deve se
comportar de forma previsvel. Este comportamento refere-se s
modificaes na aparncia do widget durante o processo de interao.
So exemplos de padres o OSF/Motif, o OpenLook, o Windows 3.11 e o
Windows 95. A grande vantagem que as diversas interfaces
construdas obedecendo a um padro sero consistentes umas com as
outras. Entretanto, o uso de determinado padro no garante que a
interface tenha alta usabilidade.

114
O padro OpenLook foi proposto pela Sun MicroSystems para as
interfaces grficas das estaes grficas no ambiente SunOS (uma
verso da Sun para o Unix). At metade da dcada de 90 era o padro
adotado pela Sun, quando foi substitudo pelo Motif. O Motif foi proposto
pela Open System Foundation (OSF) para ser um padro internacional.
Diversos fabricantes aderiram a esta proposta, inclusive a Sun
Microsystems. Os produtos da Microsoft e de outros fabricantes que
utilizam o ambiente operacional Microsoft Windows seguem o padro de
mesmo nome. As diferentes verses do MS Windows 3.1 e 95
apresentam padres de interfaces bastante diferentes. Entretanto cada
aplicao que executada em cada uma destas verses possuem
aparncia e comportamento padronizados, como est ilustrado nas
caixas de dilogo para a mesma funo imprimir do Netscape. Nas
figuras a seguir.

115
O padro no diz respeito a como o software da interface
implementado. Apenas aspectos da interao, justamente a aparncia e
comportamento, que determinam o que o usurio deve interpretar e
como deve agir. Uma das grandes vantagens de um padro manter
consistente a aparncia e o comportamento em diversas aplicaes
facilitando este processo de interao usurio-sistema.
Um padro deve ser implementado pelo software da interface. A
implementao pode utilizar-se de ferramentas de software que auxiliam
na codificao dos widgets que seguem um determinado padro. Mais
adiante, veremos os diversos tipos de ferramentas para interfaces que
oferecem apoio implementaao de interfaces de um determinado
padro. Existem diferentes ferramentas que permitem implementar um
mesmo padro.

6.2 Design de Interfaces de Usurio

Nesta seo, vamos abordar o design de interfaces de usurio. Este
assunto bastante extenso para ser abordado de maneira exaustiva
nesta seo. Longe disso. Vamos apenas discutir alguns pontos
principais com o objetivo de dar uma viso geral da rea.

6.2.1 A Engenharia Semitica de Interfaces de Usurio

O foco principal de nossa abordagem para o desenvolvimento de software tem sido as
funes da aplicao, chamadas de casos de uso na especificao de requisitos. Cada
funo opera sobre conceitos do domnio e sua execuo controlada por comandos de
funo.
Vamos abordar o design de interfaces com a perspectiva que o designer
deve comunicar qual foi a soluo que ele projetou para o usurio para
que ele possa atingir as suas metas. Esta abordagem recebe o nome de
Engenharia Semitica, pois aborda o processo de construir uma
mensagem utilizando diversos tipos de signos: textos, cones, smbolos
grficos, sons, gestos, etc. A interface deve ser vista como a mensagem
que o designer construiu para comunicar ao usurio o modelo conceitual
da aplicao.
A Engenharia Semitica , portanto, uma abordagem para o design de
interfaces de usurios na qual o sistema computacional visto como um
meio de comunicao atravs do qual o designer envia, para o(s)
usurio(s) uma mensagem cuja expresso a interface e o contedo
(1) o que o usurio pode fazer com o sistema e (2) como ele pode
interagir com o sistema. Esta mensagem no uma mensagem simples
como uma palavra ou frase, mas uma mensagem bastante complexa,
pois ela dinmica, interativa, multimdia, multi-cdigo e
metacomunicativa. Ela tambm unidirecional, pois vai sempre do
designer para o usurio.

116
Por exemplo, quando o designer quer que o usurio pressione com o
mouse uma determinada rea da tela para acionar a execuo da funo
imprimir ele pode utilizar o widget boto de acionamento (tambm
conhecido como command button) com um rtulo escrito Imprimir. Este
widget tem uma funo comunicativa que diz algo equivalente a
"pressione aqui para ativar a funo Imprimir". Da mesma forma o
widget caixa de texto comunica ao usurio "digite um texto". Uma
moldura pode ser utilizada para comunicar que os elementos inseridos
em seu interior pertencem a uma mesma categoria. A janela caixa de
dilogo pode comunicar quais so as interaes que compem um
comando e que necessrias para a execuo de funo da aplicao.
A perspectiva da Engenharia Semitica que cada elemento presente
na interface, cones, botes, sons, palavras ou qualquer outro signo tem
o potencial de comunicar algo. Cada deciso de design que o designer
toma tem um impacto na maneira como o usurio interpreta aquilo que
ele quis dizer. Semitica a disciplina que estuda os signos e os
sistemas de significao e de comunicao. A Engenharia Semitica tem
por objetivo apresentar tcnicas, mtodos e formalismos que apiem o
usurio a construir a interface como sendo uma mensagem formada por
signos de diversas natureza (um sistema de signos ou sistema
semitico).
O design de interfaces na abordagem da Engenharia Semitica consiste
em:
projetar os comandos de funo para cada uma das funes,
comunicar para o usurio quais as aes ele deve fazer em cada comando,
elaborar representaes para os conceitos do domnio,
comunicar para o usurio quais as funes o sistema oferece e como acessar cada
comando.
Vejamos a seguir algumas diretrizes que auxiliam o design de interface nesta abordagem.
esta diretrizes no so regras ou leis, mas dicas que auxiliam o designer. O princpio geral
que fundamenta toda esta abordagem que o designer tem que escolher qual o melhor
signo para comunicar aquilo que ele quer dizer ao usurio. Isto significa ainda que o
designer precisa conhecer o usurio para saber quais tipos de signos sero melhor
interpretados por ele.
Nas sees seguintes veremos conceitos e tcnicas para realizar cada
uma destas atividades.

6.2.2 Projetando comandos de funo

Para cada funo da aplicao devemos ter um comando de funo. Vimos na seo 4.2 que
o modelo de interao determina o conjunto de comando de funes da aplicao. Cada
comando formado por uma estrutura de interaes bsicas. O modelo conceitual de
interao descreve esta estrutura de interaes de maneira abstrata. Veremos agora como
projetar cada comando de funo utilizando os objetos de interfaces (widgets) da maioria
das ferramentas de interfaces grficas.

117

6.2.3 Comunicando comandos de funo

Uma vez que o designer tenha escolhido qual funo ele quer utilizar, a interface deve
permitir que ele controle a execuo de cada uma delas apresentando o comando de
funo.Cada comando deve comunicar as aes para o usurio fornecer operandos,
controlar a execuo e visualizar resultados. Vejamos cada um deles separadamente.
Em princpio, toda funo tem associada a si um comando de funo. O
comando mais simples possvel aquele que necessrio para ativar a
execuo de uma funo que no necessite de operando algum. Um
comando assim precisa ter uma nica interao bsica que pode ser
pressionar uma tecla ou pressionar um widget boto de comando.

6.2.4 Representando conceitos do domnio

O usurio quer que o sistema execute funes para modificar propriedades ou
relaciomentos de conceitos do domnio. Estes conceitos precisam ser representados para
que o usurio possa perceb-los. Por exemplo, o conceito cliente deve ser representado na
interface pelo seu nome completo (um texto). Uma outra interface pode represent-lo por
uma fotografia associada ao pr-nome.
O conceito de margem esquerda de uma pgina no Word representado
por uma linha pontilhada sobre a pgina indicando a distncia para a
borda esquerda. Este conceito tambm representado pelo nome
margem esquerda seguido de um nmero que representa o valor da
distncia para a borda.
O conceito pasta no Windows representado por um cone amarelo
representando uma pasta e por uma janela, quando o objetivo mostrar
o seu "contedo". O conceito de arquivo representado por cones que
representam o tipo do arquivo e pelo nome do arquivo. No MS-DOS, os
arquivos so representados pelo nome com at 8 letras seguido por um
ponto e mais trs letras representado o seu tipo.
A escolha do conceito no segue nenhuma regra especfica. A regra
geral que se deve escolher uma representao que seja mais familiar
ao usurio, isto , que permita ele entender o conceito associando-o a
seus conhecimentos prvios. Um recurso bastante utilizado o de
metfora. A metfora um recurso utilizado, por exemplo, quando se
quer falar sobre algo utilizando um conceito que j seja conhecido do
usurio. O desktop, as pastas e arquivos do Windows (originalmente do
Xerox Star) fazem parte de uma metfora para induzir o usurio a
realizar com o sistema as atividades que ele faz normalmente na sua
mesa do escritrio.

6.2.5 Organizando e Comunicando funes da aplicao

Normalmente um sistema apresenta dezenas ou centenas de funes da aplicao em um
software. Para que o designer comunique todos eles, ele precisa lanar mo de certos
recursos de apresentao.

118
O acesso aos comandos de funes podem ser organizados em menus.
Existem diversas formas de menus. Simples, Pull-down, Pop-up que
podem ser organizados de forma linear, hierrquica ou com um
hipertexto.

119

7 Design da Arquitetura de
Componentes de Software
Cada funo da aplicao que teve o seu comportamento descrito atravs modelos
conceituais deve ser agora descrita em termos de funes, classes, estruturas de dados, etc.,
chamados de componentes de software. Estes componentes que implementam cada funo
interagem entre si e com os componentes de outras funes da aplicao. Esta estrutura de
componentes interconectados entre si que formam o software recebe o nome de
arquitetura de componentes de software, ou simplesmente arquitetura de software.
Neste captulo veremos como o modelo conceitual da aplicao pode ser
implementado em termos de componentes de software e como
estruturar estes componentes de modo a definir a arquitetura do
software.
O que ser visto neste captulo:
7.1 Arquitetura de Software
7.2 Componentes de Software
7.3 Componentes lgicos
7.4 Princpios para o design da arquitetura de componentes
7.5 Modelando a arquitetura usando a UML
7.6 Estilos e Padres de design
7.7 Exemplos
Os conceitos tericos apresentados nas diversas sees deste captulo sero ilustrados a
partir de exemplos que apresentam arquiteturas diferentes para uma mesma funo da
aplicao. Utilizaremos a funo da aplicao Consulta Livro j introduzida em exemplos
do captulo anterior. Os exemplos esto descritos em pginas independentes para que
possamos ter uma viso global e fazer referncias diretas atravs de links a partir de cada
seo. Estaremos sempre sugerindo uma visita s pginas do exemplo.

7.1 Arquitetura de Software

A arquitetura de software uma especificao abstrata do funcionamento do software em
termos de componentes que esto interconectados entre si. Ela permite especificar,
visualizar e documentar a estrutura e o funcionamento do software independente da
linguagem de programao na qual ele ser implementado. Isto possvel se considerarmos
que o software pode ser composto por componentes abstratos - independentes da linguagem
- que juntos formam um software completo que satisfaz os requisitos especificados (a
funcionalidade). Estes componentes esto interligados ou interconectados de maneira a
interagir e cooperar entre si.
Alguns autores utilizam o termo configurao para se referir maneira
como os componentes esto interconectados. Estrutura e topologia
so termos utilizados no mesmo sentido. Para diferenciar a programao
do design da arquitetura de software pode-se utilizar, respectivamente,

120
os termos programao-em-ponto-pequeno (programming-in-thesmall) e programao-em-ponto-grande (programming-in-the-large).
O conceito de arquitetura de software comeou a surgir desde que
foram desenvolvidas as primeiras tcnicas para o particionamento de
programas. As tcnicas de modularizao e decomposio funcional, por
exemplo, introduzem os conceitos de funes, procedimentos, mdulos
e classes que permitem particionar um programa em unidades
menores. Estes pedaos, ou componentes, interagem entre si atravs de
chamadas de funo ou troca de mensagens, por exemplo, para que o
software funcione corretamente.
O particionamento do software em componentes oferece vrios
benefcios.
Permite ao programador compreender melhor o software
Possibilita que estas partes possam ser reutilizadas mais de uma vez dentro do
mesmo programa ou por outro programa
Podem ser gerenciadas mais facilmente quanto estiverem sendo executadas.
Os conceitos e a tecnologia de orientao a objetos consolidaram o
conceito de componentes e, conseqentemente, o de arquitetura de
software. Nos anos 90, a arquitetura de software passou a ser um
importante tpico de pesquisa. Atualmente, ela faz parte do processo de
desenvolvimento de software e dos programas dos cursos de engenharia
de software.
A arquitetura no descrita por um nico diagrama. Diversos diagramas
descrevem a arquitetura proporcionando diferentes vises do software.
Estas vises podem ser estticas ou dinmicas, fsicas ou lgicas. Os
exemplos que apresentamos neste captulo apresentam diversos
diagramas que descrevem a arquitetura do software.
A arquitetura pode descrever tanto a estrutura lgica do funcionamento
do software quanto a arquitetura fsica de componentes fsicos que
formam o software. A arquitetura lgica descreve o funcionamento
lgico do software em termos de funes, variveis e classes. A
arquitetura fsica descreve o conjunto de arquivos fontes, arquivos de
dados, bibliotecas, executveis e outros que compem fisicamente o
software. A seguir, veremos como os diversos tipos de componentes
formam o software.

7.2 Componentes de Software

O termo componente de software est bastante popular atualmente. Diversos autores e
desenvolvedores tm usado o termo com propsitos diferentes. Alguns autores utilizam o
termo componente para se referir a pedaos do cdigo fonte, como funes, estruturas de
dados e classes. Outros chamam de componentes instncias de classes (objetos) de um
programa que podem ser utilizadas por outras instncias. H ainda a denominao de
componentes para as bibliotecas de funes e bibliotecas de ligao dinmica.

121
Para entendermos melhor os diversos tipos de componentes utilizados
em engenharia de software vamos identificar alguns critrios de
classificao. Na nossa classificao utilizaremos os critrios de
componentes lgicos (ou funcionais) e fsicos, de tempo-dedesenvolvimento e de tempo-de-execuo.
O componente fsico aquele existe para o sistema operacional e para
outras ferramentas do sistema, normalmente na forma de arquivos. Eles
podem ser armazenados, transferidos de uma lugar para outro,
compilados, etc. O componente lgico ou funcional aquele que possui
uma utilidade para o funcionamento do programa.
O componente de tempo-de-desenvolvimento aquele utilizado durante
o desenvolvimento do software, enquanto o de tempo-de-execuo
aquele pronto para ser executado pelo sistema ou que est sendo
executado. Existem componentes lgicos e fsicos tanto de
desenvolvimento quanto de execuo.
Com base nestes critrios podemos categorizar os componentes em:
componentes de programa - so componentes lgicos de tempo-dedesenvolvimento fornecidos pelas linguagens de programao e que utilizamos para
construir um programa.
Ex.: tipos de dados, variveis, procedimentos, funes, classes, mdulos, pacotes dependem da linguagem de programao.
Descrevemos as solues nos nossos exemplos usando componentes lgicos. As
solues A e B utilizam variveis e funes. A soluo C utiliza classes.
componentes fsicos de desenvolvimento - so componentes fsicos tempo-dedesenvolvimento que contm os componentes lgicos. Eles so manipulados pelas
ferramentas de desenvolvimento (editores e compiladores) e pelo sistema
operacional.
Ex.: arquivos de cdigo fonte, arquivos de cdigo objeto, arquivos de declaraes
(.h), bibliotecas de componentes de programa (de ligao esttica).
As funes Ler( ) e Escrever( ) da soluo A dos exemplos fazem parte de uma
biblioteca de funes oferecida pelo compilador. Da mesma forma todas as funes
do Xview -- xv_create( ), xv_set( ), xv_get( ), xv_init( ), xv_destroy( ),
xv_main_loop( ) -- fazem parte da biblioteca libxview.a. O programa da soluo B
utiliza os arquivos .h xview.h, frame.h, panel.h que tambm so componentes
fsicos.
componentes fsicos de tempo-de-execuo - So os componentes instalao e
execuo que compem o sistema antes que ele seja executado. So os componentes
que obtemos ao adquirir o software.
Ex.: arquivos executveis, arquivos de configurao, arquivos de dados, bibliotecas
de ligao dinmica (DLL).
A biblioteca XView utiliza funes oferecidas por uma outra biblioteca que precisa
estar sendo executado ao mesmo tempo que a aplicao. Esta biblioteca de ligao
dinmica o XServer que oferece os servios necessrios para o desenho de janelas
e leitura dos eventos de entrada.

122

componentes lgicos de tempo-de-execuo - So os componentes lgicos que

existem quando o sistema est sendo executado ou que so criados a partir da
execuo de outros componentes. Podem ser de dois tipos:
o intraoperveis - quando so visveis apenas por componentes do mesmo
programa
Ex.: variveis, funes, objetos de programa.
o interoperveis - quando so visveis por componentes de diferentes
programa
Ex.: processos, threads, objetos CORBA, objetos COM.
O notificador uma funo do XServer incorporado ao programa durante a
execuo funo xv_main_loop( ).
O xv_main_loop um componente lgico de tempo-de-desenvolvimento
que faz parte da biblioteca libxview.a -- componente fsico de tempo de
desenvolvimento -- que responsvel pela interao em tempo-de-execuo
da funo notificador -- componente lgico de tempo de execuo -- que faz
parte do XServer, uma biblioteca de ligao dinmica -- componente fsico
de tempo de execuo.

Esta classificao no a nica possvel. Alm disso, existe um estreito relacionamento

entre os diversos tipos de componentes. Os componentes de programa so "manipulados" e
referenciados pelo programador durante o processo de programao. Aps o processo de
compilao e a sua posterior execuo eles se transformam em componentes lgicos de
tempo-de-execuo que so manipulados e referenciados por outros componentes
dinmicos. Os componentes de programas, ditos lgicos, precisam ser armazenados em
arquivos de cdigo fonte ou em bibliotecas - componentes fsicos de tempo-dedesenvolvimento.
Os componentes lgicos ou funcionais so aqueles que so utilizados
para que o software funcione como desejado. Eles so os componentes
que permitem que o software faa aquilo que foi especificado. Os
componentes fsicos no tm papel para a lgica do programa, i.e., para
o seu funcionamento. Eles oferecem o apoio necessrio para que o
software possa ser gerenciado pelo sistema operacional e pelas
ferramentas de desenvolvimento e instalao. Daqui por diante
concentraremos nossas atenes aos componentes lgicos do software.

7.3 Componentes lgicos

Grande parte dos componentes lgicos de um programa dependente da linguagem de
programao na qual ele ser escrito. Na etapa de design, entretanto, nosso objetivo
descrever o funcionamento do software independente de qual linguagem ele ser
implementado. Vamos utilizar componentes lgicos de programas num nvel mais abstrato,
independente da linguagem de programao.
No nvel abstrato do design da arquitetura, consideremos apenas como
tipos de componentes lgicos, as variveis, as funes ou
procedimentos, e as classes (e os mdulos). Consideramos que eles so
suficientes para projetarmos a arquitetura de componentes de software.

123
A varivel o componente responsvel pelo armazenamento de dados.
Cada varivel tem um nome que a identifica e o tipo de dados que
determina o que pode ser armazenado pela varivel.
A funo a unidade lgica que realiza uma ou mais tarefas especficas
modificando o estado de outros componentes de software,
especialmente as variveis. Cada funo deve se caracterizar por aquilo
que ela faz, isto , pelo servio que ela oferece. Cada funo
referenciada por um nome. A funo pode ter argumentos que
funcionam como interface de comunicao com outros componentes.
Estes argumentos podem ser para recebimento e/ou para o
fornecimento de dados. A interface de uma funo formada pelos seu
nome e seus argumentos. Uma funo pode agregar outras funes.
Neste caso as funes agregadas apenas existem para a funo que as
contm. Uma funo pode utilizar outras funes para poder realizar as
suas tarefas. A utilizao de uma funo por outra realizada atravs da
sua interface.
A classe o componente que agrega variveis e funes num nico
componente lgico. Esta agregao deve ser feita seguindo alguns
critrios especficos. As funes da classe operam sobre as variveis da
classe e estas por sua vez s podem ser alteradas pelo grupo de funes
associadas. Para os componentes externos classe apenas as funes
so visveis. Podemos dizer que a classe oferece uma srie de servios
para operar sobre os dados armazenados nas suas variveis. Cada
classe identificada por um nome e possui como interface uma srie de
funes que so oferecidas. As funes de uma classe podem utilizar
servios das funes de outra classe, mas no podem operar
diretamente sobre suas variveis.
O mdulo ou pacote agrega funes ou classes de acordo com
categorias especficas. Um mdulo funcional aquele no qual todos os
seus componentes esto unidos visando atingir um aspecto da
funcionalidade. Eles possuem dependncia funcional. Um mdulo de
servios aquele que agrega componentes que oferecem servios que
no tm necessariamente dependncia funcional. Por exemplo, um
mdulo com funes matemticas, um mdulos com classes para
objetos de interfaces grficas, etc. Cada mdulo possui um nome e uma
interface que contm as interface de todas as funes e classes que
esto nele contidas.
Os componentes lgicos oferecem recursos e restries para decidirmos
o que podemos construir para implementar o software. Na prtica estes
recursos podem variar de linguagem para linguagem, mas em geral,
eles so comuns a maioria das linguagens. Com os componentes
abstratos podemos nos concentrar na soluo sem preocupao com as
particularidades de cada linguagem. Entretanto, alguns componentes
no podero ser implementados diretamente em uma determinada
linguagem.

124
Existem diversos paradigmas de programao. Podemos citar os
paradigmas de programao procedimental, funcional, orientado a
objetos e lgica. No paradigma de orientao a objetos o programador
tem recursos que no encontra em linguagens no paradigma de
programao procedimental e funcional. Ao realizar o design da
arquitetura em termos de componentes o engenheiro pode optar apenas
pelos componentes lgicos que podero ser implementados pela
linguagem de programao a ser utilizada. Assim, pode-se optar por
utilizar apenas funes se a programao ser no paradigma
procedimental. Da mesma forma, pode-se considerar classes como
componente lgico se o paradigma de programao for orientado a
objetos. No vamos considerar o paradigma de programao lgica por
no ser muito utilizado em desenvolvimento de software.

7.4 Princpios para o design da arquitetura

e seus componentes
Uma engenharia se faz com mtodos, tcnicas, ferramentas, formalismos e princpios.
Diversos conceitos e princpios ligados a estes conceitos tm sido introduzidos ao longo da
histria da engenharia de software. Um princpio gira em torno de uma idia elaborada a
partir de experincias anteriores e que aponta um caminho ou soluo para os problemas no
desenvolvimento. Seguir um princpio no uma obrigao, mas uma grande chance de se
obter sucesso.
Vamos apresentar alguns princpios para o design da arquitetura do
software e de seus componentes que foram introduzidos na engenharia
de software e que so incorporados em diversas linguagens e
formalismos.

Abstrao
A abstrao a capacidade psicolgica que os seres humanos tm de se concentrar num
certo nvel de um problema, sem levar em considerao detalhes irrelevantes de menor
nvel. A abstrao deve ser utilizada como tcnicas de resoluo de problemas nas diversas
reas de engenharia. As linguagens de modelagem e de programao oferecem recursos
para que possamos trabalhar a abstrao.
No design da arquitetura esta tcnica fundamental. Nosso objetivo
encontrar uma soluo funcional de software em termos de
componentes abstratos, sem levar em considerao detalhes das
linguagens de programao.
A abstrao est presente em quase tudo na computao. O sistema
operacional oferece recursos que abstraem o funcionamento do
computador. Um programa escrito numa linguagem de programao
algortmica (Pascal ou C) oferece comandos que abstraem a maneira
como o computador executaria o comando em linguagem de mquina. O
conceito de funo permite abstrair os detalhes de implementao da

125
funo para que possamos nos concentrar apenas naquilo que a funo
faz. O uso de diagramas que descrevem o software oferece uma viso
abstrata do funcionamento, independente de como ele est
implementado.

Modularizao
A modularizao uma tcnica utilizada em diversas reas da engenharia para se construir
um produto que seja formado por componentes, os mdulos, que possam ser montados ou
integrados. Esta tcnica permite que o esforo intelectual para a construo de um
programa possa ser diminudo. Ela tambm facilita o processo de compilao e execuo de
um programa. Pode-se compilar componentes separadamente, bem como interlig-los
apenas durante a execuo quando for necessrio.
A modularizao um dos caminhos para garantir a abstrao. Podemos
nos referir a componentes especficos e utilizar alguns dos seus servios
sem preocupao de como ele foi implementado. Com o conceito de
componente, estamos dizendo como uma certa unidade computacional
que abstrai certos detalhes pode ser utilizada na composio de outros
componentes. Para isto o componente precisa ser referenciado por um
nome e precisa ter uma interface que diga como ele pode ser
"interconectado" a outros componentes.
Diversos tipos de componentes podem ser encontrados na maioria das
linguagens e ferramentas de programao. As variveis de dados, as
funes e as classes de um programa; as bibliotecas de funes e de
classes; os arquivos fontes, executveis e de dados; e diversos outros.

Encapsulamento
Para que a abstrao seja implementada com maior rigor, cada componente (mdulo) do
software deve encapsular todos os detalhes internos de implementao e deixar visvel
apenas a sua interface. A interface do componente deve dizer aquilo que ele faz, o que ele
precisa para se interconectar com outros componentes, e o que ele pode oferecer para os
outros componentes.
Este princpio, tambm chamado de ocultao de informao
(information hiding) sugere que os componentes sejam projetados de tal
modo que os seus elementos internos sejam inacessveis a outros
componentes. O acesso apenas deve ser feito pela interface. Isto
garante a integridade do componentes, uma vez que evita que seus
elementos sejam alterados por outros componentes.

Reutilizao
Alm de facilitar o processo de desenvolvimento ao diminuir o esforo intelectual ou
facilitar a compilao, os componentes podem ser reutilizados em diferentes software. Uma
funo que tenha sido construda para um software especfico pode ser reutilizada em um
outro software. A funcionalidade especfica de cada componentes ser utilizada para

126
determinar a funcionalidade global do software. Software com diferentes funcionalidades
globais podem ser construdos alguns componentes especficos comuns.
Normalmente os componentes reutilizveis (tipos de dados, funes ou
classes) so armazenados em um outro componentes no-funcional
chamados de bibliotecas. Os componentes podem ser incorporados
durante a compilao ou durante a execuo. No primeiro caso os
componentes ficam em bibliotecas de compilao ou de ligao esttica
e no segundo nas bibliotecas de ligao dinmicas.

Generalizao
A construo de componentes ou mdulos especficos que facilitem o processo de
desenvolvimento de software deve seguir um outro princpio importante: a generalizao.
Para que um componente de software tenha utilidade em diversos programas diferentes ele
deve ser o mais genrico possvel. Para isto ele precisa ser construdo com o objetivo de
oferecer servios de propsito geral.
Por exemplo, uma funo que desenha na tela um retngulo de qualquer
tamanho mais genrica do que uma funo que desenha um retngulo
com tamanho fixo. Esta funo poderia ser ainda mais genrica se
permitisse que o desenho de um retngulo com bordas com diversas
espessuras e cores.

7.5 Modelando a arquitetura usando a UML

A arquitetura essencialmente um modelo abstrato que descreve a estrutura de
componentes que compe um software e o seu funcionamento. Este modelo deve ser
descrito atravs de notaes e linguagens apropriadas. Diversas linguagens de descrio
de arquitetura tm sido propostas, entretanto nenhuma ainda firmou-se como uma
linguagem padro.
Vimos que a UML foi proposta como uma linguagem para especificao,
visualizao, construo e documentao de sistemas de software e
pode ser utilizada em diversas etapas do desenvolvimento. A UML no
foi elaborada com a finalidade de descrever a arquitetura do software.
Entretanto, ela apresenta diversos diagramas que permitem representar
a estrutura lgica e fsica do software em termos de seus componentes,
bem como a descrio do seu comportamento.
Vamos utilizar alguns dos diagramas UML para descrever a arquitetura
lgica do software. preciso ressaltar, porm, que a UML foi
desenvolvida para a modelagem de software desenvolvido no paradigma
de orientao a objetos. Para representarmos componentes funes
preciso fazer algumas adaptaes. Outro aspecto importante que na
UML o termo componente refere-se a componentes fsicos.Na UML existe
uma notao especfica para a representao de componentes fsicos e
diagramas que descrevem a arquitetura em termos destes
componentes. Os componentes lgicos so representados como atravs
de diagramas de classes e de objetos.

127

7.5.1 Modelando a dependncia de funes

As funes que compem um software podem ser modeladas usando um diagrama de
objetos simplificado. O diagrama de funes semelhante ao diagrama de objetos e
descreve a relao de dependncia entre as funes. Neste diagrama cada funo
representada por um retngulo e a dependncia entre elas indicada por uma seta tracejada.
Esta dependncia indica que uma determinada funo USA uma outra funo.
A soluo B dos exemplos composta por diversas funes que
possuem dependncia entre si, como mostra a figura abaixo.

Este diagrama mostra apenas que uma funo usa uma ou outras
funes. A funo ConsultarLivro( ) usa as funes xv_init( ),
xv_main_loop( ), CriarJanelaConsulta( ) e CriarJanelaResposta( ). Estas
duas ltimas funes usam xv_create( ).

7.5.2 Usando o diagrama de interao

Para mostrar como as funes interagem entre si podemos utilizar o diagrama de interao
da UML. Este diagrama mostra como as funes interagem entre si. Este diagrama possui
duas formas: o diagrama de seqncia e o diagrama de colaborao. o diagrama de
seqncia mostrar como as interaes entre as funes ocorrem ao longo do tempo. A
figura abaixo ilustra um diagrama de seqncia .

128

Cada funo representada por um retngulo e so alinhadas na parte superior. De cada

retngulo parte uma linha pontilhada indicando a passagem do tempo de cima para baixo. O
tempo no qual cada funo est ativa representado por um retngulo vertical sobre a linha
do tempo. Quando uma funo chama uma outra funo ela ativa esta funo. Isto
representado no diagrama por uma linha saindo da funo que chama e chegando na linha
de tempo da funo chama. O retngulo vertical que indica a ativao da funo comea a
partir deste ponto. O retorno funo que fez a chamada representado por uma seta
tracejada. Cada uma das setas horizontais de chamada e retorno pode indicar quais valores
(dados) so passados ou retornados entre as funes.

7.5.3 Usando diagrama de atividades

As atividades internas a cada funo pode ser descrita atravs de diagramas de atividades.
Estes diagramas descrevem cada passo da funo e permitem representar estruturas de
decises e repeties internas a cada funo. As figuras abaixo descrevem os diagrama sde
atividades para as funes ConsultarLivro( ) e Procurar( ), da soluo A dos exemplos.

129

130

7.6 Estilos e Padres de Design

Arquitetural
Padres so solues para problemas especficos que ocorrem de forma recorrente em um
determinado contexto que foram identificados a partir da experincia coletiva de
desenvolvedores de software. A proposta original de padres veio do trabalho de
Christopher Alexander na rea de arquitetura (para construes). Sua definio para
padres:
Cada padro uma regra (esquema) de trs partes que expressa uma
relao entre um certo contexto, um problema, e uma soluo.
O contexto descreve uma situao no desenvolvimento na qual existe um problema. O
problema, que ocorre repetidamente no contexto, deve tambm ser descrito bem como as
foras (requisitos, restries e propriedades) associadas a ele. A soluo descreve uma
configurao ou estrutura de componentes e suas interconexes, obedecendo s foras do
problema.
As foras, denominao dada por [Alexander], descrevem os requisitos que caracterizam o
problema e que a soluo deve satisfazer, as restries que devem ser aplicadas s solues
e propriedades desejveis que a soluo deve ter.

7.6.1 Padres no desenvolvimento de software

Os padres so desenvolvidos ao longo dos anos por desenvolvedores de sistemas que
reconheceram o valor de certos princpios e estruturas organizacionais de certas classes de
software.
O uso de padres e estilos de design comum em vrias disciplinas da
engenharia. Eles so codificados tipicamente em manuais de engenharia
ou em padres ou normas
Em software podemos ter padres a nvel conceitual, a nvel de
arquitetura de software ou a nvel de algoritmos e estruturas de dados.O
padres podem ser vistos como tijolos-de-construo mentais no
desenvolvimento de software. Eles so entidades abstratas que
apresentam solues para o desenvolvimento e podem ser instanciadas
quando se encontra problemas especficos num determinado contexto.
Os padres se diferenciam de mtodos de desenvolvimento de software
por serem dependentes-do-problema ao passo que os mtodos so
independentes-do-problema. Os mtodos apresentam passos o
desenvolvimento e notaes para a descrio do sistema, mas no
abordam como solucionar certos problemas especficos.
Um sistema de software no deve ser descrito com apenas um padro,
mas por diversos padres relacionados entre si, compondo uma
arquitetura heterognea.

131
Os padres podem ser descritos em sistemas ou catlogos de padres.
Num sistema os padres so descritos de maneira uniforme, so
classificados. Tambm so descritos os seus relacionamentos. Num
catlogo os padres so descritos de maneira isolada.

7.6.2 Categorias de padres e Relacionamentos

Cada padro depende de padres menores que ele contm e de padres maiores no qual ele
est contido.
Padres arquiteturais - expressam o esquema de organizao estrutural
fundamental para um sistema de software. Assemelham-se aos Estilos Arquiteturais
descritos por [Shaw & Garlan 96].
Padres de design - prov um esquema para refinamento dos subsistemas ou
componentes de um sistema de software.
Idiomas - so padres de baixo nvel, especficos para o desenvolvimento em uma
determinada linguagem de programao, descrevendo como implementar aspectos
particulares de cada componente.
Os diversos padres podem ser relacionados entre si. Trs relaes so identificados:
refinamento, variante e combinao.
Refinamento: Um padro que resolve um determinado problema pode, por sua vez,
gerar novos problemas. Componentes isolados de um padro especfico podem ser
descritos por padres mais detalhados.
Variante: Um padro pode ser uma variante de um outro. De uma perspectiva geral
um padro e suas variantes descrevem solues para problemas bastante similares.
Estes problemas normalmente variam em algumas das foras envolvidas e no na
sua caractersitica geral.
Combinao: Padres podem ser combinados em uma estrutura mais complexa no
mesmo nvel de abstrao. Tal situao pode ocorrer quando o problema original
inclui mais foras do que podem ser balanceadas em um nico padro. Neste caso,
combinar vrios padres pode resolver o problema, cada um satisfazendo um
conjunto particular de foras.

7.6.3 Descrio de padres

Cada padro pode ser descrito atravs do seguinte esquema:
Nome - o nome do padro e uma breve descrio.
Tambm conhecido como - outros nomes, se algum for conhecido.
Exemplo - um exemplo ilustrativo do padro.
Contexto - as situaes nas quais o padro pode ser aplicado.
Problema - o problema que o padro aborda, incluindo uma discusso das foras
associadas.
Soluo - o princpio fundamental da soluo por trs do padro
Estrutura - um especificao detalhada dos aspectos estruturais.
Dinmica - cenrios descrevendo o comportamento em tempo-de-execuo.
Implementao - diretrizes para implementar o padro.

132

Exemplo resolvido - discusso de algum aspecto importante que no coberto nas

descries da Soluo, Estrutura, Dinmica e Implementao.
Variantes - Uma breve descrio das variantes ou especializaes de um padro.
Usos conhecidos - Exemplos do uso obtidos de sistemas existentes.
Conseqncias - Os benefcios que o padro proporciona e potenciais vantagens.
Ver tambm - Referncias a padres que resolvem problemas similares e a padres
que ajudam refinar os padres que est sendo descrito.

7.6.4 Exemplos
Vamos apresentar, de forma sucinta, alguns exemplos de padres de cada uma das
categorias. A descrio detalhada de cada padro pode ser vista em [Buchmann et al. 96].

Model-View-Controller
Contexto: Aplicaes interativas com interface de usurio grfica (IUG) flexvel.
Problema: As IUGs mudam bastante, sejam por modificaes na
funcionalidade que requer uma mudana nos comandos ou menus, na
necessidades de alteraes na representao dos dados por
necessidades dos usurios, ou na utilizao de uma nova plataforma
com um padro diferente de look & feel. As seguintes foras influenciam
a soluo.
Uma mesma informao pode ser representada de maneira diferente e em janelas
diferentes.
As representaes das informaes devem refletir na tela imediatamente as
mudanas que ocorrem no sistema.
As mudanas na IUG devem ser fceis de fazer e em tempo-de-execuo.
O suporte a diferentes padres de look & feel no devem afetar o cdigo do ncleo
funcional.

133
Soluo: MVC divide a aplicao em trs reas: processamento, sada e entrada.

O componente Model encapsula o ncleo da funcionalidade e os dados que ela manipula.

Ele independente das representaes especficas mostradas na sada. O componente View
mostra informaes ao usurio a partir de dados obtidos do Model. Podem existir mltiplas
visualizaes do modelo. Cada View possui um Controller associado. Cada Controller
recebe eventos da entrada e traduz em servios para o Model ou para o View.

134

Estrutura: O Model encapsula os dados e exporta as funes que oferecem servios

especficos. Controllers chamam estas funes dependendo dos comandos do usurio.
papel do Model prover funes para o acesso ao seus dados que so usadas pelos
componentes View para poderem obter os dados a serem mostrados.
O mecanismo de propagao de mudanas mantm um registro de
todos os componentes que so dependentes dos componentes do
modelo. Todos os componentes View e alguns Controllers selecionados
registram que querem ser informados das mudanas no Model. O
mecanismo de propagao de mudanas a nica ligao do Model com
Views e Controllers. Cada View define um procedimento de update que
ativado pelo mecanismo de propagao de mudanas. Quando este
procedimento chamado, o componente View recupera os valores
atuais do modelo e mostra-os na tela. Existem uma relao um-para-um
entre Views e Controllers para que seja possvel a manipulao destes
ltimos sem alterao Models.
Se o comportamento de um Controller dependente do Model ele deve
registrar-se no mecanismo de propagao de mudanas. Isto pode
ocorrer quando, por exemplo, as opes de um menu podem ser
habilitadas ou desabilitadas de acordo o estado do sistema.
Utilizando este padro elaboramos uma terceira arquitetura - soluo C
- para a implementao da funo Consultar Livro( ).

135

Baseado em eventos (ou chamada implcita)

Na soluo B dos exemplos que utiliza as funes do XView para utilizar o sistemas de
janelas XWindows elaboramos uma arquitetura de software que segue um padro chamado
de arquitetura baseada em eventos. Este padro caracteriza-se pela presena de um
componente, chamado notificador ou gerente de eventos, que associa eventos do sistemas a
funes ou procedimentos do sistema (que podem ser funes ou mtodos de um objeto).
Ao invs de chamar um procedimento ou funo explicitamente, um componente anuncia
um ou mais eventos. Estes componentes so chamados de anunciantes. Outros
componentes do sistema registram no notificador um procedimento ou funo a ser
associada a ele. Quando um evento anunciado o notificador chama todos os
procedimentos que tenham sido registrado com aquele evento. Uma caracterstica deste
padro que no se tem um fluxo de execuo pr-definido, a ordem de execuo
depende de quais eventos aconteceram.
As principais vantagens so reuso, evoluo e manuteno de
componentes, um vez que os componentes podem ser alterados
realizando-se apenas modificaes nos registros do notificador.
Desvantagens:
Difcil correo uma vez que no existe um fluxo pr-definido, nem se sabe com
preciso quais as pr- e ps-condies quando uma funo ou precidemento
chamado pelo notificador.
Torna-se difcil a passagem de dados dos componentes que geram eventos para os
que sero chamados pelo notificador.
Quando um componente anuncia um evento ele no pode garantir que os outro
componentes iro responder.

Sistemas em camadas

Um sistema em camadas organizado hierarquicamente com cada camada

oferecendo servios para camadas superiores e utilizando servios de camadas
inferiores.
Alguns sistemas apenas permitem que os servios de uma camada apenas sejam
acessados por camadas imediatamente superior, i.e., a interao apenas ocorre entre
duas camadas adjacentes.
O modelo computacional o de que cada camada, a partir da inferior, implementa
uma mquina virtual que oferece servios, a partir de servios oferecidos pelas
mquinas de nveis inferiores. So considerados componentes as diversas mquinas
virtuais oferecidas em cada camada.
Os conectores so definidos pelos protocolos que determinam com as camadas iro
interagir. A maioria do sistemas computacionais com este estilo implementam
conexes atravs de chamadas a funes oferecidas por camadas anteriores.
Os principais exemplos de aplicao incluem sistemas operacionais e sistemas de
bancos de dados.
Podemos destacar algumas propriedades interessantes:

136
Possibilita um processo de design incremental - um problema complexo
pode ser particionado em nveis crescente de abstrao, resolvendo-os num
seqncia do mais baixo para o mais alto nvel.
o Oferecem suporte para reuso. Pode-se projetar um sistema reusando
camadas inferiores e implementando apenas camadas de mais alto nvel de
abstrao.
o Oferecem suporte para evoluo e manuteno. Uma vez definidas as
interfaces (os protocolos de interao) entre as diversas camadas pode-se
acrescentar facilmente novas camadas superiores a um sistema, ou modificar
os componentes de camadas existentes por outras mais atualizadas.
Como desvantagens temos:
o Nem todo problemas pode ser facilmente particionado em camadas. Muitas
vezes difcl encontrar o nvel certo de abstrao para cada componente.
o A performance pode ser afetada quando camadas de mais alto nvel precisa
interagir com camadas de nveis inferiores.
o

Tubos e Filtros

Cada componente, o filtro, tem um conjunto de entradas e sadas.

Um filtro l um stream de dados de suas entradas e produz streams de dados em
suas sadas.
Cada filtro realiza uma computao que transforma o stream de dados de entrada no
stream de dados de sada
O filtro gera dados na sada antes mesmo dos dados da entrada terem sido
totalmente consumidos
Os tubos so conectores que interligam a sada de um filtro da entrada de outro.
Uma configurao de filtros e tubos determinam um modelo computacional
formado por elementos que transformam (filtram) dados recebidos nas suas entradas
e geram dados nas suas sadas, podendo ser executados sequencialmente ou
concorrentemente..
Os invariantes mais importantes deste estilos determinam que filtros sejam
entidades independentes, no compartilhando estados com outros componentes.
Um outro invariante determina que um filtro no tem conhecimento de quais filtros
que lhe fornecem dados ou quais os que recebem seus dados.
Pipelines so uma especializao deste estilo no qual os filtros so conectados numa
seqncia linear.
O exemplo mais conhecido de aplicao deste estilo so configuraes definidas por
usurios de shell do unix.
Propriedades:
o fcil entender o comportamento geral do sistema, conhecendo-se o
comportamento de cada filtro.
o Incentiva reusabilidade dos componentes.
o Fcil evoluo e manuteno - filtros podem ser trocados e modificados sem
alterar outros componentes do sistema.

137
Suporte a execuo corrente - um filtro pode ir gerando dados na sada
enquanto outro est lendo estes dados atravs da sua entrada conectada por
um tubo.
Desvantagens: tende a gerar processamento em lote; no adequado para aplicaes
interativas; necessidade de adequar dados do stream para um determinado filtro.
o

Estratgia
Frequentemente necessrio usar algoritmos alternativos num programa. Um exemplo
disto pode ser um programa para compresso de dados que oferece mais de uma alternativa
de compresso com diferentes utilizao de espao e tempo dos recursos do sistema. Uma
soluo elegante encapsular os algoritmos em diferentes classes intercambiveis que
podem ser instanciadas quando necessrias.
O padro Estratgia encapsula algoritmos alternativos para uma
mesma funcionalidade. Neste padro, o componente EstratgiaAbstrata
uma classe abstrata que define uma estratgia comum para todas as
estratgias. Parte da sua interface o metdo
InterfaceDoAlgoritmo(), que deve ser implementado por todas as
subclasses. Cada EstratgiaConcreta uma subclasse de
EstratgiaAbstrata e implementa cada algoritmo especfico na
especializao do mtodo InterfaceDoAlgoritmo().
Contexto() o procedimento que utiliza os mltiplos algoritmos e
contm uma instncia de uma das estratgias. Quando o algoritmo
precisa ser aplicado, Contexto() chama o mtodo Interface-doContexto(), que por sua vez chama a instncia correspondente do
mtodo InterfaceDoAlgoritmo() da classe EstratgiaAbstrata.

7.7 Exemplos de arquiteturas

Para ilustrar os conceitos tericos deste captulo vamos apresentar duas arquiteturas
distintas que implementam uma nica funo da aplicao de um sistema de biblioteca.
Vamos utilizar a especificao conceitual para a funo Consultar Livro apresentada no
captulo 4. Para esta funo vamos apresentar duas solues diferentes. Evidentemente, as
solues apresentadas so bastante simples e esto num escopo bastante pequeno.
Devido esta simplicidade, pode parecer que o design da arquitetura de
software perda de tempo no desenvolvimento e que seria melhor
partirmos direto para a implementao. Num caso simples, talvez sim,
mas o objetivo da arquitetura de software oferecer recursos para a
especificao, visualizao e documentao de software complexo com
centenas ou milhares de linhas de cdigo. Nosso objetivo ilustrar
concretamente como o design da arquitetura de componentes permite
abstrair detalhes de programao para chegarmos a soluo de software
desejada.

7.7.1 Soluo A

138
Vejamos uma soluo bastante simples de arquitetura para implementar a funo da
aplicao Consultar Livro. Este programa poderia ser formado pelas funes: LerDados( ),
Procurar( ), FornecerResultado( ). Esta soluo no utiliza interfaces WIMP e produz
uma interface que tem a seguinte aparncia.

A funo LerDados( ) deve solicitar ao usurio os dados de autor, ttulo e ISBN do livro. A
funo Procurar( ) deve procurar na base de dados a localizao do livro na biblioteca.
FornecerResultado( ) deve mostrar na tela a localizao do livro para o usurio. Estes trs
componentes podem ser agrupados em uma funo principal responsvel por fazer a
chamada a cada uma das funes em seqncia. Estas funes utilizam outros dois
componentes: Ler( ) e Escrever( ), que fazem parte de uma biblioteca de funes de entrada
e sada disponveis no compilador utilizado.
Representando cada componentes funo por um quadrado e a relao
de dependncia entre uma funo que utiliza uma outra podemos ter a
seguinte diagrama que descreve arquitetura esttica (configurao) de
componentes.

139

As funes ConsultarLivro( ) e Procurar( ) podem ser descrita pelos

seguintes diagrama de atividades.

140

Estes componentes interagem entre si da seguinte forma.

Vejamos os algoritmos que implementam estes componentes funes.

Estrutura de dados
struct lista_info_livro {

141
char autor[30];
char titulo[30];
char isbn[30];
char posicao[10];
lista_info_livro *proximo;
}
Funes
ConsultaLivro( ) {
string autor,titulo,isbn,posicao;
int escolha;
LerDados(autor,titulo,isbn,escolha);
if (escolha = 1) {
Procurar(autor,titulo,isbn,posicao);
FornecerResultado(posicao);
}
LimparTela( );
}
LerDados(out:autor,out:titulo,out:isbn,out:escolha) {
Escreva("Autor:");
Leia(autor);
Escreva("Titulo:");
Leia(titulo);
Escreva("ISBN:");
Leia(isbn");
Escreva("1. Iniciar");
Escreva("2. Desistir");
Leia(escolha);
}
Procurar (in:autor, in:titulo, in:isbn, out: posicao) {
info_livros *lista_info_livros;
info_livros = inicio_lista;
while (info_livros != NULL)
if (autor = = info_livros.autor) ||
(titulo = = info_livros.titulo) ||
(isbn = = info_livros.isbn)
then
posicao = info_livros.posicao
else
posicao = NULL;
}
}
FornecerResultado(in:posicao) {
if (posicao != NULL)
then

142
Escreva("A posicao do livro na estante :", posicao);
else
Escreva("Livro no encontrado");
}
Esta soluo no satisfaz complementamente o modelo de interao que foi especificado no
captulo 4. Isto ocorre por limitaes da linguagem, dos componentes de bibliotecas que
foram utilizados e da maneira como eles podem ser interligados.

7.7.2 Soluo B
Vamos apresentar agora uma soluo envolvendo interfaces grficas no estilo WIMP. O
usurio vai poder fornecer as informaes em uma janela de dilogo (janela consulta) na
qual ele pode interagir com qualquer elemento independente de ordem. O resultado
apresentado em uma outra janela (janela resultado). As duas janelas podem ser vistas na
figura abaixo.

Uma arquitetura para esta mesma funo da aplicao poderia ser construdas pelos
componentes: ConsultarLivro( ), DesenharJanelaConsulta( ), JanelaResultado( ),
Procurar( ), Desistir( ) que seriam construdas numa linguagem procedimental (como C,
por exemplo) e utilizariam funes de uma biblioteca para a construo de widgets de
interfaces grficas, um toolkit (veja seo 4.3), chamada de XView. As funes desta
biblioteca so incorporadas ao programa em tempo-de-execuo. Ela portanto uma
biblioteca de ligao dinmica (DLL) que um componente fsico de tempo-deexecuo(veja seo 7.4).
Na biblioteca XView vamos utilizar os seguintes componentes lgicos
(funes):
xv_init( ) - que inicia a execuo da biblioteca

143

xv_create( ) - que cria os diversos widgets

xv_get( ) - que obtem valores de atributos de widgets
xv_set( ) - que modifica valores de atributos
xv_main_loop( ) - que realiza o papel de notificador

A relao de dependncia entre estas funes pode ser vista na figura abaixo.

Estas funes interagem entre si de acordo com o seguinte diagrama de seqncia.

144

Diagramas de Atividades
Na parte esquerda da figura abaixo temos o diagrama de atividades para a funo
ConsultarLivro( ). As funes CriaJanelaConsulta( ) e CriaJanelaResultado( ) no esto
descritas em detalhes. Entretanto, como podemos ver no algoritmo logo adiante, elas so
compostas por seqncias de chamadas funo xv_create( ). Desta forma consideramos

145
desnecessrio entrar em detalhes.

A seguir temos o diagrama de atividades para a funo xv_main_loop( ). Na parte direita da

figura indicamos apenas que tratar eventos chama as funes Procurar( ), Desistir( ) e
FimJanelaResultado( ).

146

A seguir, temos os diagramas de atividades para funes Procurar( ) e Desistir( ). A funo

procurar( ) semelhante funo de mesmo nome da soluo A. Entretanto, devido
limitao do notificador (xv_main_loop( )) no poder passar parmetros. esta funo deve
obter as informaes fornecidas pelo usurio diretamente dos widgets caixa de texto. Isto
feito pela funo ObterDados( ). Da mesma forma, para fornecer o resultado, esta funo
deve ativar MostraJanelaResultado( ) que se encarregara de fornecer a posio ao usurio.
Esta funo apenas ativa a janela que havia sido criada anteriormente. Aps isto,
MostraJanelaResultado( ) retorna o controle para Procurar( ) que por sua vez passa o
controle de volta para o xv_main_loop( ).

147
A funo xv_destroy( ) recebe como argumento o objeto JanelaConsulta
para destruir o programa e encerrar a execuo.

Algoritmos para as funes

A biblioteca XView tambm oferece algumas estruturas de dados para construirmos os
widgets:
Frame - moldura de uma janela.
Panel - interior da janela onde podem ser colocados outros widgets.
Panel_item - os widgets botes, caixa de texto, etc.
Estruturas de dados globais
struct lista_info_livro {
char autor[30];
char titulo[30];
char isbn[30];
char posicao[10];
lista_info_livro *proximo;
}
// janelas e widgets

148
Frame JanelaConsulta, JanelaResultado;
Panel
PanelConsulta, PanelResultado;
Panel_item text_autor, text_titulo, text_isbn, text_resultado,
button_iniciar, button_desistir, button_fechar;
Funes

ConsultarLivro ( ) {
xv_init( );
JanelaConsulta( );
JanelaResultado( );
xv_main_loop( );
}
DesenharJanelaConsulta( ) {
JanelaConsulta = xv_create(NULL,FRAME,
FRAME_LABEL, "Consultar Livro",
XV_WIDTH, 200,
XV_HEIGHT, 100,
NULL);
PanelConsulta = xv_create(JanelaConsulta, PANEL, NULL);
text_autor = xv_create(PanelConsulta, PANEL_TEXT,
PANEL_LABEL_STRING, "Autor:",
PANEL_VALUE,"",
NULL);
text_titulo = xv_create(PanelConsulta, PANEL_TEXT,
PANEL_LABEL_STRING, "Ttulo:",
PANEL_VALUE,"",
NULL);
text_isbn = xv_create(PanelConsulta, PANEL_TEXT,
PANEL_LABEL_STRING, "Cdigo ISBN:",
PANEL_VALUE,"",
NULL);
button_iniciar = xv_create(PanelConsulta, PANEL_BUTTON,
PANEL_LABEL_STRING, "Iniciar",
PANEL_NOTIFY_PROC, procurar,
NULL);
button_desistir = xv_create(PanelConsulta, PANEL_BUTTON,
PANEL_LABEL_STRING, "Desistir",
PANEL_NOTIFY_PROC, desistir,
NULL);
}

149

DesenharJanelaResultado( ) {
JanelaResultado = xv_create(JanelaConsulta ,FRAME_CMD,
FRAME_LABEL, "Resultado",
NULL);
PanelResultado = xv_create(JanelaResultado, PANEL, NULL);
text_resultado = xv_create(PanelResultado, PANEL_TEXT,
PANEL_LABEL_STRING, "A posicao do
livro :",
PANEL_VALUE,"",
NULL);
button_fechar = xv_create(PanelResultado, PANEL_BUTTON,
PANEL_LABEL_STRING, "Fechar",
PANEL_NOTIFY_PROC, FimJanelaResultado,
NULL);
FimJanelaResultado( ) {
xv_set(JanelaResultado, XV_SHOW, FALSE, NULL);
}
Procurar( ) {
string autor,titulo,isbn,posicao;
info_livros *lista_info_livros;
autor = xv_get(text_autor,PANEL_VALUE);
titulo = xv_get(text_titulo,PANEL_VALUE);
isbn = xv_get(text_isbn,PANEL_VALUE);
info_livros = inicio_lista;
while (info_livros != NULL)
if (autor = = info_livros.autor) ||
(titulo = = info_livros.titulo) ||
(isbn = = info_livros.isbn)
then
posicao = info_livros.posicao
else
posicao = NULL;
}
MostraJanelaResultado(posicao)
}
Desistir( ) {
xv_destroy_frame(JanelaConsulta);
exit( );
}

150

MostraJanelaResultado(in:posicao) {
xv_set(text_resultado,posicao);
xv_set(JanelaResultado, XV_SHOW, TRUE, NULL);
}

7.7.3 Soluo C
Usando o padro MVC, apresentado na seo 7.6, podemos elaborar uma terceira
arquitetura para a funo Consultar Livro( ). Esta soluo utiliza o paradigma de orientao
a objetos e descrita pelo seguinte diagrama de classes.

151
A interao entre os objetos destas classes descrita no diagrama abaixo.

152

Verificao
Programas

Testes

de

A etapa de design de software (do modelo conceitual, da interface e da

arquitetura) visa encontrar as solues que satisfaam os requisitos do
software. No design as solues so especificadas atravs de
formalismos e modelos que possibilitam diferentes vises do software.
Entretanto, para que o software funcione preciso que as idias
concebidas durante do design seja codificadas em uma linguagem de
programao para que possam ser traduzidas e executadas num
computador.
O programa produzido durante esta etapa pode conter falhas ou erros.
Os erros podem ser ocasionados por diversos fatores. Um deles pode ser
a interpretao errada dos modelos produzidos durante o design. Em
outros casos o programador interpretou erradamente os comandos de
um programa. A complexidade de um programa, seja pela complexidade
de um algoritmo ou pelo seu tamanho, pode levar ao programador a
gerar um software com bastante erros de funcionamento.
Definir o que um erro ou falha num software no uma tarefa simples.
Podemos simplificar dizendo que um erro quando o software no se
comporta conforme foi especificado. Isto pode ocorrer quando o software
no realiza um funo esperada, fornece resultados no esperados, no
consegue terminar quando esperado, etc.
Para se avaliar o funcionamento do teste preciso definir quais os
critrios necessrios para consideramos que o mesmo est correto ou
no, isto , o que pode ser considerado um erro ou falha. Alm disso,
preciso determinar quais mtodos ou tcnicas para verificao do
funcionamento sero empregadas.
Este captulo aborda as vrias formas de verificar a correo do
funcionamento de um software, ou simplesmente verificao de
programas. Sero vistos alguns mtodos e tcnicas que permitem
avaliar um programa tentando verificar se o mesmo est correto ou
no.

8.1 Verificao de Programas e Qualidade

de Software
Vimos no captulo 1 que vrios so os fatores que determinam a
qualidade de software. Cada um destes fatores precisam ser
considerados para garantirmos a qualidade do software. Para isto devese utilizar tcnicas para avaliao e anlise de cada um dos fatores de
qualidade do software.

153
Os fatores de qualidade de software podem ser classificados em do
processo ou do produto e internos e externos. Os fatores de qualidade
do processo visam assegurar a qualidade do desenvolvimento do
produto em todas as suas etapas. Os fatores relacionados ao produto
permitem analisar a qualidade do software em si.
Embora todos os fatores sejam importante para a qualidade final do
software, podemos destacar alguns deles como fundamentais para que o
software exista com um produto que funcione em mquinas reais e
resolva problemas dos usurios.
McCall classifica os fatores de qualidade do produto em trs categorias:
fatores operacionais - aspectos relacionados com o funcionamento e utilizao do
software
fatores de reviso - relacionados com a manuteno, evoluo e avaliao do
software
fatores de transio - relacionados com a instalao, reutilizao e interao com
outros produtos
A categoria dos fatores operacionais relaciona alguns daqueles que so
essenciais e indispensveis para o funcionamento e utilizao do
software. Dentre os fatores que se enquadram nesta categoria podem
citar:
correo
eficincia ou desempenho
robustez
integridade
confiabilidade
validade
usabilidade
A usabilidade engloba outros fatores relacionados com a utilizao do
software pelo seus usurios. Dentre os fatores da usabilidade podemos
citar a utilidade, facilidade de uso, facilidade de aprendizado, a
produtividade do usurio, a flexibilidade no uso e a satisfao do
usurio. A avaliao da usabilidade de um software est diretamente
relacionada sua interface de usurio. Existem mtodos e tcnicas
especificas para avaliao da usabilidade. Podem ser realizados, por
exemplo, testes com os usurio que permitam medir alguns fatores de
usabilidade ou aplicados questionrios que avaliem a opinio dos
usurio. A avaliao da usabilidade objeto do Design de Interfaces de
Usurio e no ser considerado aqui.
A validade de um software o fator que considera que o software est
de acordo com os requisitos funcionais e no-funcionais que foram
determinados durante a etapa de anlise e especificao de requisitos.
Um software correto no necessariamente um software vlido, mas a
validao requer que ele esteja correto.

154
A confiabilidade de um software uma qualidade subjetiva que depende
de outros fatores como a correo, eficincia, robustez e integridade.
Um software passa a ser confivel para os clientes e usurios quando o
mesmo esta correto, realiza as tarefas de forma eficiente, funciona bem
em situaes adversas e que no permite violaes de acesso ou danos
a seus componentes.
A correo de um software , portanto, apenas um dentre os muitos
fatores de qualidade de um software que precisam ser avaliados.
Entretanto ela fundamental para que vrias outros fatores de
qualidade possam ser avaliados. A correo avalia o programa que
quem faz com que o software funcione e seja til para algum.

8.2 Formas de verificao de programas

A correo pode ser verificada de diversas maneiras. Mas no basta
apenas verificar. preciso identificar qual a falha ou erro e corrigir. Mais
ainda, preciso garantir que o software est livre de erros ou, pelo
menos, que contenha um nmero muito pequeno de erros que no
foram detectados.
Na correo de um programa importante diferenciar erros de sintaxe
de erros de semntica. Os erros de sintaxe ocorrem quando o programa
no escrito corretamente, isto , de acordo com a gramtica formal da
linguagem de programao e com as palavras chaves (comandos, tipos,
identificadores, etc.) escritos corretamente. Os erros de sintaxe so
normalmente detectados pelo analisador sinttico do compilador ou
interpretador da linguagem.
Os erros de semntica ocorrem por problemas de interpretao das
instrues da linguagem. Estes erros so tambm conhecidos como
erros de lgica de programao e tem uma interferncia direta no
funcionamento do programa. Os erros de semntica quase sempre
ocorrem por uma interpretao equivocada do programador. Ele espera
que o computador execute as instrues de uma determinada maneira
quando na verdade ele est realizando de outra maneira. Como a
semntica de uma linguagem de programao definida de forma
rigorosa, normalmente o programador quem causa o erro de
semntica. A verificao de programas tem por objetivo detectar os
erros de semntica de um programa.
Existem diversas formas de verificar se o funcionamento de um
programa est correto ou no. Vamos considerar aqui trs categorias de
verificao:
inspeo de programas
testes de funcionamento
prova formal

155
A inspeo uma forma analtica de verificao da correo na qual o
cdigo fonte do programa analisado diretamente. Ela pode ser
esttica ou dinmica. A inspeo esttica feita mentalmente, num
processo no qual o inspetor (que pode ser o prprio programador)
percorre o cdigo executando mentalmente cada uma das instrues.
Este processo denominado de rastreamento do cdigo fonte.
A inspeo dinmica realizada com o auxlio de uma ferramenta de
depurao (debugger). Estas ferramentas permitem a execuo passoa-passo de trechos do programa e a visualizao de variveis do
programa.
Normalmente estas tcnicas de inspeo so aplicadas para corrigir um
erro j detectado em um programa, pela aplicao de testes de
funcionamento.
Os testes de funcionamento tm por objetivo a detectar o maior
nmero possvel de erros. Deve-se executar o programa de maneira a
forar certos limites para os erros possam ser encontrados. Os testes
no podem garantir que no existam erros num software, exceto em
casos muito de programas muito simples. Em programas que possuam
estrutura de controle como a repetio o nmero de caminhos possveis
de execuo aumenta bastante de maneira a tornar invivel o teste
exaustivo de todas as situaes. necessrio definir os casos de teste
de maneira que seja possvel que os caminhos possveis possam ser
testados.
Os teste de funcionamento podem ser divididos em testes em ponto
pequeno ou teste de unidades e em teste em ponto grande ou
teste de integrao. Os teste de unidades visam verificar o
funcionamento dos componentes, mdulos ou unidades funcionais
isoladamente. Os testes de integrao verificam se os componentes
funcionam corretamente aps a integrao com os outros componentes.
A prova de programa a forma mais precisa de verificar se um
programa est correto ou no. Ela pode garantir que um programa est
livre de erros. Isto possvel por um programa um objeto formal, isto
, definido por uma linguagem de programao formal de base
matemtica. Podemos explicar esta idia de forma simples.
Cada sentena de um programa uma instruo para o computador
realizar uma certa atividade. Este comportamento o significado ou
semntica da sentena do programa. para que o comportamento do
computador seja sempre o mesmo para cada instruo, a semntica dos
elementos de uma linguagem de programao deve ser definida
formalmente. Desta forma se espera que cada elemento de um
programa provoque uma transformao precisa em outros elementos.
Analogamente, a combinao das instrues deve possibilitar mudanas
tambm previsveis no programa. Assim, espera-se todo um programa
altere sempre o estado de outros elementos do programa da mesma
maneira. Pode-se ento provar que para uma dada condio inicial
chega-se a uma condio final se as instrues forem executadas.

156
Exemplificando, vamos considerar inicialmente uma instruo de um
programa Pascal
{x=5}
x := x + 1;
{x=6}

A expresso {x=5} indica a condio da varivel antes da execuo da

instruo, enquanto que {x=6} mostra a situao aps a execuo da
instruo. De acordo com a semntica da instruo pode-se garantir a
condio final da varivel sempre a inicial incrementada de 1. Isto
pode parecer bvio numa nica e simples instruo, mas torna-se um
recurso bastante valioso quando temos um conjunto complexo de
instrues. Por outro lado, a complexidade e os custos da aplicao de
mtodos de prova formal em programas muito grande enorme.

8.3 Uma introduo prova de programas

Para aplicarmos os mtodos de prova necessrio recorrer s notaes
matemticas baseadas em lgica. O clculo de predicados, por exemplo,
permite expressar as condies de programa e as regras de prova com
base na semntica das instrues de uma linguagem. Linguagens de
especificaes formais com Z, VDM ou B, so tambm bastante
utilizadas para prova de programas. Alis, uma das grandes vantagens
da aplicaes de mtodos formais em engenharia de software que se
pode provar matematicamente que um programa est correto em
relao sua especificao formal. Algumas ferramentas possibilitam a
realizao de provas automticas, diminuindo a complexidade e os
custos do mtodo.
De uma forma geral a prova de programa requer condies que devem
ser expressas numa notao matemtica e regras de prova que
podem ser aplicadas de acordo com as instrues de um programas.
Expressando as instrues por S (statements) e as condies por {C}
podemos dizer que:
{C1} S1 {C2} e {C2} S2 {C3}

Que indica a instruo S1 modifica o programa de uma condio C1 para

uma condio C2 e as instruo S2 de C2 para C3.
Quando queremos mostrar que um programa ou trecho de programa
est correto indicamos qual a condio final (ou ps-condio) que deve
ser atingida para uma certa condio inicial (pr-condio)
{Pr} programa {Ps}

No caso de um programa que realiza a diviso de dois nmeros positivos

a expresso de prova seria:
{y>0 & x>0} programa-diviso {y = x*q + r}

onde q o quociente e r o resto. Mais adiante mostraremos

Uma regra de prova expressa por uma notao do tipo:
E1,
E3

E2

157
Indica que se E1 e E2 tenham sido provados, ento deduzimos que E3
tambm verdade. Por exemplo, a regra que vale para uma seqncia
de instrues a seguinte:
{C1}
S1
{C2},
{C2}
S2
{C3}
{C1} S1;S2 {C3}
Da mesma forma teramos regras para as outras principais estruturas de
controle como repetio e seleo. Vejamos o caso de uma repetio.
Seja o trecho de um programa e as condies iniciais de sua varivel:
{x >= 0}
while (x>0) do
x:= x - 1;
end while
{x = 0}

Aplicando as regras de prova da repetio e da atribuio podemos

provar que o programa est correto, isto que para a condio inicial
{x>=0} teremos a condio final {x=0}. A regra da repetio pode ser
descrita como
{Invariante
&
ExprCond}
S
{Invariante}
{Invariante}while (ExprCond) S {Invariante & not ExprCond}
Onde ExprCond a expresso condicional do while e Invariante uma
expresso que deve ser verdade em todo o loop do while, e tambm
antes e depois da sua execuo. A idia bsica que se o corpo S do
while no torna o invariante falso -- {Invariante & ExprCond} S
{Invariante} -- caso a ExprCond seja verdadeira, ento deduz-se que a
expresso inferior verdadeira. Aplicando ao programa acima temos
que o invariante {x>=0} e a regra fica:
{x>=0
&
x>0}
x
:=
x
1;
{x>=0}
{x>=0}while (x>0) x := x - 1 {x>=0 & not x>0}
Podemos verificar facilmente que a expresso de cima verdadeira.
Com base na regra podemos deduzir que a expresso inferior
verdadeira. Como {x>=0 & not x>0} o mesmo que {x>=0 & x<=0},
temos que {x=0} o que est de acordo como o nosso programa.
Usando o mesmo mtodo podemos provar que o programa abaixo
realiza corretamente uma diviso de y por x:
{y>0 & x>0}
r=y;
q=0;
while (r >= x) begin
q := q + 1;
r := r - x;
end;
{y = x*q + r & x>r>=0}

O invariante deste programa y = x*q + r, que a expresso que indica

uma diviso e que gostaramos que fosse vlida ao final. A prova fica
como exerccio.

8.4 Testes de correo

158
O teste a maneira mais comum de fazermos a verificao da correo
de um programa. Os testes consistem na execuo controlada do
programa com o objetivo de analisar o seu comportamento para verificar
se ele comporta-se como esperado. A limitao de um teste est em ele
poder identificar que existem erros, mas no poder garantir que erros
no existem.
Vimos que podemos diferenciar os testes em testes de ponto pequeno e
teste de ponto grande. Os teste de ponto pequeno ou de unidades
possibilitam verificar trecho isolados de um programa, normalmente um
componentes ou mdulo. Os principais tipos de teste de ponto pequeno
so os testes da caixa branca e os testes da caixa preta.
Os testes em ponto grande tem por objetivo verificar a correo de
conjuntos de componentes interconectados. Eles so aplicados a
componentes como um todo.

8.4.1 Fundamentos
A idia fundamental por trs de um teste pode ser explicada de forma
simples. Seja P um programa e D e I o domnio e a imagem,
respectivamente. O domnio refere-se aos valores iniciais ou de entrada
de D e I os valores resultantes ao final da execuo de P. Por
simplicidade, vamos considerar P que se comporta com uma funo com
domnio D e I. Obviamente, em casos reais, D e I podem conter
seqncias de dados e P pode ter vrias funes de entrada/sada.
Seja R os valores resultantes desejveis determinados durante a
especificao. Seja d dados do domnio D, dizemos que P(d) refere-se
aos possveis resultados de P para os dados iniciais d. Dizemos que um
programa est correto se P(d) satisfaz R. P est correto se e somente se
para todo dado d, P(d) satisfaz R. Dizemos que um programa no est
correto se o programa no termina de executar, ou se termina mas P(d)
no satisfaz R.
A presena de um erro demonstrada pela existncia de dados d, tal
que P(d) no satisfaz R. Muitas vezes impossvel verificar P(d) para
todos os dados d do domnio D. Nestas situaes importante elaborar
casos de testes.
Um caso de teste um elemento d de D. Um conjunto de casos de teste
T um subconjunto de D. Um conjunto de teste T dito ideal se, sempre
que P for incorreto, existe um d pertencente a T que faz P(d) no
satisfazer a R.

159

A escolha dos casos de teste a etapa mais importante durante a

realizao de um teste. Como o objetivo encontrar erros, deve-se
escolher os casos de teste que force a deteco deles. Esta escolha
depende do tipo de teste que podemos aplicar.
Vejamos um exemplo de como a escolha de casos de testes deve ser
criteriosa. Suponha o programa que verifica o valor mximo de dois
nmeros.
read(x); read(y);
if (x>y) then
max := x;
else
max := x;
end if;
write(max);

Se escolhermos como caso de teste os valores {x=3, y=2; x=4, y=3; x=5, y=1; x=10, y=5}
nenhum deles revelar a existncia de erro. Entretanto, com apenas dois casos de testes
escolhidos com base na lgica do programa {x=3, y=2; x=2, y=3}, que explora o fato de
que um teste comparativo feito, revela o erro no segundo caso de teste. Ter muitos casos
de testes no garantia de testes bem-sucedidos. Mais importante escolher casos de testes
que ajudem a identificar erros.
Resumindo, as regras gerais para se realizar um teste:
1. Executar um programa com a inteno de descobrir um erro
2. Um bom caso de teste aquele que tem uma elevada probabilidade de revelar um
erro ainda no descoberto.
3. Um teste bem-sucedido aquele que revela um erro ainda no descoberto.

8.4.2 Testes da caixa branca

Os teste da caixa branca esto baseados nos elementos internos de um
trecho de programa.O objetivo encontrar o menor nmero de casos de
teste que permita que todos os comandos de um programa seja
executado pelo menos uma vez. Os casos de teste so determinados a

160
partir das estruturas de controle do programa. A idia escolher os
casos de teste de forma a forar que todos os caminho possveis do fluxo
de controle do programa sejam percorridos durante os testes. O teste do
caminho bsico, o teste de loops (laos) e o teste de estruturas de
controles so tipos de teste da caixa branca.
No teste do caminho bsico, o passo inicial determinar todos os
caminhos possveis. Para isto costuma-se elaborar um grafo de fluxo
de controle do programa. O grfico permite identificar os caminhos
possveis para que se possa elaborar os casos de uso. Como cada
caminho definido pelas expresses condicionais das estruturas de
controle, deve-se determinar os casos de teste escolhendo valores de
variveis para os casos nos quais cada uma das expresses sejam
verdadeiras ou no.
Vejamos um exemplo para um programa que calcula o mximo divisor
comum (MDC) de dois inteiros.
read(x); read(y);
while xy do
if (x>y) then
x := x - y;
else
y := y - x;
end if;
end while;
write("MDC=",x);

Observe que a estrutura de controle while possui dois caminhos

possveis. A condio do while sugere dois possveis casos de teste. Um
deles para os valores de x=y e o outro para valores de xy. No
primeiro caso testa-se o programa para que o while no seja executado.
No segundo, testa-se para que ele seja executado pelo menos uma vez.
No corpo do while temos uma estrutura de controle de seleo (if ... then
... else). Esta estrutura possibilita dois caminhos possveis. A expresso
condicional desta estrutura sugere mais dois casos de teste para os dois
caminhos. preciso escolher pelo menos um caso de teste no qual
tenhamos x>y e outro no qual tenhamos xy. Combinando todas as
possibilidades podemos definir quatro casos de teste.
1. x=y e x>y
2. x=y e xy
3. xy e x>y, que pode ser reduzido x>y
4. xy e xy, que pode ser reduzido x<y
Que podem ser reduzidos a trs casos:
1. x=y
2. x>y
3. x<y
Com isto cobrimos todos os caminhos possveis.

161
Para casos de programas mais complexos podemos usar o grafo de
fluxo de controle para determinarmos a o nmero de caminhos
possveis.

Seja um trecho de programa que calcula a mdia aritmtica de 100

nmeros ou menos que se situem entre valores-limite mnimo e mximo.
Ele tambm computa a soma e o nmero total vlido.
i = 1;
total.entrada = total.valido = 0;
soma= 0;
while valor[i] != -999 && total.entrada < 100 {
total.entrada++;
if valor[i] minimo && valor[i] maximo {
total.valido++;
soma = soma + valor[i];
}
i++;
}
if total.valido > 0
media = soma/total.valido;
else
media = -999;

O grafo de fluxo derivado da seguinte maneira. Cada comando simples

representado por um n. Cada estrutura de controle representada
por um grafo como mostra a figura a seguir. Para as estruturas de
controle que possuem expresses condicionais, cada expresso
representada por um n do grafo. Caso a expresso condicional seja
composta por vrias expresses condicionais, um n para cada
expresso deve ser representado no grafo.
Para o programa da mdia temos, portanto, o seguinte grafo de fluxo.

162

O nmero de caminhos possveis pode ser determinado a partir do grafo

de fluxo de vrias maneiras:
Pelo nmero de regies do grafo
Pela frmula E - N + 2, onde E o nmero de elos e N o nmero de ns (N)
No exemplo temos que o nmero de caminhos possveis 4.
O grafo tem 6 regies
O grafo tem 17 elos e 13 ns, portanto, 17 - 13 + 2 = 6.
Os caminhos possveis so:
Caminho 1: 1-2-10-12-13
Caminho 2: 1-2-10-11-13
Caminho 3: 1-2-3-10-11-13...
Caminho 4: 1-2-3-4-5-8-9-2...
Caminho 5: 1-2-3-4-5-6-8-9-2...
Caminho 6: 1-2-3-4-5-6-7-8-9-2
As reticncias depois dos caminhos 4 a 6 indicam que qualquer caminho
ao longo do restante j foi coberto pelos caminhos possveis.
Os casos de teste devem ser escolhidos com base nas expresses
condicionais que forcem o programa a percorrer cada um dos caminhos
possveis.
Casos de teste do caminho 1:
o valor[1] = -999
o Resultado esperado: mdia = -999 e outros totais com os valores iniciais

163

Casos de teste do caminho 2:

o Para testar este caminho preciso forar que a mdia seja calculada
o Utilizar:
0 < k1, ..., kn < i 100
minimo valor[k1],..., valor[kn] maximo
valor[i] = -999
o Resultado esperado: valor da mdia calculado corretamente baseado nos k
valores e totais com valores apropriados
Casos de teste do caminho 3:
o Utilizar:
0 < k1, ..., kn 100 < i e

minimo valor[k1],..., valor[kn] maximo e

valor[i] = -999
o Resultado esperado: valor da mdia calculado corretamente baseado nos 100
primeiros valores e total.valido=n e total.entrada=n
Casos de teste do caminho 4:
o Utilizar:
0 < k1, ..., kn < i 100 e
valor[k1],...,valor[kj] < minimo e
minimo valor[kj],..., valor[kn] maximo e
valor[i] = -999
o Resultados esperados: valor da mdia calculado para os valores de kj a kn e
total.valido=j e total.entrada=n
Casos de teste do caminho 5:
o Utilizar:
0 < k1, ..., kn < i 100 e
minimo valor[k1],..., valor[kj] maximo e
valor[kj],..., valor[kn] > maximo e
valor[i] = -999
o Resultados esperados: valor da mdia calculado para os valores de k1 a kj e
total.valido=n-j e total.entrada=n
Casos de teste do caminho 6:
o Utilizar:
0 < k1, ..., kn < i 100 e
maximo valor[k1],..., valor[kn] ou valor[k1],..., valor[kn]
minimo e
valor[i] = -999
o Resultados esperados: valor da mdia = -999 e total.valido=0 e
total.entrada=n

8.4.3 Testes da caixa preta

Os testes da caixa preta so chamados de testes funcionais por estarem
baseados nos requisitos funcionais do software. Espera-se poder
verificar aquilo que se pretende que o programa faa. Exemplos de

164
tcnicas de teste da caixa so os grafos de causa-efeito, testes
baseados em tabela de deciso e teste do valor limite.
O teste da caixa preta no uma alternativa ao teste da caixa branca,
mas uma abordagem complementar.Ele permite verificar a validade do
software em relao aos requisitos. Por exemplo, suponha que o cliente
solicitou que o software calculasse o valor mdio das trs notas dos
alunos. O desenvolvedor construiu uma funo que calcula a mdia
aritmtica. Os teste da caixa-preta devem permitir verificar que a funo
implementada no a funo correta.
De acordo com os requisitos, a mdia deve ser calculada pela frmula
media = (a*4 + b*5 + c*6)/15. Desta forma, para o caso de teste
cujos valores sejam {a = 2, b=3, c=4}, o valor esperado 3,1333, e
para o caso {a = 5, b=6, c=8}, o valor esperado 6,5333.
Aplicando alguma tcnica de teste da caixa preta chega-se ao valor
media = 3, para o primeiro caso de teste e media = 6,333 uma vez que
o desenvolvedor implementou uma funo que calcula a mdia
aritmtica e no a mdia ponderada.
Uma das tcnicas utilizadas para o teste da caixa-preta utiliza grafos
de causa-efeito. Esta tcnica oferece um representao concisa das
condies lgicas e das aes correspondentes. A tcnica segue 4
passos:
1. Causas (condies de entrada) e efeitos (aes) so relacionados para um mdulo e
um identificador atribudo a cada um.
2. Um grafo de causa-efeito (descrito a seguir) desenvolvido.
3. O grafo convertido numa tabela de deciso.
4. As regras da tabela so convertidas em casos de teste.
Considere como exemplo um programa que realiza a cobrana de
chamadas telefnicas. Os valores de cada chamadas so contabilizados
de acordo com a durao, local de destino (para onde for feita a
chamada) e faixa de horrio.
Se o local de destino for o mesmo da origem (chamada local) e a faixa de horrio
for das 6:00 s 23:59 ento valor do minuto R$ 1,00.
Se chamada local e a faixa for 0:00 s 5:59 o valor do minuto de cada chamada
R0,50.
Se o local for um outro estado no pas (chamada interurbana) e a faixa de horrio for
das 9:00 s 21:00 ento o valor do minuto calculado de acordo com o valor bsico
por estado.
Se chamada interurbana e faixa de horrio for das 21:00 s 9:00 o valor do minuto
fixo, sendo R$1,00.
Se chamada internacional o valor no depende de faixa de horrio e calculado de
acordo com o valor bsico por pas.
Para o programa cobrana temos ento as causas
tipo da chamada: local (CL), interurbana (DDD) e internacional (DDI)
faixa de horrio: 6-24, 0-6, 9-21, 21-9

165

estado ou pas: AC,AM, AP, ... (estados do Brasil), EUA, RU, JP, ...

Os efeitos esperados so os clculos de cobrana conforme especificado

F1= durao*R$1,00
F2= R$0,50
F3= durao*valor_localidade
O grafo de causa-efeito para a especificao acima o seguinte:

Com base no grafo de causa-efeito a seguinte tabela de deciso pode

ser elaborada.
CL
X
X
DDD

DDI
6-24

X
X

0-6

9-21
21-9
valor_localidade

X
X
X

166
F1
F1
F2
F3
F3
Com base no grafo ou na tabela acima podemos derivar cinco casos de
teste nos quais podemos verificar se para as entradas correspondentes
(causas) o programa realiza os clculos correspondentes (efeitos).
Caso1: {tipo_da_chamada=CL, faixa_de_horrio=6-24, valor_localidade=X}
Caso2: {tipo_da_chamada=DDD, faixa_de_horrio=21-9, valor_localidade=X}
Caso3: {tipo_da_chamada=CL, faixa_de_horrio=0-6, valor_localidade=X}
Caso4: {tipo_da_chamada=DDD, faixa_de_horrio=9-21, valor_localidade=X}
Caso5: {tipo_da_chamada=DDI, faixa_de_horrio=Y, valor_localidade=X}
Um outro tipo de tcnica para os teste da caixa-preta pode ser utilizada
para completar a tcnica de causa-efeito. A tcnica de anlise do valor
limite visa estabelecer casos de testes nos quais os valores de limites
extremos sero avaliados.
Para o exemplo anterior poderamos criar casos que testassem valores
de faixa de horrio prximos ao limite. Por exemplo, 5:59, 6:00, 6:01,
23:59, 0:00, 0:01, e assim da mesma forma para as outras faixas de
horrio.