ti - análise de sistemas - concursos

8/6/2019 TI - Anlise de sistemas - Concursos

1/123

Anlise de Sistemas


2/123

ndice

Captulo 1 - Introduo 1

1.1 Anlise e Especificao de Requisitos 11.2 A Organizao deste Texto 2

PARTE I ESPECIFICAO DE REQUISITOS 3

Captulo 2 Tcnicas de Levantamento de Requisitos 4

2.1 Amostragem 42.2 Investigao 72.3 Entrevistas 82.4 Questionrios 132.5 Observao 182.6 Prototipao 20

Captulo 3 Modelagem de Casos de Uso 23

3.1 Casos de Uso 233.2 Diagramas de Casos de Uso 253.3 Descrio de Casos de Uso 263.4 Associaes entre Casos de Uso 28

PARTE II ANLISE ORIENTADA A OBJETOS 33

Captulo 4 Introduo Orientao a Objetos 34

4.1 Abordagem Estruturada x Abordagem Orientada a Objetos 344.2 Conceitos da Orientao a Objetos 364.3 Processo de Desenvolvimento Orientado a Objetos 474.4 A Linguagem de Modelagem Unificada 56

Captulo 5 - Anlise Orientada a Objetos 59

5.1 - Identificao de Classes 605.2 - Especificao de Hierarquias de Generalizao / Especializao 62

5.3 - Identificao de Subsistemas 635.4 - Identificao de Associaes e Definio de Atributos 645.5 - Determinao do Comportamento 695.6 - Definio das Operaes 72

PARTE III ANLISE ESSENCIAL DE SISTEMAS 75

Captulo 6 Introduo Anlise Essencial 76

6.1 - Conceitos 776.2 - Especificao da Essncia do Sistema 82


3/123

Captulo 7 Modelagem de Dados 86

7.1 - Conceitos Bsicos 867.2 - Restries de Integridade ou Leis de Consolidao 907.3 - Outras Consideraes sobre Atributos 947.4 - Outros Conceitos Importantes 967.5 - Dicionrio de Dados 102

Captulo 8 Modelagem Funcional 104

8.1 - Conceitos Bsicos 1058.2 - Construindo DFDs 1118.3 - Tcnicas de Especificao de Processos 113


4/123

1 IntroduoO desenvolvimento de software uma atividade de crescente importncia na sociedade

contempornea. A utilizao de computadores nas mais diversas reas do conhecimentohumano tem gerado uma crescente demanda por solues computadorizadas.

importante observar que, associada ao acrscimo da demanda, a evoluo dohardware tem sido mais acentuada, disponibilizando aos usurios mquinas cada vez maisvelozes e com maior capacidade de processamento.

Neste contexto, identificou-se, j na dcada de 70, uma situao crtica nodesenvolvimento de software, a chamada Crise do Software [Pressman00], caracterizada

pelos seguintes fatos:

demanda muito superior capacidade de desenvolvimento; qualidade insuficiente dos produtos; e estimativas de custo e tempo raramente cumpridas nos projetos.

Visando melhorar a qualidade dos produtos de software e aumentar a produtividade noprocesso de desenvolvimento, surgiu a rea de pesquisa denominadaEngenharia de Software.A Engenharia de Software busca organizar esforos no desenvolvimento de ferramentas,metodologias e ambientes de suporte ao desenvolvimento de software.

Dentre as principais atividades de um processo de desenvolvimento de software,destaca-se a atividade de anlise e especificao de requisitos, na qual os requisitos de umsistema so levantados e modelados, para s ento ser projetada e implementada uma soluo.Esta atividade o objeto de estudo deste texto.

1.1 Anlise e Especificao de Requisitos

Um completo entendimento dos requisitos do software essencial para o sucesso deum esforo de desenvolvimento de software. A atividade de anlise e especificao derequisitos um processo de descoberta, refinamento, modelagem e especificao. O escopodo software definido no planejamento do projeto refinado em detalhe, as funes e odesempenho do software so especificados, as interfaces com outros sistemas so indicadas erestries que o software deve atender so estabelecidas. Modelos dos dados requeridos, docontrole e do comportamento operacional so construdos. Finalmente, critrios para a

avaliao da qualidade em atividades subseqentes so estabelecidos.Os principais profissionais envolvidos nesta atividade so o engenheiro de software

(muitas vezes chamado analista) e o cliente / usurio.

Neste texto, dividiremos a atividade de Anlise e Especificao de Requisitos em duasoutras com propsitos mais especficos, ainda que extremamente relacionadas:

Elicitao de Requisitos: nesta atividade, os requisitos so capturados sob uma perspectiva dos usurios, isto , os modelos gerados procuram definir asfuncionalidades (requisitos funcionais) e restries (requisitos no funcionais) quedevem ser consideradas para atender s necessidades dos usurios;

Anlise: nesta atividade, so modelados as estruturas internas de um sistemacapazes de satisfazer os requisitos identificados.


5/123

A etapa de Elicitao de Requisitos (ou Especificao de Requisitos) independente

de paradigma, uma vez que trata os requisitos do sistema sob uma perspectiva externa.Entretanto, a atividade de Anlise, que modela as estruturas internas de um sistema,

completamente dependente do paradigma adotado no desenvolvimento. Assim, este texto dividido em trs partes:

PARTE I - ESPECIFICAO DE REQUISITOS: trata do levantamento e da modelagemdos requisitos segundo uma perspectiva externa, independente de paradigma.

Nesta parte, so discutidas tcnicas para levantamento de requisitos e a tcnica demodelagem de casos de uso, para modelagem dos requisitos funcionais de umsistema.

PARTE II - ANLISE ORIENTADA A OBJETOS: apresenta os principais conceitos daorientao a objetos e a linguagem de modelagem unificada (UML) e explora amodelagem de anlise segundo o paradigma de objetos.

PARTE III - ANLISE ESSENCIAL DE SISTEMAS: apresenta os principais conceitos daanlise essencial e discute a modelagem de anlise segundo o mtodo da anliseessencial, que adota o paradigma estruturado.

1.2 - A Organizao deste Texto

Este texto procura oferecer uma viso geral atividade de Anlise e Especificao deRequisitos e contm, alm desta Introduo, mais sete captulos, divididos em trs partes.

Na PARTE I, o captulo 2 Tcnicas de Levantamento de Requisitos apresenta as

principais tcnicas utilizadas na identificao dos requisitos de um sistema. O captulo 3 Modelagem de Casos de Uso trata da modelagem de requisitos funcionais, utilizando atcnica de modelagem de casos de uso.

Na PARTE II, o enfoque recai sobre o paradigma orientado a objetos (OO). O captulo4 Introduo Orientao a Objetos discute os principais conceitos da orientao aobjetos e alguns aspectos relacionados com o processo de desenvolvimento OO, bem comointroduz a Linguagem de Modelagem Unificada (Unified Modeling Language UML). Ocaptulo 5 Anlise Orientada a Objetos discute a modelagem de anlise segundo o

paradigma OO, utilizando os modelos propostos na UML.

Finalmente, na PARTE III, discute-se a Anlise Essencial. O captulo 6 Introduo

Anlise Essencial apresenta os principais conceitos e modelos utilizados na AnliseEssencial. O captulo 7 Modelagem de Dados apresenta o modelo de Entidades eRelacionamentos. No captulo 8 Modelagem Funcional o foco a tcnica de Diagramasde Fluxos de Dados.


6/123

PARTE I ESPECIFICAO DE REQUISITOS


7/123

2 Tcnicas de Levantamento de Requisitos (Referncia: [Kendall92])Em todo desenvolvimento de software, um aspecto fundamental a captura dos

requisitos dos usurios. Para apoiar este trabalho, diversas tcnicas podem ser utilizadas.

2.1 Amostragem (Referncia: Captulo 4 [Kendall92])

Em um levantamento de requisitos, geralmente um engenheiro de software se deparacom duas importantes questes:

Entre os muitos relatrios, formulrios e documentos gerados pelos membros deuma organizao, quais devero ser objeto de investigao?

Pode haver um grande nmero de pessoas afetadas pelo sistema de informaoproposto. Quais delas devem ser entrevistadas, observadas ou questionadas?

Servindo de base para todas as tcnicas de levantamento de requisitos, entre elasinvestigao, entrevistas e observao, esto as decises cruciais dizendo respeito a o queexaminar e quem questionar ou observar. Estas decises podem ser apoiadas por umaabordagem estruturada chamada amostragem.

Amostragem o processo de seleo sistemtica de elementos representativos de uma populao. Quando os elementos selecionados em uma amostragem so analisados, pode-seassumir que esta anlise revelar informaes teis acerca da populao como um todo.

Por que usar amostragem?

diminuir custos; acelerar o processo de levantamento de informaes; eficincia: a informao tende a ser mais apurada, j que menos elementos podem

ser analisados, mas estes podem ser analisados com mais detalhes; reduzir tendncias.

O Processo da Amostragem

H quatro passos que um engenheiro de software deve seguir para projetar uma boa

amostra:1. Determinar os dados a serem coletados ou descritos: Definir o que coletar e para

que, isto , que tipo de tcnica de levantamento de informao ser usado depois.Coletar dados irrelevantes representa perda de tempo.

2. Determinar a populao a ser amostrada (o que / quem): No caso de documentos,definir quais documentos investigar e de que perodo / intervalo. No caso de

pessoas, estabelecer a que nvel da organizao pertencem ou se so pessoas defora.

3. Escolher o tipo da amostra.4. Decidir sobre o tamanho da amostra.

Os dois primeiros passos dizem respeito ao contexto do desenvolvimento. Os doisltimos referem-se tcnica de amostragem propriamente dita e so detalhados a seguir.


8/123

Tipos de Amostra

Elementos da amostra soselecionados ...

no baseada emprobabilidades

baseada em probabilidades

diretamente, sem restries de Convenincia Randmica Simples

segundo um critrio especfico Intencional Randmica Complexa

Amostra de Convenincia: irrestrita, no utiliza probabilidades, mais fcil e,geralmente, apresenta resultados irreais. Ex: aviso chamando os interessados a

participar de uma reunio.

Amostra Intencional: a escolha feita com base em critrios pr-estabelecidos peloengenheiro de software, sem levar em conta probabilidades. uma amostra apenasmoderadamente confivel. Ex: engenheiro de software escolhe, para entrevista, umgrupo de indivduos que aparentam ter conhecimento e interesse no novo sistema.

