Analise de Sistemas - Apostila

UFES - Universidade Federal do Esprito Santo

Anlise de SistemasNotas de Aula

Ricardo de Almeida FalboE-mail: [email protected]

2002/2

ndiceCaptulo 1 - Introduo 1.1 Anlise e Especificao de Requisitos 1.2 A Organizao deste Texto PARTE I ESPECIFICAO DE REQUISITOS Captulo 2 Tcnicas de Levantamento de Requisitos 2.1 Amostragem 2.2 Investigao 2.3 Entrevistas 2.4 Questionrios 2.5 Observao 2.6 Prototipao Captulo 3 Modelagem de Casos de Uso 3.1 Casos de Uso 3.2 Diagramas de Casos de Uso 3.3 Descrio de Casos de Uso 3.4 Associaes entre Casos de Uso PARTE II ANLISE ORIENTADA A OBJETOS Captulo 4 Introduo Orientao a Objetos 4.1 Abordagem Estruturada x Abordagem Orientada a Objetos 4.2 Conceitos da Orientao a Objetos 4.3 Processo de Desenvolvimento Orientado a Objetos 4.4 A Linguagem de Modelagem Unificada Captulo 5 - Anlise Orientada a Objetos 5.1 - Identificao de Classes 5.2 - Especificao de Hierarquias de Generalizao / Especializao 5.3 - Identificao de Subsistemas 5.4 - Identificao de Associaes e Definio de Atributos 5.5 - Determinao do Comportamento 5.6 - Definio das Operaes PARTE III ANLISE ESSENCIAL DE SISTEMAS Captulo 6 Introduo Anlise Essencial 6.1 - Conceitos 6.2 - Especificao da Essncia do Sistema 1 1 2 3 4 4 7 8 13 18 20 23 23 25 26 28 33 34 34 36 47 56 59 60 62 63 64 69 72 75 76 77 82

Captulo 7 Modelagem de Dados 7.1 - Conceitos Bsicos 7.2 - Restries de Integridade ou Leis de Consolidao 7.3 - Outras Consideraes sobre Atributos 7.4 - Outros Conceitos Importantes 7.5 - Dicionrio de Dados Captulo 8 Modelagem Funcional 8.1 - Conceitos Bsicos 8.2 - Construindo DFDs 8.3 - Tcnicas de Especificao de Processos

86 86 90 94 96 102 104 105 111 113

UFESDepartamento de Informtica

Anlise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.1 - Introduo

1 IntroduoO desenvolvimento de software uma atividade de crescente importncia na sociedade contempornea. A utilizao de computadores nas mais diversas reas do conhecimento humano tem gerado uma crescente demanda por solues computadorizadas. importante observar que, associada ao acrscimo da demanda, a evoluo do hardware tem sido mais acentuada, disponibilizando aos usurios mquinas cada vez mais velozes e com maior capacidade de processamento. Neste contexto, identificou-se, j na dcada de 70, uma situao crtica no desenvolvimento 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 no processo de desenvolvimento, surgiu a rea de pesquisa denominada Engenharia 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 um sistema 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 RequisitosUm completo entendimento dos requisitos do software essencial para o sucesso de um esforo de desenvolvimento de software. A atividade de anlise e especificao de requisitos um processo de descoberta, refinamento, modelagem e especificao. O escopo do software definido no planejamento do projeto refinado em detalhe, as funes e o desempenho do software so especificados, as interfaces com outros sistemas so indicadas e restries que o software deve atender so estabelecidas. Modelos dos dados requeridos, do controle 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 duas outras 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 as funcionalidades (requisitos funcionais) e restries (requisitos no funcionais) que devem ser consideradas para atender s necessidades dos usurios; Anlise: nesta atividade, so modelados as estruturas internas de um sistema capazes de satisfazer os requisitos identificados.1


Anlise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.1 - Introduo

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 modelagem dos requisitos segundo uma perspectiva externa, independente de paradigma. Nesta parte, so discutidas tcnicas para levantamento de requisitos e a tcnica de modelagem de casos de uso, para modelagem dos requisitos funcionais de um sistema. PARTE II - ANLISE ORIENTADA A OBJETOS: apresenta os principais conceitos da orientao a objetos e a linguagem de modelagem unificada (UML) e explora a modelagem de anlise segundo o paradigma de objetos. PARTE III - ANLISE ESSENCIAL DE SISTEMAS: apresenta os principais conceitos da anlise essencial e discute a modelagem de anlise segundo o mtodo da anlise essencial, que adota o paradigma estruturado.

1.2 - A Organizao deste TextoEste texto procura oferecer uma viso geral atividade de Anlise e Especificao de Requisitos 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 a tcnica de modelagem de casos de uso. Na PARTE II, o enfoque recai sobre o paradigma orientado a objetos (OO). O captulo 4 Introduo Orientao a Objetos discute os principais conceitos da orientao a objetos e alguns aspectos relacionados com o processo de desenvolvimento OO, bem como introduz a Linguagem de Modelagem Unificada (Unified Modeling Language UML). O captulo 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 Anlise Essencial. O captulo 7 Modelagem de Dados apresenta o modelo de Entidades e Relacionamentos. No captulo 8 Modelagem Funcional o foco a tcnica de Diagramas de Fluxos de Dados.

2

PARTE I ESPECIFICAO DE REQUISITOS

3


Anlise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 Tcnicas de Levantamento de Requisitos

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 depara com duas importantes questes: Entre os muitos relatrios, formulrios e documentos gerados pelos membros de uma organizao, quais devero ser objeto de investigao? Pode haver um grande nmero de pessoas afetadas pelo sistema de informao proposto. Quais delas devem ser entrevistadas, observadas ou questionadas?

