Escolar Documentos
Profissional Documentos
Cultura Documentos
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?
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.
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.
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.
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);
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);
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.
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.
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.
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.
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.
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.
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.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
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.
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.
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.
31
32
o
Reconstruo de requisitos
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
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
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.
41
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
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.
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.
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.
48
ex.: FU1;...
Se uma meta usada para mais de uma funo de usurio, elas devem ser
separadas por uma vrgula (,).
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
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
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.
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.
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.
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
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.
56
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)
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.
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
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.
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.
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.
63
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".
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.
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.
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.
72
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.
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
2. Notao
1.
ex.: FU1;...
Se uma meta usada para mais de uma funo de usurio, elas devem ser
separadas por uma vrgula (,).
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
78
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
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.
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.
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
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.
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.
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
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.
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.
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.
93
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.
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.
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.
96
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.
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".
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.
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.
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.
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.
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.
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.
107
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
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.
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.
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.
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.
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.
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.
117
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.
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.
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
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.
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.
127
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( ).
128
129
130
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.
132
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.
134
135
Sistemas em camadas
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
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.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
140
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
A relao de dependncia entre estas funes pode ser vista na figura abaixo.
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.
146
147
A funo xv_destroy( ) recebe como argumento o objeto JanelaConsulta
para destruir o programa e encerrar a execuo.
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
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.
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}
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}
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
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.
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);
161
Para casos de programas mais complexos podemos usar o grafo de
fluxo de controle para determinarmos a o nmero de caminhos
possveis.
162
163
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, ...
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.