Amostra Randmica Simples: necessrio ter em mos uma lista da populao aser amostrada (documentos ou pessoas) para garantir que cada elemento tem igualchance de ser selecionado. Geralmente, no prtica, especialmente paradocumentos e relatrios.

Amostra Randmica Complexa: pode ser de trs tipos:

Amostra sistemtica: o tipo mais simples de amostragem que leva em conta probabilidades. Consiste em se pegar sempre o k-simo elemento dapopulao. Pode introduzir tendncias.

Amostra Estratificada: a abordagem mais importante para um engenheiro desoftware. Identifica sub-populaes e escolhe elementos dentre essas sub-

populaes. Muito til quando se deseja usar diferentes tcnicas delevantamento de informao para sub-grupos especficos. Ex: coletarinformaes de pessoas de diferentes nveis da organizao.

Amostra de Grupos: consiste em selecionar um grupo para ser estudado. Ex:selecionar um ou duas filiais de uma organizao, assumindo que espelham ocomportamento de todas filiais.

Tamanho da Amostra

O tamanho da amostra depende substancialmente do custo envolvido e do temporequerido para se proceder a investigao, entrevista ou questionrio posteriormente. Oclculo do tamanho da amostra varia, ainda, em funo do tipo de informao que se desejaobter.

Quando a informao desejada for quantitativa, h dois procedimentos bsicos declculo, dependentes do tipo de informao que se deseja obter:


9/123

Percentuais: quando se deseja saber propores ou percentuais, por exemplo o percentual de pessoas em uma organizao que pensa de um certo modo, otamanho da amostra pode ser calculado da seguinte forma:

1. Determinar o atributo a ser amostrado.2. Localizar onde pode ser achado.3. Estimar o percentual da populao que tem o atributo (p).4. Considerar um intervalo de aceitao (i). Ex: 10%5. Escolher nvel de confiabilidade (%) e procurar seu correspondente coeficiente

de segurana na tabela 2.1 (z).6. Calcular o erro padro: p = i / z.7. Determinar o tamanho da amostra (n): n = (p (1 p) / p

2) + 1

Nvel de

Confiabilidade (%)

Coeficiente de

Segurana (z)99 2,5898 2,3397 2,1796 2,0595 1,9690 1,6580 1,2850 0,67

Tabela 2.1 Valores de Coeficiente de Segurana [Kendall92].

Valores: quando se deseja saber quantidades (valores) reais, por exemplo o nmerode erros de preenchimento de um determinado formulrio, o tamanho da amostra

pode ser calculado da seguinte forma:

1. Determinar a varivel a ser amostrada.2. Localizar onde pode ser achada.3. Examinar a varivel para se ter uma idia acerca de sua magnitude e disperso.

Idealmente, deveria se conhecer a mdia e o desvio padro (s). Contudo, exatamente isso que normalmente se quer saber ao fazermos uma amostragem.Logo, necessrio fazer uma estimativa inicial, que ser refinada com aamostragem.

4. Considerar um intervalo de aceitao (i).5. Escolher nvel de confiabilidade (%) e procurar seu correspondente coeficiente

de segurana na tabela 1.1 (z).6. Calcular o erro padro da mdia: x = i / z.7. Determinar o tamanho da amostra (n): n = (s / x)

2 + 1

Quando as informaes a serem coletadas forem qualitativas, melhor tentar obt-lasatravs de entrevistas. Entretanto, no h frmulas mgicas para ajudar engenheiros desoftware a determinar quantas pessoas entrevistar em uma organizao. Esta deciso deve ser

baseada no tempo gasto para se proceder uma entrevista. Uma boa regra de bolso,

independentemente do tamanho da organizao, consiste em entrevistar pelo menos trspessoas em cada nvel da organizao e uma pessoa por rea funcional.


10/123


11/123

Anlise de Documentos Qualitativos

Documentos sem formato pr-determinado, tais como memorandos, quadros de avisoe manuais, tambm so teis para o levantamento de requisitos, uma vez que mostram comoos membros de uma organizao so engajados nos processos da mesma.

A anlise de documentos qualitativos deve envolver as seguintes tarefas:

Examinar documentos para identificar como os elementos da organizao soreferenciados e, assim, conhecer a organizao.

Identificar disputas (entre departamentos ou com outras empresas) e, assim,conhecer a poltica da organizao.

Identificar termos que aparecem repetidamente em documentos e caracterizem oque bom ou ruim para a organizao.

Reconhecer a existncia de senso de humor nos documentos, o que pode indicar otipo dos membros da organizao (por exemplo, conservadores, ...).

Ao analisar memorandos (inclusive os eletrnicos), d preferncia queles enviados para toda a organizao. Observe quem enviou e quem recebeu. Memorandos, tipicamentefluem horizontalmente ou de cima para baixo e provem uma idia clara de valores, crenas eatitudes dos membros da organizao.

Na investigao de sinais e quadros de aviso, procure por indcios que apontem acultura da organizao. Ex: Segurana em 1o Lugar.

Finalmente, ao analisar manuais e polticas organizacionais, procure identificar como

as coisas devem funcionar, como as metas estratgicas da organizao devem ser atingidas everifique se estes passos esto sendo seguidos ou no.

Tanto na anlise de dados qualitativos quanto de dados quantitativos, procure observarno s os documentos correntes, mas tambm documentos arquivados.

2.3 Entrevistas (Referncia: Captulo 5 [Kendall92])

Uma entrevista de levantamento de informaes uma conversa direcionada com um propsito especfico, que utiliza um formato pergunta-resposta. Os objetivos de umaentrevista incluem:

obter as opinies do entrevistado, o que ajuda na descoberta dos problemas-chavea serem tratados;

conhecer os sentimentos do entrevistado sobre o estado corrente do sistema;

obter metas organizacionais e pessoais; e

levantar procedimentos informais.

Entrevista x Investigao

Fatos obtidos em uma investigao podem explicar o desempenho passado.

Metas projetam o futuro. Entrevistas so importantes para se determinar metas.


12/123

O Processo de uma Entrevista

Em uma entrevista, o engenheiro de software est, provavelmente, estabelecendo umrelacionamento com uma pessoa estranha a ele. Assim, importante que ele:

construa, rapidamente, uma base de confiana e entendimento; mantenha o controle da entrevista; venda a idia do sistema, provendo ao entrevistado as informaes necessrias.

Uma entrevista envolve as seguintes etapas principais: planejamento, conduo eelaborao de um relatrio da entrevista.

2.3.1 - Planejamento

O planejamento de uma entrevista envolve os seguintes passos:1. Estudar material existente sobre os entrevistados e suas organizaes. Procure dar

ateno especial linguagem usada pelos membros da organizao, procurandoestabelecer um vocabulrio comum a ser usado na elaborao das questes da entrevista.Este passo visa, sobretudo, otimizar o tempo despendido nas entrevistas, evitando-se

perguntar questes bsicas e gerais.

2. Estabelecer objetivos. De maneira geral, h algumas reas sobre as quais um engenheirode software desejar fazer perguntas relativas ao processamento de informao e aocomportamento na tomada de deciso, tais como fontes de informao, formatos dainformao, freqncia na tomada de deciso, estilo da tomada de deciso, etc.

3. Decidir quem entrevistar. importante incluir na lista de entrevistados pessoas-chave detodos os nveis da organizao afetados pelo sistema. A pessoa de contato na organizao

pode ajudar nesta seleo. Quando necessrio, use amostragem.

4. Preparar a entrevista. Uma entrevista deve ser marcada com antecedncia e deve ter umadurao entre 45 minutos e uma hora.

5. Decidir sobre os tipos de questes e a estrutura da entrevista. O uso de tcnicasapropriadas de questionamento o corao de uma entrevista.

6. Decidir como registrar a entrevista. Entrevistas devem ser registradas para queinformaes obtidas no sejam perdidas logo em seguida. Os meios mais naturais de se

registrar uma entrevista incluem anotaes e o uso de gravador.

Tipos de Questes

Questes podem ser de trs tipos bsicos:

Questes subjetivas: permitem respostas abertas. Ex: O que voc acha de ...?Explique como voc ...?

Vantagens:

Provem riqueza de detalhes. Revelam novos questionamentos. Colocam o entrevistado a vontade. Permitem maior espontaneidade.


13/123

Desvantagens:

Podem resultar em muitos detalhes irrelevantes. Perda do controle da entrevista.

Respostas muito longas para se obter pouca informao til. Podem dar a impresso de que o entrevistador est perdido, sem objetivo.

Questes objetivas: limitam as respostas possveis. Ex: Quantos ...? Quem ...?Quanto tempo ...? Qual das seguintes informaes ...?

Vantagens:

Ganho de tempo, uma vez que vo direto ao ponto em questo. Mantm o controle da entrevista. Levam a dados relevantes.

Desvantagens:

Podem ser maantes para o entrevistado. Podem falhar na obteno de detalhes importantes. No constrem uma afinidade entre entrevistador e entrevistado.

Questes de aprofundamento: permitem explorar os detalhes de uma questo.Podem ser subjetivas ou objetivas. Ex: Por que? Voc poderia dar um exemplo?Como isto acontece?

Questes Objetivas x Subjetivas

Subjetivas ObjetivasConfiabilidade dos dados Baixa Alta

Uso eficiente do tempo Baixo Alto

Preciso dos dados Baixa Alta

Amplitude e profundidade Alta Baixa

Habilidade requerida do entrevistador Alta Baixa

Facilidade de anlise Baixa Alta

Tabela 2.2 Quadro Comparativo Questes Objetivas x Subjetivas.

Problemas na Elaborao de Questes

Questes capciosas: tendem a levar o entrevistado a responder de uma formaespecfica, isto , so tendenciosas.Ex: Sobre este assunto, voc est de acordo com os outros diretores, no est?Opo mais adequada: O que voc pensa sobre este assunto?

Duas questes em uma: O entrevistado pode responder a apenas uma delas, oupode se confundir em relao pergunta que est respondendo.

Ex: O que voc faz nesta situao e como?


14/123

Estrutura da Entrevista

Diz respeito organizao das questes em uma seqncia lgica. H quatro formasbsicas de se estabelecer a seqncia das questes:

Estrutura de Pirmide (Abordagem Indutiva): inicia com questes bastantedetalhadas, geralmente objetivas, e, medida que a entrevista progride, questesmais gerais, subjetivas, so colocadas. til para situaes onde o entrevistado

parece relutante em abordar um assunto determinado ou se o engenheiro desoftware deseja obter uma finalizao sobre o assunto.