Servindo de base para todas as tcnicas de levantamento de requisitos, entre elas investigao, entrevistas e observao, esto as decises cruciais dizendo respeito a o que examinar e quem questionar ou observar. Estas decises podem ser apoiadas por uma abordagem 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-se assumir 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 de fora. 3. Escolher o tipo da amostra. 4. Decidir sobre o tamanho da amostra. Os dois primeiros passos dizem respeito ao contexto do desenvolvimento. Os dois ltimos referem-se tcnica de amostragem propriamente dita e so detalhados a seguir.4



Tipos de Amostra Elementos da amostra so selecionados ... diretamente, sem restries segundo um critrio especfico no baseada em probabilidades de Convenincia Intencional baseada em probabilidades Randmica Simples 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 pelo engenheiro de software, sem levar em conta probabilidades. uma amostra apenas moderadamente confivel. Ex: engenheiro de software escolhe, para entrevista, um grupo de indivduos que aparentam ter conhecimento e interesse no novo sistema. Amostra Randmica Simples: necessrio ter em mos uma lista da populao a ser amostrada (documentos ou pessoas) para garantir que cada elemento tem igual chance de ser selecionado. Geralmente, no prtica, especialmente para documentos 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 da populao. Pode introduzir tendncias. Amostra Estratificada: a abordagem mais importante para um engenheiro de software. Identifica sub-populaes e escolhe elementos dentre essas subpopulaes. Muito til quando se deseja usar diferentes tcnicas de levantamento de informao para sub-grupos especficos. Ex: coletar informaes 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 o comportamento de todas filiais.

Tamanho da Amostra O tamanho da amostra depende substancialmente do custo envolvido e do tempo requerido para se proceder a investigao, entrevista ou questionrio posteriormente. O clculo do tamanho da amostra varia, ainda, em funo do tipo de informao que se deseja obter. Quando a informao desejada for quantitativa, h dois procedimentos bsicos de clculo, dependentes do tipo de informao que se deseja obter:

5



Percentuais: quando se deseja saber propores ou percentuais, por exemplo o percentual de pessoas em uma organizao que pensa de um certo modo, o tamanho da amostra pode ser calculado da seguinte forma: 1. 2. 3. 4. 5. Determinar o atributo a ser amostrado. Localizar onde pode ser achado. Estimar o percentual da populao que tem o atributo (p). Considerar um intervalo de aceitao (i). Ex: 10% 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) / p2) + 1 Nvel de Confiabilidade (%) 99 98 97 96 95 90 80 50 Coeficiente de Segurana (z) 2,58 2,33 2,17 2,05 1,96 1,65 1,28 0,67

Tabela 2.1 Valores de Coeficiente de Segurana [Kendall92]. Valores: quando se deseja saber quantidades (valores) reais, por exemplo o nmero de 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 a amostragem. 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-las atravs de entrevistas. Entretanto, no h frmulas mgicas para ajudar engenheiros de software 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 trs pessoas em cada nvel da organizao e uma pessoa por rea funcional.6



2.2 Investigao (Referncia: Captulo 4 [Kendall92])Muitas vezes, algumas informaes so difceis de serem obtidas atravs de entrevistas ou observao. Tais informaes revelam, tipicamente, um histrico da organizao e sua direo. Nestes casos, devemos utilizar investigao, isto , anlise de documentos. Atravs de investigao, podemos obter mais facilmente informaes, tais como tipos de documentos e problemas associados, informao financeira e contextos da organizao. Tais informaes so difceis de serem obtidas atravs de outras tcnicas de levantamento de requisitos, tais como entrevistas ou observao. Anlise de Documentos Quantitativos Documentos com formato pr-determinado, tais como relatrios e formulrios, trazem informaes muito teis a um engenheiro de software. Estes documentos tm um propsito especfico e um pblico-alvo. Relatrios de desempenho, por exemplo, podem mostrar metas de uma organizao, a distncia em relao meta e a tendncia atual. Relatrios usados no processo de tomada de deciso mostram informaes compiladas e podem incorporar algum conhecimento sobre a estratgia da organizao. Fichas (registros) provem atualizaes peridicas do que est ocorrendo no negcio. Um engenheiro de software pode inspecionar uma ficha para: (i) checar erros em quantidades e totais, (ii) procurar oportunidades de melhorar o desenho da ficha, (iii) observar nmero e tipos de transaes e (iv) procurar instncias onde a introduo de um sistema computadorizado pode simplificar o trabalho (clculos, por exemplo). Formulrios, assim como fichas, so muito teis para o levantamento de requisitos. Devem ser inspecionados tanto formulrios oficiais quanto no oficiais em uso. Exemplares de formulrios em branco devem ser coletados, procurando-se observar o tipo, propsito e o pblico alvo. Deve-se, ainda, verificar quem realmente recebe o formulrio. Ao se examinar formulrios preenchidos, observar se: (i) h itens no preenchidos, (ii) h formulrios nunca usados, (iii) h formulrios no oficiais usados regularmente e (iv) os formulrios so preenchidos pelas pessoas certas. Na investigao de formulrios preenchidos, possvel detectar problemas como: (i) a informao no flui como planejado, (ii) pontos de gargalo no processamento de formulrios, (iii) trabalho duplicado desnecessariamente, e (iv) falta de viso do fluxo global da informao, isto , porque um formulrio preenchido e quem o utilizar.

7



Anlise de Documentos Qualitativos Documentos sem formato pr-determinado, tais como memorandos, quadros de aviso e manuais, tambm so teis para o levantamento de requisitos, uma vez que mostram como os 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 so referenciados 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 o que bom ou ruim para a organizao. Reconhecer a existncia de senso de humor nos documentos, o que pode indicar o tipo 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, tipicamente fluem horizontalmente ou de cima para baixo e provem uma idia clara de valores, crenas e atitudes dos membros da organizao. Na investigao de sinais e quadros de aviso, procure por indcios que apontem a cultura 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 e verifique se estes passos esto sendo seguidos ou no. Tanto na anlise de dados qualitativos quanto de dados quantitativos, procure observar no 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 uma entrevista incluem: obter as opinies do entrevistado, o que ajuda na descoberta dos problemas-chave a 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.8



O Processo de uma Entrevista Em uma entrevista, o engenheiro de software est, provavelmente, estabelecendo um relacionamento 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 e elaborao 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, procurando estabelecer 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 engenheiro de software desejar fazer perguntas relativas ao processamento de informao e ao comportamento na tomada de deciso, tais como fontes de informao, formatos da informao, freqncia na tomada de deciso, estilo da tomada de deciso, etc. 3. Decidir quem entrevistar. importante incluir na lista de entrevistados pessoas-chave de todos 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 uma durao entre 45 minutos e uma hora. 5. Decidir sobre os tipos de questes e a estrutura da entrevista. O uso de tcnicas apropriadas de questionamento o corao de uma entrevista. 6. Decidir como registrar a entrevista. Entrevistas devem ser registradas para que informaes 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.9



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 Confiabilidade dos dados Uso eficiente do tempo Preciso dos dados Amplitude e profundidade Habilidade requerida do entrevistador Facilidade de anlise Baixa Baixo Baixa Alta Alta Baixa Objetivas Alta Alto Alta Baixa 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 forma especfica, 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, ou pode se confundir em relao pergunta que est respondendo. Ex: O que voc faz nesta situao e como?10



Estrutura da Entrevista Diz respeito organizao das questes em uma seqncia lgica. H quatro formas bsicas de se estabelecer a seqncia das questes: Estrutura de Pirmide (Abordagem Indutiva): inicia com questes bastante detalhadas, geralmente objetivas, e, medida que a entrevista progride, questes mais gerais, subjetivas, so colocadas. til para situaes onde o entrevistado parece relutante em abordar um assunto determinado ou se o engenheiro de software deseja obter uma finalizao sobre o assunto. comea com uma questo

termina com uma questo geral Estrutura de Funil (Abordagem Dedutiva): inicia com questes gerais subjetivas e, medida que a entrevista avana, perguntas mais especficas, usando questes objetivas, so feitas. Esta estrutura prov um meio fcil e no ameaador para se comear uma bateria de entrevistas. Permite levantar bastante informao detalhada, sendo desnecessrias longas seqncias de questes objetivas e de aprofundamento. comea com questes genricas e

termina com questes Estrutura de Diamante: Combinao das duas anteriores: comea com questes especficas, passa a questes gerais e fecha a entrevista novamente com questes especficas. Freqentemente, a melhor forma de se estruturar uma entrevista, j que mantm o interesse do entrevistado em uma variedade de questes. Contudo, tende a ser mais longa. inicia com questes especficas examina questes gerais fecha com questes Entrevista No Estruturada: No h uma definio da seqncia das questes. De acordo com o andar da entrevista, caminhos possveis so avaliados e a seqncia estabelecida. Requer mais tempo. Vale ressaltar que, ainda que a seqncia das questes no seja definida a priori, as questes devem ser definidas antecipadamente, ou seja, o planejamento necessrio.11



Entrevistas Estruturadas x No Estruturadas No Estruturada Avaliao Tempo Requerido Treinamento Requerido Espontaneidade Insight do Entrevistado Flexibilidade Controle Preciso Confiabilidade Amplitude e Profundidade Difcil Alto Muito Alta Muita Oportunidade Alta Baixo Baixa Baixa a Mdia Alta Estruturada Fcil Baixo a Mdio Limitado Baixa Pouca Baixa Alto Alta Mdia a 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 sua realizao. 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.12



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 for usar gravador, coloque-o em local visvel. Diga ao entrevistado o que ser feito com as informaes coletadas e re-assegure seu aspecto confidencial. A entrevista deve durar entre 45 minutos e uma hora. Quando estiver incerto sobre uma questo, pea para o entrevistado dar definies ou outros esclarecimentos. Use questes de aprofundamento. Ao trmino da entrevista, pergunte se h algo mais sobre o assunto que o entrevistado 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 o relatrio to rpido quanto possvel para assegurar qualidade. Registre entrevistado, entrevistador, data, assunto e objetivos. Diga se os objetivos foram 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 ou proposto) 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.

13



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) realmente difundido ou limitado. Examinar uma grande amostra de usurios do sistema para sentir problemas ou levantar questes importantes, antes de se programar entrevistas.

H muitas similaridades entre estas duas tcnicas. De fato, pode ser til utilizar as duas abordagens 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 necessrio saber que proporo de um dado grupo aprova ou desaprova uma particular caracterstica do sistema proposto. Em estudos exploratrios, quando se deseja saber uma opinio global antes de se definir qualquer direo especfica para o projeto.

Etapas do Processo de Uso de Questionrios Assim como as entrevistas, para se empregar questionrios, um conjunto de passos deve ser realizado, envolvendo pelo menos planejamento, aplicao e anlise. 2.4.1 Planejamento No planejamento de um questionrio, devem ser levados em considerao aspectos relacionados 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 tambm para questionrios. Contudo, importante ressaltar que h diferenas fundamentais entre estas tcnicas e, portanto, novos aspectos devem ser considerados. Em primeiro lugar, entrevistas permitem interao direta com o entrevistado a respeito das questes e seus significados. Em uma entrevista, o engenheiro de software pode refinar uma questo, definir um termo obscuro, alterar o curso do questionamento e controlar o contexto 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,14



ter administrao planejada em detalhes, e levantar, antecipadamente, as dvidas das pessoas que iro respond-lo.