Estrutura de Funil(Abordagem Dedutiva): inicia com questes gerais subjetivas e, medida que a entrevista avana, perguntas mais especficas, usando questesobjetivas, so feitas. Esta estrutura prov um meio fcil e no ameaador para secomear uma bateria de entrevistas. Permite levantar bastante informaodetalhada, sendo desnecessrias longas seqncias de questes objetivas e deaprofundamento.

Estrutura de Diamante: Combinao das duas anteriores: comea com questesespecficas, passa a questes gerais e fecha a entrevista novamente com questesespecficas. Freqentemente, a melhor forma de se estruturar uma entrevista, jque mantm o interesse do entrevistado em uma variedade de questes. Contudo,tende a ser mais longa.

Entrevista No Estruturada: No h uma definio da seqncia das questes. Deacordo com o andar da entrevista, caminhos possveis so avaliados e a seqncia estabelecida. Requer mais tempo. Vale ressaltar que, ainda que a seqncia dasquestes no seja definida a priori, as questes devem ser definidas

antecipadamente, ou seja, o planejamento necessrio.

comea com uma questo

termina com uma questo geral

comea com questes genricas e

termina com questes

inicia com questes especficas

examina questes gerais

fecha com questes


15/123

Entrevistas Estruturadas x No Estruturadas

No Estruturada Estruturada

Avaliao Difcil Fcil

Tempo Requerido Alto Baixo a Mdio

Treinamento Requerido Muito Limitado

Espontaneidade Alta Baixa

Insight do Entrevistado Muita Oportunidade Pouca

Flexibilidade Alta Baixa

Controle Baixo Alto

Preciso Baixa AltaConfiabilidade Baixa a Mdia Mdia a Alta

Amplitude e Profundidade Alta Baixa a Mdia

Tabela 2.3 Comparao entre as Abordagens Estruturada e No Estruturada.

Registro da Entrevista

importante registrar os principais aspectos de uma entrevista durante a suarealizao. No planejamento, deve-se definir como isto ser feito. H duas formas principais,

cujas vantagens e desvantagens so apresentadas a seguir: Gravador: requer a permisso do entrevistado.

Vantagens:

Registro completo da entrevista. Rapidez e melhor desenvolvimento. Reproduo para outros membros da equipe.

Desvantagens:

Pode deixar o entrevistado pouco a vontade. Pode deixar o entrevistador distrado. Pode haver necessidade de transcrever a fita.

Anotaes

Vantagens:

Mantm o entrevistador alerta. Pode ser usado para fornecer um roteiro para a entrevista. Mostra interesse e preparao do entrevistador.

Desvantagens:

Perda do andamento da conversa.

Excessiva ateno a fatos e pouca a sentimentos e opinies.


16/123

2.3.2 Conduo da Entrevista

Um dia antes, entre em contato com o entrevistado para confirmar o horrio e o

local da entrevista. Chegue um pouco antes do horrio marcado.

Apresente-se e esboe brevemente os objetivos da entrevista.

Relembre o entrevistado de que voc estar registrando pontos importantes. Se forusar gravador, coloque-o em local visvel.

Diga ao entrevistado o que ser feito com as informaes coletadas e re-assegureseu aspecto confidencial.

A entrevista deve durar entre 45 minutos e uma hora.

Quando estiver incerto sobre uma questo, pea para o entrevistado dar definiesou outros esclarecimentos. Use questes de aprofundamento.

Ao trmino da entrevista, pergunte se h algo mais sobre o assunto que oentrevistado ache importante voc saber.

Faa um resumo da entrevista e d suas impresses globais.

Informe o entrevistado sobre os passos seguintes.

Pergunte se h outra pessoa com a qual voc deveria conversar.

Quando for o caso, marque nova entrevista.

2.3.3 Relatrio da Entrevista

O relatrio ou ata da entrevista deve capturar a essncia da entrevista. Escreva orelatrio to rpido quanto possvel para assegurar qualidade.

Registre entrevistado, entrevistador, data, assunto e objetivos. Diga se os objetivosforam alcanados e aponte objetivos para entrevistas futuras. Registre, ainda, os pontos

principais da entrevista e sua opinio.

2.4 Questionrios (Referncia: Captulo 6 [Kendall92])O uso de questionrios constitui uma tcnica de levantamento de informaes que

permite ao engenheiro de software obter de vrias pessoas afetadas pelo sistema (corrente ouproposto) informaes, tais como:

Posturas: o que as pessoas na organizao dizem querer;

Crenas: o que as pessoas pensam ser realmente verdade;

Comportamento: o que as pessoas fazem;

Caractersticas: propriedades de pessoas ou coisas.


17/123

Um questionrio pode ter objetivos distintos, em funo de sua aplicao, tais como:

Procurar quantificar o que foi levantado em entrevistas.

Determinar como um sentimento (expresso em uma entrevista) realmentedifundido ou limitado.

Examinar uma grande amostra de usurios do sistema para sentir problemas oulevantar questes importantes, antes de se programar entrevistas.

H muitas similaridades entre estas duas tcnicas. De fato, pode ser til utilizar as duasabordagens em conjunto:

procurando refinar respostas no claras de um questionrio em uma entrevista;

projetando um questionrio com base no que foi levantado em uma entrevista.

Questionrios: Quando Usar? As pessoas esto espalhadas por toda a organizao.

H um grande nmero de pessoas envolvidas no projeto do sistema e necessriosaber que proporo de um dado grupo aprova ou desaprova uma particularcaracterstica do sistema proposto.

Em estudos exploratrios, quando se deseja saber uma opinio global antes de sedefinir qualquer direo especfica para o projeto.

Etapas do Processo de Uso de Questionrios

Assim como as entrevistas, para se empregar questionrios, um conjunto de passosdeve ser realizado, envolvendo pelo menos planejamento, aplicao e anlise.

2.4.1 Planejamento

No planejamento de um questionrio, devem ser levados em considerao aspectosrelacionados com a redao das questes, escalas, formato e ordem das questes.

Redao das Questes

Uma vez que questionrios e entrevistas seguem uma abordagem pergunta-resposta,

seria bastante razovel pensar que a consideraes feitas para entrevistas aplicam-se tambmpara questionrios. Contudo, importante ressaltar que h diferenas fundamentais entre estastcnicas e, portanto, novos aspectos devem ser considerados.

Em primeiro lugar, entrevistas permitem interao direta com o entrevistado a respeitodas questes e seus significados. Em uma entrevista, o engenheiro de software pode refinaruma questo, definir um termo obscuro, alterar o curso do questionamento e controlar ocontexto de modo geral. Isto no necessariamente verdade para um questionrio e, portanto,o planejamento de um questionrio e de suas questes deve ser mais cuidadoso.

Um questionrio deve:

ter questes claras e no ambguas,

ter fluxo bem definido,


18/123

ter administrao planejada em detalhes, e

levantar, antecipadamente, as dvidas das pessoas que iro respond-lo.

Questes SubjetivasQuando for utilizar questes subjetivas em um questionrio, antecipe o tipo de

resposta que voc espera obter. Estas questes devem ser restritas o suficiente para guiar aspessoas, de modo que respondam de uma maneira especfica. Tome cuidado com perguntasque permitam respostas muito amplas, pois isto pode dificultar a comparao e a interpretaodos resultados.

Questes subjetivas devem ser usadas em questionrios para levantar opinies sobrealgum aspecto do sistema ou em situaes exploratrias.

Questes Objetivas

Questes objetivas devem ser utilizadas em um questionrio:

quando o engenheiro de software capaz de listar as possveis respostas ou

para examinar uma grande amostra de pessoas.

Respostas a questes objetivas podem ser mais facilmente quantificadas. Respostas aquestes subjetivas so analisadas e interpretadas de maneira diferente. A tabela 2.4 comparao uso de questes objetivas e subjetivas em questionrios.

Questes Subjetivas Questes Objetivas

Tempo gasto para responder Alto Baixo

Natureza exploratria Alta Baixa

Amplitude e profundidade Alta Baixa

Facilidade de preparao Alta Baixa

Facilidade de anlise Baixa Alta

Tabela 2.4 Uso de questes subjetivas e objetivas em questionrios.

Linguagem Utilizada: Diretrizes Sempre que possvel, use o vocabulrio das pessoas que iro responder. Prime pela

simplicidade.

Utilize perguntas simples e curtas.

Evite redao tendenciosa.

Garanta que as questes esto tecnicamente precisas antes de inclui-las noquestionrio.

Para verificar a linguagem utilizada, aplique o questionrio antecipadamente em

um grupo piloto, pedindo ateno adequabilidade dos termos empregados.


19/123

Escalas

So usadas para medir um atributo ou caracterstica. A razo para se utilizar escalas permitir medio ou julgamento. Escalas so geralmente arbitrrias e podem no ser nicas,

por exemplo, temperatura: oC, oF, K. H quatro tipos bsicos de escalas: Nominal: utilizada para classificar coisas. a forma mais fraca de medio, uma

vez que s obtm totais para cada classificao.Ex: Que tipo de software voc mais usa?1- Editor de Texto 2- Planilha 3- Grfico 4- Outros

Ordinria: tambm permite classificao, mas implica em um rank, isto , umaescala maior ou menor que a outra. Contudo, no se pode assumir que a distnciaentre as classes a mesma.Ex: O suporte tcnico do Centro de Informao :(a) Extremamente til (b) Muito til (c) til(d) Pouco til (e) Nada til

de Intervalo: intervalos entre os nmeros das opes so iguais, o que permite quesejam feitas operaes matemticas sobre os dados obtidos do questionrio e,

portanto, uma anlise mais completa.Ex: O suporte tcnico do Centro de Informao :1- Nada til 2 3 4 5- Extremamente til

de Razo: idem de intervalo, s que possui um zero absoluto.Ex: Quantas horas, aproximadamente, voc despende diariamente no computador:0 2 4 6 8

Tipos de Escala: Quando usar?

de Razo: os intervalos so iguais e h um zero absoluto.

de Intervalo: os intervalos so iguais, mas no h um zero absoluto.

Ordinria: no possvel assumir que os intervalos so iguais, mas as classespodem ser colocadas em uma ordem.

Nominal: deseja-se classificar coisas, mas estas no podem ser ordenadas.

Problemas na Construo de Escalas

Lenidade: a pessoa responde a todas as questes do mesmo jeito. Soluo: mover acategoria para a esquerda ou direita.

Tendncia Central: a pessoa responde tudo na mdia. Soluo: criar uma escalacom mais pontos, ajustar os descritores ou tornar as diferenas menores nosextremos.