Questes Subjetivas Quando 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 as pessoas, de modo que respondam de uma maneira especfica. Tome cuidado com perguntas que permitam respostas muito amplas, pois isto pode dificultar a comparao e a interpretao dos resultados. Questes subjetivas devem ser usadas em questionrios para levantar opinies sobre algum 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 a questes subjetivas so analisadas e interpretadas de maneira diferente. A tabela 2.4 compara o uso de questes objetivas e subjetivas em questionrios. Questes Subjetivas Tempo gasto para responder Natureza exploratria Amplitude e profundidade Facilidade de preparao Facilidade de anlise Alto Alta Alta Alta Baixa Questes Objetivas Baixo Baixa Baixa 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 no questionrio. Para verificar a linguagem utilizada, aplique o questionrio antecipadamente em um grupo piloto, pedindo ateno adequabilidade dos termos empregados.15



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 , uma escala maior ou menor que a outra. Contudo, no se pode assumir que a distncia entre 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 que sejam 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 classes podem 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 a categoria para a esquerda ou direita. Tendncia Central: a pessoa responde tudo na mdia. Soluo: criar uma escala com mais pontos, ajustar os descritores ou tornar as diferenas menores nos extremos. Efeito Aurola: a impresso formada em uma questo levada para outra. Soluo: mesclar questes sobre objetos diferentes.

16



Projeto do Questionrio Estilo Um formulrio bem projetado (aspectos de estilo) pode aumentar taxa de respostas. As seguintes 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 (inclusive instrues). Seja consistente no estilo. Coloque instrues sempre no mesmo local em relao ao lay-out do questionrio, para facilitar a localizao das instrues. Use letras maisculas 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 cada questo para atingir esses objetivos. Use um grupo piloto para auxiliar ou observe o questionrio 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 deciso de quem deve responder o questionrio feita em conjunto com o estabelecimento dos seus objetivos. 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 do questionrio. Vantagens: 100% de retorno Instrues uniformes Resultado rpido Problemas: Pode ser difcil reunir todas as pessoas. O respondedor pode ter coisas importantes a fazer.

17



Analista entrega e recolhe cada questionrio individualmente. Vantagens: Boa taxa de resposta Problemas: 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. geograficamente.

til

somente

para

alcanar

pessoas

distribudas

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 desapercebidas usando 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 tenham interao 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. obter informaes sobre o tomador de deciso e seu ambiente, que no so capturadas por outras tcnicas. confirmar ou negar informaes de entrevistas e/ou questionrios.

A observao usada para:

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

18



Observao do Comportamento Permite observar como um gerente obtm, processa, compartilha e usa a informao para executar seu trabalho. No planejamento da observao do comportamento, os seguintes passos 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 a observao, as seguintes abordagens podem ser empregadas: Pares de adjetivos: estabelea pares de adjetivos que capturem adequadamente o comportamento 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 subordinados questiona subordinados l informao externa processa informaes Scripts: Para cada indivduo observado, escreva uma lista de atividades por ele desempenhadas. 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 observao do ambiente fsico tem uma forte analogia com a crtica de filmes. Muitas vezes, possvel observar particularidades do ambiente fsico que confirmam ou negam narrativas encontradas em entrevistas e questionrios. Uma forma sistemtica de se proceder uma observao do ambiente fsico a chamada observao estruturada do ambiente. Ela sistemtica porque prov uma abordagem padro para anlise de elementos que influenciam a tomada de deciso, permitindo que vrios engenheiros de software utilizem uma mesma base. Dentre os elementos a serem observados, destacam-se: Localizao do escritrio em relao a outros escritrios: Escritrios de fcil acesso tendem a aumentar a freqncia de interao e o fluxo de mensagens19



informais. Grupos de escritrios encorajam o compartilhamento de informaes. Escritrios de difcil acesso tendem a aumentar a freqncia de mensagens orientadas a tarefas. Mveis e publicaes em geral: revelam necessidade de informao interna ou externa. Outros: vestimentas, equipamentos, etc.

2.6 Prototipao (Referncia: Captulo 8 [Kendall92])A prototipao uma tcnica valiosa para se obter rapidamente informaes especficas sobre requisitos de informao do usurio. Tipicamente, a prototipao permite capturar os seguintes tipos de informao: Reaes iniciais do usurio: Como o usurio se sente em relao ao sistema em desenvolvimento? Reaes ao prottipo podem ser obtidas atravs da observao, entrevistas, questionrio ou relatrio de avaliao. Sugestes do usurio para refinar ou alterar o prottipo: guiam o engenheiro de software na direo de melhor atender as necessidades dos usurios. Inovaes: novas capacidades, no imaginadas antes da interao com o prottipo. Informaes para reviso de planos: estabelecer prioridades e redirecionar planos.

Abordagens para a Prototipao Prottipo no-operacional: apenas as interfaces de entrada e sada so implementadas; o processamento propriamente dito no. til para avaliar certos aspectos do sistema quando a codificao requerida pela aplicao custosa e a noo bsica do que o sistema pode ser transmitida pela anlise de suas entradas e sadas. Prottipo arranjado s pressas: o prottipo possui toda a funcionalidade do sistema final, mas no foi construdo com o devido cuidado e, portanto, sua qualidade e desempenho so deficientes. Prottipo primeiro de uma srie: um sistema piloto desenvolvido para ser avaliado antes de ser distribudo. til quando o sistema ser implantado em vrios locais diferentes. Prottipo de caractersticas selecionadas: apenas parte das caractersticas do sistema final so implementadas. O sistema vai sendo construdo em partes: cada prottipo aprovado passa a ser um mdulo do sistema.

Prototipao como Alternativa para o Ciclo de Vida no Desenvolvimento de Sistemas Quando um modelo de ciclo de vida clssico (seqencial linear) utilizado, dependendo do tamanho do sistema, o tempo requerido para completar o ciclo pode ser muito grande e os requisitos dos usurios podem ser alterados, fazendo com que o sistema entregue no satisfaa as necessidades dos usurios.20



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 o software esto em conformidade com o requerido pelos usurios. De fato, a rigor, a abordagem de prottipo de caractersticas selecionadas no deveria ser considerada prototipao, mas sim parte da estratgia de um desenvolvimento incremental ou evolutivo. Contudo, as outras trs abordagens poderiam ser utilizadas em um desenvolvimento 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 da soluo) 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 e muitas vezes, nem desejvel, construir um sistema completo. Construa o prottipo rapidamente: a construo de um prottipo na fase de anlise e especificao de requisitos no pode consumir tempo em demasia, caso contrrio perde sua finalidade. Para acelerar a construo, use ferramentas adequadas. Modifique o prottipo em iteraes sucessivas: o prottipo deve ser alterado em direo s necessidades do usurio. Cada modificao requer uma nova avaliao. Enfatize a interface com o usurio: as interfaces do prottipo devem permitir que o usurio interaja facilmente com o sistema. Um mnimo de treinamento deve ser requerido. Sistemas interativos com interfaces grficas so muito indicados prototipao.

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

21



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 esta questo no for tratada com cuidado, a prototipao pode se estender indefinidamente. 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 sido apropriadamente 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 necessidades e expectativas dos usurios. Permite uma interao com o usurio ao longo de todo o ciclo de vida do desenvolvimento.

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

22


Anlise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 Modelagem de Casos de Uso

3 Modelagem de Casos de UsoQuando um novo sistema precisa ser construdo, surge uma importante questo: Como caracterizar 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 se relacionam e como se comportam no contexto do sistema. Alm disso, preciso especificar e modelar o problema de maneira que seja possvel criar um projeto efetivo. O desenvolvimento de sistemas um processo de construo de modelos, que tipicamente comea com um modelo de requisitos e termina com um modelo de implementao (cdigo). Modelos de objetos (diagramas de classes, diagramas de interao, etc...) e modelos estruturados (diagramas de entidades e relacionamentos, diagramas de fluxo de dados, etc...) incluem detalhes, tais como, a estrutura interna dos objetos/entidades, suas associaes, como eles interagem dinamicamente e como invocam o comportamento dos demais. Estas informaes so necessrias para projetar e construir um sistema, mas no so suficientes para comunicar requisitos. Elas no capturam o conhecimento sobre as tarefas do domnio e, portanto, difcil verificar se um modelo deste tipo realmente corresponde ao sistema que tem de ser construdo [Jacobson96]. Assim, o primeiro modelo do sistema a ser construdo deve ser passvel de compreenso tanto por desenvolvedores - analistas, projetistas, programadores e testadores como pela comunidade usuria - clientes e usurios. Modelos estruturados e de objetos so muito complexos e, portanto, no servem para este propsito. Este modelo inicial deve descrever 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. Usurios interagem com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casos de uso de um sistema representam tudo que os usurios podem fazer com este sistema. Casos de 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 a ser usado. Desenvolvedores devem modelar os casos de uso explicitamente bem no incio do desenvolvimento de software. Em todo projeto, para que seja bem sucedido, casos de uso devem ser identificados [Jacobson96]. Em suma, o processo de desenvolvimento de software comea pelo entendimento de como 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 UsoNenhum sistema computacional existe isoladamente. Todo sistema interage com atores humanos ou outros sistemas, que utilizam esse sistema para algum propsito e esperam que o sistema se comporte de acordo com as maneiras previstas. Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa e uma descrio de um conjunto de seqncias de aes realizadas pelo sistema para produzir um resultado de valor observvel por um ator [Booch00].

23



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 uso captura 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 durante seu desenvolvimento. Assim, os casos de uso no apenas representam o comportamento desejado do sistema, mas tambm podem ser utilizados como a base de casos de teste para o sistema, 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 uso define o comportamento de um sistema (e a informao associada) atravs de um conjunto de casos de uso. O ambiente do sistema definido pela descrio dos diferentes usurios. Estes usurios utilizam o sistema atravs de um nmero de casos de uso. 2. Eles oferecem uma abordagem para a modelagem de sistemas. Para gerenciar a complexidade de sistemas reais, comum apresentar os modelos do sistema em um nmero de diferentes vises. Em uma abordagem guiada por casos de uso, pode-se construir uma viso para cada caso de uso, isto , em cada viso so modelados apenas aqueles elementos que participam de um caso de uso especfico. Um particular elemento pode, claro, participar de vrios casos de uso. Isto significa que um 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 de levantamento de requisitos, mas outros casos de uso podem ser descobertos medida que o trabalho 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 a descobrir 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 interaes discretas 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 um caso de uso logo no incio. Os objetivos do usurio podem ser o ponto de partida para a elaborao dos casos de uso. Proponha um caso de uso para satisfazer cada um dos objetivos do usurio. A partir deles, estude as possveis interaes do usurio com o sistema e refine o modelo de casos de uso.24



3.2 - Diagramas de Casos de UsoDiagramas de casos de uso especificam as funcionalidades que um sistema tem de oferecer, segundo diferentes perspectivas dos usurios. Basicamente, um diagrama de casos de uso apresenta dois elementos: os atores e os casos de uso. Um ator um papel que um usurio, outro sistema ou dispositivo desempenha com respeito ao sistema. Casos de uso representam funcionalidades requeridas externamente. Uma associao entre um ator e um caso 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 associao entre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si, cada um 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.

Caso de Uso 1 Ator 1 Caso de Uso 3 Caso de Uso 2 Ator 2

Ator

Caso 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 como usurios e outros sistemas que se comunicam com o sistema em questo. Atores so externos ao sistema; os casos de uso comportam os elementos de modelo que residem dentro do sistema. Assim, ao se definir fronteiras entre atores e casos de uso, est-se delimitando o escopo do sistema. Por estarem fora do sistema, atores esto fora do controle de nossas ferramentas de modelagem e no precisam ser descritos em detalhes. Atores representam tudo que 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 pode desempenhar. Vrios usurios em uma organizao podem interagir com o sistema da mesma forma e, portanto, desempenham o mesmo papel. Um ator representa exatamente um certo papel que diversos usurios podem desempenhar. Assim, atores podem ser pensados como classes, isto , descries de um comportamento, enquanto usurios podem desempenhar diversos papis e, assim, servir como instncias de diferentes classes de atores. Ao lidar com atores, 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.25