Efeito Aurola: a impresso formada em uma questo levada para outra.Soluo: mesclar questes sobre objetos diferentes.


20/123

Projeto do Questionrio

Estilo

Um formulrio bem projetado (aspectos de estilo) pode aumentar taxa de respostas. Asseguintes diretrizes podem ser teis na hora de se projetar um questionrio:

Deixe amplos espaos em branco para atrair as pessoas.

Deixe espao suficiente para as respostas das questes subjetivas.

Em questes com escala, pea para fazer um crculo na resposta.

Use os objetivos do questionrio para ajudar a determinar o formato (inclusiveinstrues).

Seja consistente no estilo. Coloque instrues sempre no mesmo local em relao

ao lay-out do questionrio, para facilitar a localizao das instrues. Use letrasmaisculas e minsculas nas perguntas e apenas letras maisculas nas respostas.

Ordem das Questes

Para ordenar as questes, considere os objetivos e, ento, determine a funo de cadaquesto para atingir esses objetivos. Use um grupo piloto para auxiliar ou observe oquestionrio com olhos de respondedor. Algumas orientaes devem ser seguidas:

As primeiras questes devem ser de interesse dos respondedores.

Agrupe itens de contedo similar e observe tendncias de associao.

Coloque os itens de menor controvrsia primeiro.

2.4.2 Aplicao do Questionrio

A primeira questo a ser definida : quem deve responder o questionrio? A decisode quem deve responder o questionrio feita em conjunto com o estabelecimento dos seusobjetivos. Quando houver muitas pessoas aptas a responder o questionrio, use amostragem.

Mtodos de Aplicao

Reunir todos os respondedores em um mesmo local para a aplicao doquestionrio.

Vantagens:

100% de retorno Instrues uniformes Resultado rpido

Problemas:

Pode ser difcil reunir todas as pessoas. O respondedor pode ter coisas importantes a fazer.


21/123

Analista entrega e recolhe cada questionrio individualmente.

Vantagens:

Boa taxa de respostaProblemas:

Desperdcio do tempo do analista. O respondedor pode ser identificado.

Respondedor administra o questionrio.

Vantagens:

Anonimato garantido. Respostas mais reais.

Problemas: Taxa menor de respostas. Este problema pode ser minimizado, mantendo-se

uma lista de respondedores e controlando a devoluo.

Por correspondncia. til somente para alcanar pessoas distribudasgeograficamente.

2.5 - Observao (Referncia: Captulo 7 [Kendall92])

Observar o comportamento e o ambiente do indivduo que toma decises pode ser uma

forma bastante eficaz de levantar informaes que, tipicamente, passam desapercebidasusando outras tcnicas.

Tomadas de deciso ocorrem em diversos nveis da organizao: operacional,gerencial e estratgico e, portanto, importante observ-las em todos os nveis que tenhaminterao com o sistema. Atravs da observao possvel capturar:

o que realmente feito e no apenas o que documentado ou explicado.

o relacionamento entre o tomador de deciso e outros membros da organizao.

A observao usada para:

obter informaes sobre o tomador de deciso e seu ambiente, que no socapturadas por outras tcnicas.

confirmar ou negar informaes de entrevistas e/ou questionrios.

Alguns pontos importantes devem ser realados: o analista deve saber o que observar,quem observar, quando, onde, porque e como.


22/123

Observao do Comportamento

Permite observar como um gerente obtm, processa, compartilha e usa a informaopara executar seu trabalho. No planejamento da observao do comportamento, os seguintespassos devem ser realizados:

1. Decidir o que observar (atividades).

2. Decidir em que nvel de detalhe a atividade deve ser observada.

3. Preparar material para a observao.

4. Decidir quando observar

Amostragem de Horrios: perodos para observao escolhidos aleatoriamente.Evita tendncias, mas no permite a observao completa de um evento e to

pouco de um evento pouco freqente.

Amostragem de Eventos: observao de eventos completos.

O ideal combinar estas duas abordagens.

A observao deve ser registrada. Para tal, na preparao do material para aobservao, as seguintes abordagens podem ser empregadas:

Pares de adjetivos: estabelea pares de adjetivos que capturem adequadamente ocomportamento do indivduo durante a tomada de deciso, tais como, decidido/indeciso, confidencial/no confidencial, etc.

Categorias: defina previamente categorias de atividades e durante a observao

anote sua ocorrncia ou no.Ex: O Gerente instrui subordinadosquestiona subordinadosl informao externa

processa informaes

Scripts: Para cada indivduo observado, escreva uma lista de atividades por eledesempenhadas. O tomador de deciso o ator, que observado atuando, isto ,tomando decises.

Observao de Ambiente Fsico

O tomador de deciso influencia e influenciado pelo seu meio fsico. A observaodo ambiente fsico tem uma forte analogia com a crtica de filmes. Muitas vezes, possvelobservar particularidades do ambiente fsico que confirmam ou negam narrativas encontradasem entrevistas e questionrios.

Uma forma sistemtica de se proceder uma observao do ambiente fsico a chamadaobservao estruturada do ambiente. Ela sistemtica porque prov uma abordagem padro

para anlise de elementos que influenciam a tomada de deciso, permitindo que vriosengenheiros de software utilizem uma mesma base. Dentre os elementos a serem observados,destacam-se:

Localizao do escritrio em relao a outros escritrios: Escritrios de fcilacesso tendem a aumentar a freqncia de interao e o fluxo de mensagens


23/123


24/123

Usando a prototipao como uma alternativa para o ciclo de vida de desenvolvimento

de um sistema, possvel capturar mais rapidamente se os requisitos colocados sobre osoftware esto em conformidade com o requerido pelos usurios.

De fato, a rigor, a abordagem de prottipo de caractersticas selecionadas no deveriaser considerada prototipao, mas sim parte da estratgia de um desenvolvimento incrementalou evolutivo. Contudo, as outras trs abordagens poderiam ser utilizadas em umdesenvolvimento com ciclo de vida com prototipao.

Decidindo quando e que tipo de Prototipao usar

Considerar:

Tipo do problema a ser resolvido (domnio do problema, tipo do sistema)

Soluo a ser apresentada pelo sistema (tecnologia a ser empregada domnio dasoluo)

Novidade (em termos de tecnologia e do domnio do problema)

Complexidade (considerar clareza dos requisitos e tamanho do sistema)

Diretrizes para o Desenvolvimento de um Prottipo

Trabalhe com mdulos gerenciveis: para fins de prototipao no necessrio emuitas vezes, nem desejvel, construir um sistema completo.

Construa o prottipo rapidamente: a construo de um prottipo na fase de anlisee especificao de requisitos no pode consumir tempo em demasia, caso contrrioperde sua finalidade. Para acelerar a construo, use ferramentas adequadas.

Modifique o prottipo em iteraes sucessivas: o prottipo deve ser alterado emdireo s necessidades do usurio. Cada modificao requer uma nova avaliao.

Enfatize a interface com o usurio: as interfaces do prottipo devem permitir que ousurio interaja facilmente com o sistema. Um mnimo de treinamento deve serrequerido. Sistemas interativos com interfaces grficas so muito indicados

prototipao.

Usurios na Prototipao

Usurios so fundamentais na prototipao. Para capturar as reaes dos usurios emrelao ao prottipo, outras tcnicas de levantamento de informao devem ser usadas emconjunto. Durante a experimentao do usurio com o prottipo, utiliza-se a observao. Paracapturar opinies e sugestes, podem ser empregados, alm da observao, entrevistas equestionrios.


25/123

Problemas da Prototipao

Gerncia do projeto: Normalmente, vrias iteraes so necessrias para se refinar

um prottipo. Sob esta tica, surge uma importante questo: quando parar? Se estaquesto no for tratada com cuidado, a prototipao pode se estenderindefinidamente. importante, pois, delinear e seguir um plano para coletar,analisar e interpretar as informaes de realimentao do usurio.

Considerar o prottipo como sendo o sistema final: a qualidade pode no ter sidoapropriadamente considerada.

Vantagens da Prototipao

Permite alterar o sistema mais cedo no desenvolvimento, adequando-o mais de

perto s necessidades do usurio (menor custo de uma alterao). Permite descartar um sistema quando este se mostrar inadequado (prottipo de

viabilidade).

Possibilidade de desenvolver um sistema que atenda mais de perto as necessidadese expectativas dos usurios. Permite uma interao com o usurio ao longo de todoo ciclo de vida do desenvolvimento.

Referncias do Captulo:

[Kendall92] K.E. Kendall, J.E. Kendall; Systems Analysis and Design, Prentice Hall, 1992.


26/123

3 Modelagem de Casos de Uso

Quando um novo sistema precisa ser construdo, surge uma importante questo: Comocaracterizar os requisitos do sistema de um modo adequado para a Engenharia de Software,uma vez que, necessrio identificar quais os objetos/entidades relevantes, como eles serelacionam e como se comportam no contexto do sistema. Alm disso, preciso especificar emodelar o problema de maneira que seja possvel criar um projeto efetivo.

O desenvolvimento de sistemas um processo de construo de modelos, quetipicamente comea com um modelo de requisitos e termina com um modelo deimplementao (cdigo). Modelos de objetos (diagramas de classes, diagramas de interao,etc...) e modelos estruturados (diagramas de entidades e relacionamentos, diagramas de fluxode dados, etc...) incluem detalhes, tais como, a estrutura interna dos objetos/entidades, suasassociaes, como eles interagem dinamicamente e como invocam o comportamento dosdemais. Estas informaes so necessrias para projetar e construir um sistema, mas no sosuficientes para comunicar requisitos. Elas no capturam o conhecimento sobre as tarefas dodomnio e, portanto, difcil verificar se um modelo deste tipo realmente corresponde aosistema que tem de ser construdo [Jacobson96].

Assim, o primeiro modelo do sistema a ser construdo deve ser passvel decompreenso tanto por desenvolvedores - analistas, projetistas, programadores e testadores -como pela comunidade usuria - clientes e usurios. Modelos estruturados e de objetos somuito complexos e, portanto, no servem para este propsito. Este modelo inicial devedescrever o sistema, seu ambiente e como sistema e ambiente esto relacionados. Em outras

palavras, ele deve descrever o sistema segundo uma perspectiva externa.

Modelos de caso de uso (use cases) so uma forma de estruturar esta viso externa.Como o prprio nome sugere, um caso de uso uma maneira de usar o sistema. Usuriosinteragem com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casosde uso de um sistema representam tudo que os usurios podem fazer com este sistema. Casosde uso so os itens que um desenvolvedor vende a seus clientes.