Quando um ator interage com o sistema, normalmente, ele realiza uma seqncia comportamentalmente relacionada de aes em um dilogo com o sistema. Tal seqncia compreende 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 uso constitui um curso completo de eventos com um ator e especifica a interao que acontece entre o ator e o sistema. O conjunto de todas as descries de casos de uso especifica todas as maneiras de se usar o sistema e, conseqentemente, a sua funcionalidade completa. Um bom caso de uso compreende uma seqncia de transaes realizadas pelo sistema, que produz um resultado de valor observvel para um particular ator. Por produzir um resultado de valor observvel, queremos dizer que um caso de uso tem de garantir que um ator realiza uma tarefa que tem um valor identificvel. Isso importante para se obter casos de 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 todos os eventos do mundo externo para os quais o sistema deve reagir. Identificar estes eventos pode ajud-lo a identificar os casos de uso. Para sistemas grandes, pode ser difcil propor uma lista de casos de uso. Nestas situaes, 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 uso separados 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 ser descritas como casos de uso separados. Qualquer que seja a abordagem utilizada, devemos sempre identificar os atores de um caso de uso, descobrir qual o objetivo real do usurio e considerar modos alternativos de satisfazer estes objetivos.

3.3 - Descrio de Casos de UsoUm caso de uso deve descrever o que um sistema faz. Geralmente, um diagrama de casos de uso insuficiente para este propsito. Assim, deve-se especificar o comportamento de 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 caso de 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 deles deve 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 em cursos alternativos. Normalmente, um caso de uso possui apenas um nico curso bsico, mas diversos cursos alternativos. Tomemos como exemplo, um caixa automtico de banco, cujo diagrama de casos de uso mostrado na figura 3.2.

26



Efetuar Saque

Cliente

Emitir Extrato

Sistema Bancrio

Informar Saldo

Figura 3.2 - Exemplo de um modelo de caso de uso. O caso de uso Efetuar Saque poderia ser descrito da seguinte maneira: Fluxo de Eventos Principal Uma mensagem de saudao est sendo mostrada na tela. O cliente insere seu carto no 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 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. O cliente seleciona a opo saque. O caixa mostra uma tela para que seja informada a quantia. 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 informe trs vezes senha incorreta, o carto dever ser confiscado. Saque no autorizado: Se o saque no for aceito pelo Sistema Bancrio, uma mensagem informando o cliente mostrada por 10 segundos e o carto ejetado. Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento que lhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trmino da transao. Como visto pelo exemplo anterior, um caso de uso pode ter um nmero de cursos alternativos que podem levar o caso de uso por diferentes fluxos. Tanto quanto possvel, esses cursos alternativos, freqentemente cursos de exceo, devem ser anotados durante a especificao de um caso do uso.27



3.4 - Associaes entre Casos de UsoUma 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 de relacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser descritos como 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 outro caso de uso bsico (relacionamento de extenso). O objetivo desses relacionamentos tornar um modelo mais compreensvel, evitar redundncias entre casos de uso e permitir descrever casos 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 esse comportamento includo deve ser indicado na descrio do caso de uso base, atravs de uma referncia 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 mais casos 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. Um relacionamento 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 uso tm 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.

Validar Cliente

Efetuar Saque

Emitir Extrato

Informar Saldo

Figura 3.3 O relacionamento inclui para descrever compartilhamento entre casos de uso. O caso de uso Validar poderia 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 e checa se ele aceitvel.

28



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 ser mostrada para o cliente que poder entrar com a senha correta. Caso o cliente informe trs vezes uma senha incorreta, o carto dever ser confiscado. Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento que lhe 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 Efetuar Saque 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 a quantia. 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, uma mensagem informando o cliente mostrada por 10 segundos e o carto ejetado. Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento que lhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trmino da transao. O relacionamento de generalizao entre casos de uso significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai. O caso de uso filho dever acrescentar ou sobrescrever o comportamento de seu pai e poder ser substitudo em qualquer local no qual o pai aparea [Booch00]. Voltando ao exemplo do sistema de caixa automtico, suponha que haja duas formas adotadas para se validar o cliente: a primeira atravs de senha, como descrito anteriormente, e a segunda por meio de anlise da retina do cliente. Neste caso, poderiam ser criadas duas especializaes do caso de uso Validar Cliente, como mostra a figura 3.4.

29



Validar Cliente

Verificar Senha

Analisar Retina

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 base incorpora implicitamente o comportamento de um outro caso de uso em um local especificado em sua descrio como sendo um ponto de extenso. O caso de uso base poder permanecer isolado, mas, sob certas circunstncias, seu comportamento poder ser estendido pelo comportamento de um outro caso de uso [Booch00]. Um relacionamento de extenso utilizado para modelar uma parte de um caso de uso que o usurio considera como opcional. Desse modo, separa-se o comportamento opcional do comportamento 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 representado como uma associao de dependncia, agora estereotipada como estende (extend). O relacionamento estende nos permite capturar os requisitos funcionais de um sistema complexo de forma incremental. Inicialmente, as funes bsicas so entendidas, para s ento a complexidade ser introduzida. Na modelagem de casos de uso, devemos primeiro descrever os casos de uso bsicos, para s ento estend-los para permitir descrever casos de uso mais avanados. O caso de uso no qual a nova funcionalidade adicionada deve ter um curso de eventos completo e significativo por si prprio. Assim, sua descrio deve ser completamente independente. Suponha que, no exemplo do caixa automtico, deseja-se coletar dados estatsticos sobre o uso da transao de saque para alimentar o caixa eletrnico com as notas mais adequadas para saque. Para tal, poderamos estender o caso de uso Efetuar Saque, de modo que, quando necessrio, um outro caso de uso, denominado Coletar Informaes Estatsticas de Saque, contasse e acumulasse o tipo das notas entregues em um saque. A figura 3.5 ilustra este caso.

30



Efetuar Saque

Coletar Informaes Estatsticas de Saque

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 de requisitos, 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 de projeto. Para utilizar os relacionamentos de incluso e extenso, aplique as seguintes regras: Utilize o relacionamento estende quando estiver descrevendo uma variao de um curso normal; Utilize o relacionamento inclui quando houver repetio em dois ou mais casos de uso separados e for desejvel evitar esta repetio. Durante a anlise e descrio detalhada dos casos de uso, o sistema cuidadosamente estudado. Uma vez que, geralmente, os casos de uso enfocam uma particular funcionalidade, possvel analisar a funcionalidade total do sistema de maneira incremental. Deste modo, casos de uso para reas funcionalmente diferentes podem ser desenvolvidos independentemente e, mais tarde, reunidos para formar um modelo de requisitos completo. Com isso, permite-se enfocar um problema de cada vez, abrindo caminho para um desenvolvimento incremental. medida que os modelos crescem, importante dividi-los para facilitar a leitura e o entendimento. Dividir um sistema complexo em subsistemas sempre uma boa opo. Para dividir e reunir casos de uso em grupos relacionados conceitual e semanticamente, a UML oferece 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 mostrada nessa figura indica que o pacote Caixa Automtico solicita servios do pacote Contas.31



Caixa Automtico

Contas

Figura 3.5 Casos de Uso Agrupados em Pacotes. Uma vez que a funcionalidade do sistema tiver sido capturada nos casos de uso, ela deve ser alocada a diferentes elementos de modelagem. Um elemento de modelagem, obviamente, pode ser comum a diversos casos de uso. Basicamente, o mapeamento de um caso 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 de informao so mapeadas diretamente para elementos em um modelo de anlise. As funcionalidades diretamente dependentes do ambiente do sistema representam funcionalidades requeridas pela interface do sistema e, portanto, so tratadas na fase de projeto, especificamente no projeto da interface do sistema. Finalmente, funcionalidades que tipicamente envolvem o controle de uma aplicao devem ser mapeadas em elementos no projeto do controle do sistema.

Referncias do Captulo: [Booch00] [Fowler97] [Furlan98] G. Booch, J. Rumbaugh, I. Jacobson; UML Guia do Usurio. Editora Campus, 2000. M. Fowler, K. Scott; UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley Object Technology Series, 1997. J.D. Furlan; Modelagem de Objetos Atravs da UML; Makron Books, 1998.

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

32

PARTE II ANLISE ORIENTADA A OBJETOS

33


Anlise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 Introduo Orientao a Objetos

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 meio computacional. A modelagem envolve, ento, a identificao de objetos e operaes relevantes no mundo real e o mapeamento desses em representaes abstratas no Espao de Solues. distncia existente entre o problema no mundo real e o modelo abstrato construdo, convencionou-se chamar gap semntico e, obviamente, quanto menor ele for, mais direto ser o mapeamento e, portanto, mais rapidamente sero construdas solues para o problema. Sob essa tica, fcil perceber que o gap semntico representa a rea de atuao da Engenharia de Software. Diversas tcnicas e mtodos tm sido propostos para as diferentes fases do processo de desenvolvimento, buscando minimiz-lo. A Orientao a Objetos um dos paradigmas existentes para apoiar o desenvolvimento de sistemas, que busca fornecer meios para se diminuir o gap semntico. Este captulo visa introduzir os principais conceitos e benefcios da orientao a objetos.

4.1 Abordagem Estruturada x Abordagem Orientada a ObjetosUma vez que, atualmente, a Orientao a Objetos tem tomado o espao antes ocupado pelo paradigma estruturado no desenvolvimento de sistemas, interessante fazer uma comparao entre os paradigmas que fundamentam estas abordagens: Estruturado: adota uma viso de desenvolvimento baseada em um modelo entradaprocessamento-sada. No paradigma estruturado, os dados so considerados separadamente das funes que os transformam e a decomposio funcional usada intensamente. Orientado a Objetos: pressupe que o mundo composto por objetos, 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 que existem no domnio do problema, isto , os sistemas so modelados como um nmero de objetos que interagem. Em funo do paradigma que os rege, mtodos de anlise e projeto de sistemas so classificados em mtodos estruturados e mtodos orientados a objetos. Mtodos Estruturados Fazem clara distino entre funes e dados. Funes, a princpio, so ativas e tm comportamento, enquanto dados so repositrios passivos de informao, afetados por funes. Esta diviso tem origem na arquitetura de hardware de von Neumann, onde a separao entre programa e dados fortemente enfatizada. Os mtodos orientados a funes conduzem o desenvolvimento de software estruturando 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 filosofia da proposta original da Anlise Estruturada [DeMarco78] [Gane79], cuja ferramenta bsica de modelagem so os diagramas de fluxo de dados (DFDs).34



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 tm origem 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 nos dados est fundamentada em dois fatores significativos: Dados possuem existncia prpria nas organizaes independentemente dos processos que os manipulam. Dados so muito mais estveis que as funes em uma organizao. A menos que haja grandes mudanas nos negcios de uma empresa, os dados tendem a se manter estveis. Assim, possvel desenvolver modelos de dados sem redundncia, sem inconsistncia e 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 deve ser construdo de forma iterativa, no podendo ser considerado um produto acabado. A Anlise Essencial [Pompilho95] procurou conciliar as abordagens orientadas a dados 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) como ferramentas para a modelagem de sistemas. Um sistema desenvolvido usando um mtodo estruturado, freqentemente, difcil de ser 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 funes relacionadas a essa estrutura. Em suma, a interpretao dos dados apenas implcita, provida pelos programas que lem ou escrevem dados. Diferentes programas podem dar diferentes interpretaes 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 entidade que 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 so modelados como um nmero de objetos que interagem. Os modelos baseados em objetos so teis para a compreenso de problemas, para a comunicao com os especialistas e usurios das aplicaes, e para a realizao das tarefas ao longo do ciclo de desenvolvimento de software. Os principais objetivos da orientao a objetos so: diminuir a distncia conceitual entre o mundo real (domnio do problema) e o modelo abstrato 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.35



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 um produto orientado a objeto: Um sistema construdo usando um mtodo orientado a objetos aquele cujos componentes so partes encapsuladas de dados e funes, que podem herdar atributos e comportamento de outros componentes da mesma natureza, e cujos componentes comunicam-se entre si por meio de mensagens. Mtodos orientados a objetos utilizam uma perspectiva mais humana de observao da realidade, incluindo objetos, classificao e compreenso hierrquica. So benefcios esperados 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 , ela no uma nova tbua de salvao para eliminar os problemas de produtividade e qualidade que tm atormentado a indstria de software ao longo das ltimas dcadas. Se praticada cuidadosamente, combinada com vrias outras tcnicas de Engenharia de Software - tais como, 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 processo de desenvolvimento que garanta o uso consistente dessas tcnicas e que seja apoiado por ferramentas computacionais, tais como ferramentas CASE e Ambientes de Desenvolvimento de Software.