Deve-se notar que modelos de caso de uso so independentes do mtodo de anlise aser usado. Desenvolvedores devem modelar os casos de uso explicitamente bem no incio dodesenvolvimento de software. Em todo projeto, para que seja bem sucedido, casos de usodevem ser identificados [Jacobson96].

Em suma, o processo de desenvolvimento de software comea pelo entendimento decomo o sistema ser usado. Uma vez que as maneiras de usar o sistema tenham sido definidas,a modelagem pode, ento, ser iniciada.

3.1 Casos de Uso

Nenhum sistema computacional existe isoladamente. Todo sistema interage comatores humanos ou outros sistemas, que utilizam esse sistema para algum propsito e esperamque o sistema se comporte de acordo com as maneiras previstas. Um caso de uso especificaum comportamento de um sistema segundo uma perspectiva externa e uma descrio de umconjunto de seqncias de aes realizadas pelo sistema para produzir um resultado de valor

observvel por um ator [Booch00].


27/123

Em essncia, um caso de uso (use case) uma interao tpica entre um ator (usurio

humano, outro sistema computacional ou um dispositivo) e um sistema. Um caso de usocaptura alguma funo visvel ao ator e, em especial, busca atingir uma meta do usurio

[Fowler97].Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma

compreenso comum com os usurios finais do sistema e com os especialistas do domnio.Alm disso, servem para ajudar a validar e verificar o sistema medida que ele evolui duranteseu desenvolvimento. Assim, os casos de uso no apenas representam o comportamentodesejado do sistema, mas tambm podem ser utilizados como a base de casos de teste para osistema, principalmente os testes de integrao e de sistema [Booch00].

Casos de uso tm dois importantes papis:

1. Eles capturam os requisitos funcionais de um sistema. Um modelo de caso de usodefine o comportamento de um sistema (e a informao associada) atravs de um

conjunto de casos de uso. O ambiente do sistema definido pela descrio dosdiferentes usurios. Estes usurios utilizam o sistema atravs de um nmero de casosde uso.

2. Eles oferecem uma abordagem para a modelagem de sistemas. Para gerenciar acomplexidade de sistemas reais, comum apresentar os modelos do sistema em umnmero de diferentes vises. Em uma abordagem guiada por casos de uso, pode-seconstruir uma viso para cada caso de uso, isto , em cada viso so modeladosapenas aqueles elementos que participam de um caso de uso especfico. Um

particular elemento pode, claro, participar de vrios casos de uso. Isto significa queum modelo do sistema completo s visto atravs de um conjunto de vises - uma

por caso de uso. Encontra-se todas as responsabilidades de um elemento de modelo,olhando todos os casos de uso onde este tem um papel.

Alm de serem uma ferramenta essencial na captura dos requisitos de um sistema,casos de uso tm um papel fundamental no planejamento e controle de projetos iterativos.

A captura dos casos de uso a primeira atividade a ser realizada no desenvolvimento, propriamente dito. A maioria dos casos de uso normalmente gerada durante a fase delevantamento de requisitos, mas outros casos de uso podem ser descobertos medida que otrabalho prossegue. Todo caso de uso um requisito potencial e, enquanto um requisito no capturado, no possvel planejar como trat-lo.

Usualmente, em primeiro lugar, casos de uso so listados e discutidos, para s ento,se realizar alguma modelagem. Entretanto, em alguns casos, a modelagem conceitual ajuda adescobrir casos de uso.

Um caso de uso pode ser capturado atravs de conversas com usurios tpicos,discutindo as vrias coisas que eles querem fazer com o sistema. Cada uma dessas interaesdiscretas constitui um caso de uso. D a ela um nome e escreva uma descrio textual

pequena (no mais do que uns poucos pargrafos). No tente capturar todos os detalhes de umcaso de uso logo no incio.

Os objetivos do usurio podem ser o ponto de partida para a elaborao dos casos deuso. Proponha um caso de uso para satisfazer cada um dos objetivos do usurio. A partirdeles, estude as possveis interaes do usurio com o sistema e refine o modelo de casos deuso.


28/123

3.2 - Diagramas de Casos de Uso

Diagramas de casos de uso especificam as funcionalidades que um sistema tem de

oferecer, segundo diferentes perspectivas dos usurios. Basicamente, um diagrama de casosde uso apresenta dois elementos: os atores e os casos de uso. Um ator um papel que umusurio, outro sistema ou dispositivo desempenha com respeito ao sistema. Casos de usorepresentam funcionalidades requeridas externamente. Uma associao entre um ator e umcaso de uso significa que estmulos podem ser enviados entre atores e casos de uso. Os atores

podero estar conectados aos casos de uso somente por meio de associaes. A associaoentre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si, cadaum com a possibilidade de enviar e receber mensagens [Booch00].

A figura 3.1 mostra a notao bsica da Linguagem de Modelagem Unificada UML[Booch00] para diagramas de casos de uso.

Figura 3.1 - Notao Bsica da UML para Modelos de Caso de Uso.

Um ator modela qualquer coisa que precise interagir com o sistema, tais comousurios e outros sistemas que se comunicam com o sistema em questo. Atores so externosao sistema; os casos de uso comportam os elementos de modelo que residem dentro dosistema. Assim, ao se definir fronteiras entre atores e casos de uso, est-se delimitando oescopo do sistema. Por estarem fora do sistema, atores esto fora do controle de nossasferramentas de modelagem e no precisam ser descritos em detalhes. Atores representam tudoque tem necessidade de trocar informao com o sistema. Nada mais externo ao sistema deve

ter impacto sobre o sistema. importante realar a diferena entre ator e usurio. Um usurio uma pessoa que

utiliza o sistema, enquanto um ator representa um papel especfico que um usurio podedesempenhar. Vrios usurios em uma organizao podem interagir com o sistema da mesmaforma e, portanto, desempenham o mesmo papel. Um ator representa exatamente um certo

papel que diversos usurios podem desempenhar. Assim, atores podem ser pensados comoclasses, isto , descries de um comportamento, enquanto usurios podem desempenhardiversos papis e, assim, servir como instncias de diferentes classes de atores. Ao lidar comatores, importante pensar em termos de papis ao invs de usurios. Um bom ponto de

partida para a identificao de atores verificar por que o sistema deve ser desenvolvido,

procurando observar que atores o sistema se prope a ajudar.

Ator

Caso de Uso

Caso de Uso 1

Ator 1

Caso de Uso2

Caso de Uso 3 Ator 2


29/123

Quando um ator interage com o sistema, normalmente, ele realiza uma seqncia

comportamentalmente relacionada de aes em um dilogo com o sistema. Tal seqnciacompreende um caso de uso. Um caso de uso , de fato, uma maneira especfica de utilizar o

sistema, atravs da execuo de alguma parte de sua funcionalidade. Cada caso de usoconstitui um curso completo de eventos com um ator e especifica a interao que aconteceentre o ator e o sistema. O conjunto de todas as descries de casos de uso especifica todas asmaneiras de se usar o sistema e, conseqentemente, a sua funcionalidade completa.

Um bom caso de uso compreende uma seqncia de transaes realizadas pelosistema, que produz um resultado de valor observvel para um particular ator. Por produzirum resultado de valor observvel, queremos dizer que um caso de uso tem de garantir que umator realiza uma tarefa que tem um valor identificvel. Isso importante para se obter casosde uso que no sejam muito pequenos. Por outro lado, a identificao de um particular ator importante na obteno de casos de uso que no sejam muito grandes.

Uma boa fonte para identificar casos de uso so os eventos externos. Pense sobre todosos eventos do mundo externo para os quais o sistema deve reagir. Identificar estes eventospode ajud-lo a identificar os casos de uso.

Para sistemas grandes, pode ser difcil propor uma lista de casos de uso. Nestassituaes, mais fcil chegar primeiro a uma lista de atores e tentar elaborar os casos de uso

para cada ator. Para cada curso completo de eventos com um ator, um caso de uso identificado. Nem sempre est claro qual funcionalidade deve ser colocada em casos de usoseparados ou o que apenas uma variante de um caso de uso. A priori, se as diferenas forem

pequenas, elas podem ser descritas como variantes do caso de uso; caso contrrio, devem serdescritas como casos de uso separados.

Qualquer que seja a abordagem utilizada, devemos sempre identificar os atores de umcaso de uso, descobrir qual o objetivo real do usurio e considerar modos alternativos desatisfazer estes objetivos.

3.3 - Descrio de Casos de Uso

Um caso de uso deve descrever o que um sistema faz. Geralmente, um diagrama decasos de uso insuficiente para este propsito. Assim, deve-se especificar o comportamentode um caso de uso pela descrio textual de seu fluxo de eventos, de modo que algum de fora

possa compreend-lo. Ao escrever o fluxo de eventos, deve-se incluir como e quando o casode uso inicia e termina, quando o caso de uso interage com os atores e outros casos de uso e

quais so as informaes transferidas e o fluxo bsico e fluxos alternativos do comportamento[Booch00].

Uma vez que o conjunto inicial de casos de uso estiver estabilizado, cada um delesdeve ser descrito em mais detalhes. Primeiro, deve-se descrever o fluxo de eventos principal(ou curso bsico), isto , o curso de eventos mais importante, que normalmente ocorre.Variantes do curso bsico de eventos e erros que possam vir a ocorrer devem ser descritos emcursos alternativos. Normalmente, um caso de uso possui apenas um nico curso bsico, masdiversos cursos alternativos. Tomemos como exemplo, um caixa automtico de banco, cujodiagrama de casos de uso mostrado na figura 3.2.


30/123

Figura 3.2 - Exemplo de um modelo de caso de uso.

O caso de usoEfetuar Saque poderia ser descrito da seguinte maneira:

Fluxo de Eventos Principal

Uma mensagem de saudao est sendo mostrada na tela. O cliente insere seu cartono caixa automtico, que l o cdigo da tarja magntica e checa se ele aceitvel.

Se o carto aceitvel, o caixa pede ao cliente para informar a senha e fica aguardandoat que ela seja informada.

O cliente informa a senha. Se a senha estiver correta, o caixa solicita que o clienteinforme o tipo de transao e fica aguardando.

O cliente seleciona a opo saque. O caixa mostra uma tela para que seja informada aquantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisio para o sistema

bancrio para que seja efetuado um saque na quantia especificada.

Se o saque autorizado, as notas so preparadas para serem entregues, o carto ejetado, um recibo emitido e as notas liberadas.

Cursos Alternativos

O carto no aceitvel: Se o carto no aceitvel porque sua tarja magntica no passvel de leitura ou de um tipo incompatvel, o carto ejetado com um bip.

Senha incorreta: Se a senha informada est incorreta, uma mensagem deve ser

mostrada para o cliente que poder entrar com a senha correta. Caso o cliente informetrs vezes senha incorreta, o carto dever ser confiscado.

Saque no autorizado: Se o saque no for aceito pelo Sistema Bancrio, umamensagem informando o cliente mostrada por 10 segundos e o carto ejetado.

Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento quelhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trminoda transao.

Como visto pelo exemplo anterior, um caso de uso pode ter um nmero de cursosalternativos que podem levar o caso de uso por diferentes fluxos. Tanto quanto possvel, esses

cursos alternativos, freqentemente cursos de exceo, devem ser anotados durante aespecificao de um caso do uso.

Cliente

Efetuar Saque

Emitir ExtratoSistema Bancrio

Informar Saldo


31/123

3.4 - Associaes entre Casos de Uso

Uma vez que um modelo de caso de uso expressa apenas a viso externa do sistema,

comunicaes internas entre elementos dentro do sistema no devem ser modeladas. Contudo, para permitir uma descrio mais apurada dos casos de uso em um diagrama, trs tipos derelacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser descritoscomo verses especializadas de outros casos de uso (relacionamento de generalizao/especializao); casos de uso podem ser includos como parte de outro caso de uso(relacionamento de incluso); ou casos de uso podem estender o comportamento de um outrocaso de uso bsico (relacionamento de extenso). O objetivo desses relacionamentos tornarum modelo mais compreensvel, evitar redundncias entre casos de uso e permitir descrevercasos de uso em camadas.

O relacionamento de incluso entre casos de uso significa que o caso de uso base

incorpora explicitamente o comportamento de outro caso de uso. O local em que essecomportamento includo deve ser indicado na descrio do caso de uso base, atravs de umareferncia explcita chamada ao caso de uso includo. Um relacionamento de incluso empregado quando h uma poro de comportamento que similar ao longo de um ou maiscasos de uso e no se deseja repetir a sua descrio. Para evitar redundncia e assegurar reuso,extrai-se essa descrio e compartilha-se a mesma entre diferentes casos de uso. Umrelacionamento de incluso representado por uma dependncia, estereotipada como inclui(include), como mostra a figura 3.3.

No exemplo do caixa automtico, podemos perceber que todos os trs casos de usotm em comum uma poro que diz respeito transao inicial do carto. Neste caso, um

relacionamento inclui deve ser empregado, como mostra a figura 3.3.

Figura 3.3 O relacionamento inclui para descrever compartilhamento entre casos de uso.

O caso de uso Validarpoderia ser descrito da seguinte forma:

Curso Normal

Uma mensagem de saudao est sendo mostrada na tela.

O cliente insere seu carto no caixa automtico, que l o cdigo da tarja magntica echeca se ele aceitvel.

Efetuar SaqueEmitir Extrato Informar Saldo

Validar Cliente


32/123

Se o carto aceitvel, o caixa pede ao cliente para informar a senha e fica aguardando

at que ela seja informada.

O cliente informa a senha. Se a senha estiver correta, o caixa solicita que o cliente

informe o tipo de transao e fica aguardando.Cursos Alternativos

O carto no aceitvel: Se o carto no aceitvel porque sua tarja magntica no passvel de leitura ou de um tipo incompatvel, o carto ejetado com um bip.

Senha incorreta: Se a senha informada est incorreta, uma mensagem deve sermostrada para o cliente que poder entrar com a senha correta. Caso o cliente informetrs vezes uma senha incorreta, o carto dever ser confiscado.

Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento quelhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trmino

da transao.

Com esta captura isolada do caso de uso de Validar Cliente, o caso de uso EfetuarSaque passaria a apresentar a seguinte descrio:

Curso Normal

O cliente realiza o caso de uso Validar Cliente.

O cliente seleciona a opo saque. O caixa mostra uma tela para que seja informada aquantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisio para o sistema

bancrio para que seja efetuado um saque na quantia especificada.Se o saque autorizado, as notas so preparadas para serem entregues, o carto

ejetado, um recibo emitido e as notas liberadas.

Cursos Alternativos

Saque no autorizado: Se o saque no for aceito pelo Sistema Bancrio, umamensagem informando o cliente mostrada por 10 segundos e o carto ejetado.

Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento quelhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trminoda transao.

O relacionamento de generalizao entre casos de uso significa que o caso de usofilho herda o comportamento e o significado do caso de uso pai. O caso de uso filho deveracrescentar ou sobrescrever o comportamento de seu pai e poder ser substitudo em qualquerlocal no qual o pai aparea [Booch00].

Voltando ao exemplo do sistema de caixa automtico, suponha que haja duas formasadotadas para se validar o cliente: a primeira atravs de senha, como descrito anteriormente, ea segunda por meio de anlise da retina do cliente. Neste caso, poderiam ser criadas duasespecializaes do caso de uso Validar Cliente, como mostra a figura 3.4.


33/123

Figura 3.4 O relacionamento de generalizao/especializao entre casos de uso.

Um relacionamento de extenso entre casos de uso significa que o caso de uso baseincorpora implicitamente o comportamento de um outro caso de uso em um local especificadoem sua descrio como sendo um ponto de extenso. O caso de uso base poder permanecerisolado, mas, sob certas circunstncias, seu comportamento poder ser estendido pelocomportamento de um outro caso de uso [Booch00].

Um relacionamento de extenso utilizado para modelar uma parte de um caso de usoque o usurio considera como opcional. Desse modo, separa-se o comportamento opcional docomportamento obrigatrio. Um relacionamento de extenso tambm poder ser empregado

para modelar um subfluxo separado, que executado somente sob determinadas condies.Assim como o relacionamento de incluso, o relacionamento de extenso representadocomo uma associao de dependncia, agora estereotipada como estende (extend).

O relacionamento estende nos permite capturar os requisitos funcionais de um sistemacomplexo de forma incremental. Inicialmente, as funes bsicas so entendidas, para sento a complexidade ser introduzida. Na modelagem de casos de uso, devemos primeirodescrever os casos de uso bsicos, para s ento estend-los para permitir descrever casos deuso mais avanados. O caso de uso no qual a nova funcionalidade adicionada deve ter umcurso de eventos completo e significativo por si prprio. Assim, sua descrio deve sercompletamente independente.

Suponha que, no exemplo do caixa automtico, deseja-se coletar dados estatsticossobre o uso da transao de saque para alimentar o caixa eletrnico com as notas maisadequadas para saque. Para tal, poderamos estender o caso de uso Efetuar Saque, de modoque, quando necessrio, um outro caso de uso, denominado Coletar Informaes Estatsticasde Saque, contasse e acumulasse o tipo das notas entregues em um saque. A figura 3.5 ilustraeste caso.

Validar Cliente

Verificar Senha Analisar Retina


34/123

Figura 3.5 O relacionamento estende entre casos de uso.

O relacionamento estende usado, ento, para modelar extenses a outros casos de

uso completos e utilizado para modelar:

partes opcionais de casos de uso,

cursos complexos e alternativos,

subseqncias que so executadas apenas em certos casos ou

a insero de diversos casos de uso diferentes dentro de um outro

A quebra de um caso de uso em vrios pode ocorrer tanto na fase de levantamento derequisitos, quanto na fase de anlise e projeto. Na fase de levantamento de requisitos, interessante desmembrar aqueles casos de uso que se apresentam muito complicados.

Entretanto, h casos de uso cuja complexidade global no deve ser detalhada antes da fase deprojeto.

Para utilizar os relacionamentos de incluso e extenso, aplique as seguintes regras:

Utilize o relacionamento estende quando estiver descrevendo uma variao de umcurso normal;

Utilize o relacionamento inclui quando houver repetio em dois ou mais casos de usoseparados e for desejvel evitar esta repetio.

Durante a anlise e descrio detalhada dos casos de uso, o sistema cuidadosamenteestudado. Uma vez que, geralmente, os casos de uso enfocam uma particular funcionalidade,

possvel analisar a funcionalidade total do sistema de maneira incremental. Deste modo, casosde uso para reas funcionalmente diferentes podem ser desenvolvidos independentemente e,mais tarde, reunidos para formar um modelo de requisitos completo. Com isso, permite-seenfocar um problema de cada vez, abrindo caminho para um desenvolvimento incremental.

medida que os modelos crescem, importante dividi-los para facilitar a leitura e oentendimento. Dividir um sistema complexo em subsistemas sempre uma boa opo. Paradividir e reunir casos de uso em grupos relacionados conceitual e semanticamente, a UMLoferece como ferramenta de modelagem os pacotes.

A figura 3.6 mostra um exemplo no contexto de um sistema bancrio. Neste exemplo,o sistema bancrio no est mais sendo considerado um outro sistema, mas um subsistema do

mesmo sistema do caixa automtico. A associao de dependncia entre os pacotes mostradanessa figura indica que o pacote Caixa Automtico solicita servios do pacote Contas.

Coletar Informaes Estatsticas de Saque

Efetuar Saque


35/123

Figura 3.5 Casos de Uso Agrupados em Pacotes.

Uma vez que a funcionalidade do sistema tiver sido capturada nos casos de uso, eladeve ser alocada a diferentes elementos de modelagem. Um elemento de modelagem,obviamente, pode ser comum a diversos casos de uso. Basicamente, o mapeamento de umcaso de uso em elementos de modelo pode ser apoiado pelos seguintes princpios:

As funcionalidades dos casos de uso que lidam com o registro e a manipulao deinformao so mapeadas diretamente para elementos em um modelo de anlise.

As funcionalidades diretamente dependentes do ambiente do sistema representamfuncionalidades requeridas pela interface do sistema e, portanto, so tratadas na fasede projeto, especificamente no projeto da interface do sistema.

Finalmente, funcionalidades que tipicamente envolvem o controle de uma aplicaodevem ser mapeadas em elementos no projeto do controle do sistema.

Referncias do Captulo:

[Booch00] G. Booch, J. Rumbaugh, I. Jacobson; UML Guia do Usurio. EditoraCampus, 2000.

[Fowler97] M. Fowler, K. Scott; UML Distilled: Applying the Standard Object ModelingLanguage, Addison-Wesley Object Technology Series, 1997.