4.2 Conceitos da Orientao a Objetos4.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 a complexidade inerente dos problemas do mundo real, abstraindo conhecimento relevante e encapsulando-o dentro de objetos. De fato, alguns princpios bsicos gerais para a administrao 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 modelos mentais de partes dele. Tais modelos so uma viso simplificada de algo, onde apenas36



elementos relevantes so considerados. Modelos mentais, portanto, so mais simples do que os 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 se deseja modelar. Se um mapa inclusse todos os detalhes do territrio, provavelmente teria o mesmo tamanho do territrio e, portanto, no serviria a seu propsito. Da mesma forma que um mapa precisa ser significativamente menor que o territrio que mapeia, incluindo apenas informaes cuidadosamente selecionadas, um modelo mental abstrai apenas as caractersticas relevantes de um sistema para seu entendimento. Assim, podemos definir abstrao como sendo o princpio de ignorar aspectos no relevantes de um assunto, segundo a perspectiva de um observador, tornando possvel uma concentrao maior nos aspectos principais do mesmo. De fato, a abstrao consiste na seleo que um observador 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 Dados Consiste 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 no topo da pilha. Um objeto do tipo pilha s pode ser modificado e observado atravs dessas duas operaes.

37



Abstrao de Procedimentos Segundo esse princpio, uma operao com um efeito bem definido pode ser tratada por 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 ela seja, na realidade, construda como uma seqncia de operaes de nvel mais baixo, tais como: calcular-INSS, calcular-IR, calcular-anunio, etc. Encapsulamento No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamento interno. Uma pessoa, por exemplo, geralmente utiliza uma televiso sem saber efetivamente qual 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 um canal 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 ocultos dos demais objetos [Rumbaugh94]. A interface de comunicao de um objeto deve ser definida 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 abstrao enfoca o comportamento observvel de um objeto, o encapsulamento enfoca a implementao que origina esse comportamento. Encapsulamento freqentemente conseguido atravs do ocultamento de informao, isto , escondendo detalhes que no contribuem para suas caractersticas essenciais. Tipicamente, em um sistema orientado a objetos, a estrutura de um objeto, e a implementao de seus mtodos, so encapsuladas [Booch94]. Por exemplo, para usar um carro, uma pessoa no precisa conhecer sua estrutura interna (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 que38



permite utiliz-lo, a que chamamos de interface do objeto, o que inclui a ativao de operaes, tais como ligar, mudar as marchas, acelerar, frear, etc..., e no como essas operaes so de fato implementadas. Encapsulamento serve para separar a interface contratual de uma abstrao e sua implementao. Os usurios tm conhecimento apenas das operaes que podem ser requistadas e precisam estar cientes apenas do que as operaes realizam e no como elas esto implementadas. A principal motivao para o encapsulamento facilitar a reutilizao de objetos e garantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base para a localizao de decises de projeto que necessitam ser alteradas. Uma operao pode ter sido implementada de maneira ineficiente e, portanto, pode ser necessrio escolher um novo algoritmo. Se a operao est encapsulada, apenas o objeto que a define precisa ser modificado, 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 simples e coerente. Modularidade crucial para se obter reusabilidade e extensibilidade. Modularidade uma propriedade de sistemas decompostos em um conjunto de mdulos coesos e fracamente acoplados. Assim, abstrao, encapsulamento e modularidade so princpios sinergticos1. Um objeto prov uma fronteira clara em torno de uma abstrao e o encapsulamento e a modularidade provem barreiras em torno dessa abstrao [Booch94]. Hierarquia Abstrao um princpio importantssimo, mas em todas as aplicaes, exceto aquelas mais triviais, deparamo-nos com um nmero de abstraes maior do que conseguimos compreender em um dado momento. O encapsulamento ajuda a gerenciar esta complexidade atravs do ocultamento da viso interna de nossas abstraes. Modularidade auxilia tambm, dando-nos um meio de agrupar logicamente abstraes relacionadas. Entretanto, isto ainda no o bastante. Um conjunto de abstraes freqentemente forma uma hierarquia e, pela identificao dessas hierarquias, possvel simplificar significativamente o entendimento sobre um problema [Booch94]. Em suma, hierarquia uma forma de arrumar as abstraes.

4.2.2 - Conceitos BsicosObjetos O mundo real povoado por elementos que interagem entre si, onde cada um deles desempenha um papel especfico. A esses elementos, chamamos objetos. Objetos podem ser coisas concretas ou abstratas, tais como um carro, uma reserva de passagem area, uma organizao, 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 incorpora uma abstrao relevante no contexto de uma aplicao. Um objeto possui um estado1

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



(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 possui identidade prpria [Booch94]. Estado O estado de um objeto compreende o conjunto de suas propriedades, associadas a seus valores 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. Comportamento A abstrao incorporada por um objeto caracterizada por um conjunto de servios ou operaes, que outros objetos, ditos clientes, podem requisitar. Operaes so usadas para recuperar ou manipular a informao de estado de um objeto e referem-se apenas s estruturas de dados do prprio objeto, no devend

Analise de Sistemas - Apostila

Documents

Transcript of Analise de Sistemas - Apostila