[Furlan98] J.D. Furlan; Modelagem de Objetos Atravs da UML; Makron Books, 1998.

[Jacobson96] I. Jacobson; The Use Case Construct in Object-Oriented SoftwareEngineering, In: Scenario-Based Design, 1996.

CaixaAutomtico

Contas


36/123

PARTE II ANLISE ORIENTADA A OBJETOS


37/123

4. Introduo Orientao a ObjetosA construo de uma soluo computadorizada consiste no mapeamento do problema

a ser resolvido no mundo real num modelo de soluo no Espao de Solues, isto , o meiocomputacional. A modelagem envolve, ento, a identificao de objetos e operaesrelevantes no mundo real e o mapeamento desses em representaes abstratas no Espao deSolues.

distncia existente entre o problema no mundo real e o modelo abstrato construdo,convencionou-se chamargap semntico e, obviamente, quanto menor ele for, mais direto sero mapeamento e, portanto, mais rapidamente sero construdas solues para o problema. Sobessa tica, fcil perceber que ogap semntico representa a rea de atuao da Engenharia deSoftware. Diversas tcnicas e mtodos tm sido propostos para as diferentes fases do processode desenvolvimento, buscando minimiz-lo. A Orientao a Objetos um dos paradigmasexistentes para apoiar o desenvolvimento de sistemas, que busca fornecer meios para sediminuir ogap semntico. Este captulo visa introduzir os principais conceitos e benefcios daorientao a objetos.

4.1 Abordagem Estruturada x Abordagem Orientada a Objetos

Uma vez que, atualmente, a Orientao a Objetos tem tomado o espao antes ocupado pelo paradigma estruturado no desenvolvimento de sistemas, interessante fazer umacomparao entre os paradigmas que fundamentam estas abordagens:

Estruturado: adota uma viso de desenvolvimento baseada em um modelo entrada- processamento-sada. No paradigma estruturado, os dados so consideradosseparadamente das funes que os transformam e a decomposio funcional usadaintensamente.

Orientado a Objetos: pressupe que o mundo composto porobjetos, onde um objeto uma entidade que combina estrutura de dados e comportamento funcional. No

paradigma orientado a objetos, os sisitemas so estruturados a partir dos objetos queexistem no domnio do problema, isto , os sistemas so modelados como um nmerode objetos que interagem.

Em funo do paradigma que os rege, mtodos de anlise e projeto de sistemas soclassificados em mtodos estruturados e mtodos orientados a objetos.

Mtodos Estruturados

Fazem clara distino entre funes e dados. Funes, a princpio, so ativas e tmcomportamento, enquanto dados so repositrios passivos de informao, afetados porfunes. Esta diviso tem origem na arquitetura de hardware de von Neumann, onde aseparao entre programa e dados fortemente enfatizada.

Os mtodos orientados a funes conduzem o desenvolvimento de softwareestruturando as aplicaes segundo a tica das funes (aes) que o sistema dever realizar.O sistema decomposto em funes, e os dados so transportados entre elas. Esta a filosofiada proposta original da Anlise Estruturada [DeMarco78] [Gane79], cuja ferramenta bsica demodelagem so os diagramas de fluxo de dados (DFDs).


38/123

Os mtodos orientados a dados, por sua vez, enfatizam a identificao e estruturao

dos dados, subjulgando a anlise das funes para um segundo plano. Esses mtodos tmorigem no projeto de bancos de dados e, geralmente, tm no modelo de Entidades e

Relacionamentos (ER) [Chen79] sua principal ferramenta.A nfase nas funes, geralmente, leva a sistemas com muita redundncia e,

conseqentemente, inconsistentes e difceis de serem integrados. Por outro lado, a nfase nosdados est fundamentada em dois fatores significativos:

Dados possuem existncia prpria nas organizaes independentemente dos processosque os manipulam.

Dados so muito mais estveis que as funes em uma organizao. A menos que hajagrandes mudanas nos negcios de uma empresa, os dados tendem a se manterestveis.

Assim, possvel desenvolver modelos de dados sem redundncia, sem inconsistnciae fceis de integrar. Entretanto, uma vez que o modelo de dados deve representar a realidade,e o conhecimento da realidade, muitas vezes, passa pelo conhecimento das funes, ele deveser construdo de forma iterativa, no podendo ser considerado um produto acabado.

A Anlise Essencial [Pompilho95] procurou conciliar as abordagens orientadas adados e a funes em um nico mtodo, utilizando modelos para dados, funes e controles(DFDs e Modelo ER e Diagramas de Transio de Estados, respectivamente) comoferramentas para a modelagem de sistemas.

Um sistema desenvolvido usando um mtodo estruturado, freqentemente, difcil deser mantido. A princpio, o problema principal advm do fato de todas as funes terem de

conhecer como os dados esto armazenados, isto , a estrutura dos dados. Alm disso,mudanas na estrutura dos dados quase sempre acarretam modificaes em todas as funesrelacionadas a essa estrutura. Em suma, a interpretao dos dados apenas implcita, provida

pelos programas que lem ou escrevem dados. Diferentes programas podem dar diferentesinterpretaes aos dados e, portanto, necessrio conhecer como eles foram projetados para

poder interpret-los corretamente [Snyder93].

Mtodos Orientados a Objetos

Os mtodos orientados a objetos partem de um ponto de vista distinto e intermedirio,onde se pressupe que o mundo real povoado por objetos, onde um objeto uma entidadeque combina estrutura de dados e comportamento funcional. Mtodos orientados a objetos

estruturam os sistemas a partir dos objetos que existem no domnio do problema.A orientao a objetos oferece um nmero de conceitos bastante apropriados para a

modelagem de sistemas. Utilizando a orientao a objetos como base, os sistemas somodelados como um nmero de objetos que interagem. Os modelos baseados em objetos soteis para a compreenso de problemas, para a comunicao com os especialistas e usuriosdas aplicaes, e para a realizao das tarefas ao longo do ciclo de desenvolvimento desoftware. Os principais objetivos da orientao a objetos so:

diminuir a distncia conceitual entre o mundo real (domnio do problema) e o modeloabstrato de soluo (domnio da soluo);

trabalhar com noes intuitivas (objetos e aes) durante todo o ciclo de vida,atrasando, ao mximo, a introduo de conceitos de implementao.


39/123

Normalmente, esta uma maneira mais natural para descrever sistemas, j que os

objetos so geralmente bastante estveis. Alteraes que por ventura venham a ocorrer,geralmente, afetam um ou alguns poucos objetos [Jacobson92].

Eduard Yourdon [Yourdon94] d uma bom resumo do que pode ser considerado umproduto orientado a objeto:

Um sistema construdo usando um mtodo orientado a objetos aquele cujoscomponentes so partes encapsuladas de dados e funes, que podem herdar atributose comportamento de outros componentes da mesma natureza, e cujos componentescomunicam-se entre si por meio de mensagens.

Mtodos orientados a objetos utilizam uma perspectiva mais humana de observao darealidade, incluindo objetos, classificao e compreenso hierrquica. So benefciosesperados com o uso da orientao a objetos:

Capacidade de enfrentar novos domnios de aplicao; Melhoria da interao entre analistas e especialistas; Aumento da consistncia interna dos resultados da anlise; Uso de uma representao bsica consistente para a anlise e projeto; Alterabilidade, legibilidade e extensibilidade; Possibilidade de ciclos de desenvolvimento variados; Apoio reutilizao.

importante enfatizar, no entanto, que a orientao a objetos no mgica, isto , elano uma nova tbua de salvao para eliminar os problemas de produtividade e qualidadeque tm atormentado a indstria de software ao longo das ltimas dcadas. Se praticadacuidadosamente, combinada com vrias outras tcnicas de Engenharia de Software - taiscomo, uso de mtricas, reutilizao, testes, e garantia da qualidade - a orientao a objetos

pode ajudar a levar a melhorias substanciais no desempenho de uma organizao de software[Yourdon94]. Portanto, imprescindvel, para grandes projetos, a definio de um processode desenvolvimento que garanta o uso consistente dessas tcnicas e que seja apoiado porferramentas computacionais, tais como ferramentas CASE e Ambientes de Desenvolvimentode Software.

4.2 Conceitos da Orientao a Objetos

4.2.1 - Princpios para Administrar ComplexidadeO mundo real algo extremamente complexo. Quanto mais de perto o observamos,mais claramente percebemos sua complexidade. A orientao a objetos tenta gerenciar acomplexidade inerente dos problemas do mundo real, abstraindo conhecimento relevante eencapsulando-o dentro de objetos. De fato, alguns princpios bsicos gerais para aadministrao da complexidade norteiam este processo de modelagem, entre eles, abstrao,encapsulamento, modularidade e hierarquia.

Abstrao

Uma das principais formas do ser humano lidar com a complexidade atravs do uso

de abstraes. As pessoas tipicamente tentam compreender o mundo, construindo modelosmentais de partes dele. Tais modelos so uma viso simplificada de algo, onde apenas


40/123

elementos relevantes so considerados. Modelos mentais, portanto, so mais simples do queos complexos sistemas que eles modelam.

Consideremos, por exemplo, um mapa como um modelo do territrio que ele

representa. Um mapa til porque abstrai apenas aquelas caractersticas do territrio que sedeseja modelar. Se um mapa inclusse todos os detalhes do territrio, provavelmente teria omesmo tamanho do territrio e, portanto, no serviria a seu propsito.

Da mesma forma que um mapa precisa ser significativamente menor que o territrioque mapeia, incluindo apenas informaes cuidadosamente selecionadas, um modelo mentalabstrai apenas as caractersticas relevantes de um sistema para seu entendimento. Assim,

podemos definir abstrao como sendo o princpio de ignorar aspectos no relevantes de umassunto, segundo a perspectiva de um observador, tornando possvel uma concentrao maiornos aspectos principais do mesmo. De fato, a abstrao consiste na seleo que umobservador faz de alguns aspectos de um assunto, em detrimento de outros que no

demonstram ser relevantes para o propsito em questo.No que tange o desenvolvimento de software, duas formas adicionais de abstrao tm

grande importncia: a abstrao de dados e a abstrao de procedimentos.

Figura 4.1 - A abstrao enfoca as caractersticas essenciais de um objeto [Booch94].

Abstrao de DadosConsiste em definir um tipo de dado conforme as operaes aplicveis aos objetos

deste tipo. Os objetos s podem ser modificados e observados atravs dessas operaes[Coad92].

Exemplo: Um tipo de dado pilha pode ser definido atravs das operaes empilhar, isto ,colocar um elemento no topo da pilha, e desempilhar, ou seja, retirar o elemento que est notopo da pilha. Um objeto do tipo pilha s pode ser modificado e observado atravs dessasduas operaes.


41/123

Abstrao de Procedimentos

Segundo esse princpio, uma operao com um efeito bem definido pode ser tratadapor seus usurios como uma entidade nica, mesmo que a operao seja realmente conseguida

atravs de alguma seqncia de operaes de nvel mais baixo.Exemplo: Seja a operao calcular-salrio-lquido de um objeto do tipo funcionrio.Essa operao pode ser tratada por seus usurios como uma entidade nica, mesmo que elaseja, na realidade, construda como uma seqncia de operaes de nvel mais baixo, taiscomo: calcular-INSS, calcular-IR, calcular-anunio, etc.

Encapsulamento

No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamentointerno. Uma pessoa, por exemplo, geralmente utiliza uma televiso sem saber efetivamentequal a sua estrutura interna ou como seus mecanismos internos so ativados. Para utiliz-la,

basta saber realizar algumas operaes bsicas, tais como ligar/desligar a TV, mudar de umcanal para outro, regular volume, cor, etc. Como estas operaes produzem seus resultados,mostrando um programa na tela, no interessa ao telespectador.

O encapsulamento consiste na separao dos aspectos externos de um objeto,acessveis por outros objetos, de seus detalhes internos de implementao, que ficam ocultosdos demais objetos [Rumbaugh94]. A interface de comunicao de um objeto deve serdefinida de forma a revelar o menos possvel sobre o seu funcionamento interno.

Figura 4.2 - O encapsulamento oculta os detalhes de implementao de um objeto [Booch94].

Abstrao e encapsulamento so conceitos complementares: enquanto a abstraoenfoca o comportamento observvel de um objeto, o encapsulamento enfoca a implementaoque origina esse comportamento. Encapsulamento freqentemente conseguido atravs doocultamento de informao, isto , escondendo detalhes que no contribuem para suascaractersticas essenciais. Tipicamente, em um sistema orientado a objetos, a estrutura de umobjeto, e a implementao de seus mtodos, so encapsuladas [Booch94].

Por exemplo, para usar um carro, uma pessoa no precisa conhecer sua estruturainterna (motor, caixa de marcha, etc...), nem to pouco como se d a implementao de seus

mtodos. Sabe-se que necessrio ligar o carro, mas no preciso saber como esta operao implementada. Assim, sobre carros, um motorista precisa conhecer apenas as operaes que


42/123

permite utiliz-lo, a que chamamos de interface do objeto, o que inclui a ativao deoperaes, tais como ligar, mudar as marchas, acelerar, frear, etc..., e no como essasoperaes so de fato implementadas.

Encapsulamento serve para separar a interface contratual de uma abstrao e suaimplementao. Os usurios tm conhecimento apenas das operaes que podem serrequistadas e precisam estar cientes apenas do que as operaes realizam e no como elasesto implementadas.

A principal motivao para o encapsulamento facilitar a reutilizao de objetos egarantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base para alocalizao de decises de projeto que necessitam ser alteradas. Uma operao pode ter sidoimplementada de maneira ineficiente e, portanto, pode ser necessrio escolher um novoalgoritmo. Se a operao est encapsulada, apenas o objeto que a define precisa sermodificado, garantindo estabilidade ao sistema.

Modularidade

Muitos mtodos de construo de software buscam obter sistemas modulares, isto ,construdos a partir de elementos que sejam autnomos, conectados por uma estrutura simplese coerente. Modularidade crucial para se obter reusabilidade e extensibilidade.

Modularidade uma propriedade de sistemas decompostos em um conjunto demdulos coesos e fracamente acoplados. Assim, abstrao, encapsulamento e modularidadeso princpios sinergticos1. Um objeto prov uma fronteira clara em torno de uma abstrao eo encapsulamento e a modularidade provem barreiras em torno dessa abstrao [Booch94].

HierarquiaAbstrao um princpio importantssimo, mas em todas as aplicaes, exceto aquelas

mais triviais, deparamo-nos com um nmero de abstraes maior do que conseguimoscompreender em um dado momento. O encapsulamento ajuda a gerenciar esta complexidadeatravs do ocultamento da viso interna de nossas abstraes. Modularidade auxilia tambm,dando-nos um meio de agrupar logicamente abstraes relacionadas. Entretanto, isto aindano o bastante. Um conjunto de abstraes freqentemente forma uma hierarquia e, pelaidentificao dessas hierarquias, possvel simplificar significativamente o entendimentosobre um problema [Booch94]. Em suma, hierarquia uma forma de arrumar as abstraes.

4.2.2 - Conceitos Bsicos

Objetos

O mundo real povoado por elementos que interagem entre si, onde cada um delesdesempenha um papel especfico. A esses elementos, chamamos objetos. Objetos podem sercoisas concretas ou abstratas, tais como um carro, uma reserva de passagem area, umaorganizao, uma planta de engenharia, um componente de uma planta de engenharia, etc...

Do ponto de vista da modelagem de sistemas, um objeto uma entidade que incorporauma abstrao relevante no contexto de uma aplicao. Um objeto possui um estado

1 Sinergia: esforo simultneo de vrios elementos para a realizao de uma ao.


43/123

(informao), exibe um comportamento bem definido, expresso por um nmero de operaes

para examinar ou alterar seu estado, e tem identidade nica.

Figura 4.3 - Um objeto possui estado, exibe algum comportamento bem definido e possuiidentidade prpria [Booch94].

Estado

O estado de um objeto compreende o conjunto de suas propriedades, associadas a seusvalores correntes. Propriedades de objetos so geralmente referenciadas como atributos e,

portanto, o estado de um objeto diz respeito aos seus atributos e aos valores a eles associados.

ComportamentoA abstrao incorporada por um objeto caracterizada por um conjunto de servios ou

operaes, que outros objetos, ditos clientes, podem requisitar. Operaes so usadas pararecuperar ou manipular a informao de estado de um objeto e referem-se apenas s estruturasde dados do prprio objeto, no devendo acessar diretamente estruturas de outros objetos.

A comunicao entre objetos d-se por meio de troca de mensagens. Para acessar ainformao de estado de um objeto, necessrio enviar uma mensagem para ele. Umamensagem consiste do nome de uma operao e os argumentos requeridos. Assim, ocomportamento de um objeto representa como este objeto reage s mensagens a ele enviadas.Em outras palavras, o conjunto de mensagens a que um objeto pode responder representa o

seu comportamento. Um objeto , pois, uma entidade que tem seu estado representado por umconjunto de atributos (uma estrutura de informao) e seu comportamento representado porum conjunto de operaes.

Identidade

Cada objeto tem uma identidade prpria, que lhe inerente. Todos os objetos tmexistncia prpria, ou seja, dois objetos so distintos mesmo se seu estado e comportamentoforem iguais. A identidade de um objeto transcende os valores correntes de suas variveis deestado (atributos). Identificar um objeto diretamente geralmente mais eficiente que design-lo pela sua descrio [Snyder93].

No mundo real, um objeto limita-se a existir, mas, no que se refere ao mundocomputacional, cada objeto dispe de um identificador nico pelo qual pode ser referenciadoinequivocamente [Rumbaugh94].


44/123

Classes e Instncias

bastante comum encontrarmos no mundo real, diferentes objetos desempenhando

um mesmo papel. Consideremos, por exemplo, duas cadeiras. Apesar de serem objetosdiferentes, elas compartilham uma mesma estrutura e um mesmo comportamento. Entretanto,no h necessidade de se despender tempo modelando as duas cadeiras, ou vrias delas. Bastadefinir, em um nico lugar, um modelo descrevendo a estrutura e o comportamento dessesobjetos. A esse modelo damos o nome de classe.

Uma classe descreve um conjunto de objetos com as mesmas propriedades (atributos),o mesmo comportamento (operaes), os mesmos relacionamentos com outros objetos e amesma semntica. Objetos que se comportam da maneira especificada pela classe so ditosinstncias dessa classe.

Todo objeto pertence a uma classe, ou seja, instncia de uma classe. De fato, a

orientao a objetos norteia o processo de desenvolvimento atravs da classificao deobjetos, isto , objetos so agrupados em classes, em funo de exibirem facetas similares,sem, no entanto, perda de sua individualidade. Assim, a modelagem orientada a objetosconsiste, basicamente, na definio de classes. O comportamento e a estrutura de informaode uma instncia so definidos pela sua classe.

Objetos com propriedades e comportamento idnticos so descritos como instncias deuma mesma classe, de modo que a descrio de suas propriedades possa ser feita uma nicavez, de forma concisa, independentemente do nmero de objetos que tenham tais

propriedades em comum. Deste modo, uma classe captura a semntica das caractersticascomuns a todas as suas instncias.

Enquanto um objeto individual uma entidade real, que executa algum papel nosistema como um todo, uma classe captura a estrutura e comportamento comum a todos osobjetos que ela descreve. Assim, uma classe serve como uma espcie de contrato que deve serestabelecido entre uma abstrao e todos os seus clientes.

Figura 4.4 - Classificao o meio pelo qual ordenamos conhecimento [Booch94].


45/123

Alguns autores utilizam os conceitos de classe e tipo indistintamente. Entretanto, umtipo e uma classe no so a mesma coisa. Um tipo definido por um conjunto de operaes,isto , pelas manipulaes que podemos fazer com o tipo. Uma classe mais do que isso.

Podemos tambm olhar para dentro de uma classe, por exemplo, para ver sua estrutura deinformao. Assim, uma classe melhor conceituada como uma implementao especfica deum tipo [Jacobson92].

Mecanismos de Estruturao

Em qualquer sistema, objetos relacionam-se uns com os outros. Em sistemas notriviais, por sua vez, geralmente nos deparamos com uma razovel quantidade de objetos eclasses e h necessidade de lidar com esta complexidade. Assim, preciso estruturar classes eobjetos. Vrios mecanismos tm sido propostos, entre eles, associao, composio e herana.

Ligaes e Associaes

Objetos relacionam-se com outros objetos. Por exemplo, em o empregado Jootrabalha no departamento de Pessoal, temos um relacionamento entre o objeto empregadoJoo e o objeto departamento Pessoal.

Ligaes e associaes so meios de se representar relacionamentos entre objetos eentre classes, respectivamente. Uma ligao uma conexo entre objetos. No exemploanterior, h uma lig

ti - análise de sistemas - concursos

Documents