Home

Modelagem de Sistemas de Informações

1. Figura 47 Descri o das regras uma a uma As regras de neg cio ser o utilizadas nos pr ximos passos para definir modelos mais formais do sistema Mas podemos por exemplo definir a cardinalidade dos termos em cada relacionamento descrito como na Figura 48 e no texto a seguir e Um cliente pede um ou mais livros e Livros podem ser pedidos por nenhum um ou mais clientes e Uma distribuidora entrega um ou mais livros e Um livro entregue por apenas uma distribuidora 101 Cliente UN 0 N Livro 1 D 1 Distribuidora Figura 48 Regras com cardinalidades interessante notar que regras de neg cio devem ser feitas de forma declarativa n o indicando como v o ser implementadas onde v o funcionar quem ser respons vel ou quando devem ser testadas Desse jeito as regras ser o flex veis o suficiente para ser utilizadas na modelagem do neg cio Como devem ser declarativas elas tamb m n o devem ser escritas como um procedimento VI 7 Outras Ferramentas de Modelagem O uso de tabelas permite relacionar informa es levantadas separadamente Elas s o bastante importantes nas confer ncias dos modelos VI 7 1 Respons veis por decis o Processo x Organiza o Essa tabela associa as pessoas da organiza o que foram representadas no organograma com as fun es da empresa que podem ter sido representadas anteriormente de v rias formas
2. quanto o sistema custa para ser desenvolvido A partir desse valor pode se come ar se necess rio a pensar em um pre o a ser cobrado 80 x Nessa rela o o cliente tenta pagar o menor pre o poss vel para o sistema e o fornecedor tenta cobrar o maior pre o poss vel Tanto fornecedores quanto clientes devem evitar fazer um acordo com risco de futuro arrependimento 212 Para sistemas de informa o o principal fator de custo o gasto com pessoal Assim o custo do software diretamente ligado quantidade de pessoas envolvidas no seu desenvolvimento e ao tempo que elas dedicam a essa atividade XI 3 Esfor o e Tempo de Desenvolvimento Tendo em vista que o principal fator de custo no desenvolvimento de software o gasto com pessoal uma das principais preocupa es da Engenharia de Software determinar qual ser a quantidade de pessoas e o tempo por elas dedicado a um projeto Para isso usamos o conceito de Esfor o que representa a quantidade de trabalho realizado medido em pessoa m s ou seja o trabalho feito por uma pessoa em um m s Assim podemos dizer que um sistema precisa de 4 pessoas m s para ser realizado ou seja que uma pessoa trabalhando 4 meses ou 4 pessoas trabalhando um m s Acontece que sistemas de informa o s o um pouco como beb s n o podemos ter a gesta o de um beb com nove m es em um m s Na verdade Boehm achou uma rela o entre o esfor o necess rio e
3. Por m muitas vezes n o s dif cil descobrir quais s o os requisitos n o funcionais mas tamb m produzir uma especifica o do sistema que possa ser cumprida em custo razo vel e prazo h bil de forma a atender os usu rios Um exemplo t pico seriam dois requisitos n o funcionais que genericamente s o opostos velocidade e transportabilidade Ora para fazer um software muito veloz voc precisa adapt lo especificamente para o 36 ambiente onde ele est funcionando Para fazer um software transport vel voc precisa implement lo de forma a funcionar no maior n mero poss vel de ambientes Normalmente esses dois requisitos se relacionam de forma inversa e para implement los simultaneamente necess rio um grande investimento de recursos Existem muitas formas de se dividir os requisitos n o funcionais a figura a seguir apresenta uma dessas formas apenas para deixar clara a quantidade de fatores que podem envolver um requisito n o funcional mas sem consider la melhor ou pior que outras Requisitos N o Funcionais Requisitos Requisitos do da Produto Organiza o Requisitos Externos Requisitos Requisitos Requisitos Requisitos Requisitos de de de de Interope De Usabilidade Confiabilidade Portabilidade rabilidade Etica Requisitos de Efici ncia Requisitos Requisitos Requisitos De de De Prazo Implementa o Padroniza o Requisitos Lega
4. e Diz se que uma tabela est na primeira forma normal quando todos os seus atributos s o at micos e Diz se que uma tabela est na primeira forma normal se cada coluna cont m apenas um valor e se cada linha cont m as mesmas colunas e Diz se que uma tabela est na primeira forma normal quando n o cont m tabelas aninhadas e Diz se que um modelo est na primeira forma normal se o Est integrado por tabelas o As linhas da tabela s o un vocas o A linha n o cont m itens repetitivos o Os atributos s o at micos o O atributo n o cont m valores nulos A seguinte tabela n o est na 1FN Gerente Empregado Jim Susan Rob Beth Mary Alice John Asim Renee Mike Joe Alan Tim Tabela 16 Tabela que n o est na 1FN 4 a s oe S lt 3 e Uma tabela ou entidade que n o est na primeira forma normal denotada como NN n o normalizada ou NFNF Non first normal form ou ainda NF s Essa regra foi abandonada na pr tica pela necessidade que temos de trabalhar com esses tipos de valores 139 Gerente Empregado Jim Susan Jim Rob Jim Beth Mary Alice Mary John Mary Asim Renee Mike Joe Alan Joe Tim Tabela 17 A mesma informa o da tabela anterior normalizada em 1FN Turma C digo smallint Nome String Hor rio smalldatetime Alunos Lista de Alunos Figura 76 Uma tabela n o normalizada pode conter uma lista em um
5. Figura 60 Entidade Aluno identificada pelo atributo CPF na nota o da Engenharia da Informa o Autom vel Autom vel Placa Chassis Chassis AK1 1 Placa AK1 1 Modelo Modelo Ano Ano Figura 61 A entidade autom vel pode ser identificada unicamente tanto pela placa como pelo Chassi levando a dois modelos diferentes como mostrado nesta figura A nota o fornecida pela ferramenta Erwin permite a identifica o das chaves alternativas AK Alternate Key 1 10 2 Relacionamentos Identificadores Algumas inst ncias s o identificadas tamb m ou at mesmo unicamente por seus relacionamentos Uma forma de denotar isso utilizar uma linha mais grossa no relacionamento ou algum s mbolo espec fico R Ou seja servem para modelar a abstra o de identifica o i A nota o IDEF1X por exemplo usa um c rculo negro 128 Alguns autores chamam as entidades que s o identificadas por seu relacionamento com outras entidades de entidades fracas ou entidades dependentes Atualmente esses nomes s o considerados derrogat rios para entidades que podem ser muito importantes em um modelo Os alunos tamb m muitas vezes tendem a achar que n o devemos modelar entidades fracas conclus o que est absolutamente errada Chaves Estrangeiras No modelo conceitual n o existe o conceito de chave estrangeira que uma caracter stica do modelo relacional Uma chave estrangeira
6. M gico de 0z sua documenta o n o t o simples A partir da encena o do uso da interface feita uma avalia o que pode levar a necessidade de aceit la melhor la ou at mesmo iniciar tudo do in cio 74 enis E PIE P Na hist ria uma pessoa manipula o M gico de Oz atr s de uma cortina 204 Higura 11U Exemplo de partes de um prototipo de baixa tidelidade Algumas janelas foram desenhadas a m o outras em um computador O mouse um ponteiro que pode ser mexido com a m o Landay Lee Benjani Cos Sawtos Allen A WSA Sendo CAE ma OMS TO DS ina o t e OMM Go to Iittenhanee View Tak to maan meny rekruah wi new inta ps Precemt Absent Take Attendance fom E ente PO Lock Up Sc 4 Wando studa Figura 111 Um prot tipo de baixa fidelidade de uma tela indicando opera es poss veis em vermelho Landay 75 r MES N M n aai 4 Imagem ilustrativa usada pelos princ pios de fair use Imagem ilustrativa usada pelos princ pios de fair use N o se aplicam a essa imagem os mesmos direitos desse texto 76 E cio nd N r r PE Imagem ilustrativa usada pelos princ pios de fair use N o se aplicam a essa imagem os mesmos direitos desse texto 205 ConsacrS TAS Man Sereen SEAR TAB a Conmerg Senac Mans dl Snoras SEARCH p wW Aunnagee Fug P E Kvan Kou tor us O Mas wans o uset OPON Conver Amon EEAS Gus
7. Relat rios raramente s o entidades Normalmente eles s o apenas os resultados de um processo que acessa v rias entidades Linhas de relat rio geralmente s o entidades Nomes de colunas indicam entidades ou seus atributos Por m nenhum valor calculado ou derivado atributo ou entidade Substantivos em regras de neg cio s o normalmente entidades Produtos quando n o s o nicos s o normalmente entidades Pap is como funcion rio atendente apostador etc s o bons candidatos para entidades Um grupo de dados que se repete em uma entrada ou sa da de dados normalmente uma entidade ou mais 1 7 1 Onde encontr las Al m de encontr las em entrevistas e em regras de neg cio podemos utilizar alguns documentos para encontrar entidades Relat rios Formul rios de entrada de dados Arquivos tanto de papel quanto no computador Fichas como fichas de cadastro de empr stimo etc Pedidos requisi es e documentos do g nero Documentos cont beis e fiscais como nota fiscal Planilhas de dados em papel ou eletr nicas Listagens registros agendas protocolos e outros documentos de trabalho Sistemas j existentes Bancos de dados j existentes 117 Outra forma de encontrar entidades buscar sistemas semelhantes j resolvidos e padr es de projeto ou padr es internacionais sobre o assunto sendo tratado 1 7 2 Descrevendo Entidades extremamente importante a descri o precisa de cad
8. dos processos e A borda de um diagrama representa a borda da atividade expandida Todas as atividades s o realizadas nas folhas isto na ltima atividade modelada mais detalhada As atividades superiores s o apenas abstra o que n o desempenham nenhum procedimento real Algumas heur sticas interessantes para se usar durante a modelagem Richard J Mayer 1992 1999 id e Questione as fronteiras e Essa atividade cai dentro do escopo da atividade superior e Esta atividade est conforme o escopo e o ponto de vista estabelecido no projeto 84 Observe os limites num ricos do modelo 3 a 6 sub fun es por diagrama N o procure sempre 6 atividade descreve as atividades como elas aparecem no mundo real Cuidado com excesso de liga o entre as atividades teia de aranha que indica a falta de organiza o dos n vel de abstra o das atividades Passos da constru o do modelo A seguir os passos a serem seguidos quando da constru o de um modelo IDEFO 1 Ra a O 10 11 12 13 14 15 16 Defina objetivo e motiva o Responda as seguintes perguntas Por que o processo est sendo modelado O que esse modelo vai mostrar O que os leitores desse modelo poder o fazer com ele e Exemplo Identificar as tarefas de cada funcion rio da loja entendendo como elas se relacionam em detalhe suficiente para desenvolver um manual de treinamento Desenvolva as quest es que o m
9. es The human mind has first to construct forms independently before we can find them in things Einstein Albert 1879 1955 Todo modelo uma abstra o de algo que existe ou se imagina que possa existir no mundo real Abstra o o processo mental de separar um ou mais elementos de uma totalidade complexa de forma a facilitar a sua compreens o por meio de um modelo Normalmente desejamos que o modelo seja ao mesmo tempo simples o bastante para ser f cil de manipular e complexo o suficiente para resolver o problema em quest o No nosso dia a dia utilizamos a abstra o para poder trabalhar com toda a informa o que o mundo nos fornece Um mapa por exemplo um modelo de uma cidade Dependendo da informa o que queremos colocamos alguns s mbolos e tiramos outros do mapa Um mapa tamb m n o pode ser perfeito tem que abstrair as informa es que n o s o necess rias naquele instante ou teria que ter o mesmo tamanho da cidade No desenvolvimento de sistemas utilizamos alguns processos de abstra o t picos e Classifica o e Composi o e Generaliza o e Identifica o e e Normaliza o 1 2 1 Classifica o um membro de No processo de classifica o eliminamos parte da individualidade do objeto ou sistema analisado e o consideramos como um exemplar de uma classe padr o Quando fazemos isso aceitamos que esse objeto agora uma inst ncia da classe divide com todas as out
10. feito nas fases mais avan adas do desenvolvimento S Originalmente chamadas de entidades externas Esse nome n o utilizado neste texto para n o confundir com o conceito de entidade de dados Atualmente nos modelos orientados a objeto conhecido como ator Originalmente chamadas de dep sitos de dados 145 Em 1984 dezesseis anos antes de este texto ser escrito McMenamim e Palmer B17 conseguiram definir de forma clara um m todo de desenvolvimento que permite dividir sem sombra de d vidas o que essencial do que encarna o Essencial e Encarna o podem ser vistos como uma nova maneira de definir o que l gico ou f sico mas vamos ficar com os nomes dados por Palmer e McMenamim para evitar toda carga cognitiva trazida pelos nomes l gico e f sico Eles tamb m permitiram que descobr ssemos com perguntas simples se um requisito do sistema verdadeiro ou falso Esse m todo uma evolu o da An lise Estruturada e conhecido como An lise Essencial Yourdon mais tarde vai denominar uma nova vers o da An lise Estruturada baseada na An lise Essencial de An lise Estruturada Moderna Existem pequenas diferen as na forma de Palmer e McMenamim e Yourdon Esse texto baseado em vers es ainda mais modernas principalmente nos textos de B34 e Ruble B39 mas ainda mantendo a ess ncia da An lise Essencial VIII 2 A An lise Essencial O objetivo da An li
11. i i Solu o de Problemas N De IN Jo E s E Processos Organizacionais H Infraestrutura Treinamento Ger ncia Melhoria Figura 3 Framework fornecido pela norma ISO 12207 adaptado de Machado B6 1 2 1 A Necessidade de Garantir a Qualidade Desenvolver software um processo de transforma o de uma necessidade do cliente em uma sequ ncia de produtos de software an lise projeto prot tipo manuais que tem em seu fim um programa de computador Essas transforma es s o imperfeitas devidos a problemas de comunica o entre o usu rio e o desenvolvedor e falhas nas t cnicas utilizadas pelo desenvolvedor para garantir que nenhuma informa o perdida ou inserida de forma esp ria no sistema Para garantir que o sistema faz o que o usu rio deseja utilizamos duas t cnicas a verifica o e a valida o Verificar significa analisar se o produto de uma fase do processo de desenvolvimento est de acordo com sua especifica o Validar significa analisar se o produto de uma fase do processo de desenvolvimento est de acordo com as expectativas do cliente Precisamos ter claro em nossa mente a diferen a entre as duas atividades Quando transformamos um algoritmo em portugu s para pascal por exemplo podemos fazer isso de forma perfeita e ao mesmo tempo fazer algo que o cliente n o deseja Quando validamos um programa com o cliente e o aprovamos n o necessariam
12. na verdade um conjunto de v rios DFD interligados de forma hier rquica de modo que exista um DFD inicial e que cada DFD al m desse possa ser alcan ado a partir da expans o sucessiva dos processos em DFDs DFDs Nivelados s o a forma mais tradicional de descrever um sistema de forma top down em Engenharia de Software Alguns autores chamam de DFD n vel zero o DFD de Contexto Outros chamam de DFD n vel zero o DFD gerado pela expans o do processo que aparece no DFD de Contexto N s ficaremos com a segunda op o isto o primeiro DFD o de Contexto contendo um nico processo Esse processo expandido para o DFD n vel zero que contem um n mero razo vel de processos entre 5 e 9 normalmente Um DFD particionado representa cada atividade essencial como um diagrama isolado cujo significado ser explicado mais tarde DFDs particionados t m apenas um processo por diagrama a atividade essencial que recebe dados de no m ximo um agente externo e de uma ou mais mem rias Nosso m todo de desenvolvimento baseado no uso de DFDs particionados e nas expans es de seus processos Um DFD global a unifica o em um s diagrama de todos os DFDs particionados de um sistema eliminando as repeti es de agentes externos e mem rias Um DFD global Isso porque a modelagem conceitual de dados se encaixa perfeitamente com o conceito de modelo essencial e ainda permite uma transi o r pida para os SGBD relacionais oops Estamos
13. o e a tarefas como reconhecimento e classifica o A ergonomia outro fator importante Outros fatores importantes em projetos reais s o as ferramentas dispon veis e o h bito e a cultura do usu rio Enquanto um projeto acad mico ou um web site de propaganda pode ousar muito na sua concep o de interface projetos empresariais muitas vezes devem seguir padr es ou se adaptar a condi es de uso que n o s o as ideais Projetos internacionais ainda t m outros problemas pois a varia o de cultura de um local para o outro pode invalidar premissas do desenvolvedor Como exemplo simples enquanto as l nguas como portugu s e ingl s s o escritas da esquerda para direita rabe e hebraico s o escritas da direita para esquerda Isso afeta toda uma forma de entender a interface com o usu rio Dentro do fator humano e cognitivo uma quest o que sempre deve ser levada em conta que o usu rio faz um modelo mental do sistema fazendo suposi es sobre o que deve ocorrer em uma parte do sistema baseado no aprendizado que teve em outra parte do mesmo Vamos dar um exemplo simples se em uma parte do sistema ao tentar apagar um objeto o usu rio tem a oportunidade de desistir ou voltar atr s vai esperar que o mesmo aconte a em todo o sistema Quando por algum motivo essa regra quebrada o usu rio fica surpreso pois h uma quebra do seu modelo mental apagar permite desistir ou voltar atr s Isso faz com que nossos modelos de
14. O l 11 que um analista pode fazer calcular o custo de desenvolvimento de um sistema Apenas no final de um projeto temos certeza absoluta do custo que tivemos para desenvolv lo At l o que podemos fazer levantar de forma mais ou menos educada uma previs o de custos para o projeto Essa previs o deve ser atualizada constantemente enquanto o projeto caminha Devemos compreender que o grande fator de custo no desenvolvimento de um software a m o de obra Normalmente esse custo levantado em homem hora ou homem m s O uso dessa m o de obra proporcional a complexidade do projeto fruto de seu tamanho e de suas exig ncias operacionais ou funcionais Existem v rias t cnicas de previs o do tamanho de um sistema No cap tulo Qual o tamanho do software estudaremos algumas dessas t cnicas Na pr tica por m devemos E ainda implanta o manuten o e opera o 12 De forma exponencial 66 compreender que a maioria das empresas ainda as desconhece ou n o as implementa Nesse caso elas acabam utilizando a experi ncia de seus funcion rios para informalmente fazer previs es que normalmente se mostram pouco acuradas Quanto ao pre o podemos fazer algumas observa es A primeira que n o h necessariamente uma rela o direta entre custo e pre o Apesar de muitas empresas de desenvolvimento fazerem uma previs o de custo e calcularem o pre o em cima dessa previs o usando mar
15. Similarmente existem v rios tipos de requisitos que s o aplic veis ou n o dependendo da vis o necess ria naquele instante Segundo a norma IEFE Std 1220 1994 um requisito uma senten a identificando uma capacidade uma caracter stica f sica ou um fator de qualidade que limita um produto ou um processo e Um requisito do usu rio algum comportamento ou caracter stica que o usu rio deseja do software ou o sistema como um todo o que o usu rio quer S o escritos pelo pr prio usu rio ou levantados por um analista de sistemas que consulta o usu rio e Um requisito do sistema algum comportamento ou caracter stica exigido do sistema como um todo incluindo hardware e software O comportamento desejado do sistema S o normalmente levantados por engenheiros ou analistas de sistemas refinando os requisitos dos usu rios e os transformando em termos de engenharia e Um requisito do software algum comportamento ou caracter stica que exigido do software S o normalmente levantados por analistas de sistemas Exemplos de requisitos s o e O sistema dever imprimir a nota fiscal de venda ao consumidor referente venda sendo registrada 30 O sistema dever permitir ao usu rio calcular diferentes or amentos para uma mesma proposta baseados em formas diferentes de pagamento O sistema dever avisar que a rede est fora do ar em 20 4 segundos ap s a rede sair do ar O sistema dever permitir o agend
16. Uma seta pode ser dividida ou setas podem ser agregadas Os segmentos resultantes devem ser nomeados adequadamente para representar as partes Por exemplo uma seta identifica o de usu rio e uma seta solicita o de servi o podem ser unificadas na seta solicita o identificada O inverso tamb m pode acontecer Se uma seta cont m dados e controles ou se estamos incertos se cont m controle ou dados devemos mostr la como controle 79 GRAPHIC INTERPRETATION A means A A A A A A means N A A means A A j Where B is a B portion of A B A A amp B means e Rd B Figura 31 Fork e join n o rotulados t m interpreta es padronizadas e Uma caixa possui e No m nimo 1 seta de controle e No m nimo 1 seta de sa da e No m ximo 1 seta de chamada e Zero ou mais setas de entrada e mecanismo e Informa o de suporte pode ser colocada em um texto associado ao diagrama e Abrevia es jarg o etc devem ser colocados em um gloss rio nico para o modelo This fork means that Files contains Customer Records needed by Function 2 and Price amp Tax Tables needed by Function 3 Tax Requirements This join means Account Entries are created by Files Deliver Products and KEEP Do Billings RECORDS 1 Customer R Price amp Tax ecords Tables DELIVER PRODUCTS Account Ordered 2 A Entries Product Transactions DO BILLI
17. bem clara e nenhum passo foi perdido Uma lista de eventos tem a seguinte apar ncia Gerente cadastra distribuidora Gerente cadastra livro Cliente pede livros Sexta feira hora de fazer requisi es de livros para as distribuidoras Distribuidora entrega livros Gerente solicita relat rio de vendas Gerente solicita relat rio de livros em atraso Se a distribuidora n o entregar os livros pedidos depois de 15 dias cancelar pedido o IAN EO Figura 82 Exemplos de uma lista de eventos VII 8 1 Classificando os Eventos Apesar de termos descrito os eventos como podendo ser de v rios tipos n o extremamente necess rio identificar todos os eventos Por m fazer isso traz a vantagem de podermos testar a forma como o evento est descrito Aqui est o algumas perguntas de teste e Eventos externos o S o esperados ou agendados Se esperados possuem um n o evento correspondente o S o n o esperados ou n o agendados o S o uma solicita o ou possuem dados e Eventos temporais o S ocorrem dessa forma o S o realmente temporais ou podem ser calculados antes sendo nesse caso uma sa da do sistema o S o Relativos S o n o eventos Qual o evento original o O evento original existe sempre Opcionalmente podemos construir uma tabela de classifica o de eventos como a apresentada a seguir Todo evento deve ser facilmente classificado A dificuldade de class
18. cio como percebidas pelo usu rio dividindo as em 5 grupos agrupados em 2 tipos X1 6 1 1 Fun es Transacionais Um processo elementar a menor atividade significativa para o usu rio de forma indivis vel Isso significa que o usu rio o v como um processo nico completo e independente de outros que se inicia com o sistema em um estado consistente e termina com o sistema em um estado consistente Um processo elementar ser contado como uma de tr s poss veis formas de fun o transacional e Sa das externas SE ou EO s o informa es de neg cio que o usu rio final pode receber representando relat rios telas e mensagens de erro como um todo e n o em suas partes individuais e Consultas externas CE ou EQ que s o sa das simples e imediatas sem altera o na base usualmente caracteriz veis por chaves simples de consulta e Entradas externas EE ou El que s o processos elementares que processam informa es de neg cio recebidas pelo sistema de fora da fronteira da aplica o e Cuja finalidade principal manter um Arquivo L gico Interno X1 6 1 2 Fun es de Dados e Arquivos l gicos internos ALI ou ILF que cont m os dados permanentes relevantes para o usu rio e mantidos e utilizados pelo sistema O sistema cria altera e apaga esses dados e Arquivos de interface externos AIE ou EIF que cont m dados permanentes e relevantes para os usu rios guardados em algum lugar por outra aplica
19. como o reconhecimento de padr es visuais X 1 3 As A es dos Usu rios Segundo Donald Norman B44 para executar uma a o passamos por sete est gios 15 Formar o objetivo o que se deseja no sentido mais amplo por exemplo matar a sede 23 A Execu o dividida em 3 passos 24 Formar a inten o o que se far por exemplo beber gua ou beber um suco 25 Especificar a a o algo como ir a geladeira pegar uma garrafa de gua ir ao arm rio pegar um copo colocar gua no copo e beber 26 Executar a a o 27 A Avalia o dividida tamb m em 3 passos 28 Perceber o estado do mundo 29 Interpretar o estado do mundo e 30 Avaliar o resultado em rela o aos objetivos originais Entender como um usu rio constr i seu modelo mental tamb m entender como executar sua atividade Fazendo perguntas espec ficas sobre como as fazes ser o realizadas ou modeladas permite ao projetista alcan ar um resultado mais adequado X 2 Coletando Informa es Sobre o Usu rio Uma das mais importantes atribui es do analista ou designer ao projetar uma interface conhecer seu usu rio Usu rios diferentes t m demandas diferentes para um mesmo sistema Um modelo simplificado de usu rios admite tr s tipos de usu rios um usu rio que n o conhece a aplica o e nem o sistema novato um usu rio que conhece a aplica o e o sistema experiente e o usu rio que conhece bem a
20. defini es mais de um sistema entre os sistemas de informa o t picos O professor deve orientar e explicar a diferen a Confus es comuns incluem sistemas de vendas estoque compras e controle de produ o Os alunos devem preparar uma descri o informal desse projeto Esse tema ser utilizado no desenvolvimento de um projeto durante todo o curso 28 29 Cap tulo IV Usu rios e Requisitos A hundred objective measurements didn t sum the worth of a garden only the delight of its users did that Only the use made it mean something Lois McMaster Bujold A Civil Campain 1999 Stakeholders Requisitos Funcionais Requisitos N o Funcionais Requisitos Verdadeiros Requisitos Falsos Elicita o de Requisitos Entrevistas JAD A principal tarefa de um analista descobrir o que o sistema deve fazer e como deve se comportar segundo as expectativas de seus usu rios e outros interessados Usualmente chamamos isso de requisitos do sistema O problema que no in cio do desenvolvimento ningu m realmente sabe o que um sistema desejado deve fazer ao ficar pronto inclusive o cliente Descobrir os requisitos de um sistema uma tarefa investigativa criativa e cont nua IV 1 O que um Requisito 2 O objetivo da an lise capturar todos os requisitos para o software sendo desenvolvido e apenas aqueles requisitos verdadeiros Qualquer que seja o sistema existem v rias formas de entend lo
21. e Redigir itens espec ficos claros e concisos e descarte palavras sup rfluas e Incluir apenas uma id ia por item e Evitar itens com categorias de respostas desbalanceadas e Evitar itens com dupla nega o e Evitar palavras especializadas jarg es abreviaturas e anacronismos e Redigir itens relevantes para a sua pesquisa e Evitar itens demogr ficos que identifiquem os entrevistados IV 8 2 2 Entrevista Aberta Esse tipo de entrevista evita muitos dos problemas dos question rios por m tamb m cria outros O entrevistador formula uma quest o e permite que o entrevistado responda como quiser O entrevistador pode pedir mais detalhes mas n o determina os termos da entrevista Permanecem entretanto as quest es as perguntas podem ser respondidas A resposta faz parte do repert rio normal do discurso do entrevistado H muitas coisas que as pessoas sabem fazer mas tem dificuldade de descrever como h tamb m o conhecimento t cito que de dif cil elicita o Os benef cios das entrevistas abertas s o a aus ncia de restri es a possibilidade de trabalhar uma vis o ampla e geral de reas espec ficas e a express o livre do entrevistado 47 H desvantagens tamb m A tarefa de entrevistar dif cil e desgastante O entrevistador e o entrevistado precisam reconhecer a necessidade de m tua colabora o ou o resultado n o ser o desejado H falta de procedimentos padronizados para estruturar as informa es rece
22. es suas rela es etc Novo Dic Aur lio An lise de Sistemas Analista de Sistemas Ferramentas Ciclo de Vida Equipe de Desenvolvimento Desenvolver software a atividade de longo prazo de criar um ou mais programas de computador um sistema de forma a atender necessidades espec ficas de um cliente ou grupo de clientes No desenvolvimento de software realizamos as atividades de descoberta das necessidades e de cria o do produto de software propriamente dito Podemos dividir as atividades do processo de desenvolvimento em alguns grandes grupos e Atividades de An lise cuja finalidade descobrir o que deve ser feito e Atividades de Projeto cuja finalidade descobrir como o software deve ser feito e Atividades de Implementa o cuja finalidade produzir o produto de software de acordo com as especifica es produzidas nas fases anteriores e Atividades de Controle de Qualidade onde se incluem todas as atividades com objetivo de garantir a qualidade do produto como testes e verifica es De acordo com o processo de desenvolvimento escolhido cada uma dessas atividades pode ser dividida em v rias outras sub atividades ou tarefas Elas podem ser executadas de diferentes formas em diferentes ordens Tamb m poss vel que as atividades de an lise e projeto sejam feitas de forma impl cita por exemplo quando desenvolvemos o software unicamente por meio de prot tipos Dependendo
23. na rela o entre alunos e cursos oferecidos em um semestre em uma universidade Alguns cursos n o recebem inscri o alguns alunos n o fazem inscri o em nenhum curso o O N 1 N Semelhante ao 0 N 0 N Tamb m muito comum por m agora exigimos que haja pelo menos um relacionamento na segunda entidade Pode ser encontrado por exemplo na rela o entre m sicas e CDs onde est o gravadas para controle de uma discoteca Uma mesma m sica pode estar em v rios CDs mas n o poss vel registrar um CD sem m sicas deve existir pelo menos uma Por m uma m sica pode nunca ter sido gravada o 1 N 0 N similar ao anterior o LN 1 N Aqui temos um relacionamento m ltiplo que deve existir pelo menos uma vez Um exemplo o relacionamento entre salas de uma empresa e m veis colocados nessa sala Essa representa o muitas vezes verdadeira mas evitada sendo trocada pelo relacionamento 0 N 1 N pois exige que ambas as entidades quando est o sendo criadas sejam sempre criadas juntas ou que existam algumas entidades na base como semente 125 1 1 0 1 0 1 0 1 0 N 0 1 o 1 1 1 1 0 N 0 N 0 N 1 1 E E 1 N 1 1 1 N CN 0 N 1 N 1 N 0 1 Figura 58 Tipos de relacionamentos entre entidades baseado no conceito que uma entidade um conjunto de inst ncias 1 8 2 Descrevendo Relacionamentos Relacionamentos podem ser descritos por linhas
24. o a especializa o 1 2 4 Identifica o identificado por Com a identifica o n s somos capazes de entender como caracterizar unicamente um objeto Um nome identifica uma pessoa por exemplo Ao identificar unicamente um objeto podemos separ lo de outro objeto semelhante e atribuir a entidades espec ficas atributos e caracter sticas que s pertencem a ela e n o pertencem a outros elementos daquela classe H uma diferen a entre instanciar e identificar Uma inst ncia deve possuir uma identifica o e uma identifica o se aplica a uma inst ncia A identifica o permite a que duas inst ncias sejam reconhecidas como distintas ou como representa es de um mesmo objeto normalmente devendo ser reunidas em uma 1 2 5 Normaliza o Toda aplica o ao funcionar deve tratar de casos espec ficos que ocorrem durante o funcionamento normal Por m bem mais f cil discutir o funcionamento normal antes e depois os casos espec ficos A abstra o de iniciar pelo modo normal indica que devemos come ar a trabalhar pelo modo comum ou normal de funcionamento ou ainda melhor o modo onde tudo ocorre da forma mais simples e depois ir inserindo mecanismos para tratar das varia es poss veis 1 2 6 Trabalhando com as abstra es Imagine que precisamos descrever comprar um carro bvio que todo carro possui quatro pneus um motor etc Isso uma classe bastante geral Por m desejamos ainda falar sobre
25. o os processadores de texto e as planilhas eletr nicas e Sistemas de n vel gerencial que utilizam dados da opera o e outros dados inseridos nesses sistemas para permitir a obten o de informa es que permitam a ger ncia da empresa suportando a tomada de decis es o controle e o monitoramento e Sistemas de n vel estrat gico que s o sistemas destinados a decis es de mais alto n vel efeito estrat gico e utilizam dados de todos os sistemas anteriores normalmente de forma agregada e processada sendo utilizados pela alta ger ncia Operacional Figura 2 N veis dos sistemas de informa o dentro de uma organiza o Ainda segundo Laudon a cada n vel de sistemas de informa o podemos associar um ou mais tipos de sistemas e Sistemas de Suporte Executivo SSE encontrados no n vel estrat gico s o destinados a apoiar a alta ger ncia em tarefas estrat gicas como o planejamento de longo prazo Usam dados fortemente agregados internos e externos a organiza o e s o capazes de responder perguntas espec ficas ou ainda fazer proje es Podem ser capazes de fazer simula es e ter uma interface interativa 11 e Sistemas de Apoio a Decis o SAD encontrados no n vel gerencial s o utilizados pelos v rios n veis de ger ncia e utilizam como entrada dados em pequeno volume agrega es ou ainda bases massivas de dados previamente preparadas para permir atividades de an lise de dados Como resposta
26. o padr o para diagramas de estado mas a nota o utilizada na Figura 86 com s mbolos especiais para os estados iniciais e finais ser a adotada nesse texto Diagramas de estados podem ser representados por tabelas como a seguir 169 Estado Atual Evento Resposta Pr ximo Estado In cio Evento a Estado 1 Tabela 25 Tabela representando o diagrama da Figura 86 VIIL13 5 Tabelas de Decis o Uma tabela de decis o descreve que a es devem ser tomadas quando uma s rie de fatos acontece Uma tabela de decis o tem duas partes Na primeira parte cada linha representa um fato Na segunda parte cada linha representa uma a o As colunas significam combina es de fatos determinados pelos valores verdadeiro falso e n o aplic vel m ee Cliente deve dinheiro hi h em e a sa O RRE Tabela 26 Uma tabela de decis es VIII 13 6 Pr condi es e p s condi es Baseadas em linguagens formais de especifica o e implementadas em algumas linguagens como Eiffel pr condi es e p s condi es s o declara es que devem ser verdade antes e depois do c digo ser executado Por exemplo um cadastro poderia ser especificado de forma bastante simplificada como pr input x y z onde x Nome y e Endere o z Telefone p s x y Z Aluno VII1 14 Dicion rio de Dados O Dicion rio de Dados uma defini o formal e estruturada dos fluxos de
27. o resultado que n o poss vel comprar pe as de reposi o Tamb m importante verificar se a causa primordial do problema um processo ou um dado Al m disso o entrevistador deve tentar obter alguma informa o de valor financeiro sobre o impacto do problema seja em valores absolutos ou relativos objetivos ou subjetivos V 6 3 Metas em sistemas novos Em nossa defini o de metas falamos sobre a melhoria do neg cio do cliente Mas o que acontece quando o neg cio ainda n o existe Como definir uma melhoria nesse caso Claramente temos que mudar nossa defini o nesse caso O melhor abandonar o conceito de melhoria ou seja um conceito relativo por um conceito absoluto como um objetivo de neg cio Assim em vez da meta ser Diminuir o tempo de atendimento ao cliente para 2s passaria a ser Atender o cliente em 2s Devemos notar que nesse caso as metas ficam iguais a requisitos n o funcionais V 7 Os Requisitos Preliminares importante registrar todos os requisitos que forem percebidos durante essa fase inicial do contato com o cliente Esses requisitos aparecem informalmente mas devem ser anotados diligentemente pois talvez sejam at mesmo esquecidos por parte do cliente o que n o garante que sejam menos importantes apesar de ser um indicativo V 7 1 Definindo o Escopo Uma boa estrat gia complementar a especifica o dos requisitos preliminares a defini o do escopo por meio de
28. onde a dimens o adicional representa o tempo ou seja as c lulas passam a ser vetores indexados por intervalos de tempo ligados as fases do neg cio Outros usos da Matriz CRUD A Matriz CRUD na verdade pode ser utilizada em v rias fases do projeto Antes de termos um modelo de dados e uma lista de eventos por exemplo podemos construir tabelas CRUD a partir dos requisitos originais do projeto www cos ufrj br publicacoes reltec es61603 pdf 163 VIII 11 Entendendo um Evento Para garantir que entendemos completamente um evento devemos nos perguntar as sete perguntas do m todo 5W2H Who When Where What Why How How Much o o a Who Ou Quem Quem s o os agentes externos Quem o iniciador Quem o transportador Existem outras pessoas ou sistemas envolvidos nesse evento Essa atividade precisa de mais agentes externos When Quando Quando ocorre essa atividade Alguma coisa precisa acontecer antes dessa atividade Alguma coisa deve acontecer depois dessa atividade Essa atividade est limitada no tempo por algum outro evento Por exemplo s podemos vender ap s a loja abrir e at a loja fechar a Quando os dados de entrada ou de sa da s o necess rios Where Onde Onde ocorre a atividade em que setor ou departamento De onde vem o est mulo Para onde vai cada sa da What O que O que deve ser feito pela atividade Que dados devem vir no evento externo Que sa
29. ou sink Um processo tem um nome e um n mero O nome deve ser formado por um verbo no infinitivo e um objeto atender cliente vender produto etc O n mero deve identificar unicamente o processo Se estivermos usando um DFD para descrever um processo que aparece em outro DFD ent o usamos uma numera o hier rquica Por exemplo os processos que ficam em um DFD que explica o processo n mero 2 devem ser numerados 2 1 2 2 2 3 e assim sucessivamente Se precisarmos de outro DFD para explicar o processo 2 2 os processos nesse terceiro DFD ser o numerados 2 2 1 2 1 2 sucessivamente Agentes externos e mem rias dep sitos de dados possu am um r tulo na nota o original de Gane e Sarson B42 por m na nota o de Yourdon que utilizamos agora n o possuem r tulos XI1 6 2 Entendendo os Fluxos de Dados Em um DFD na verdade temos tr s tipos de fluxos de dados O primeiro tipo de fluxo que ocorre entre um processo e um agente externo representa dados que est o cruzando a fronteira do sistema Esse tipo de fluxo indica que cada dado descrito no fluxo estar possivelmente de forma opcional sendo apresentado por ou a um agente externo Ele representa realmente um fluxo dos dados nele descritos J entre um processo e uma mem ria o fluxo tem um significado levemente diferente Em primeiro lugar ele ocorre dentro do sistema n o cruza nenhuma fronteira Mas principalment
30. quando onde porque e como sempre que poss vel Tente completar o ciclo quem qual quando onde porque como para todos os assuntos Em d vida pergunta novamente de outra forma O entrevistador deve pedir que processos complicados sejam explicados mais de uma vez preferencialmente sob perspectivas diferentes Z E importante estabelecer exemplos concretos para o que est sendo descrito pelo usu rio Tamb m em caso de uma d vida melhor descrever um exemplo concreto o que aconteceria se do que uma d vida abstrata O entrevistador deve estar consciente que muito dif cil encontrar um entrevistado capaz de raciocinar plenamente de forma abstrata sobre um problema Mesmo nesse caso normalmente a forma abstrata se resume ao caso perfeito sendo que as exce es s o melhores explicadas com exemplos N o tenha pressa n o responda pelo entrevistado N o se preocupe com a demora para responder ou o sil ncio O sil ncio inclusive uma boa t tica para fazer o entrevistado continuar falando Deixe o entrevistado pensar olhe para ele curiosamente Antes de mudar de assunto verifique sua compreens o explicando de forma resumida o que acabou de ouvir Isso permite ao entrevistado pensar e dar uma clarifica o se necess rio Esteja atento para a aus ncia de cr ticas por parte do candidato Isso pode ser causado pela falta de confian a do entrevistado em voc ou porq
31. rios cen rios alternativos alguns que tamb m levam ao objetivo desejado outros que levam a vers es parciais desse objetivo e ainda cen rios de falhas Todos esses cen rios tamb m s o descritos nos casos de uso por m normalmente de forma compactada sendo mostrado apenas como eles diferem do caso de uso principal Os cen rios diferem em fun es de condi es espec ficas que podem acontecer na execu o de uma inst ncia do caso de uso Por exemplo se o caso de uso descreve uma retirada de dinheiro de uma conta banc ria o cen rio principal considera que existe saldo na banca enquanto cen rios alternativos podem considerar que n o existe saldo suficiente ou que tarde demais para retirar a quantia pedida A figura a seguir ilustra o conceito de um caso de uso contendo um caminho principal e quatro condi es que podem alterar a execu o de uma inst ncia do caso de uso A figura seguinte mostra poss veis cen rios de execu o desse caso de uso 70 5 F ak x PERT s No Rio de Janeiro h um limite de retirada nos caixas autom ticos a partir de certa hora da noite por medida de seguran a 175 T E 4 2 Fig 88 Representa o abstrata de um caso de uso mostrando um caminho principal e algumas condi es e alternativas p bo sA 1 e o F TN g Fig 89 Representa o abstrata da execu o de diferentes cen rios poss veis no caso de uso da figura anterior Fluxo Fluxo B sico Alternativo
32. sobre transpar ncia em tablet PCs ou qualquer outra forma incluindo a uni o das citadas Podem ser feitos a m o livre ou com aux lio de r guas gabaritos ou outros materiais de desenho Pode ser preto e branco ou colorido Podem usar materiais pr desenhados como frames de janelas ou serem feitos a partir de colagens Poucos s o as habilidades necess rias para desenhar um PBF Seu custo tamb m baixo e o ciclo de intera o com o usu rio muito r pido PBFs podem ser desenhados junto com o usu rio inclusive em uma reuni o de JAD Um dos efeitos psicol gicos interessantes que o usu rio n o vendo uma implementa o fica mais disposto a propor mudan as pois n o v nenhum custo ou esfor o associado s mesmas o que na pr tica verdade A principal caracter stica de PBF que eles s o explicados e executados ou melhor encenados manualmente Partes do prot tipo podem ser desenhadas com detalhes enquanto outras podem ser s indicadas Alguns objetos podem ser cortados em um tamanho apropriado como caixas mensagens e menus A constru o dessa encena o semelhante t cnica de storyboarding usada no cinema 203 Figura 109 Um storyboard para um desenho animado indica como deve ser a sequ ncia de cenas Original encontrado em http www surrart ac uk arc archive digitation html Como o comportamento de um PBF executado por uma pessoa em uma estrat gia conhecida como
33. uma chave de outra tabela que usamos em uma tabela para indicar o relacionamento Por m comum que as ferramentas de modelagem copiem as chaves estrangeiras automaticamente Em benef cio da pr tica atual e em detrimento da pureza te rica mostramos a seguir algumas possibilidades da nota o de relacionamento Empresa CNPJ Produto Nome NomerFantasia NomeRegistro EL S preco Telefone Descri o Contato Figura 62 Entidades identificadas por um relacionamento Produto podem ser denotadas de uma forma diferenciada para declarar que sua exist ncia dependente da exist ncia de outra entidade Software Erwin Empresa CNPJ Produto NomeFantasia Nome NomeRegistro S OH Preco Telefone Descri o Contato Figura 63 O mesmo relacionamento agora n o identificador Percebemos que a entidade Produto agora tem o seu s mbolo normal Software Erwin Empresa Empresa Br CNPJ Produto CNPJ TORUNO Nom rantasia Nome E ER Nome omeFantasia CNPJ FK omeFantasia NomeRegistro y produz z SN NomeRegistro Produz 4 CNPJ FK Telefone Preco Telefone Preco Contato Descri o Contato Descri o Figura 64 Uma vis o do modelo l gico ainda do mesmo relacionamento agora recebendo um nome Perceba que dependendo do relacionamento ser identificador ou n o a chave da entidade m e copiada para a chave ou para os atributos comuns da
34. 1 Fluxo Fluxo Fluxo B sico Alternativo 1 Alternativo 2 Fluxo Fluxo B sico Alternativo 3 Fluxo Fluxo Fluxo B sico Alternativo 3 Altemativo 1 Fluxo Fluxo Fluxo Fluxo B sico Alternativo 3 Altemativo 1 Alternativo 2 Fluxo Fluxo B sico Alternativo 4 Fluxo Fluxo B sico Alternativo 3 Altarmativo 4 Fig 90 Representa o abstrata alternativa da execu o de diferentes cen rios poss veis Cen rios al m do fluxo principal podem representar variantes normais do fluxo principal casos raros exce es e erros Dessa maneira podemos compreender um caso de uso como a descri o de uma cole o de cen rios de sucesso ou falha que descrevem um determinado processo do sistema com a finalidade de atender um objetivo do usu rio 176 tem Objetivo femea Caso de uso cont m chama za condi o Cen rio sucesso falha Fig 91 Principais conceitos envolvidos em casos de uso baseado em 1 IX 3 Formas de narrativa A narrativa a forma de b sica de descri o dos cen rios do caso de uso A forma de narrativa apresenta v rias vantagens sobre outras formas j utilizadas de modelagem de processos como manter o contexto vis vel eliminar dificuldades de compreens o para o usu rio causadas por linguagens t cnicas com forte grau de abstra o e deixar claro qual o valor de cada fun o para os usu rios Um caso de uso pode ser descrito como
35. 41 Um diagrama de atividades de UML simples linear indicando as suas figuras b sicas Tamb m poss vel indicar a possibilidade de tomar caminhos diferentes em fun o de uma decis o Isso indicado por um losango sendo que cada caminho poss vel deve receber como r tulo uma express o que indique a decis o guard expression O padr o tamb m admite que n o seja usado o losango ver exemplo mais adiante mas sim setas saindo diretamente de um estado V Processar pedido material n o dispon vel Recusar pedido material dispon vel Enviar pedido Figura 42 Fragmento de diagrama de atividade mostrando uma decis o 92 Outra caracter stica interessante de diagramas de atividade que permite a cria o de caminhos paralelos e sua poss vel sincroniza o fork e join Praparar entrega Separar produtos Preparar Nota Fiscal Empacotar entrega Figura 43 Exemplo de caminhos em paralelo e sincroniza o Forks e Joins devem ser balanceados mas n o necessariamente de forma imediata como na figura 93 Person Prepare Beverage O A d Find no coffee nocola om im j gt N Beverage Y Ns DA found coffee found cola V Em aadwater cet N 7 to Reservoir Cups N Ei fo N Put Filter TA Es in Machine set cans N J gt ofcola J Turn on Machine No coffeePot tumOn d Brew coff
36. Est dio Fox fez Guerra nas Estrelas aparece 3 vezes Atualiza o o Se precisarmos alterar um dado de Guerra nas Estrelas sua dura o por exemplo teremos que fazer isso v rias vezes Elimina o o Se precisarmos apagar um filme por exemplo Might Ducks perdemos a informa o que existe um est dio chamado Disney Inclus o o S podemos incluir um est dio se tivermos tamb m um filme para incluir Segunda Forma Normal 2FN Uma modelo de entidades e relacionamentos est na segunda forma normal quando al m de estar na primeira forma normal n o cont m depend ncias parciais da chave incluindo se nessa chave atributos e relacionamentos identificadores Uma depend ncia funcional parcial ocorre quando uma coluna depende apenas de parte de uma chave prim ria composta Se A Uma dependente funcional de X usamos a nota o X gt A tabela est 2FN se est na 1FN e cada uma das colunas n o pertencentes chave prim ria n o for dependente parcialmente dessa chave 48 Logo se a chave prim ria for simples a tabela na 1FN est automaticamente na 2FN 141 Primeiro devemos notar que isso significa que uma tabela cuja chave seja formada por um nico atributo est automaticamente na 2FN 1 14 4 Terceira Forma Normal Uma modelo de entidades e relacionamentos est na terceira forma normal quando al m de estar na 2FN n o cont m depend ncias transitiv
37. Pessoas que representam pessoas ou pap is envolvidos em um processo e Informa o ou dados que representam informa o utilizada ou gerada em um processo e Produtos ou servi os que s o gerados ou consumidos pelo processo e Objetivos que representam o motivo da realiza o de um processo ou tarefa Tipo S mbolo Unidade Organizacional gt Pessoa ou Cargo Fluxo de Informa o Rela es Organizacionais Produto ou Servi o Objetivo Figura 37 Elementos complementares dos diagramas eEPC 89 A seguir apresentamos um exemplo de diagrama EPC para demonstrar os usos dos elementos adicionais Figura 38 Exemplo de eEPC Formas diferentes dos diagramas E poss vel desenhar os EPCes de diferentes formas Uma dessas formas permite que iniciemos apenas com as comunica es entre unidades como mostrado na figura a seguir Isto permite um conhecimento inicial do processo que pode ser muito til na sua discuss o durante reuni es ou entrevistas solicita o pam produto ba Erea produto Figura 39 EPCe baseado apenas em unidades da organiza o observe que nesse n vel s o permitidos loops v 5 2 1 EPC e 5W2H Um evento indica quando when algum processo fun o ou tarefa deve ser iniciado Uma fun o ou tarefa indica o qu what deve ser feito 90 Uma unidade organizacional indica quem who deve fazer V1 5 2 2 Passos para construir modelos EP
38. analista realmente ter que assumi los ao longo do processo Ele entrevista pessoas em busca de fatos e detalhes descobre fatos escondidos intencionalmente ou n o muitas vezes por meio de infer ncias ou pistas encontradas prop e solu es mais adequadas para problemas atuais e futuros a partir de diagn sticos planeja sistemas abstratos a partir de diagramas e ainda muitas outras atividades II1 2 Ciclo de Vida e Processo de Desenvolvimento A norma ISO 12207 fornece um framework para compreender as atividades e processos do ciclo de vida do software da sua concep o at o fim do seu uso que podemos indicar pela figura a seguir importante perceber a quantidade de processos envolvidos no ciclo de vida do software pois eles nos mostram que muitas vezes subestimamos as verdadeiras necessidades para implantar e manter um sistema de informa o 3 A ny PEN S 3 Ou seja essas decis es muitas vezes tomadas antes de se iniciar a an lise de um sistema devem influenciar apenas a forma de funcionamento n o a raz o desse funcionamento 20 Processos Fundamentais N a Processos de Apoio Aquisi o i Documenta o Fornecimento Ger ncia de Configura o f Garantia de Qualidade Opera o ae Verifica o o Valida o Desenvolvimento E Yoa oog Revis o Conjunta S l TE e i r su e Manuten o ro Auditoria lt
39. aplica o mas pouco o sistema eventual Normalmente um sistema tem que atender simultaneamente a todos esses tipos de usu rio e ainda ajudar a transformar um usu rio novato em experiente E necess rio ent o coletar informa es sobre os usu rios do sistema Isso pode ser feito por meio de formul rios Esses formul rios devem levantar a forma o do usu rio seu o exemplo escolhido bastante complicado e envolve sub objetivos e sub inten es em uma atividade longa e composta 199 tempo no cargo e na empresa sua experi ncia com computadores Internet outros sistemas da empresa ou sistemas semelhantes Al m disso interessante conhecer que atividades o usu rio faz em seu trabalho e com que freqii ncia di ria semanal mensal raramente Outras informa es podem ser levantadas como impossibilidades de usar uma ferramenta espec fica ou incapacidades f sicas Existem v rios modelos de formul rios que podem ser utilizados como refer ncia na literatura e na Internet a seguir apresentamos um exemplo muito simples X 2 1 Question rio para identifica o de usu rios Pergunta Respostas Forma o Sem 1 grau 2 grau 3 P s educa o grau graduado formal Tempo na empresa Menos Entre 6 Entre 1e Entre Mais de 5 de 6 meses e 2 anos 2e5 anos meses 1 ano anos Tempo no cargo Menos Entre 6 Entre
40. avalia o do entendimento que n o pode ser compartilhado B1 Bellinger et al B2 afirmam que com o aumento da compreens o e da capacidade de fazer conex es entre partes dados informa es etc passamos do trabalho direto com o dado em si para informa o ent o para o conhecimento e finalmente para a sabedoria sabedoria D compreendendo E principios conhecimento Ez pi D 2 compreendendo padr es informa o compreendendo rela es dados compreens o Figura 1 Entendimento das rela es entre dados informa o conhecimento e sabedoria segundo Bellinger et al B2 ll 2 Caracter sticas dos Sistemas de Informa o E importante entender que sistemas de informa o s o sistemas interativos e reativos Interativo significa que o sistema troca informa es com o ambiente em especial com os agentes externos que fazem parte desse ambiente pessoas e outros sistemas de computador O sistema s faz sentido se capaz dessa intera o Reativo significa que o sistema funciona reagindo a mudan as no ambiente e em especial a mudan as provocadas pelos agentes externos Nossos sistemas tamb m s o sistemas de respostas planejadas Isso significa que nossas respostas s o determinadas e determin sticas que podemos criar um programa que as produza Tamb m significa que todas as perguntas que podem ser feitas ao sistema podem e s o identificadas previamente Escolhendo essas regras de
41. b sicas de um diagrama de Entidades e Relacionamentos segundo Peter Chen Existem muitas nota es para Diagrama de Entidades e Relacionamentos A nota o original foi proposta por Chen e composta de entidades ret ngulos relacionamentos losangos atributos c rculos e linhas de conex o linhas que indicam a cardinalidade de uma entidade em um relacionamento Chen ainda prop e s mbolos para entidades fracas e entidades associativas As nota es modernas abandonaram o uso de s mbolos especiais para atributos incluindo a lista de atributo de alguma forma no s mbolo da entidade Consideramos as nota es como as mais interessantes na atualidade e IDEFIX utilizada pela ferramenta ERWIN bastante difundida no mercado e Engenharia de Informa o bastante difundida e tamb m presente como nota o alternativa no ERWIN e Nota o de Setzer difundida no Brasil por seu autor e Nota o de Ceri Bertini e Navathe B32 pouco difundida mas com aspectos te ricos interessantes e Uso da UML para representar modelos de dados n o orientados a objetos Toda a nota o moderna tem como caracter stica importante definir a cardinalidade m nima e m xima em uma rela o n o utilizar um s mbolo especial para relacionamentos mas sim a linha e descrever atributos dentro do s mbolo de entidades 31 a as Deploramos o termo entidade fraca que leva os alunos a acreditar que n o devem existir entidades
42. dados elementos de dados mem rias entidades e relacionamentos B34 Funciona para os dados um sistema sendo descrito como um dicion rio funciona para a l ngua que falamos Existem v rias nota es diferentes para construir dicion rios de dados mas todas s o equivalentes Nossa nota o ter o seguinte formato b sico lt termo definido gt lt defini o do termo gt 170 O DD deve conter a descri o de todos os fluxos e de todas as mem rias entidades do sistema O termo definido normalmente uma palavra enquanto a defini o do termo pode assumir v rias formas e Combina o de outros termos uso do lt termo gt lt termo gt e Repeti o de termos uso das chaves possivelmente com limites m nimos e m ximos lt termo gt 1 3 lt termo gt e Termos opcionais uso dos par nteses lt termo gt e Uma escolha entre termos uso dos colchetes lt termol gt lt termo2 gt e Valores poss veis uso de aspas valor e Coment rios uso de asteriscos um nome de pessoa A seguinte defini o v lida comprador nome cge cnpj endere o 0 2 telefone pessoa_de_contato Significando que um comprador deve ser representado por um nome um CGC ou CNPJ o endere o entre 0 e 2 telefones e opcionalmente uma pessoa de contato Itens simples ser o descritos por um coment rio Quando o significado bvio usa se o coment rio dado elementar Tamb
43. das devem ser feitas Que dados s o necess rios Why Por que Porque o evento acontece Porque alguns dados s o necess rios How Como Como a atividade acontece detalhadamente Como s o as sa das relat rios e entradas How much Qual o valor Quanto custa Quanto custa implementar o evento Quanto custa o evento para a empresa cliente Quanto custa um erro na atividade que realiza o evento O Diagrama de Fluxo de Dados 164 VIII 12 O Dicion rio de Eventos Com o tempo a Lista de Eventos entendida para um dicion rio de eventos que descreve detalhadamente as caracter sticas de cada evento Cada entrada no Dicion rio de Eventos composta de e Identificador do evento um n mero nico identificar do evento Esse n mero obrigat rio e N mero de seq ncia do evento no tempo se existe Novamente um n mero por m indicando a ordem do evento no tempo se existir O n mero opcional V rios eventos podem possuir a mesma ordem pois aconteceriam no mesmo intervalo de tempo e Nome do evento uma senten a que identifica o evento de acordo com as regras an lise essencial e Descri o do evento uma descri o mais longa do evento possivelmente contendo informa es n o essenciais como a motiva o do agente externo por m que aumentam a compreens o do evento E um resumo do que o evento e Classifica o do evento externo E NE temporal R A N o evento e Iniciador o ag
44. de informa o Usualmente tamb m usamos o termo DFD para descrever um conjunto de diagramas constru dos com essa nota o Figura Descri o Processo Um processo identificado apenas pelo nome 1 2 Um processo com n mero e nome Nome Agente Externo Um Agente Externo identificado Mem ria Uma mem ria identificada ON Um fluxo de dados sem identifica o N fluxo Um fluxo de dados identificado Tabela 117 S mbolos e seus significados para a constru o de um Diagrama de Fluxo de Dados 235 Agente Externo est mulo resposta Processo Mem ria Figura 118 Um DFD simples produtos comprados produtos dispon veis Sistema Compradores de Compra Vendedores e Venda Figura 119 Um DFD de Contexto muito simples Pa q es E Eai SN Da aa produtos novos A produtos comprados gn produtos existentes A 1 produtos k Comprar Pa RN Compradores Produtos EE 2 e Rg S Promover gt ege Produtos Ng 5 4 produtos dispon veis Vendedores Figura 120 A explos o do DFD de Contexto da Figura 119 DFDs n o descrevem uma seqii ncia de execu o ou qualquer outra rela o de controle Se uma seta indica que dados passam de um processo A para um processo B poss vel que A chame B B chame A ou ainda que outro processo superior chame os dois e fa a a transfer ncia de dados DFDs tamb m n o d
45. de Dados Hier rquico ou nivelado j foi uma das principais ferramentas de an lise e documenta o de sistemas Atualmente devido met fora de programa o gerada pelos ambientes GUI que baseada em eventos ele normalmente dispensado Tamb m devemos notar que a an lise essencial apesar de facilitar sua cria o dificulta a manuten o de um DFD hier rquico pois esse deve ser reconstru do a cada modifica o dos eventos particionados Em todo caso o DFD nivelado permite uma vis o abstrata do sistema composta de vis es parciais cada vez mais detalhadas Como essa caracter stica muito boa algumas vezes ainda podemos desenvolver DFD hier rquicos Para isso iniciamos com o DFD Global do sistema O DFD global n o nada mais que a unifica o de todos os DFD particionados do sistema em um nico DFD onde cada mem ria atividade essencial e agente externo s aparece uma vez Ao fazer o DFD global escolhemos uma folha de grande tamanho A3 ou maior e colocamos os DFDs particionados nessa folha um a um sempre reaproveitando todos os s mbolos j existentes Essa forma de construir pode ser dif cil para sistemas muito grandes sendo outra estrat gia colocar no centro da folha todas as mem rias depois colocando os processos ao redor das mem rias e os agentes externos ao redor dos processos Se o sistema ficar realmente muito complicado aceit vel duplicar agentes externos A duplica o de mem rias para facil
46. de atendimento e Diminuir o tamanho das filas com a m trica tamanho m dio da fila Para cada para par meta m trica podem ser necess rios um procedimento de medida e um procedimento de levantamento de dados passados Isso n o uma pr tica comum no desenvolvimento de sistemas por m algo desej vel A principal vantagem de associar ao sistema metas que n o fazem parte dos requisitos demonstrar a sua utilidade isto como o sistema far o cliente ganhar mais dinheiro ou realizar melhor sua tarefa Devemos tomar cuidado por m com as armadilhas que existem na escolha das metas Primeiro muito comum que um cliente deseje uma meta que n o pode ser alcan ada por um sistema com o objetivo definido A quest o nesse caso se resume a negociar a mudan a da meta ou negociar a mudan a do objetivo Como exemplo podemos citar o caso de um cliente que desejava um sistema de controle de pedidos para os fornecedores baseado em pedidos de clientes e desejava que o sistema diminu sse o prazo de entrega para os clientes Analisado o funcionamento da empresa comprovamos que era imposs vel acelerar o prazo meramente controlando os pedidos Era poss vel por m fazer uma previs o mais acertada do prazo de entrega e estar preparado para atrasos mediante o acompanhamento dos pedidos 61 Outra armadilha ter uma meta que afetada por muitas coisas al m do sistema Em um caso simples t nhamos a proposta de um sis
47. de interesse para o sistema Durante a modelagem conceitual nos preocupamos com as coisas que o sistema deve lembrar e colocamos essas coisas no modelo de entidade e relacionamentos Uma entidade deve ser relevante para o objetivo do neg cio e necess ria para a sua opera o 110 Cada entidade tem dois tipos de caracter sticas importantes seus atributos e seus relacionamentos Os atributos s o caracter sticas que toda a inst ncia de um tipo possui mas que podem variar entre as inst ncias Uma inst ncia do tipo aluno tem os atributos nome e ano de matr cula por exemplo Atributos caracterizam a informa o que deve ser guardada sobre uma entidade S devemos colocar como atributos aquelas informa es que o sistema precisa lembrar em algum momento Assim uma inst ncia de aluno n o precisa ter o atributo nome do animal de estima o em um sistema acad mico pois apesar de ser algo importante para o aluno propriamente dito n o tem import ncia alguma para o sistema Cada caracter stica deve possuir um dom nio O dom nio indica o conjunto de valores v lidos para a caracter stica No caso de nome geralmente aceitamos qualquer segii ncia de caracteres enquanto no caso de altura podemos aceitar apenas valores reais positivos menores que 2 5 Atributos eram originalmente descritos por c rculos no modelo E R As nota es mais modernas anotam os atributos dentro dos
48. de n o fazer parte da suposi o de um sistema perfeito tamb m s o postergadas para a fase de projeto como controle de acesso seguran a Na pr tica interessante imaginar o sistema como um g nio da l mpada capaz de fazer qualquer coisa em tempo zero se possuir a informa o necess ria Figura 79 O sistema deve ser visto como um g nio todo poderoso capaz de realizar qualquer pedido imediatamente se tiver a informa o necess ria VIH 3 4 O Modelo Essencial M nimo Os princ pios anteriores v o definir claramente a nossa forma de trabalho por m muitas vezes ser o in teis para ajudar a escolher qual o o modelo essencial entre dois modelos poss veis Precisamos por m para garantir que nosso m todo tem uma resposta nica ter uma forma de escolher entre dois modelos qual o modelo essencial mesmo que eles cumpram todos os requisitos anteriores O princ pio do modelo essencial m nimo exige que entre dois modelos possivelmente essenciais a defini o menos complicada o modelo essencial Assim possu mos uma forma clara de escolha VIII 3 5 O Princ pio da Aus ncia de Surpresas Esse princ pio n o faz parte da an lise essencial mas foi proposto pelo GUIDE MVS group B27 para auxiliar a an lise de neg cios Ele essencialmente auto explanat rio O princ pio conservado quando o produto e Faz o que o usu rio espera e Responde de forma previs vel e consistente aos est mul
49. deve ser detalhada nessa fase por m a aus ncia dessa modelagem na fase de an lise pode levar a graves erros de estimativa de custos pois comportamentos distintos para alcan ar a mesma funcionalidade podem ter custos de desenvolvimento muito diferenciados Por exemplo imaginem um sistema cuja finalidade registrar as multas de tr nsito aplicadas por policiais e gerar alguns relat rios A especifica o funcional simples o principal evento policial envia auto de infra o Por m isso pode ser recebido de v rias formas por meio de um digitador que l o auto de infra o por meio da digitaliza o e 78 Imagem ilustrativa usada pelos princ pios de fair use N o se aplicam a essa imagem os mesmos direitos desse texto Imagem ilustrativa usada pelos princ pios de fair use N o se aplicam a essa imagem os mesmos direitos desse texto 207 reconhecimento de caracteres ou recebendo arquivos gerados por PDAs como j acontece em algumas cidades O custo de implementa o de cada uma dessas formas muito diferente al m do que um sistema pode exigir que todas essas formas sendo implementadas o que aumenta ainda mais o custo Por isso importante criar um modelo do comportamento do sistema ainda na an lise respondendo de certa forma como as fun es ser o executadas mesmo que em um n vel muito alto de abstra o Esse modelo pode ser muito simples por m n o existem ferramentas padroniz
50. devem fornecer relat rios espec ficos an lises e decis es e respostas a perguntas ad hoc e Sistemas de Informa o Gerencial SIG tamb m encontrados no n vel gerencial s o utilizados pelos v rios n veis de ger ncia Utilizam grande volume de dados ou sum rios de transa es e modelos simples para obter relat rios sum rios agregados e de exce es e Sistemas de Trabalho com Conhecimento STC encontrados no n vel de conhecimento utilizam projetos especifica es e bases de conhecimento em geral para produzir modelos e gr ficos Normalmente s o utilizados por profissionais com n vel superior e Sistemas de Escrit rio SE encontrados no n vel de conhecimento tem como objetivo aumentar a produtividade na manipula o de dados em um escrit rio Permitem a manipula o de documentos correio eletr nico e agendas e Sistemas Processamento de Transa es SPT encontrados no n vel operacional tratam eventos e transa es e fornecem relat rios detalhados listas e sum rios utilizados pelos gerentes al m de documentos espec ficos para a transa o em que s o utilizados Os SPT suportam n o s a opera o di ria da empresa mas tamb m criam os dados que s o mais tarde utilizados pelos outros tipos de sistemas 1 3 1 Sistemas de Informa es T picos Atualmente j consideremos que v rios sistemas de informa es t picos de uma empresa s o necessidades b sicas que podem ser atendidas de um
51. digo cliente A amp p Tipo 3 Nome de Estado atual kg Endere o T Data de empr stimo Data de entrega he Observa es hp Telefone Diretor AP Nome de diretor Ator kg Nome de ator A Nome do filme O Ano dp Distribuidora f Figura 69 Modelo da locadora com atributos e os tipos com cones dos atributos nota o El software ERWIN 3 5 Aluguel amp Nome do filme FK amp C digo cliente FK C digo fita FK Data de empr stimo Data de entrega Observa es Cliente amp C digo cliente Nome Endere o Telefone Fita amp Nome do filme FK amp C digo fita Tipo Estado atual Y Diretor amp Nome de diretor Ator A Nor seo Figura 70 Modelo da locadora mostrando chaves prim rias e chaves estrangeiras FK que n o deviam estar em um modelo conceitual nota o El software ERWIN 3 5 amp Nome do filme Ano Distribuidora Aluguel amp Nome do filme FK crenta q Nome do fime FK amp C digo cliente FK amp C digo cliente C digo fia C digo fita FI e Data de empr stimo Endere o Data de entrega Telefone Observa es Tipo Estado_atual Filme amp Nome do filme Ano Distribuidora Diretor amp Nome de diretor Ator amp Nome de
52. distor es pois bons programadores deveriam utilizar menos linhas de c digo para realizar uma fun o Pontos de fun o podem ser criticados por ser uma medida abstrata demais por m permitem a compara o de sistemas de forma direta XI 5 Uma vis o reduzida do modelo COCOMO II COCOMO Constructive Cost Model um m todo de previs o de custos de software Atualmente poss vel conseguir gratuitamente um software COCOMO baseado em pontos de fun o o que facilita o c lculo de custos de projeto de sistemas de informa o A rela o entre o tempo de desenvolvimento e o esfor o necess rio que apresentamos em sua forma completa a seguir parte importante do modelo COCOMO SCED 100 Equa o 1 Tempo de Desenvolvimento calculado pelo modelo COCOMO TDEV CX EM o Es Nessa f rmula PMs a quantidade nominal de pessoas m s SCED a compress o necess ria no tempo de desenvolvimento B C e D s o constantes calibr veis e E um coeficiente calculado a partir de coeficientes de escala N E B 001x gt SF j 1 Equa o 2 C lculo de E a partir dos coeficientes de escala Na fase inicial do projeto os coeficientes de escala s o 5 N 5 e representam a preced ncia do sistema a flexibilidade do projeto o risco do projeto e da arquitetura a coes o da equipe e a maturidade do processo Em situa o normal para todos os casos o valor de E igual a 0 2807 Ficaremos ent o com uma f rmula s
53. dos campos FIGURA A SER RECUPERADA Figura 77 Normalizando a tabela turma aparece a tabela aluno que estava escondida em um atributo n o at mico Recomendamos enfaticamente o uso da primeira forma normal ou seja a n o utiliza o de atributos multivalorados no modelo conceitual Dessa forma evitamos a oculta o de entidades e relacionamentos dentro de outras entidades o que pode causar um grande desnivelamento entre o modelo conceitual e a real dificuldade de implementa o Um modelo de entidades e relacionamentos est na primeira forma normal se todos seus atributos s o tipos at micos 1 14 2 Algumas Anomalias Resolvidas pelas Formas Normais Imaginemos a seguinte tabela apenas na 1FN 140 1 14 3 T tulo Dura o Est dio Estrela Guerra nas Estrelas 124 Fox Carrie Fisher Guerra nas Estrelas 124 Fox Carrie Fisher Guerra nas Estrelas 124 Fox Carrie Fisher Might Ducks 104 Disney Emilio Estevez Wayne s 95 Paramount Dana Carvey World Wayne s 95 World Tabela 18 Uma tabela na 1FN adaptada de XXX Batini Paramount Mike Meyers Podemos verificar que essa tabela est na IFN por m ainda apresenta os seguintes problemas que ser o resolvidos pelas pr ximas duas formas normais Redund ncia o Muita informa o est repetida desnecessariamente em v rias tuplas Por exemplo o fato que o
54. entidade filha Software Erwin 1 11 Descri o Gr fica do Modelo V rias s o as nota es existentes para o modelo de entidade e relacionamento Usaremos nesse texto a nota o de Martin tamb m conhecida como Information Engineering fornecida pelo software Erwin No Erwin essa c pia chamada migra o e opcional no modelo l gico 129 Nessa nota o n o temos um s mbolo para relacionamentos apenas um ret ngulo para entidades Os relacionamentos s o indicados por linhas Uma linha cheia indica um relacionamento identificador Uma linha tracejada indica um relacionamento n o identificador Por isso n o podemos usar relacionamentos com atributos necessitando de uma nova entidade nesse caso Tamb m n o podemos criar relacionamentos m ltiplos necessitando de criar entidades para represent los Apesar de parecer que temos um modelo menos poderoso temos na verdade apenas uma sintaxe mais simples com o mesmo poder de modelagem Algumas decis es tamb m ficam tomadas automaticamente tamb m Por exemplo n o precisamos decidir se um objeto com atributo um relacionamento ou uma entidade pois relacionamentos n o t m atributos em nosso modelo Acreditamos que a modelagem segundo as regras do IDEFIX ou da Engenharia de Informa o possibilita encontrar mais facilmente um modelo essencial do sistema que as regras tradicionais de Chen ou ainda extens es as mesmas um ou mais zero ou ma
55. expandida com sin nimos e conceitos semelhantes Essa lista verificada pelo cliente gerando uma lista final de t picos de interesse Novamente com o entrevistador o cliente define crit rios de an lise Os crit rios s o quase sempre os mesmos como vi s da not cia em rela o necessidade do cliente boa ruim neutra propaganda paga rea da not cia n mero estimado de leitores etc Tamb m junto com o entrevistador o cliente define que meios de comunica o escrita ser o monitorados em uma lista mantida pela empresa de clippings A partir da quantidade de t picos da complexidade da an lise do per odo de gera o de portfolios e da quantidade e frequ ncia dos meios de comunica o feito um pre o b sico do servi o para o cliente Al m do pre o b sico o cliente ainda paga pela quantidade de c pias que deseja do portfolio e do relat rio mensal No trabalho di rio da empresa s o empregados dois tipos de funcion rios leitores classificadores e analistas Os leitores l em todas as publica es e copiam os artigos desejados classificando segundo os t picos de um ou mais clientes Os classificadores pegam todas as not cias classificando as por cliente e criando um portfolio b sico Os analistas fazem as an lises di rias e guardam os dados para as an lises mensais completando os portfolios Todo dia at as 12h00min s o enviados os portfolios referentes a toda publica o obtida at as 19
56. falando de tecnologia 238 pode ser usado como passo intermedi rio para transformar um DFD particionado em um DFD nivelado DFDs globais s o normalmente ferramentas de rascunho e n o de an lise Tamb m poss vel substituir um DFD global por uma Matriz CRUD XII 6 5 Criando o DFD Particionado A principal forma de comunicar a modelagem essencial pela cria o de um DFD Particionado Nesse DFD apresentamos um diagrama para cada evento Cada um desses diagramas cont m apenas um evento e apenas uma atividade essencial Quando dizemos que cada diagrama cont m apenas um evento estamos tamb m dizendo existe no m ximo um fluxo de dados entrando o sistema vindo de um agente externo Da atividade para os agentes externos podem existir v rios fluxos que representam a sa da de dados do sistema Entre atividades e mem rias tamb m podem existir quantos fluxos forem necess rios para representar a busca inser o altera o e elimina o de dados da mem ria Os DFD particionados podem ser resumidos em um DFD de Contexto Nesse DFD n o aparecem as mem rias internas ao sistema e o sistema representado como apenas um processo A principal fun o do DFD de contexto representar em um s diagrama todas as intera es do ambiente com o sistema o contexto da aplica o Vejamos a seguir uma descri o simples de um sistema e os DFDs particionados equivalentes XII 6 6 Criando o DFD hier rquico O Diagrama de Fluxo
57. forma em que os processos s o executados dentro da empresa Existem v rias formas de se tratar a descri o de processos atualmente variando em diferentes n veis de complexidade VI 5 1 Fluxogramas Fluxogramas s o provavelmente a forma mais tradicional de modelar processos Atualmente fluxogramas s o poucos utilizados tendo sido substitu dos por outras formas semelhantes que foram criadas com a finalidade de evitar problemas comuns encontrados na cria o dos fluxogramas E importante frisar que fluxogramas podem ser utilizados em v rios n veis do desenvolvimento de sistemas Seu uso mais comum no passado era na especifica o de 2 Esta a defini o do BSP 86 algoritmos mas esta pr tica est totalmente superada sendo normalmente substitu do por programas em linguagens de alto n vel Seu uso na especifica o de processos tamb m est em franca decad ncia nesse caso o que se v a sua substitui o por diagramas mais modernos incluindo o uso de fluxogramas em diagramas de raia VI 5 2 EPC EPC a sigla em ingl s para Event Driven Process Chain Cadeia de Processos Dirigida por Eventos Esse m todo parte simplificada do m todo ARIS usada para modelagem de processo e tem grande aceita o no mundo estando muitas vezes associado implanta o de sistemas de ERP SAP R3 Nesse m todo um processo modelado segundo fluxo de eventos e fun es As principais primitivas descritas na figur
58. funciona o neg cio onde o sistema est inserido e Modelo de Dados que descreve os dados guardados pela mem ria do sistema na forma de um Modelo Conceitual e segundo o m todo de entidades e relacionamentos e Modelo Funcional que descreve a funcionalidade essencial do sistema utilizando diagramas de fluxo de dados Incorporamos tamb m em nossa fase de an lise a modelagem por pontos de fun o que nos permitir definir um tamanho para nosso sistema 1 1 2 Ferramentas da An lise A maior parte do trabalho de an lise feita da comunica o entre pessoas Muito dessa comunica o feita na linguagem natal dessas pessoas como o portugu s Um grande problema dessa comunica o que l nguas como o Portugu s e o Ingl s permitem a constru o de senten as amb guas No desenvolvimento de sistemas temos que evitar ao m ximo as ambigiiidades Para isso temos que restringir a linguagem utilizada de forma que uma senten a s tenha uma 19 interpreta o poss vel ou mais prov vel Para isso foram criadas v rias linguagens algumas gr ficas que tem o poder de restringir as interpreta es poss veis do que queremos dizer Veremos no decorrer desse livro uma vis o geral de algumas dessas linguagens 1 1 3 A Tecnologia A grande maioria dos autores advoga que n o devemos levar em conta a tecnologia que a ser empregada no desenvolvimento durante a an lise de sistemas A an lise deve se preocupar com o
59. informa o Custodial Necess rio para o sistema Recebe informa o funcionar Tabela 21 Tipos de Atividades Essenciais e como classific las Uma atividade essencial posta em funcionamento por meio de um est mulo isto um fluxo de dados ou um comando que prov m de um agente externo A esse est mulo damos o nome de evento essencial VIII 5 Agentes Externos Representamos as pessoas departamentos empresas m quinas ou sistemas que interagem com o sistema sendo analisado enviando ou recebendo dados por meio de agente externos indicado no DFD por meio de um quadrado Agentes externos tamb m s o chamados de entidades externas ou terminadores Normalmente agentes externos representam pessoas pois a maioria das fun es de um sistema de informa o se d por meio da intera o com uma ou mais pessoas Eventualmente um sistema de informa o interage com outro sistema recebendo ou enviando dados ou ainda com sensor ou com um atuador Os agentes externos controlam o funcionamento do sistema S o eles que det m o poder de iniciar as atividades essenciais ao enviar um est mulo ao sistema S o eles tamb m que recebem todas as respostas emitidas pelo sistema O modelo essencial est interessado nos agentes externos que det m realmente o controle dos est mulos ou que realmente recebem a informa o Usu rios do sistema implementado como digitadores n o s o modelados nos DFDs da an lise essenci
60. informa o deve permitir responder perguntas como quando 2 sobre alguma coisa 22 66 39 66 quanto quem qual e onde Informa o Dado Significado necess rio fazer um mapeamento entre dados e informa o Esse mapeamento pode ser simples ou complexo dependendo de v rias vari veis envolvidas que v o desde decis es arbitr rias tomadas pelo desenvolvedor at padr es internacionais Por exemplo em muitos sistemas preciso ter a informa o do sexo de uma pessoa masculino ou feminino Para isso guardados um n mero 1 ou 0 ou uma letra M ou F que o dado que faz a indica o da informa o Conhecimento a aplica o da informa o Podemos dizer que permite responder a pergunta como pois envolve argumentos explica es e justificativas Entre as tr s palavras que estamos analisando conhecimento a que tem significado mais geral na l ngua 2 What where when who How much portuguesa podendo ser usada no dia a dia como sin nimo de informa o Em inform tica por m normalmente chamamos de conhecimento algo que pode ser escrito na forma de regras como em se for maior de 18 anos ent o pode tirar carteira de motorista Al m disso ainda podemos analisar as palavras compreens o ou entendimento e sabedoria A compreens o permite responder a pergunta por que enquanto a sabedoria um processo complexo e pessoal de compreens o e
61. le Entre Mais de 5 de 6 meses e 2 anos 2e5 anos meses 1 ano anos Tempo de uso de Nunca Menos Entre 6 Entre Mais de 5 computador usou de6 mesese 2e5 anos meses 2 ano anos Tempo de uso da Internet Nunca Menos Entre 6 Entre Mais de 5 usou de 6 meses e 2e5 anos meses 2 ano anos Liste suas tarefas no cargo Indique a fregii ncia de realiza o Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Di ria Semanal Mensal Rara Outra Qualidade do ambiente de trabalho Ilumina o Muito Ruim Razo vel Boa Otima ruim 200 Pergunta Respostas Ru do Muito Alto Aceit vel Pouco Quase alto nenhum Postura ao trabalhar Muito Ruim Aceit vel Boa Otima ruim Risco ao trabalhar Muito Alto Pouco Baixo Nenhum venenos explos es alto X 3 Prot tipos Levando em conta a necessidade de mostrar algo menos abstrato do que modelos aos clientes qualquer processo de desenvolvimento atual tem a tend ncia de acelerar a cria o da interface com o usu rio que representada pelas telas ou formul rios com o qual o usu rio interage e os relat rios e outras formas de aviso que recebe do sistema Um prot tipo uma implementa o simplificada do sistema podendo inclusive ser
62. m comum usar o s mbolo para marcar os termos que comp e a chave de outro termo Podemos guardar tamb m regras de c lculo e regras de neg cio no dicion rio de dados Modelos de Yourdon Yourdon definiu dois modelos como objetivos do processo de an lise o modelo ambiental e o modelo comportamental O Modelo Ambiental composto de Objetivos Lista de Eventos e Diagrama de Contexto E l O Modelo Comportamenta de Eventos Declara o de Objetivos DFD hier rquico completo Mini especifica es para todos os processos que n o forem expandidos em um DFD Diagrama de Entidades e Relacionamentos completo Conjunto completo de diagramas de transi es de estado e Dicion rio de dados completo composto de Diagrama de Contexto Lista 65 O modelo ambiental foi definido por Yourdon B43 sendo quest o t pica de concurso 8 O modelo comportamental foi definido por Yourdon B43 sendo quest o t pica de concurso 171 VIII 15 Exerc cio VIII 15 1 Rede Bobo de Televis o O N cleo de Novelas da Rede Bobo de Televis o contratou voc para fazer um sistema para controlar suas novelas O sistema deve permitir que um operador cadastre em separado novelas atores e diretores Os atores podem ser contratados ou horistas Os atores e diretores s podem trabalhar em uma novela mas uma novela pode ter v rios atores e apenas um diretor Quando um ator passa a trabalhar em uma novela isso deve ser r
63. modelagem escolhemos um caminho para decidir quando o sistema vai funcionar em vez de deixar isso incerto como em muitos m todos n s determinamos que o sistema s funciona para responder um evento no ambiente causado por um agente externo e que possua uma resposta planejada 10 A metodologia de desenvolvimento apresentada neste livro feita sob medida para sistemas interativos e reativos de respostas planejadas Nesse caso somos ao mesmo tempo restritivos pois se o sistema n o pode ser modelado dessa forma n o serve para nossa metodologia como ampliativos pois a grande maioria dos sistemas pode ser modelada de forma natural com esses princ pios H 3 Sistemas de Informa o e a Organiza o Sistemas de informa o atualmente servem em todas as reas e n veis das organiza es sendo considerados como ferramenta essencial para o sucesso de suas atividades Isso nos permite classific los de acordo com a responsabilidade assumida por seus usu rios dentro da organiza o em quatro tipos principais como sugerido por Laudon B3 e Sistemas de n vel operacional que tratam da execu o acompanhamento e registro da opera o di ria da empresa sendo geralmente sistemas fortemente transacionais Exemplos s o sistemas de vendas folha de pagamento etc e Sistemas de n vel de conhecimento que suportam as pessoas que trabalham com dados e conhecimento dentro da organiza o Exemplos simples de sistemas desse tipo s
64. mostra n o s a m dia mas como valores mais altos e mais baixos o que demonstra varia o de at 28 vezes como em Cobol entre a menor e maior quantidade de linhas de c digo por ponto de fun o encontradas em projetos distintos SLOC FP Linguagem ccess ssembler lipper OBOL xcel 2EE otus Notes racle racle Dev 2K FORMS owerbuilder ES Linguagem U Tabela 39 Tabela de convers o de pontos de fun o para linhas de c digo apresentada pela empresa QSM em http www qsm com FPGearing html em 26 1 2006 85 Dados apresentados dentro das regras de fair use 226 XI 8 Estimando o Tamanho Precisamos ent o de metodologias que nos permitam prever o tamanho de um produto de software A partir de uma estimativa podemos ent o utilizar as f rmulas No caso de pontos de fun o a metodologia principal fazer uma an lise inicial e contar os pontos de fun o presentes no resultado da an lise Dependendo da qualidade do processo da empresa e da profundidade dessa an lise inicial o erro nessa contagem ser bem pequeno J no caso de linhas de c digo precisamos de um m todo de predi o como por exemplo solicitar a previs o a um especialista com experi ncia em projeto semelhante Um dos m todos sugeridos no passado foi a T cnica de Delfos Atualmente a t cnica n o aparece muito nos livros did ticos provavelmente porque n o atende as necessidades de velocidade do mundo atua
65. na reuni o Para que n o aconte a como na figura abaixo devemos combinar algumas regras de jogo de modo a alcan ar o m ximo de produtividade natural que em um grupo de 15 pessoas surjam discuss es conversas paralelas interrup es etc Em respeito ao tempo precioso dos participantes vamos necess rio estabelecer um c digo de coopera o 1V 8 4 40 Ambiente O Ambiente f sico da reuni o fundamental para a produtividade dos trabalhos Os seguintes aspectos devem ser considerados Os participantes devem estar organizados de forma a poderem se olhar e olhar para o l der de sess o A melhor arruma o a em forma de U N o devem acontecer interrup es aos participantes Todos devem cumprir a agenda principalmente o in cio e o fim da reuni o 54 Quadro Branco NY para Diagramas gt Es Flip Charts na Tela de Proje o Projetor N A O Z Eae A Participantes Pes UNE syeyg di3 Sp op igixo esed oedsg Espa o para exibi o de Flip Charts Observadores DODO Figura 20 Uma sala de JAD bem planejada 1V 8 4 50 Consenso A forma mais produtiva de decis o do grupo aquela obtida por consenso Consenso n o a unanimidade de opini es mas sim a situa o em que cada membro concorda que a solu o encontrada a melhor para o grupo e que poss
66. no seu ambiente operacional Estas restri es tanto podem ser t cnicas envolvendo necessidades ou disponibilidades de fatores como hardware software rede e interoperabilidade com outros sistemas quanto podem ser ligadas ao neg cio Restri es podem ser vistas como requisitos n o funcionais de certa forma especiais pois s o limitantes e Os impulsionadores de projeto s o as for as do neg cio que fazem o projeto acontecer Podem ser considerados requisitos na medida em que s o os geradores originais dos requisitos funcionais e n o funcionais Tanto o objetivo inicial do sistema como todos os nele interessados stakeholders s o impulsionadores e Assuntos de projeto servem para completar o quadro geral de todos os fatores que influenciar o o sucesso ou o fracasso do projeto IV 6 Requisitos Verdadeiros e Falsos Um requisito verdadeiro quando o sistema deve cumpri lo qualquer que seja a tecnologia de implementa o escolhida Se um sistema pode cumprir sua finalidade sem que um requisito seja implementado ent o esse requisito falso Requisitos falsos aparecem de v rias formas dentro do sistema por c pia de sistemas antigos por h bito do analista por pensarmos na tecnologia antes do tempo Dividem se em dois grupos Requisitos falsos tecnol gicos s o aqueles inclu dos em um sistema por antecipa o de alguma caracter stica tecnol gica futura como a linguagem de programa o a ser utilizada ou por alguma
67. o 1 1 0 N Indica uma maternidade da segunda entidade em rela o primeira ou seja cada inst ncia da primeira entidade obrigada a possuir uma m e e apenas uma que seja inst ncia da segunda entidade E um dos relacionamentos mais comuns Pode ser encontrado por exemplo na rela o entre autom veis de uma empresa e multas recebidas Cada multa de apenas um autom vel mas podem existir autom veis com 0 1 ou mais multas o 0 N 1 1 similar ao anterior o 1 1 1 N Indica uma maternidade da segunda entidade em rela o primeira ou seja cada inst ncia da primeira entidade obrigada a possuir uma m e e apenas uma que seja inst ncia da segunda entidade Al m disso obrigatoriamente a m e deve possuir uma filha Esse relacionamento apresenta o inconveniente de exigir criar uma entidade filha para criar a entidade m e Pode ser encontrado por exemplo em um cadastro de pessoas jur dicas que devem possuir um endere o mas podem possuir mais de um Tamb m encontrado na modelagem normatizada de objetos que cont m listas que obrigatoriamente possuem um item como uma nota fiscal o 1 N 1 1 similar ao anterior Relacionamentos N para M o O N 0 N 124 Esse relacionamento muito comum Representa a forma mais geral de relacionamento opcional e com todas as possibilidades para ambos os lados Pode ser encontrado por exemplo
68. o mas referenciados pela aplica o em quest o Outro sistema mant m esses dados O segundo passo determinar a complexidade de cada fun o de neg cio A complexidade fornece um peso para cada fun o de neg cio encontrada O somat rio do n mero de fun es multiplicadas pelo seu peso fornece o n mero b sico de pontos de fun o Esse n mero um indicador preliminar do tamanho do sistema Finalmente no terceiro passo o n mero b sico de pontos de fun es corrigido em fun o de fatores que aumentam ou diminuem a complexidade do sistema 217 Determinar Tipo da Contagem Identificar Escopo e Fronteira da Aplica o Contar PF Transacionais Contar PF para Dados Determinar valor do Fator de Ajuste Determinar PF n o ajustado Calcular PF Ajustado Figura 116 Procedimento de contagem dos pontos de fun o adaptado de XXX X1 6 2 Identificando Fun es de Neg cio Para identificar as fun es de neg cio devemos partir de algum documento que aponte as fun es aprovadas e pelo usu rio e teis para o neg cio N o devem ser contadas fun es necess rias por causa da tecnologia aplicada Basicamente s cobrado o que o usu rio pode ver e est disposto a pagar Tamb m importante que as fun es de neg cio sejam cobradas como o usu rio as percebem Isto significa que n o interessa se estamos usando um ou vinte arquivos para guardar uma in
69. o Lista pequena e us vel das fun es do sistema 2 Para cada caso escreva um caso simples O objetivo alcan ado o O cen rio principal de sucesso o caso do dia feliz o Mais f cil de ler e entender o Qualquer coisa a mais uma complica o Capture a inten o e responsabilidade de cada ator da ativa o at alcan ar o objetivo Diga que informa o passada entre atores Numere cada linha Resultado o Descri o leg vel das fun es do sistema 3 Escreva as condi es de falha e extens es Normalmente cada passo pode falhar Anote cada condi o de falha separadamente ap s o cen rio principal de sucesso Resultado o Lista de cen rios alternativos 4 Resolva as falhas Extens es recuper veis voltam ao caso principal Extens es n o recuper veis falham Cada cen rio vai do gatilho ao fim Extens es s o apenas uma forma resumida de escrever Pode escrever se Pode escrever cen rio do in cio ao fim Resultado o Casos de uso completos 5 Detalhe as varia es de dados Algumas extens es s o muito baixo n vel para fazer agora 191 1X 14 6 1X 14 7 IX 14 8 Ex Reembolse comprador Como Cheque dinheiro etc Adie varia es que podem ser tratadas por casos de uso de menor abstra o Boas Perguntas Quais s o as tarefas de um ator O ator precisa ser informador de certas ocorr ncias dentro do sistema O ator precisa informar o sistema de mudan as externas O si
70. o inverso X 6 2 Erros de Descri o S o erros como em vez de jogar a roupa no cesto de lavar jogar no lixo Nesse caso a descri o de duas ou mais a es s o muito semelhantes e uma delas escolhida ao acaso causando o erro E importante lembrar que antes de realizar uma atividade as pessoas a descrevem mentalmente de alguma forma Essa descri o pode ser por exemplo jogar a roupa na caixa aberta Ocorrem de forma mais comum quando os objetos confundidos est o pr ximos X 6 3 Erros Causados por Dados externos Ao discar para um n mero de telefone em vez de escolher o n mero correto disca para um n mero que est na sua frente A es autom ticas s o dirigidas por dados ativadas pela chegada do dado Algumas vezes a chegada de outro dado atrapalha uma a o j iniciada X 6 4 Erros por Ativa o Associativa confus o com dados internos Toca o telefone e dizemos pode entrar Associa es dados internos podem ativar a es X 6 5 Erros por falta de ativa o Acontecem quando por exemplo ficamos na porta da geladeira nos perguntando o que viemos fazer apenas o que conhecemos como esquecer Acontece quando se perde esquece o est mulo que nos levou a atividade X 6 6 Erros por Modos Ocorrem quando um dispositivo tem 2 modos de opera o e ativamos a fun o que desejamos no modo errado com poss veis resultados catastr ficos 210 211 Cap tulo XI Qual o Tamanho d
71. o tempo necess rio para fazer um sistema e consequentemente o tamanho m dio da equipe Obviamente o que fazemos no in cio do projeto tentar prever o esfor o necess rio para realiz lo com sucesso e consegiientemente o tempo necess rio para complet lo Essas previs es s o mais ou menos acertadas de acordo com v rios fatores incluindo a maturidade da empresa a disponibilidade de dados hist ricos a experi ncia dos respons veis pela predi o e a capacidade intr nseca do modelo utilizado na predi o Um dos principais modelos de predi o do esfor o necess rio o COCOMO II Esse modelo baseado em equa es matem ticas derivadas a partir da an lise estat stica de casos reais bastante completo No COCOMO II que apresentaremos de forma reduzida a seguir o esfor o calculado a partir de uma previs o do tamanho do software XI 4 O Tamanho do Software At agora descobrimos que para saber o pre o de um software precisamos saber seu custo e que para saber seu custo precisamos saber o esfor o necess rio para desenvolv lo Finalmente chegamos quest o mais dif cil como prever o tamanho do software de forma a determinar o esfor o necess rio A primeira quest o a responder como medir o tamanho do software V rios autores j discutiram amplamente sobre essa quest o Atualmente duas formas s o aceitas internacionalmente para essa medida milhares de linhas de c digo fonte KSLOCS a partir do a
72. originou Crit rio de aceita o o Uma medida que possa ser usada para garantir que o requisito foi alcan ado Satisfa o do usu rio o Um grau de 1 nenhum interesse a 5 extremamente satisfeito por exemplo indicando a satisfa o do cliente se esse requisito for alcan ado Insatisfa o do usu rio o Um grau de 1 nenhum interesse a 5 extremamente insatisfeito por exemplo indicando a satisfa o do cliente se esse requisito n o for alcan ado Depend ncias o Refer ncias a outros requisitos que dependem de alguma forma desse requisito Conflitos o Refer ncia aos requisitos que de alguma forma conflitam com esse Material de apoio Listagem de material de apoio para atender esse requisito Hist rico Documenta o da cria o e das mudan as efetuadas autores ainda prop em que os requisitos sejam levantados em cart es padronizados que facilitam sua discuss o O uso de cart es facilita n o s por auxiliar a documenta o mas tamb m por criar um foco se discute apenas o que est no cart o sendo tratado em entrevistas e reuni es Eventos Essenciais ser o descritos no Cap tulo VII 40 Requirement Requirement Type Event use case Description Rationale Source Fit Criteria Customer Satisfaction Customer Disatisfaction Dependencies Conflicts Supporting Materials History Volere Copyright amp Atisntic Systems Guta Figura 17 Um cart o padron
73. ou do Valor Estimado XI 9 Verificando a Sanidade da Estimativa E importante que qualquer estimativa seja verificada quanto a sua qualidade Uma das melhores formas tentar formas alternativas de estimar e verificar se os resultados s o compat veis Por exemplo interessante verificar a estimativa dada por um m todo por exemplo COCOMO II com estimativas dadas por um segundo m todo de prefer ncia feitas por pessoas diferentes XI 10 Produtividade em Pontos de Fun o Podemos apresentar dois dados recentes sobre a produtividade e Pontos de Fun o O David Consulting Groups apresenta os seguintes valores m dios para diferentes plataformas em janeiro de 2006 3 http www davidconsultinggroup com indata htm 228 Plataforma de PF por Pessoa Desenvolvimento M s Cliente Servidor EEE 1 iente Servi 7 i 3 25 Data Warehouse o Tabela 41 Valores m dios de produtividade em pontos de fun o para pessoas m s segundo David Consulting Group 229 Cap tulo XII Projeto 1 Livraria ABC O exemplo a seguir a Livraria ABC uma adapta o de um problema que apresentado em muitos cursos universit rios no Rio de Janeiro XII 1 Aten o A descri o a seguir tenta manter um n vel ainda inicial mas mostrar alguns problemas t picos da elicita o de requisitos 1 Nem todo entrevistado diz tudo o que faz na primeira entrevista 2 Alguns casos de uso ficam escondidos em uma pal
74. para levantar todos os stakeholders de um sistema e mapear de alguma forma seus interesses e intera es com o mesmo IV 2 1 Interesses e Objetivos Usu rios possuem um ou mais objetivos ao usar um sistema i e ele usa o sistema para obter uma resposta planejada Usu rios e stakeholders tem interesses no sistema isto eles esperam que o sistema afete o neg cio de alguma forma Uma pr tica poss vel definir uma tabela indicando que objetivos cada usu rio e que interesse cada stakeholder tem no sistema Isso pode ser feito de forma preliminar nessa fase 32 Objetivos e Interesses de Stakeholders Agente ou Objetivo Prioridade Interessado Cliente Fazer pedido Receber o 1 produto pedido Cliente Obter status do Prever o prazo de 2 pedido chegada do pedido Gerente Obter lista de Saber a produ o 1 pedidos di ria di ria Tabela 1 Lista de objetivos e interesses IV 3 Perspectivas dos Usu rios Quando estamos fazendo a an lise de um sistema por meio de entrevistas ou reuni es interagimos com pessoas com vis es e descri es diferentes do que o sistema Um cuidado importante que devemos ter quanto posi o da descri o que est sendo feita em rela o ao sistema Nossa metodologia est interessada em eventos que partem do ambiente de fora para dentro do sistema Assim devemos descrever cada evento com essa perspectiva Nossos clientes por m n o t m sua perspectiva limitada p
75. para contar pontos de fun o a partir da an lise que fizemos 1 Modelo Funcional lista de eventos ou DFD 2 Modelo da interface 3 Modelo de Entidades e Relacionamento MER Modelo Conceitual ou L gico A lista de eventos o DFD ou o modelo da interface nos fornece a capacidade de contar as fun es transacionais O MER nos permite contar os PFs para dados A quest o da contagem deve levar em conta que tanto a entrada tem caracter sticas de sa da mensagens de erro por exemplo quanto sa das e consultas tem caracter sticas de entrada valores de filtros nas consultas por exemplo A Tabela 32 a principal ferramenta do analista nessa contagem X1 6 10 Infla o de PFs ao decorrer do projeto normal que o n mero de PFs se modifique ao decorrer o desenvolvimento do projeto Isso acontece por dois motivos altera o dos requisitos e necessidade de implementar mais pontos de fun o para atender ao comportamento desejado pelo usu rio do que estritamente exigido pelo modelo essencial normal que os pontos de fun o previstos em um in cio de an lise aumentem em at 25 at o final do projeto X1 6 11 Utilizando Pfs para previs es Para utilizar os Pfs para fazer previs es necess rio primeiro conhecer a produtividade em PF homem m s da equipe que realizar o software importante levar em conta o ambiente onde esta equipe trabalha suas qualidades e defeitos as ferramentas dispon veis e o tipo de tr
76. para fazer funcionar os sistemas tais como programas de computador relat rios formul rios etc As conven es s o as suas regras de utiliza o Apesar de sistemas de informa o n o necessitarem de computadores para existir hoje em dia comum associar o termo imediatamente a uma implementa o usando software hardware e redes Um exemplo t pico de sistema de informa o um sistema de aluguel para uma v deo locadora Entre suas v rias finalidades a principal certamente controlar o aluguel das fitas informando quem est com qual fita em um determinado momento quando e quanto deve pagar por isso Al m disso o sistema permite outras atividades como a ger ncia do estoque de fitas a monitora o das fitas mais e menos alugadas etc Um Sistema de Informa o um conjunto de componentes inter relacionados que coleta dados no ambiente em que opera usando recursos de sensoriamento e telecomunica es entrada analisa esses dados processamento e finalmente apresenta o produto como informa o til sa da sendo constru do de forma a atender os interesses de uma organiza o de seus clientes internos e externos e de todos aqueles atingidos direta ou indiretamente pelo novo produto Ao longo deste livro usaremos a palavra organiza o para representar empresas rg os p blicos entidades beneficentes associa es e qualquer outra forma de institui o com objetivos definidos e que
77. parte recebe informa es as processas e emite novas informa es Uma das partes um ser humano a outra um computador Cada uma possui caracter sticas pr prias para cada uma dessas atividades No caso do processamento por exemplo computadores bem programados t m uma capacidade de c lculo inigual vel pelo ser humano enquanto seres humanos s o capazes de proezas no reconhecimento de padr es Deve ficar claro que n o estamos aqui nem humanizando o computador nem vendo o homem como uma m quina Apenas procuramos uma met fora que nos permita entender melhor como se realiza a interface entre eles Tamb m n o esquecemos que computadores foram programados por seres humanos Uma das formas interessantes de ver a IHC como um di logo entre o desenvolvedor e o analista por m n o trataremos desse assunto aqui 197 Responder mi Ler X Pensar COMPU Pensar TADOR Ler E Responder Figura 107 A Intera o Homem Computador X 1 1 Projetando a Interface com o Usu rio As escolhas feitas na modelagem de interface com o usu rio s o um problema ainda em aberto e que envolvem muitos fatores sendo estudados por muitos autores nos campos de intera o homem computador e projeto design de interface Entre os principais fatores envolvidos est o aqueles que envolvem aspectos humanos A ci ncia cognitiva uma das ferramentas utilizadas pois estuda o conjunto de processos mentais relacionados ao pensamento a percep
78. pode obter algum benef cio com o uso de sistemas de informa o Nisso inclu mos um enorme espectro de interesses e tamanhos tanto um consult rio dent rio quanto uma multinacional de bebidas Apesar de estarmos preocupados com o desenvolvimento de sistemas de informa o automatizados implementados na forma de programas de computador isso n o uma necessidade Durante s culos as organiza es usaram sistemas de informa o apenas com o uso de pessoas papel e tinta Apenas bem mais tarde aparecem m quinas como m quinas de escrever e de somar N o seria exagerado dizer que a escrita e os n meros foram criados para suportar os primeiros sistemas de informa o que tratavam por exemplo de colheitas e Xex o J A Tese de Doutorado XXX com rcio Muitas das t cnicas deste livro podem e devem ser aplicadas para entender sistemas de informa o manuais Este cap tulo apresenta uma breve descri o de como funciona para que servem e quem usa os sistemas de informa o dentro de uma organiza o Il 1 Dados Informa o Conhecimento Antes de entender o que um Sistema de Informa o preciso entender melhor o que significa a palavra Informa o Novamente vamos recorrer a dicion rios para ter uma defini o inicial Segundo o American Heritage informa o o dado quando processado guardado ou transmitido J no dicion rio Aur lio informa o entre outros significados pode ser Conhecim
79. principalmente um gravador Atualmente existem bons gravadores digitais a pre os razo veis no mercado e Tenha pelo menos 2 horas de grava o e um jogo de pilhas extras e Tenha um caderno de anota es melhor que um bloco reservado para o projeto Canetas de v rias cores l pis borrachas IV 8 3 Realizando a entrevista O objetivo normal de uma entrevista conseguir informa es do entrevistado para isso devemos fazer n o s que o usu rio fale mas tamb m que ele pense importante para o entrevistador n o assumir nada e n o fazer pr julgamentos caso contr rio correr o risco de fazer uma entrevista viciada O entrevistador deve manter o controle o assunto da entrevista N o deixe o entrevistador mudar de assunto ou tergiversar mantendo suas perguntas direcionadas para o objetivo da entrevista As duas principais armas do entrevistador s o a pergunta e o sil ncio Para perguntar devemos ter consci ncia do tipo de pergunta que escolhemos Se quisermos que o usu rio explique algo ent o devemos utilizar uma pergunta aberta Isso muito comum em entrevistas abertas no in cio da an lise O importante fazer o usu rio pensar para isso o entrevistador deve evitar perguntas que contenham a pr pria resposta ou as que podem ser respondidas apenas com um sim ou n o As perguntas fechadas devem ser utilizadas para tirar d vidas do entrevistador Use quest es come ando com quem qual
80. que esse objetivo sofre de um excesso de linguagem de neg cios que pode ofuscar sua verdadeira utilidade Normalmente devemos preferir termos mais diretos como identificar as fun es da organiza o em busca de estud las e propor um plano de melhoria de desempenho com poss vel reestrutura o das mesmas Ponto de Vista O ponto de vista descreve a perspectiva tomada na constru o revis o e leitura do modelo definindo na pr tica os limites do modelo e como as atividades do sistemas sendo descrito ser o abstra das ou idealizadas A partir de um ponto de vista controlamos o escopo e o n vel de detalhe de um modelo IDEFO O ponto de vista sempre nico apesar das sess es de modelagem inclu rem normalmente diferentes participantes com m ltiplos pontos de vista Uma forma de imaginar um ponto de vista e melhor descreve lo entender o IDEFO como parte de um manual destinado a descrever o funcionamento do sistema para alguma pessoa ou algum grupo no contexto do neg cio 83 Contexto O escopo do modelo dividido em duas partes a profundidade e a extens o A profundidade define o n vel de detalhe esperado do modelo A extens o define as fronteiras do sistema sendo analisado E importante a defini o inicial do contexto mesmo tendo consci ncia que ele pode sofrer altera es intencionais durante o curso do processo de modelagem O contexto representado fortemente no diagrama de contexto A 0 pr
81. relacionamentos que s o alterados com o tempo Nesse caso pode ser necess rio criar novas entidades e Entidades isoladas em geral incorretas apesar de n o necessariamente incorretas Muito mais raramente no modelo conceitual Entidades isoladas podem algumas vezes aparecer no modelo relacional para guardar constantes do sistema e Entidades nicas entidades que possuem apenas uma inst ncia est o geralmente erradas e Entidades sem atributos geralmente erradas a menos que estejam sendo usadas no lugar de um relacionamento n x m mesmo assim n o seriam necess rias na modelagem conceitual e Eliminar uma entidade por ser fraca 1 17 Leitura Complementar Aconselhamos avidamente o livro de Paulo Cougo Modelagem Conceitual de Dados B31 e o livro de Bertini Ceri e Navathe B32 Conceptual Modelling O tratamento extensivo dado ao problema da modelagem conceitual de dados nesses dois livros pode ser de grande ajuda ao analista iniciante ou experiente 2 Outro livro nacional importante Projeto de Banco de Dados de Carlos Alberto Heuser Muito bom mesmo Para a obten o de padr es de projeto o livro de David Hay que em portugu s recebeu o nome de Princ pios de Modelagem de Dados mas em ingl s se chama Data Patterns ou seja Padr es de Dados tamb m excelente Ele tamb m leva o leitor a compreender seus padr es por meio de uma modelagem Top down o que pode ser utilizado como exemplos no apr
82. ser necess rio indicar outras fontes de obten o de informa o como manuais existentes e os pr prios programas Nesse ponto nossa abordagem bem diferente da abordagem essencial tradicional B17 que defende a cria o de um modelo da encarna o atual Entendemos que o tempo e esfor o necess rios para levantar o sistema atual de forma detalhada para depois transform lo em um novo sistema com requisitos bastante diferentes podem inviabilizar um projeto Assim normalmente por press es do neg cio somos obrigados a tratar cada projeto segundo a metodologia essencial para derivar sistemas novos Temos de nos perguntar se v lido documentar um sistema obsoleto para implementar um sistema novo A resposta essencial sim pois n o envolve o c lculo de custos A resposta pr tica baseada na experi ncia real de levantar sistemas novos para substituir sistemas j existentes n o N o temos tempo recursos ou pessoas para isso V 8 1 Problema do sistema atual Ap s o levantamento do sistema atual devemos apontar baseado nas reclama es dos clientes e em nossas observa es quais s o os problemas do sistema atual 64 Novamente importante lembrar que os problemas de neg cio s o mais importantes que os problemas t cnicos Muitas lojas hoje em dia utilizam sistemas feitos em MS DOS porque eles atendem perfeitamente seus requisitos de neg cio Os problemas atuais principalmente quando relacionados ao neg ci
83. um modelo espec fico uma Ferrari Testarossa por exemplo Logo acabamos de especializar nosso modelo mas ainda n o chegamos ao n vel de objeto Quando vemos o carro espec fico a temos o objeto Ele identific vel como inst ncia daquela classe porque apesar de dividir v rias caracter sticas em comum com outros objetos da classe tamb m tem algumas caracter sticas nicas como o n mero de s rie do chassi Finalmente desejamos trocar a cor do assento do carro Nesse instante j estamos vendo uma parte do carro decompondo o em suas partes 1 3 A Mem ria do Sistema Na an lise essencial importante compreender o conceito de mem ria do sistema Para cada necessidade do cliente como relat rios e tomadas de decis o o sistema precisa de certa quantidade de dados Esses dados s o sempre fornecidos pelo mundo exterior pois o sistema n o pode inventar dados por m nem sempre no mesmo momento em que a fun o necess ria realizada Normalmente por sinal um sistema de informa es 30 n taat N o confundir com a opera o de normaliza o relativa as formas normais 108 composto por fun es que coletam dados para que sejam mais tarde utilizados por fun es que fornecem relat rios Dessa forma esses dados necess rios para realizar uma fun o precisam estar em algum lugar Na an lise essencial n s abstra mos a localiza o e forma f sica dos dados supondo que o sistema possui
84. um prazo como na senten a uma semana ap s esgotar o prazo de pagamento enviar lembrete Novamente o nome n o evento pode causar confus o Um n o evento um evento em especial um evento temporal relativo Um s evento esperado pode necessitar de v rios n o eventos que ocorrem normalmente em prazos distintos Assim se temos um evento esperado cliente paga conta at o dia 30 do m s podemos ter v rios n o eventos para os prazos de 1 dia 1 semana 1 m s 3 meses e 1 ano por exemplo Um n o evento um evento temporal relativo que deve acontecer se um evento esperado agendado n o ocorre possivelmente considerando um prazo 62 i i E x eventos temporais podem ser implementados como eventos internos mas n o necessariamente Isso costuma causar confus o pois temos o h bito imediato de pensar na implementa o e de associar a proibi o de eventos internos na an lise como a proibi o de eventos internos na implementa o Exigimos apenas na an lise essencial que n o existam eventos essenciais internos A implementa o n o est limitada por essa regra 154 Eventos Essenciais Eventos Externos Esperados N o Esperados Eventos Temporais Absolutos Relativos L N o Evento Figura 81 Tipos de eventos essenciais e seus subtipos VIII 6 3 Um Exemplo Esclarecedor Vamos tentar entender mel
85. um texto de v rias formas por m podemos considerar que tr s dessas formas s o as principais 1 Descri o cont nua 2 Descri o numerada 3 Descri o particionada IX 3 1 Descri o cont nua Na descri o cont nua o caso de uso descrito como um texto tradicional da l ngua corrente Um exemplo simples pode ser visto na figura a seguir O Cliente chega ao caixa eletr nico e insere seu cart o O Sistema requisita a senha ao Cliente Ap s o Cliente fornecer sua senha e esta ser validade o Sistema exibe as op es de opera es poss veis O Cliente opta por realizar um saque Ent o o Sistema requisita o total a ser sacado O Sistema fornece a quantia desejada e imprime o recibo para o Cliente Fig 92 Um caso de uso descrito como uma narrativa A descri o cont nua bastante adequada para a fase inicial dos projetos pois pode ser retirada diretamente de entrevistas e facilmente validade pelo usu rio Em fase mais avan adas apresenta problemas por se tornar muito confusa com a adi o de detalhes e a falta de estrutura Outro problema acontece quando forem criados os passos alternativos referente a cen rios poss veis que n o ter o como se referir ao ponto onde pode acontecer a diferen a para o cen rio principal 177 IX 3 2 Descri o numerada Na descri o numerada ou itemizada a narrativa feita na forma de passos simples numerados sequencialmente Existem duas formas b sicas de c
86. vendas por vendedor e por loja contaremos como duas sa das pois s o necess rios procedimentos l gicos distintos para calcular cada um desses valores Linhas de sum rio e total por m n o s o contadas como novas sa das Uma sa da externa pode ter uma parte de entrada para por exemplo selecionar os registros necess rios em um relat rio usando alguns campos como filtro Essa parte entrada n o contada a parte j est considerada nessa contagem Identificando Consultas Consultas s o na pr tica sa das simplificadas Normalmente utilizadas para achar informa es para modific las ou apag las S o sempre no monitor n o existe uma consulta em relat rio de papel Uma consulta n o pode calcular nenhum valor Em caso de c lculo de qualquer valor temos uma sa da Identificando Entradas Entradas permitem adicionar modificar e apagar informa es Se uma tela permite estas 3 fun es s o contadas 3 entradas Normalmente as fun es de modificar e apagar ainda exigem consultas correspondentes para achar a informa o que ser alterada Um comando espec fico para o sistema executar algo uma entrada Mensagens de erro que fazem parte de um processo n o s o contadas isoladamente mas sim como um DET Por exemplo se voc esquecer de colocar um campo obrigat rio e receber uma mensagem de erro n o deve contar uma sa da a mais e sim essa mensagem como um DET da entrada ou consulta Men
87. 170 n o esperado 154 158 n o evento 159 165 temporal 138 145 159 Fatos 45 96 97 Fun es de Neg cio 70 73 218 IDEFO 5 74 75 76 77 81 82 83 85 86 104 236 IDEFIX 105 112 113 128 130 132 133 134 Interface com o Usu rio 27 197 198 JAD 5 30 45 53 54 157 203 Martin James 129 McMenamim 146 Mem ria 108 145 161 Microsoft 28 65 202 Modelagem Conceitual de Dados 109 144 Modelo de Processo 20 22 23 24 25 41 59 60 102 103 167 193 Modelo Funcional 19 145 225 Palmer 146 Pontos de Fun o 212 226 228 arquivos 217 interfaces 217 sa das 219 241 Pressman 19 Regras de Neg cio 70 95 98 106 Relat rios 117 159 Requerimentos verdadeiros 39 Requisitos 22 30 31 36 37 38 39 41 42 45 56 57 63 68 188 189 Requisitos falsos 38 SAD 12 SADT 74 236 SIG 12 Sistemas de informa o 10 11 Tecnologia Interna Perfeita 147 Tela 166 Termos 96 97 171 230 Testes 22 Win Win 24 Yourdon Edward 146 152 169 171 235 237 242
88. 4 Descreva como s o as equipes de desenvolvimento da empresa em que voc trabalha e de uma grande empresa como a Microsoft por exemplo 111 4 1 Trabalho em Grupo Projeto de Cadeira A turma deve se dividir em grupos de tr s a cinco pessoas com quatro sendo o tamanho ideal Cada grupo deve escolher um projeto de um sistema de informa o Essa escolha deve se basear nos seguintes princ pios e conselhos O sistema deve ser simples o bastante para que todos o entendam Algum participante do grupo deve ter experi ncia com o sistema ou com um sistema parecido A melhor op o escolher um aspecto do funcionamento de um neg cio familiar que algum membro do grupo tenha acesso Exemplos t picos estoque de uma loja atendimento de um consult rio notas de um curso pagamento de mensalidades de uma academia etc Outra op o um sistema que algum membro do grupo tenha desenvolvido ou participado do desenvolvimento N o ser aceito um sistema de locadora de v deo por ser um exemplo muito utilizado na literatura permitindo pl gio facilmente Na pr tica um trabalho de cadeira deve conter de 10 a 20 eventos e mais de cinco entidades para ter alguma gra a Por m nesse ponto o aluno n o sabe ainda o que um evento ou uma entidade O professor deve orientar os alunos para que o sistema fa a aproximadamente 15 coisas incluindo cadastros relat rios e processamentos Os alunos muitas vezes misturam em suas
89. 6 2 Declara es de A es ou Restri es Representam as restri es ou condi es que as institui es colocam em suas a es Podem aparecer por for a de lei pr tica de mercado de decis o da pr pria empresa ou ainda outros motivos Exemplos e Um aluno deve ter um DRE e Um aluno n o pode se registrar em dois cursos que acontecem no mesmo hor rio Uma Declara o de A o pode ser uma condi o uma restri o de integridade ou uma autoriza o Uma condi o diz que se alguma coisa for verdade ent o outra regra deve ser aplicada se ent o Uma restri o de integridade uma declara o que deve sempre ser verdade Uma autoriza o d uma prerrogativa ou privil gio a um termo normalmente permitindo que uma pessoa possa realizar uma a o Declara es de a es podem ser de uma variedade de outros tipos Recomendamos a leitura de 97 Uma declara o de a o pode dizer que precisa acontecer controle ou o que pode acontecer influ ncia VI 6 3 Deriva es S o regras que mostram como transformar conhecimento em uma forma para outro tipo de conhecimento possivelmente em outra forma incluindo leis da natureza B27 Geralmente s o regras ou procedimentos de c lculo ou manipula o de dados Exemplo e O valor a ser pago do imposto predial 3 do valor venal do im vel e A lista de devedores inclui todos os devedores a mais de dois anos V1 6 4 Regras e Eventos Cada regra de neg cio
90. AD Muitas vezes quando um grupo de inform tica entrega um sistema de informa o aos seus clientes escuta a frase n o era isso que eu queria Isto acontece porque os desenvolvedores n o conseguiram levantar com os usu rios suas verdadeiras necessidades Este problema de comunica o pode ter diversas causas linguagem especializada de ambas as partes desconhecimento da rea de atua o pelos desenvolvedores preocupa es com a tecnologia empregada ao inv s das necessidades dos usu rios etc Na fase inicial do projeto a dificuldade de comunica o entre clientes e equipe de desenvolvimento a principal causa de defeitos que ser o encontrados no produto final 53 Para enfrentar os problemas de comunica o entre desenvolvedores e usu rios foram desenvolvidos ao final da d cada de 1970 v rios m todos onde o desenvolvimento de sistemas baseado na din mica de grupo Na forma tradicional de desenvolver sistemas os analistas entrevistam os usu rios um ap s outro tomando notas que s o mais tarde consolidadas e ent o validadas com o usu rio finalmente se transformando em um documento de an lise O JAD Joint Application Design ou M todo de Projeto Interativo substitui as entrevistas individuais por reuni es de grupo onde participam representantes dos usu rios e os representantes dos desenvolvedores Quando o m todo aplicado de forma correta os resultados alcan ados ultrapassam os objetivos i
91. Autom vel Jo o Autom vel Jos Ford GM Caminh o Jos Autom vel GM Autom vel Tabela 20 Tr s tabelas que substituem a tabela anterior 1 14 6 Formas Normais e o Modelo E R Podemos ver que as formas normais podem ser facilmente aplicadas ao modelo de entidades e relacionamento simplesmente substituindo a palavra tabela pela palavra entidade 1 15 Outros termos Entidade Associativa transforma o de um relacionamento em entidade para permitir relacion lo em outro relacionamento Entidade Fraca entidade que n o possui identificador por si mesma dependendo de outra para sua exist ncia N o aprovamos essa classifica o pelo peso do nome fraca Muitas vezes as entidades fracas s o as mais importantes em um sistema 1 16 Verificando o Modelo Alguns erros comuns e Estabelecimento de associa es desnecess rias e Usar uma entidade como atributo em outra entidade e n o fazer o relacionamento que seria o correto 143 e Modelar entidades nicas principalmente uma que represente o sistema e Permitir redund ncias como relacionamentos redundantes principalmente os que podem ser resolvidos por uma navega o em uma segii ncia de relacionamentos Tamb m atributos redundantes com a c pia de um atributo que j pode ser alcan ado por meio de um relacionamento e Esquecimento do aspecto temporal isto dos hist ricos das transa es como atributos que mudam de valor com o tempo ou
92. B33 uma entidade pode estar em cinco grandes categorias e Objetos tang veis e Pap is exercidos e Eventos e Intera es e Especifica es 32 gt zx Novamente lembro que apesar de usarmos a nota o E R para descrever regras de neg cio estamos falando de duas atividades diferentes e que tem resultados diferentes apesar de poderem por coincid ncia terem o mesmo resultado 115 Podemos facilmente ver porque objetos tang veis s o bons candidatos a entidades normalmente sistemas de informa o falam em algum momento de objetos tang veis como produtos e equipamentos Algumas vezes por m um objeto tang vel como uma pessoa assume uma fun o ou papel espec fico como aluno ou professor Eventos ou intera es acontecem em algum momento do tempo e representam classes importantes de entidades Um exemplo de evento uma reuni o em uma agenda Normalmente eventos exigem atributos como data e dura o Exemplos t picos de intera es s o contrata o de servi o ou venda de produto Intera es s o semelhantes a relacionamentos ou a objetos tang veis ou eventos sendo muitas vezes representadas dessa forma Finalmente especifica o s o tipos especiais de entidades que classificam outra entidade Um bom exemplo f brica que uma especifica o para autom vel Geralmente especifica es tamb m podem ser implementadas como um atributo na entidade especificada
93. C EPCe B23 Identifique os eventos que iniciam as fun es que servem como gatilhos para o processo se iniciar Normalmente vem de fora para dentro do processo Identifique as fun es do processo associando as aos eventos que as iniciam e sua segii ncia Decomponha as fun es verificando se s o a es l gicas simples ou compostas executadas por uma ou mais pessoas ou ainda um sistema de computador Verifique tamb m se a fun o uma transa o isolada ou pode ser dividida em partes se pode ser interrompida em um momento espec fico e se existe um evento que a interrompa ou que a fa a funcionar novamente Analise os eventos novamente definindo os e refinando os se necess rio Garanta que s o necess rios e suficientes para iniciar a fun o Analise se existem casos especiais nos quais as fun es acontecem ou n o Use operadores l gicos para montar as rela es entre os eventos Identifique os eventos de finaliza o e as sa das tanto de material quanto de informa o Procure identificar quem processos e pessoas no resto da organiza o que dependem do processo sendo analisado EPCs podem ser muito pequenos ou enormes dependendo unicamente do tamanho do processo que est sendo mapeado V1 5 2 3 Regras de ouro de EPCs B23 e N o existem n s isolados e N o existem loops e Fun es e eventos t m apenas uma entrada e uma sa da e Operadores l gicos cont m v rios fluxos de entrada e um de sa d
94. Controle de ch o de f brica Controle da produ o Configurador de produtos Planejamento de Manuten o Acompanhamento de Manuten o e ainda muitos outros 12 ll 4 Tipos de Projetos de Sistemas de Informa o Existem tr s tipos de projeto de sistemas de informa o manual manual para autom tico e re automa o B4 Os processos de re automa o ainda podem se dividir em recodifica o re projeto e re desenvolvimento melhoria ou manuten o Todos esses tipos de projeto apresentam ao analista de sistemas o mesmo desafio descobrir o que deve ser feito Por m cada tipo apresenta certas particularidades que facilitam ou dificultam esse trabalho de an lise O trabalho do analista em sistemas manuais mais relacionado formaliza o por meio de documenta o e padr es de processos j adotados a cria o de novos processos e a transforma o de processos existentes tendo em vista otimiz los ou possibilitar que atendam novas necessidades da organiza o Esses processos podem ser bastante complexos e convolutos em alguns casos o que exige do analista uma boa capacidade de compreens o e modelagem Por m como n o ser o transformados em programas de computador o analista pode trabalhar com ferramentais mais informais e mais pr ximas ao dia a dia do usu rio Os projetos que apresentam maior dificuldade s o os de passagem do processo manual para o autom tico Isso acontece porque normalmente esses projet
95. Modelagem de Sistemas de Informa es Da An lise de Requisitos ao Modelo de Interface Incluindo Modelagem de Neg cios Modelagem Conceitual de Dados Casos de Uso Pontos de Fun o Edi o 2006 1 Semestre Geraldo Xex o Modelagem de Sistemas de Informa o Da An lise de Requisitos ao Modelo de Interface Geraldo Xex o Copyright O 2006 Geraldo Xex o Este documento est licenciado sob a Creative Commons Atribui o Uso N o Comercial N o a obras derivadas 2 0 Brasil Para ver uma c pia dessa licen a visite http creativecommons org licenses by nc nd 2 0 br ou envie uma carta a Creative Commons 543 Howard Street 5th Floor San G Francisco California 94105 USA Todo o esfor o foi feito para fornecer a mais completa e adequada informa o Contudo o autor n o assume responsabilidade pelos resultados e uso da informa o fornecida e mail de contato xexeo ufrj br Cap tulo Introdu o Este livro sobre a Modelagem de Sistemas de Informa o seguindo uma forma bastante atualizada da An lise Essencial unificada com outros m todos importantes no dia a dia do desenvolvedor de software como o Modelo de Entidades e Relacionamentos Ele fruto da experi ncia de 10 anos ensinando An lise de Sistemas para gradua o primeiro na Universidade Est cio de S e
96. NG 3 Account Clerk Invoices Figura 32 Conex es entre caixas 80 parent parent diagram box child X diagram Ai 1 Pig l g I 1 4 Ed This arrow is a control l on the parent box I This arrow is an output on the parent box This arrow is an input on the parent box Figura 33 Relacionamento entre diagramas com exemplo de DRE na caixa 2 do diagrama A1 Diagramas apenas para exposi o FEO for exposition only podem ser usados onde um n vel adicional de conhecimento necess rio para entender adequadamente uma rea espec fica do modelo Diagramas FEO n o precisam seguir as regras de sintaxe do IDEFO Diagramas FEO s o numerados com um F no final de seu c digo ou seja do c digo que teriam se fossem um diagrama normal Ao se referenciar a objetos do diagrama a seguinte nota o deve ser usada 81 Nota o de refer ncia para o IDEFO Nota o de Refer ncia Significado 2l1 Caixa 2 Entrada 1 02 A seta cujo c digo ICOM O2 Sa da 2 202 para 3C1 ou 202 para 3c1 A seta de 202 para 3C1 I C O ou M podem ser I2 para e 4C2 mai sculas ou min sculas 213 para 202 para 3C1 Da seta com c digo ICOM 12 para a caixa 2 entrada 3 atrav s da ativa o da caixa 2 que fornece a sa da 2 para a disponibilidade por meio de um fork dessa sa da como controle 1 na caixa 3 e controle 2 na caixa 4 A21 3C2 No diagrama A21 nesse
97. PC simples demonstrando parte de um processo de recebimento de pedidos Figura 36 Exemplo de um EPC de um processo de recebimento de pedidos Segundo a vers o original de EPCs sempre deveria haver um evento entre dois processos Atualmente permitido que uma segii ncia de processos n o tenha nenhum evento entre eles De acordo com as regras sint ticas para EPCs poss vel que um processo produza um ou mais eventos simultaneamente pelo conector E ou n o pelos conectores OU ou OU 88 EXCLUSIVO J um evento s pode habilitar um grupo de processos simultaneamente pelo conector E n o sendo vi vel que de um evento se tenha uma op o de caminho n o sendo poss vel a partir de um evento alcan ar diretamente um conector OU ou OU EXCLUSIVO eEPC eEPC a sigla em ingl s para Extended Event Driven Process Chain Cadeia de Processos Dirigida por Eventos Nessa extens o poss vel declarar mais algumas informa es sobre o processo sendo descrito Esses elementos adicionais funcionam basicamente como coment rios ao processo que est sendo documentado Assim depois de descrito o processo pelo m todo n o estendido colocamos sobre eles novos elementos documentando informa es como quem realiza o processo que informa o utiliza que produtos gera ou consome etc Os principais elementos adicionais em um eEPC s o e Unidades Organizacionais que representam departamentos envolvidos em um processo e
98. Simples 7 M dia 10 Complexa 15 6 M dia 10 Complexa 15 Complexa 15 Tabela 36 C lculo da complexidade de arquivos l gicos internos Arquivos Externos Itens de dados referenciados RETs 1 19 20 50 51 1 Simples 5 Simples 5 M dia 7 2 5 Simples 5 M dia 7 Complexa 10 6 M dia 7 Complexa 10 Complexa 10 Tabela 37 C lculo da complexidade de interfaces l gicas externas X1 6 7 As Perguntas S o 14 as perguntas que devem ser feitas e ajudaram a determinar a quantidade de PF relativa a um sistema Cada uma deve ser respondida com um n mero de O a 5 indicando a import ncia da caracter stica que se pergunta sobre o sistema da seguinte forma 222 O N o tem influ ncia 1 Influ ncia incidental 2 Influ ncia moderada 3 Influ ncia m dia 4 Influ ncia significativa 5 Influ ncia essencial em todo o sistema Para cada pergunta o padr o IFPUG determina tipos de respostas padronizadas que nos permitem dar a resposta entre O e 5 mais facilmente como exemplificado no item 1 Comunica o de Dados Foge ao objetivo desse texto fornecer um detalhamento completo do padr o de contagem que pode ser obtido junto ao IFPUG l A q a O 10 11 12 13 14 Quantas facilidades de comunica o existem para facilitar a transfer ncia ou troca de informa o com a aplica o ou sistema 1 1 Aplica o em batch ou computador is
99. TCO Total Cost of Ownership O TCO de um produto o custo total que ele implica para uma organiza o Por exemplo se decidirmos trocar todo o parque computacional de uma empresa que usa Windows para Linux mesmo que o custo do Linux seja zero o TCO bem alto pois envolve o processo de troca novos profissionais treinamento etc Outro exemplo comum o da compra de uma impressora Seu TCO n o envolve apenas o custo da impressora mas tamb m o custo do material consum vel quando uma certa produ o prevista Por isso que grandes empresas comprar menos impressoras por m impressoras maiores e mais cara para baixar o TCO Para o software desenvolvido vale o mesmo conceito Qual seu TCO Envolve o pre o pago pelo software mais tudo que vai ser pago para possibilitar a implanta o e utiliza o do produto instala o cursos de treinamento manuten o mensal etc 13 Benef cios do Sistema V rios motivos podem ser analisados como benef cios esperados de um projeto Um deles moderniza o de um sistema Com o tempo a tecnologia de um sistema vai se tornando superada Isso faz com que o risco e o custo de manter o sistema funcionando naquela tecnologia aumentem aumentando gradativamente o interesse de se transportar o sistema para uma nova plataforma Simultaneamente novas tecnologias apresentam novas oportunidades como desempenho superior ou facilidade de aprendizado aumentando tamb m com o tempo o interess
100. a ou um nico fluxo de entrada e v rios de sa da e Conex es entre operadores l gicos s o ac clicas e Dois n s s podem possuir um nico link entre eles e Existe um evento inicial e um evento final e Eventos n o tomam decis es logo s possuem uma sa da VI 5 3 Diagramas de Atividade O Diagrama de Atividade uma das formas que UML B24 prop e para modelar os aspectos din micos de um sistema sendo basicamente um tipo de fluxograma mostrando como o controle flui entre atividades Um diagrama de atividades tamb m um tipo de diagrama de transi o de estados que permite a modelagem de concorr ncia Em um diagrama de atividades cada atividade modelada em um estado activity state Atividades podem eventualmente ser detalhadas em a es action states que s o at micas N o existe uma diferen a na nota o entre atividades e a es ambas s o representadas pelo mesmo s mbolo 91 Atividade Figura 40 S mbolo para uma atividade com texto Quando uma atividade ou a o terminada o controle passa imediatamente para o pr ximo estado o que indicado por meio de uma transa o seta No diagrama o fluxo sempre se inicia em um estado inicial e termina em um estado final Estado o Inicial da nici Receber pedido N a ker Atividades Processar pedido N N Ne E To Ro i i l Enviar pedido Transa es Estado ad Final Figura
101. a abaixo s o e Fun es que representam atividades tarefas ou passos do processo que precisam ser executadas Fun es s o possivelmente iniciadas ou habilitadas por eventos Fun es possivelmente geram eventos Fun es consomem recursos exigem gerenciamento tempo e aten o Fun es podem representar e Atividades tang veis e Decis es mentais e Processamento de Informa es e Eventos que representam situa es ou estados do sistema antes ou depois da execu o de uma fun o Um evento pode ser uma pr condi o ou uma p s condi o para uma fun o Um evento n o consome tempo nem recursos por si s e Conectores L gicos que permitem a unifica o e separa o de fluxos segundo os conceitos de E OU ou OU exclusivo e Caminho que indica que um passo descrito por meio de um diagrama completo EPC duas swimlane diagrams 87 Tipo S mbolo Defini o Fun o Uma fun o descreve uma transforma o uma mudan a no estado do sistema Conectores N V Um conector estabelece conex es XOR AND OR l gicas entre eventos e fun es Evento lt gt Um Evento descreve uma ocorr ncia que causa um efeito fun o Fluxo Um fluxo descreve uma rela o l l gica ou temporal entre fun es e eventos v Caminho gt Um caminho estabelece uma rela o entre processos Figura 35 Principais componentes de um EPC A figura a seguir demonstra um diagrama E
102. a entidade pois sua descri o n o serve s de documenta o mas tamb m de teste para verificar se entendemos realmente sua presen a no sistema Uma boa descri o de entidade conter os seguintes itens e Nome incluindo uma listagem de sin nimos e hom nimos e Defini o e Exemplos e Atributos veremos a seguir e Relacionamentos veremos a seguir e Eventos que a utilizam veremos no pr ximo cap tulo e Correla o descrevendo outras partes da an lise que se referem a ela e Regras e exce es relacionadas a essa entidade incluindo regras de neg cio e Outros coment rios e observa es e Uma id ia da quantidade esperada de inst ncias no sistema Durante a defini o devemos tentar responder v rias perguntas procurando deixar claro o porqu dessa entidade fazer parte do sistema Assim devemos nos preocupar em dizer o que essa entidade o que faz e para que est no sistema quando algo ou n o uma dessas entidades quando passa a ser ou deixa de ser ou se permanentemente Quando algum elemento passa de uma entidade para outra devemos tomar bastante cuidado para descrever as a es necess rias para tal fato Figura 55 No in cio da modelagem podemos ter apenas entidades isoladas a Como no excelente livro Princ pios de Modelagem de Dados de David Hay B35 34 z 2 E Devemos confessar que n o temos a mesma preocupa o com atributos por exemplo 35 e E a Ho
103. a fidelidade acima e um prot tipo de alta fidelidade correspondente Landay O uso de prot tipos desde o in cio do desenvolvimento permite ao desenvolvedor experimentar diferentes abordagens e discuti las com o usu rio obtendo feedback mais cedo durante o ciclo de desenvolvimento e tamb m antecipando a indica o pelo usu rio de erros de an lise e projeto Segundo McConnel a prototipagem de interface com o usu rio tem um bom potencial de redu o do tempo do projeto diminui o risco de insucesso e um excelente fator para o sucesso a curto primeira vez e longo prazo de um sistema Os maiores riscos associados a essa t cnica ainda segundo McConnel seriam a possibilidade de perder tempo fazendo melhorias de baixa import ncia no prot tipo al m de outros riscos de qualidade historicamente associados aos prot tipos como a utiliza o no c digo final de c digo que foi criado para ser jogado fora e consequentemente sem seguir regras e padr es de desenvolvimento O uso de prot tipos pode ser um motivador para a participa o dos usu rios no sistema diminuindo o antagonismo e aumentando a coopera o entre desenvolvedores e futuros usu rios A vis o de um algo j realizado melhora a moral do projeto como um todo 7 Rio LDA E F a ba do da Imagem ilustrativa usada pelos princ pios de fair use Imagem ilustrativa usada pelos princ pios de fair use N o se aplicam a essa imagem os mesmos direito
104. a medida do tamanho do software em fun o da sua funcionalidade como vista pelo usu rio Apenas nessa data Albrecht B45 apresentou uma medida conhecida como Pontos de Fun o cujo objetivo era servir como avaliador e preditor do tamanho de um sistema Um Ponto de Fun o PF uma medida abstrata e relativa que conta o n mero de fun es de neg cio entregues ao usu rio Um relat rio simples por exemplo pode medir 4 Pontos de Fun o Da mesma forma que um metro ou um litro Pontos de Fun o s fazem sentido quando comparados com um padr o Assim um sistema com 1 000 PF entrega o dobro de funcionalidade de que um sistema com 500 PF Com o tempo aprendemos a ter uma id ia absoluta do tamanho de um sistema a partir da contagem de seus PFs A maneira padronizada de contar pontos de fun o fornecida pelo International Function Points User Group IFPUG que fornece aos seus associados um manual contendo detalhes do que deve e do que n o deve ser contado Esse cap tulo apenas uma introdu o ao m todo descrevendo uma forma levemente simplificada da metodologia oficial servindo para fazer c lculos aproximados do n mero de pontos de fun o de um sistema X1 6 1 Procedimento de Contagem O procedimento de contagem se inicia com a determina o do prop sito da contagem isto a explicita o do motivo da contagem estar sendo realizada Normalmente esse prop sito estar relacionado a forn
105. a proposta construir um quadro claro da situa o atual do cliente e uma vis o da sua situa o futura com o sistema funcionado Esse quadro permite simultaneamente ao desenvolvedor previs es mais embasadas e ao cliente uma maior confian a nessas previs es V 2 A solicita o do cliente Normalmente o cliente ao solicitar um software tem id ia do que necessita que esse software fa a possuindo inclusive um documento descrevendo essa id ia E nesse 7 z Z 4 2 O custo de um sistema quanto ser gasto para o seu desenvolvimento O pre o do sistema quando ser cobrado ao cliente O custo fun o direta do tamanho do sistema o pre o uma quest o de mercado NIA E E us N o chamaremos esse documento de proposta de desenvolvimento por considerar que s o necess rios mais alguns dados para desenvolver uma verdadeira proposta de desenvolvimento 57 documento ou a partir das entrevistas iniciais que o analista deve procurar as principais motiva es e necessidades do cliente E sempre importante focalizar nas necessidades de neg cio do cliente Muitas vezes o cliente acredita precisar de um sistema para resolver um problema em seu neg cio quando na verdade precisa de outro Deixando claras as expectativas teremos clientes mais contentes V 3 Objetivo do Sistema O Objetivo do Sistema descrito por uma senten a de poucas linhas que permite identificar imediatamente sua finalidade A senten a dev
106. a s vez Esses sistemas constroem o que comumente chamado de ERPs de Enterprise Resource Planning ou Sistemas de Gest o Empresarial em portugu s mas que na pr tica n o s o sistemas de planejamento ou de recursos mas sim de controle e administra o de uma empresa Entre as caracter sticas encontradas em ERPs podemos citar a integra o das atividades da empresa e o uso de um banco de dados nico O l der mundial do mercado a SAP AG com o produto SAP R 3 O custo de implanta o de um ERP de grande porte pode chegar at 300 milh es de d lares No Brasil existem produtos menos ambiciosos e mais baratos Os sistemas de ERP atuais cont m m dulos representando os mais t picos sistemas de informa es necess rios em uma empresa tais como Contabilidade Fiscal Contabilidade Gerencial Or amento e Execu o Or ament ria Ativo Fixo Caixa e bancos Fluxo de Caixa Aplica es e Empr stimos Contas a Receber Contas a Pagar Controle de Viagens Controle de Inadimpl ncia Administra o dos pre os de venda Compras Controle de fretes Controle de contratos Controle de investimentos Cota es de vendas Estoque Exporta o Faturamento Gerenciamento de armaz ns Importa o Obriga es fiscais Pedidos Previs o de vendas Recebimento Gest o de informa o de RH Pagadoria Treinamento RH scorecard Planejamento de RH Planejamento de produ o Planejamento da capacidade Custos industriais
107. a um hor rio para a entrevista e o cumpra rigidamente Devido aos constantes problemas de tr nsito da cidade e a necessidade de se identificar para seguran as e secret rias o entrevistador deve sempre planejar chegar ao local com uma folga de tempo algo em torno de 15 minutos Mantenha o interesse Tome notas mas n o seja obsessivo principalmente n o interrompa o candidato para manter suas notas atualizadas Grave a entrevista e a reveja mais tarde se necess rio Escute ativamente sem interromper O entrevistado que deve falar a maior parte do tempo Utilize um tom educado e cort s N o seja engra ado sarc stico ou depreciativo N o fa a coment rios pejorativos ou preconceituosos N o fa a coment rios sobre pol tica e religi o ou outro tema controverso Seja cordial mas sem deixar de ser profissional Pergunte e responda com cortesia e honestidade N o de opini es particulares mesmo quando pedido A entrevista o momento de levantar informa es n o de emiti las N o de a um entrevistado informa es passadas por outros entrevistados Educadamente responda que n o cabe a voc a decis o ou a opini o Evite de toda a forma confrontar o entrevistado N o torne a entrevista um interrogat rio Evite discutir mesmo que n o concorde com o usu rio Em caso de discuss o defina claramente o motivo do desacordo seja ele motivado por fato ou por opini o Utilize perguntas para restabelecer a comunica o e
108. abalho que realizam afetam o c lculo dessa produtividade Por 225 exemplo comum que equipes de manuten o obtenham produtividade aparente muito maior que equipes de desenvolvimento quando utilizada a medida de pontos de fun o Sabida a produtividade da equipe basta calcular o n mero de PFs para o sistema proposto por exemplo analisando o resultado da an lise essencial e dividir esse n mero pela produtividade obtendo o esfor o necess rio para implementar o produto XI 7 Ligando COCOMO Ile Pontos de Fun o Boehm et al XXX prop e que o m todo COCOMO II pode ser utilizado para prever o tempo e o esfor o necess rio para o desenvolvimento de um software a partir da previs o de pontos de fun o necess rios Para isso usam uma tabela de convers o entre pontos de fun o e linhas de c digo l gicas apresentada originalmente por Caper Jones XXX Jones 961 A previs o se torna simples basta calcular o n mero de pontos de fun o n o corrigido pois o COCOMO II j apresenta corre es similares em seu c lculo converter para linhas de c digos com essa tabela e aplicar as f rmulas Caper Jones por m alerta que os dados apresentados n o s o confi veis sendo m dias que n o levam em conta diversas particularidades do desenvolvimento de software por um grupo espec fico usando uma arquitetura e ferramentas espec ficas Isso pode ser confirmado usando a Tabela 39 fornecida pela empresa QSM e que
109. acionamento deve ser utilizado para mostrar comportamento estrutura ou objetivos comuns entre diferentes casos de uso para mostrar que os casos de uso filhos formam uma fam lia de casos de uso com alguma similaridade ou para assegurar que o comportamento comum se mant m consistente A figura a seguir mostra um exemplo de heran a Identificar Cilente Verificar ID Senha Fazer Scan de Retina Fig 102 Exemplo de um relacionamento de heran a entre casos de uso Uma inst ncia de caso de uso executando um caso especializado vai seguir o fluxo de eventos descritos pelo caso parente inserindo comportamento adicional e modificando seu comportamento como definido no fluxo de eventos do caso especializado IX 7 Tipos de Caso de Uso Um caso de uso pode ser concreto ou abstrato Casos de uso concretos tem que ser completos e teis podendo ser instanciados isto executados diretamente S o casos de uso que existem na pr tica Casos de uso abstrato existem apenas para ajudar outros casos de uso n o precisam ser completos e nunca s o instanciados Se eliminarmos todos os casos de uso abstratos ainda teremos uma vis o bastante precisa da funcionalidade do sistema 184 Concretos B C CR Abstratos A D include gt 2 A aa extend Fig 103 Exemplo de casos de uso a e concretos IX 8 N veis de Abstra o de Um Caso de Uso Uma das formas mais interessantes de entender como desenvolver cas
110. adas para cri lo o que complica um pouco o seu desenho A seguir veremos algumas propostas j utilizadas com diferentes graus de sucesso em sistemas distintos X 4 1 O Diagrama de Navega o de Telas Esse um diagrama muito simples semelhante a um diagrama de transi es estado que mostra quais s o as poss veis navega es entre as telas de um sistema V rios autores sugerem nota es similares O exemplo da figura a seguir utiliza algumas regras arbitr rias que s o comuns em modelos de navega o N o se faz distin o entre a funcionalidade apenas na navega o Assim por exemplo de Apaga Usu rio navegamos para Lista Usu rio qualquer que seja a op o OK ou Cancel Nesse diagrama n o indicamos a necessidade de selecionar elementos para apagar ou editar o que pode ser feito em alguma outra nota o O importante aqui ter uma id ia de quantas telas abstratas ser o necess rias e ter uma no o do comportamento do sistema isso porque o cadastro de um usu rio por exemplo pode exigir v rias telas o que s seria visto no projeto Outra coisa que podemos notar que s est sendo considerado nesse modelo o comportamento normal Outros modelos ou um refinamento deste modelo podem permitir a inclus o de telas de ajuda ou mensagens de erro por exemplo Entre as vantagens de construir um diagrama de navega o est o a sua simplicidade e informalidade Apesar de abstratos p
111. ado como atributo Se for vari vel ent o deve ser um relacionamento com outra entidade Se tiver rela o com outro objeto deve ser um relacionamento Caso contr rio pode ser um atributo 136 1 12 2 T cnica Bottom Up Na t cnica Bottom Up partimos das partes para construir o todo partindo dos conceitos mais elementares para construir conceitos mais complexos Os requisitos s o decompostos analisados de forma independente e agregados em um esquema global B32 e Cria o de entidade ou atributo s o as opera es b sicas da t cnica bottom up e Unifica o de atributos em uma entidade e Organiza o de entidades em uma hierarquia de heran a e Cria o de relacionamento entre entidades Uma entidade pode ser criada para satisfazer uma necessidade Atributos levantados fo NE MN 9 podem formar uma red entidade E S 5 a H Ne cai Entidades j levantadas podem ser unificadas em uma estrutura de generaliza o especializa o Entidades n o relacionadas podem necessitar de um ap aa relacionamento entre elas RD i Figura 75 Transformadas Bottom Up 1 12 3 T cnica Inside Out Inicia nos conceitos mais importantes e navega em dire o aos menos importantes comum que modelos E R se desenvolvem em torno de algumas entidades
112. ados e levantar a opini o de fornecedores clientes e vendedores representantes ou distribuidores da empresa Sinais espec ficos que podem ser verificados s o e Quanto s tarefas realizadas se cont m erros se s o feitas vagarosamente se n o s o mais feitas como definidas em documentos da companhia se n o s o completadas e Quanto aos funcion rios se est o desestimulados se n o podem descrever suas responsabilidades e objetivos se a taxa de demiss es alta e Quanto aos parceiros externos clientes fornecedores e vendedores reclama es sugest es de melhoria queda nas vendas vendas com perdas Para auxiliar o processo de levantamento de problemas pode ser criada uma tabela com as colunas Causa Resultado Valor Processo Causador Dados causadores Sugest o de solu o 59 Problemas do Neg cio Resultado Processo Dados Sugest o de Causador Causadores Solu o Como n o N o Acima de 1 Planejamento Modelagem podemos poss vel milh o de cen rios analisar analisar planos de cen rios de neg cio mercado alternativos Como n o N o 30 do Compras Pre os Sistema de sabemos o poss vel faturamento acompanha custo real de fazer poderiam ser mento de produ o contratos de passados de custos futura longo prazo curto prazo para longo Tabela 3 Identificando problemas de neg cio V 5 Oportunidades As oportunidades s o ofertas que fazemos ao nosso cliente Devido ao n
113. ados na ordem em que est o no livro Os cap tulos de an lise funcional e modelagem de dados j foram dados em diferentes ordens tanto um quanto o outro na frente por m a an lise de dados independente da an lise funcional e o inverso n o verdade o que recomenda que seja a ordem adotada Al m disso a modelagem de dados pode ser vista como uma forma de detalhar a n vel do sistema as regras de neg cio o que apresenta uma continuidade ao curso O livro suporta bem um per odo de 15 semanas com 4 horas por semana incluindo aulas te ricas e exerc cios duas provas e um trabalho por equipe que tem em m dia 15 eventos e 10 entidades e que deve modelar de forma completa um sistema de acordo com todo material apresentado Cap tulo Il Sistemas de Informa o A complex system that works is invariably found to have evolved from a simple system that worked John Gall Sistemas de Informa o Dados Informa o Conhecimento Sle a Organiza o ERP Sistemas de Informa o s o utilizados em organiza es para planejamento monitora o comunica o e controle das suas atividades por meio da manipula o e guarda de informa es Segundo o Dicion rio Aur lio a palavra sistema significa entre outras coisas um Conjunto particular de instrumentos e conven es adotados com o fim de dar uma informa o Os instrumentos s o as ferramentas os mecanismos concretos ou abstratos que utilizamos
114. al Usu rios do sistema que apenas servem como interlocutores dos verdadeiros agentes externos s o considerados transportadores de dados Ao documentar um evento devemos documentar a exist ncia de transportadores como veremos no dicion rio de eventos Essa distin o entre agentes externos e transportadores algumas vezes muito dif cil Devemos entender que a verdadeira ess ncia de um sistema est relacionada com sua fun o no neg cio em que ele est inserido Os usu rios do sistema n o s o necessariamente os agentes externos que interagem com o sistema Devemos considerar como agentes externos aquelas pessoas ou artefatos tecnol gicos que det m o poder de iniciar o evento Por 53 a LEESE Em alguns formatos de DFD as entidades externas n o possuem s mbolo ou at mesmo n o s o indicadas SANIA N o confundir com as entidades do modelo de entidades e relacionamento 55 dora iria f E Modernamente na t cnica de Casos de Uso considera se a possibilidade de dois modelos o do neg cio e o do sistema No modelo do sistema s o utilizados os usu rios reais 150 exemplo normalmente em um sistema de vendas o agente externo que inicia o evento o comprador e n o o vendedor que est usando o sistema Por isso diferenciamos na descri o completa do evento o iniciador que o agente externo que inicia o sistema do transportador que o usu rio do sistema respons vel por introduzir os da
115. amento de uma consulta reservando a data e o hor rio da sala e do profissional de acordo com as disponibilidades da cl nica e o desejo do paciente IV 1 1 Caracter sticas de um Bom Requisito Um requisito deve ter as seguintes caracter sticas B8 Necess rio significando que se retirado haver uma defici ncia no sistema isto ele n o atender plenamente as expectativas do usu rio o Em especial n o devem existir requisitos do tipo seria interessante ter Ou o requisito necess rio ou dispens vel o Deve ser levado em conta que cada requisito aumenta a complexidade e o custo do projeto logo n o podem ser introduzidos de forma esp ria N o amb guo possuindo uma e apenas uma interpreta o Nesse caso muito importante prestar aten o na linguagem sendo utilizada Verific vel n o sendo vago ou geral e sendo quantificado de uma maneira que permita a verifica o de uma das seguintes formas inspe o an lise demonstra o ou teste Conciso de forma que cada requisito defina apenas um requisito que deve ser feito e apenas o que deve ser feito de maneira clara e simples o Um requisito para ser conciso n o inclui explica es motiva es defini es ou descri es do seu uso o Estes textos podem ser mantidos em outros documentos apontados pelo requisito de prefer ncia sob o controle de um sistema de ger ncia de requisitos Independente da Implementa o ou seja o re
116. as Uma depend ncia funcional transitiva ocorre quando um atributo al m de depender da chave prim ria da entidade depende de outro atributo ou conjunto de outros atributos n o identificadores da entidade Um exemplo de depend ncia transitiva pode ser encontrado em um sistema acad mico universit rio hipot tico onde em uma entidade aluno fosse mantida a informa o escola de origem e endere o da escola de origem O endere o dependente da escola que depende do identificador do aluno Assim para normalizar criamos a entidade escola contendo nome e endere o e outros campos necess rio eliminamos esses campos da entidade aluno e finalmente criamos o relacionamento entre aluno e escola Aluno CPF NomeAluno EnderecoAluno NomePai NomeMae EscolaOrigem EnderecoEscolaOrigem Aluno Escola CPF NomeEscola NomeAluno IN ALA End Escol m OK EnderecoAluno nderecoEscola NomePai NomeMae Figura 78 Transformando a entidade aluno para a 3FN Uma entidade est na terceira forma normal se est na 2FN e se nenhum atributo n o pertencente chave fica determinado transitivamente por esta A segunda e terceira formas normais fazem com que cada atributo que n o seja identificador forne a um fato sobre a entidade indicada pela chave e apenas pela chave XXX Kent 83 Normalizar corresponde a criar relacionamentos 1 N ou 1 1 1 14 5 Outras formas normai
117. as de Sucesso Estabelecem o que deve ser verdadeiro APOS o caso de uso Todos os interessados devem ser satisfeitos O Caminho Feliz ou Fluxo Principal Apresenta uma segii ncia de passos Normalmente N O tem condi es ou ramifica es Exce es s o tratadas como seqii ncias alternativas Os passos devem descrever trocas de informa o intera o valida o ou mudan a de estado Tipos de Passos o Obrigat rios Fluxo de informa o o Complementares Contextualiza o o N o recomendados Controle e execu o passos internos ao sistema Extens es ou Fluxos Alternativos Est o associadas aos passos do fluxo principal 188 IX 11 8 IX 11 9 IX 11 10 IX 12 e Identificam um erro a forma de trata lo e como retornar ao fluxo principal se for poss vel e Um fluxo alternativo tem pelo menos quatro partes o Identifica o o n mero da linha do fluxo principal onde a exce o ocorre e um identificador para a pr pria exce o na lista por exemplo la 1b 2a 2b o Identifica o da exce o necess rio identificar qual a exce o que ocorreu pois em uma mesma linha do fluxo principal podem ocorrer diferentes tipos de exce es Por exemplo fita danificada fita reservada etc o A es corretivas deve se identificar a segii ncia de a es que deveriam ser executadas para corrigir a exce o o Finaliza o Se o caso de uso retorna ao flux
118. as uma para sua exist ncia normalmente associados a aspectos de outra entidade que s o multi valorados como produtos e suas quantidades em um pedido e Entidades de Associa o que representam conceitos que s o naturalmente dependentes de mais de uma entidade para sua exist ncia James e Suzanne Robertson B34 sugerem algumas regras para que verifiquemos se um conceito deve ser realmente escolhido como uma entidade e Toda entidade deve ter um papel nico e definido no neg cio se voc n o pode explic la provavelmente n o precisa se lembrar dela 116 Entidades devem ter ao menos um atributo que as descrevam e prefer vel que tenham v rios Entidades devem ter mais de uma inst ncia Se a inst ncia nica ent o n o deve ser uma entidade mas uma informa o constante que parte do neg cio da empresa uma regra de neg cio Entidades devem possuir inst ncias unicamente identific veis Entidades n o possuem valores apenas atributos possuem valores Pessoas e organiza es que interagem com o sistema s o candidatos a entidade quando precisamos nos lembrar alguma coisa espec fica sobre elas para gerar relat rios ou processar dados entrados Isso n o se aplica a logons ou passwords utilizados para a seguran a do sistema pois seguran a um problema tratado no projeto f sico Devemos aplicar essa regra em rela o necessidade de identifica o e endere amento por exemplo
119. ator Figura 71 O mesmo modelo anterior com a nota o IDEF1X software ERWIN 3 5 A Cardinalidade nas Nota es Podemos identificar pelo menos tr s escolas quanto maneira de denotar a cardinalidade das nota es 132 A primeira e original chamada associativa e indica junto entidade quantas ocorr ncias da mesma podem estar associadas a uma determinada entidade Veja na Figura 72 que um filme est associado a v rias fitas Z E a que encontramos na nota o da Engenharia da Informa o A segundo a participativa que indica quantas vezes uma entidade participa de um relacionamento Na Figura 73 um filme participa at v rias vezes do relacionamento Essa interpreta o est mais perto da id ia matem tica que o relacionamento um conjunto de pares ordenados Finalmente modelos com IDEFIX usam uma nota o pr pria com significado dependente de uma combina o especial de s mbolos Fita lt ua gt Cliente Cont m Filme E Atua lt e gt m m Figura 72 O mesmo modelo segundo a nota o original de Peter Chen associativa Note que escolhemos manter o aluguel como um relacionamento nesse modelo que permite relacionamentos com atributos software Visio 2000 133 Fita em mm gt Om Cliente Cont m 1 n an A Filme 1 n RA 1 n 1 n L L Ator Dire
120. avra ou senten a que parece ter pouca import ncia Termos diferentes s o usados por entrevistados para significar a mesma coisa 4 Alguns entrevistados falam de uma parte ou de alguns objetos de um caso de uso que outro entrevistado n o falou 5 Usu rio de mais alto n vel na empresa muitas vezes n o citam partes importantes do processo 6 Algumas coisas que a empresa n o quer que aconte a acontecem XII 2 Entrevista 1 Propriet rio da Empresa Sr Jos Letrado A Livraria ABC atua no mercado de venda de livros de arte e livros raros de colecionadores sob encomenda Nossa atua o n o prev a manuten o de livros em estoque Todos os livros solicitados por seus clientes s o semanalmente encomendados s editoras distribuidoras outras livrarias e outros vendedores em geral N s somos uma esp cie de empresa de corretagem que facilita a vida de colecionadores WIA a Mt aii ei E O cliente pode pedir qualquer livro mas n s n o trabalhamos com livros comuns Nosso mercado restrito e de alto valor agregado Trabalhamos com livros do mundo todo e temos contatos em todos os lugares At no Nepal A partir do pedido do cliente a gente investiga se o livro pode ser encontrado e trazido para o Brasil Para usar os servi os da livraria os clientes devem se cadastrar previamente O pedido de cadastro aprovado por mim ou por meu filho 230 Os clientes enviam seus pedidos pelo correio telefone
121. bidas durante as entrevistas A an lise da informa o obtida n o trivial dif cil ouvir e registrar simultaneamente principalmente porque h fatos que s tomam import ncia depois de outros fatos serem conhecidos e a ele j n o foi registrado Da a import ncia da grava o e da respectiva transcri o fica mais f cil selecionar e registrar o que relevante e validar com o entrevistado S o exig ncias para o relacionamento entre os participantes de uma entrevista respeito ao conhecimento e habilidade do especialista percep o de express es n o verbais sensibilidade s diferen as culturais cordialidade e coopera o IV 8 2 3 Entrevista Estruturada A entrevista estruturada extrai informa es sobre perguntas espec ficas Nesse tipo de entrevista importante entrevistar a pessoa certa uma boa t cnica para ser usada ap s uma pesquisa com question rio quando poss vel selecionar entre as respostas as partes interessadas com maior potencial de gera o de outras informa es Suas vantagens s o Respostas diretas com menos ambigiiidade informa o detalhada Sua desvantagem b sica que as quest es relevantes precisam ser identificadas com anteced ncia IV 8 2 40 processo da entrevista O processo de entrevista n o se resume ao ato espec fico da entrevista Na verdade ele come a muito antes e acaba muito depois O processo normal da entrevista inclui 1 Determina o da necessidade
122. c fico navegando de livro para clientes ou descobrir que produtos um cliente pediu navegando de clientes para livros Indicam tamb m que precisamos nos lembrar de algo que envolve simultaneamente duas ou mais entidades do sistema e que essa lembran a s faz sentido quando todas as inst ncias envolvidas s o recuper veis simultaneamente ou sequencialmente Existem muitos relacionamentos comuns encontrados em muitos sistemas como comp e pe as comp e m quinas um bicicleta um meio de transporte faz ou gera cliente faz ou gera pedido atende visita atende solicita o de reparo usa cliente usa produto etc 119 O relacionamento um t o comum e t o til que foi escolhido como um relacionamento especial em muitos m todos derivados da Modelagem Entidade e Relacionamento original a rela o de heran a onde dizemos que uma entidade herda todas as caracter sticas de outra entidade A heran a equivale abstra o de generaliza o especifica o Existem duas formas b sicas de heran a Na heran a exclusiva dividimos uma classe em categorias Essa forma de heran a traz poucas dificuldades na modelagem e conhecida como separa o em categorias Uma pessoa por exemplo pode ser dividida em duas categorias a dos homens e a das mulheres Quando a divis o n o exclusiva ou seja quando poss vel que uma in
123. cabul rio adequado para o p blico entrevistado inclus o de todos os conte dos relevantes e de todas as possibilidades de respostas cuidado com os itens redundantes ou amb guos contendo mais de uma id ia ou n o relacionados com o prop sito da pesquisa reda o clara execu o de testes de validade e confiabilidade da pesquisa H uma tens o n o resolvida entre o uso do question rio como um evento interativo ou como instrumento neutro de medida Por um lado como entrevista visto como uma intera o Por outro lado no interesse de torn lo um instrumento muitos recursos da intera o existentes na conversa o n o s o permitidos suprimindo recursos de medida de incertezas de relev ncia e interpreta o Dificuldade importante o fato das palavras possu rem significados diferentes para pessoas diferentes em diferentes contextos Em intera es normais essas quest es de interpreta o s o negociadas entre os participantes mas em entrevistas com question rios o treinamento e o m todo utilizados pro bem essa negocia o Al m disso h necessidade do uso de t cnicas espec ficas nem sempre do conhecimento dos projetistas para a constru o e aplica o de question rios A menor ambigiidade uma das principais vantagens da entrevista via question rio Para gerar bons itens de question rio devemos e Evitar palavras amb guas ou vagas que tenham significados diferentes para pessoas diferentes
124. caracter stica tecnol gica passada como o tipo de arquivo em que est o guardados os dados atualmente Podem novamente ser divididos em Requisitos tecnol gicos inclu dos pelo passado quando inclu mos na especifica o algo que existe na implementa o existente mas que n o necess rio ao funcionamento do sistema Requisitos tecnol gicos inclu dos por antecipa o quando inclu mos algo na especifica o em fun o de alguma tecnologia escolhida para a implementa o Requisitos falsos arbitr rios s o inclu dos pelos analistas ou por preciosismo ou por caracter sticas da ferramenta de modelagem sendo utilizadas Tamb m podem ser divididos em Requisitos arbitr rios inclu dos por influ ncia da ferramenta de modelagem quando inclu mos na especifica o algo desnecess rio para fazer o sistema mas necess rio por alguma caracter stica da ferramenta de modelagem e Requisitos arbitr rios inclu dos por preciosismo quando inclu mos uma fun o esp ria no sistema i e uma fun o que foi n o solicitada pelo usu rio Qualquer requisito que n o possa ser verificado ou seja que sua presen a n o possa ser garantida por alguma forma quantific vel e mensur vel no final do projeto um requisito falso O principal problema de introduzir requisitos falsos que eles aumentam de v rias formas o risco do projeto n o se completar a contento Um requisito falso por si s pode 5 Chamado em ingl
125. cas do modelo relacional A principal forma de modelagem de dados e a forma adotada por esse texto o Modelo de Entidades e Relacionamentos ou MER por meio do Diagrama de Entidades e 28 a ER E E ate r Na an lise essencial discutiremos a necessidade de um sistema de ter uma mem ria que permite ao sistema se lembrar de fatos passados ao atender um evento A modelagem de dados a t cnica que nos permitir definir como essa mem ria isto que informa es deve guardar 105 Relacionamentos ou DER No mo Modelo de Entidades e Relacionamentos contamos com tr s abstra es para modelar o mundo entidades atributos e relacionamentos De maneira simples podemos dizer que entidades representam as coisas e conceitos do mundo atributos representam as caracter sticas dessas coisas e conceitos e relacionamentos representam as rela es existentes entre essas coisas e conceitos 1 1 Modelos de Dados e Regras de Neg cio Um modelo de dados se inicia de uma forma pr xima ao neg cio modelo conceitual e vai se aproximando com o decorrer do projeto de uma forma com alta influ ncia da tecnologia modelo f sico O modelo de dados conceitual na forma de um diagrama de entidades e relacionamento pode ser constru do diretamente sobre os termos e fatos levantados nas regras de neg cio ou por outro lado pode ser o mecanismo utilizado para levantar e documentar essas regras 1 2 Modelos e Abstra
126. caso se sugere uma estrat gia de constru o bottom up no segundo caso a estrat gia top down pode ser mais apropriada A fun o de cada uma das setas dada pelo seu posicionamento ao redor da caixa da atividade como descrito na figura a seguir e Entradas setas entrando pela direita s o dados ou objetos que s o transformados ou consumidos na sa da pelo processo e Controles setas entrando por cima s o condi es necess rias para produzir a sa da correta podendo ou n o ser transformados na sa da Controles s o restri es na opera o do processo e Uma sa da setas saindo pela esquerda apresenta um resultado do processo um artefato ou informa o criada ou transformada por ele e Os mecanismos ou recursos setas entrando por baixo s o os meios necess rios para a realiza o da fun o por m n o s o consumidos para produzir a sa da e E poss vel que uma seta saia da parte de baixo do diagrama Isso indica uma chamada de fun o que na verdade representa que o processo chamador explicado pelo processo chamado Controle Control Sa da Output Entrada Input Nome da Fun o AO Mecanismo Mechanism Chamada Call Figura 25 Um processo em IDEFO e suas entradas e sa das 22 z OI a Tamb m conhecidos informalmente como explos es 15 Ambiente Toler ncia Medir Temperatura de Opera o Alarme Monitorar A Temperatura Temperatura gt Fig
127. cifica o precisa do que deseja Uma receita geral para o levantamento de requisitos pode ser dada em 5 passos 1 Identificar quem fornecer os requisitos 2 Levantar lista de desejos para estas pessoas 3 Refinar cada lista de desejos at que seja auto consistente 4 Integrar as listas de desejos de forma que sejam consistentes 5 Determinar os requisitos n o funcionais Apesar de tudo n o uma tarefa f cil levantar os requisitos Muitos problemas podem acontecer comum que stakeholders n o saibam exatamente o que querem ou n o saibam articular propriamente suas id ias especialmente quando o desenvolvedor n o possui o linguajar t pico da rea de aplica o jarg o Muitas vezes tamb m os desenvolvedores pensam entender melhor do problema que seus clientes propondo supostas melhorias que afetam custo e aumento o risco dos sistemas propostos 43 IV 8 1 Processo de elicita o de requisitos A elicita o de requisitos pode ser modelada em um processo como o proposto por Christel e Kang apresentado nas figuras a seguir Busca de Fatos Coleta e Classifica o de Requisitos rs rs Racionaliza o e Avalia o Prioriza o Integra o e Valida o rs Figura 19 O processo de elicita o de requisitos adaptado de Christel e Lang B14 44 Tarefas da Elicita o de Requisitos Atividade Tarefas orientadas ao usu rio Tarefas orienta
128. cnaminG info icon Qor A SEn D Tony Wons o FPT name Last name E Ma O Avarage Uses D Do Ner Disrume Nor Counterep s O On buns CHAT SESSIONS R Ta Emas To ia fear uno x e xa 7 pr Z F e Inmare Criar SESION ques eat Tasos Sente Po NNG Z oses Foume Topic Torc voa Sessions juro 4 ee AE Em o are SES E O Y Bosy Crm n i w Away 5 P nor Counecrep 1Y D Joun Smm LIIT or peor Wo invren To mar l cramen Car Cra eram eg auma Users at men nA comesas fran zeen ae am s Ea Pirai I5 Avanage Users TA Quim umas m Room Curr Scrsen E e d Bet Hoo oome wer TO vove H ug E E Gracas ontot Jone masres prem doda ip O VINDO Saba T 2205 apr O mar e a neoregos P E as E uso Kiii Rasuurs Onr onsa CHAT a Hon serm6 CHAT SESSIONS oer W cuar PIC one pat Amy Udusom cont n Ro Berna Jonnson DO m He Room quite fies DP cuar rome rwo EINES gt at E Boo Usar gt O Joun Smm g Lisa Caeseg TRANSINONS IN Guu lt Fantig DESCALPIONS iN PEE Een fezes ASA sepsio LNNRATOE TO dom CHAT Figura 112 V rios prot tipos de baixa fidelidade em uma folha compondo um storyboard Landay Softwares para prototipagem de baixa fidelidade Com computadores se tornando presente em todos os ambientes poss vel pensar em construir prot tipos de baixa fidelidade diretamente no computador e n o apenas com papel O software DENIM ht
129. co para um tipo de neg cio loja de materiais de constru o ao mesmo tempo reduzindo e ampliando o escopo em fun o da rea de aplica o Finalmente declaramos que deve suportar uma fun o n o necessariamente comum nesse tipo de aplica o como um requisito primordial permita encomenda de mercadorias provavelmente diferenciando o sistema da pr tica normal do mercado N o devemos dar v rios objetivos a um sistema Quando isso parece necess rio temos a forte indica o que estamos tratando de mais de um sistema Ao declarar um objetivo devemos evitar o uso das conjun es e e tamb m ou ainda outra constru o que leve a representar mais de uma id ia Quando um objetivo tem mais de uma id ia proposta Alguns exemplos de objetivos mal definidos O Sistema otimizar o desempenho da empresa na sua rea de atua o O Sistema possibilitar o controle dos clientes 58 geralmente temos na verdade mais de um sistema sendo descrito E importante n o misturar sistemas distintos principalmente para reduzir o risco do projeto j que quanto maior for o projeto maiores ser o os riscos envolvidos V 4 Problemas Ao conversar com o cliente principalmente nas entrevistas iniciais temos a oportunidade de ouvir muitas reclama es sobre o sistema atual seja ele informatizado ou n o Isso esperado pois se n o existissem defeitos na forma como o sistema executado no moment
130. como o diagrama funcional O objetivo da tabela determinar o envolvimento dessas pessoas com as decis es relativas s fun es da empresa Esse envolvimento determinado em tr s n veis principal respons vel pela decis o grande envolvimento com a decis o e finalmente algum envolvimento com a decis o Principal respons vel pela decis o Grande envolvimento com a decis o Algum envolvimento com a decis o Tabela 9 Tipos de envolvimento com a decis o 102 Processos VP de Vendas Ger ncia do Territ rio Administra o Pedidos de Fornecimento Opera o Gerente de pedidos Gerente de vendas VP Engenharia VP Produ o Diretor da F brica Tabela 10 Exemplo de uma tabela Processo x Organiza o H V Organiza o X KNN x x VI 7 2 Dados x Processos CRUD Esta tabela uma das mais interessantes e relaciona as entidades inicialmente do modelo de conceitual de dados com os processos que as utilizam indicando pelas letras CRUD se o processo Cria l Read altera Update ou apaga Delete a entidade Uma de suas caracter sticas principais que pode ser constru da com v rios pares linha x coluna dependendo do tipo de abstra o que est sendo usado No nosso caso usaremos principalmente no mapeamento de a es CRUD entre eventos essenciais e entidades os dois temas ser o tratados mais tardes mas podem ser usados em modelos de
131. cr nimo em ingl s kilo source lines of code e pontos de fun o PFs ou FPs do ingl s Ambos possuem defensores e detratores vantagens e desvantagens mais bvias ou mais sutis Uma linha de c digo no contexto do COCOMO II deve ser uma linha execut vel ou uma declara o ou uma diretiva para o compilador que n o tenha sido gerada com um gerador autom tico e que tenha sido feita pela empresa Linhas de c digo obviamente s podem ser contadas ap s a implementa o do software 81 gire x 5 A Outros custos adicionais comuns s o equipamento e software Mesmo quando j possu mos o equipamento e o software temos que nos lembrar de amortizar o seu custo original de alguma forma entre os v rios projetos 82 Dreg Em sistemas menores a medida pessoa hora 213 Um ponto de fun o uma medida abstrata que representa a funcionalidade entregue ao cliente em fun o das interfaces do sistema com o usu rio com outros sistemas e ainda com a informa o vista pelo cliente Pontos de fun o s o tratados detalhadamente em um cap tulo posterior Pontos de fun o podem ser contados a partir desde a especifica o do sistema at sua implementa o final Essas duas medidas podem ser convertidas uma na outra por meio de estat sticas globais ou espec ficas da empresa A vantagem de KSLOC que podemos simplesmente cont las a principal cr tica que medir produtividade ou custo por KSLOCs pode provocar
132. creve o sistema como se o estivesse usando diretamente muitas vezes j usando o sistema atual Exige fun es do sistema principalmente para atender o seu n vel de atua o gerencial ou operacional Pode apresentar alguma desconfian a pois o novo sistema pode exigir novos 33 conhecimentos Conhece a entrada e a sa da do sistema mas n o necessariamente os procedimentos internos e Entrevistado parte do sistema descreve o sistema visto por dentro Muitas vezes quem vai ter o trabalho substitu do em todo ou em parte pelo sistema o que pode causar desconfian a e at mesmo franca hostilidade Conhece os procedimentos na forma como s o realizados e as exce es que podem acontecer N o podemos deixar de entender que alguns usu rios fornecem uma perspectiva mista principalmente quando envolvidos com diferentes partes do sistema Entrevistado Usu rio do Sistema Entrevistado Parte do E Sistema Que ESSO p aY A Entrevistado Omnisciente Figura 13 Os tipos de entrevistados em rela o ao sistema IV 4 Requisitos e Necessidades Requisitos s o origin rios de necessidades dos usu rios e stakeholders Enquanto os requisitos vivem no mundo das solu es as necessidades vivem no mundo dos problemas Os requisitos implementam as caracter sticas observadas do sistema que atendem as necessidades Figura 14 34 Problema Necessidades Caracter sticas S
133. da entrevista e Todas as conclus es tiradas dos fatos e opini es como apresentados e Todos os problemas de neg cio levantados durante a entrevista e Exemplos de todos os relat rios diagramas documentos etc discutidos durante a entrevista e Todos os desenhos e diagramas feitos a partir ou durante a entrevista e Qualquer coment rio relevante feito pelo entrevistado e Todos os n meros relevantes quantidades volume de dados etc coletados durante a entrevista E importante notar que o relat rio da entrevista deve ser aceito pelo entrevistado E normal o entrevistado remover alguma coisa ou colocar algo a mais O analista deve ficar atento aos motivos do usu rio em fazer modifica es Se houver discuss o quanto interpreta o de algo e o analista achar essencial manter sua vers o no relat rio deve tamb m permitir que o entrevistado coloque sua vers o IV 8 3 4 As perguntas de conclus o Ao final da entrevista importante realizar uma avalia o da percep o do entrevistado sobre a entrevista que acabou de ser realizada Para isso necess rio que seja respondido um formul rio contendo perguntas como e Voc acha que essa entrevista cobriu tudo que era necess rio e Voc acha que foram feitas as perguntas certas e Voc acha que era a pessoa mais certa para responder essas perguntas IV 8 4 JAD Outra t cnica importante de elicita o de requisitos que merece um tratamento separado o J
134. da entrevista Especifica o do objetivo da entrevista Sele o do entrevistado Marca o da entrevista Prepara o das quest es ou do roteiro A entrevista propriamente dita E ON de O 1 Documenta o da entrevista incluindo os fatos e a informa o conseguida durante a entrevista 8 Revis o da transcri o da entrevista com o entrevistado 9 Corre o da transcri o 10 Aceita o por parte do entrevistado 11 Arquivamento IV 8 2 5 Preparando a entrevista 2 A prepara o uma necessidade b sica da entrevista N o s precisamos preparar a entrevista propriamente dita mas tamb m preparar a n s mesmos como entrevistadores e ao entrevistado Uma entrevista deve ter um objetivo As perguntas ou o roteiro devem ser coerentes Para isso importante a determina o desse objetivo O entrevistado deve ter no o clara da finalidade da entrevista e perceber sua utilidade Isso se faz por meio de palestras textos de divulga o e principalmente se explicando ao entrevistado no in cio da entrevista seu objetivo e import ncia 48 Muitas vezes esse objetivo n o espec fico principalmente na fase inicial do projeto Mas deve ser claro isso quando expressado deve permitir que entrevistador e entrevistado compreendam o motivo da entrevista Assim no in cio do projeto os objetivos podem ser Conhecer o ambiente de trabalho Levantar expectativas iniciais dos usu rios J com o pas
135. das ao desenvolvedor Busca de Fatos Identificar grupos relevantes atrav s de m ltiplos n veis da organiza o Determinar os contextos operacional e do problema incluindo a defini o dos modos operacionais objetivos e cen rios de miss o como apropriados Identificar sistemas similares Realizar an lise de contexto Identificar especialistas do dom nio da aplica o e de desenvolvimento Identificar modelo de dom nio e modelo de arquitetura Conduzir pesquisas tecnol gicas para mais tarde fazer estudo de viabilidade e an lise de risco Identificar custos e restri es implementa o impostas pelo patrocinador Coleta e Classifica o dos Requisitos Levantar a lista de desejos de cada grupo Classificar a lista de acordo com funcionais n o funcionais restri es de ambiente restri es de projeto e ainda de acordo com as parti es definidas pelo modelo de dom nio e pelo paradigma de desenvolvimento Racionaliza o e Responder quest es da forma Realizar uma an lise de riscos cr ticas para a miss o Avalia o Por que voc precisa de X a investigando t cnicas custos partir de racioc nio abstrato Isso prazos e incluindo an lise de auxilia a transformar o racioc nio custos e benef cios e viabilidade das quest es sobre como para baseado na disponibilidade da as quest es sobre o qu tecnologia Prioriza o Determi
136. de faz lo v rias vezes Esse um relacionamento muito comum Normalmente significa que dois objetos que n o possuem nenhum relacionamento de propriedade ou restri o de exist ncia podem ser colocados em uma rela o hier rquica Exemplo esse tipo de relacionamento pode ser encontrado em locais onde temos um estoque de objetos que s o alocados a departamentos da empresa por exemplo computadores Um computador s pode estar alocado em um departamento ou pode estar no estoque sem aloca o Um departamento pode ter 0 1 ou v rios computadores alocados para si o 0 N 0 1 similar ao anterior o 0 1 1 N 123 Esse relacionamento normalmente tamb m indica uma rela o hier guica O primeiro objeto pode opcionalmente pertencer a essa rela o enquanto o segundo objeto obrigatoriamente pertence a rela o N o muito comum pois exige que uma inst ncia tenha no m nimo uma filha mas as filhas podem existir de forma independente Pode ser usado quando algo para existir deve ter ao menos uma parte mas estas partes tem vida pr pria mesmo s podendo ser usadas em um lugar Isso pode ser encontrado por exemplo no relacionamento entre uma venda e os itens quando nicos vendidos Uma loja de carros novos por exemplo pode em uma mesma venda negociar v rios carros mas necessariamente a venda cont m um carro J o carro pode ter sido vendido ou n o o 1 N 0 1 similar ao anterior
137. de m quinas espec ficas at grandes empresas por meio de uma rede de fun es interconectadas e interfaces entre essas atividades Esses modelos representam fun es do sistema relacionamentos funcionais e dados que suportam a integra o do sistema Segundo o padr o IFIPS 183 um modelo IDEFO composto por uma s rie hier rquica de diagramas que apresentam gradativamente um n vel maior de detalhe descrevendo fun es e suas interfaces no contexto de um sistema A descri o a seguir fortemente baseada e algumas vezes a tradu o literal do padr o IFIPS 183 O IDEFO pode ser feito em v rios n veis de abstra o Podemos descrever as fun es de uma empresa como receber pedidos ou produzir encomendas ou podemos descrever as fun es de uma pequena m quina como medir temperatura A caracter stica mais importante do IDEFO que ele n o descreve como as coisas s o feitas e tamb m n o d nenhuma ordem Ele apenas define as responsabilidades ou de certa forma os requisitos funcionais de um sistema isto que fun es devem ser feitas e qual a interface de cada fun o Assim quando precisarmos descrever passos segiienciais algoritmos ou outros detalhes devemos usar outro modelo VI 4 1 Sintaxe do IDEFO Os componentes da sintaxe de IDEFO s o diagramas formados de caixas setas linhas textos e gloss rios As fun es definidas como atividades processos ou transforma
138. de requisito do sistema pois descreve tudo que o sistema tem que saber B28 O modelo de dados estabelece um vocabul rio termos e fatos entidades e relacionamentos indica que informa o est sendo compartilhada e qual o escopo de conhecimento que est sendo considerado pelo sistema E importante notar que modelos de dados organizam representa es est ticas do sistema isto eles indicam como s o registrados os resultados das opera es do sistema mas n o como essas opera es s o feitas A cria o do modelo de dados um processo de especifica es sucessivas Inicialmente descrevemos um modelo do ambiente observado normalmente descrevendo o mundo como ele visto pelo usu rio Esse modelo conhecido como Modelo Conceitual de Dados No final devemos possuir uma descri o na vis o do desenvolvedor descrevendo o mundo de uma forma espec fica otimizada para os dispositivos sendo utilizados na implementa o do sistema linguagens de programa o SGDB sistema operacional e hardware o Modelo F sico de Dados Entre o modelo conceitual e o modelo f sico devemos passar por um passo intermedi rio onde assumimos compromissos com uma tecnologia espec fica mas n o com os produtos sendo utilizados Este passo conhecido como Modelo L gico Muitas metodologias de modelagem de dados como a IDEFIX utilizam apenas dois passos o modelo l gico e o f sico assumindo j no primeiro modelo algumas regras t pi
139. de um evento ou de uma rela o qualquer entre duas entidades muito simples Mais tarde compreendendo melhor esse relacionamento entendemos que mais interessante represent lo como uma entidade 135 e Cria o de atributos a modifica o mais simples e comum S estamos citando para completar o conjunto de operadores top down Uma entidade pode ser PO transformada em duas entidades relacionadas Um atributo de uma VS sa entidade pode ser f a transformado em uma k entidade relacionada Re 4 Uma entidade pode ser transformada em uma entidade e um conjunto de especializa es Uma entidade pode ser transformada em um n mero de entidades n o relacionadas Um relacionamento pode ser transformado em dois a relacionamentos em paralelo RE gt a lt ie Um relacionamento pode N ser transformado em uma E E ad NR entidade relacionada com m S as duas entidades ligadas a E o ad pelo relacionamento Um entidade pode receber um atributo Um relacionamento pode receber um relacionamento E ad E dE ado Figura 74 Transformadas Top Down Como escolher entre um atributo ou Entidade e Relacionamento Se o conjunto de valores for fixo durante toda a vida do sistema pode ser model
140. dem ser absolutos ou relativos Um evento relativo quando definido em fun o do decorrer de um prazo depois do acontecimento de outro evento Eventos absolutos ocorrem em fun o unicamente do calend rio e do rel gio Um evento temporal ocorre porque o sistema tem um contrato para entregar informa o a um agente em um momento espec fico B34 Eventos externos podem ser esperados ou n o esperados Um evento esperado quando sabemos que ele vai acontecer em um instante espec fico ou que tem um limite de prazo para acontecer Ele pode tamb m ser chamado de evento agendado Um evento n o esperado quando n o podemos determinar momento ou limite para seu acontecimento Eles podem tamb m ser chamados de eventos agendados ou n o agendados Os nomes esperado e n o esperado podem causar alguma confus o O sistema na realidade espera que ambos os tipos de eventos ocorram Por m alguns t m um prazo ou data para ocorrer Por isso podemos usar com mais precis o o termo agendado N o Eventos Eventos esperados formam uma categoria importante pois sabemos que no mundo real quando um evento esperado n o acontece o pagamento de uma conta por exemplo pode ser necess rio tomar uma atitude espec fica Dizemos ent o que eventos esperados podem necessitar que sejam definidos n o eventos Esse o nome que damos para eventos que acontecem em fun o de outro n o ter acontecido possivelmente a partir de
141. depois na Universidade Federal do Rio de Janeiro j como professor Adjunto O texto foi criado alterado cortado e aumentado de forma a atender as necessidades do curso do mercado e dos alunos Muito do conte do aqui apresentado resultado direto de d vidas e dos erros mais comuns que os alunos apresentam durante o curso A mat ria apresentada tamb m resultado de 15 anos de atua o como consultor envolvido direta ou indiretamente na an lise e implementa o de sistemas em diferentes projetos sobre temas variados como administra o p blica ger ncia de sat lites controle de caminh es etc O livro foi constru do com dois prop sitos O primeiro apoiar um primeiro curso de modelagem de sistemas de informa o fundamentado na an lise essencial no n vel de gradua o ou extens o visando formar um analista de sistemas O segundo fornecer uma base de sustenta o para o analista no seu dia a dia no trabalho N o apresentamos um m todo nico de an lise ou especifica o de sistemas mas sim um conjunto de ferramentas que podem ser usadas tanto em conjunto como em separado por m baseadas em uma filosofia comum Este livro n o trata de modelagem orientada a objeto que normalmente assunto de um segundo curso de modelagem de sistemas Algumas premissas foram importantes na constru o do texto N o um texto com foco te rico mas sim aplicado Durante os 10 anos em que o curso j foi dado todas as provas
142. descart vel com diferentes finalidades como validar um modelo de interface ou um modelo de funcionamento ou ainda um algoritmo Normalmente prot tipos s o constru dos utilizando a ferramenta em que o sistema est ou ser desenvolvido podendo servir inclusive para validar essa ferramenta e apresentam algum comportamento mesmo que simulado Um mock up uma representa o da interface que n o cumpre nenhuma finalidade a n o ser demonstrar a uma proposta para a apar ncia final do sistema sem a capacidade de simular seu comportamento a n o ser possivelmente a navega o entre telas Um mock up n o precisa ser feito com uma ferramenta de programa o podendo ser feito com ferramentas de desenho como os softwares Visio ou SmartDraw Um prot tipo de baixa fidelidade um mock up feito a m o da interface basicamente um conjunto de desenhos com a finalidade de demonstrar a apar ncia b sica e simular manualmente o comportamento do sistema Um prot tipo de alta fidelidade um mock up feito de forma a se assemelhar ao software final sendo normalmente constru do na linguagem de desenvolvimento ou em uma ferramenta com resultados similares Prot tipos de alta fidelidade s o executados pelo computador 201 ANSA VAI NTHA sa VC UCONENA Compony ACCOUNT 0235130 8 ater iost Locate AT M YOUR AMONT EGEJ EA 302 59 00 Eltsconpanr Figura 108 Um prot tipo de baix
143. desempenho o Conecte os ao caso de uso Coletam f rmulas estados cardinalidades o Capture separadametne O Processo de Escrita Defina o escopo e as fronteiras Determine mudan as no contexto inicial criado com listas in out Fa a um brainstorm e liste os atores prim rios Priorizando Casos de Uso Que casos de uso devem ser implementados Associar os casos de uso aos requisitos originais Em que sequ ncia devem ser implementados Selecionar os casos de uso para itera es de arquitetura Que representem funcionalidade central significante Que cubram grande parte da arquitetura Que forcem ou ilustrem um ponto espec fico e delicado da arquitetura Priorize os casos de uso cen rios para itera es futuras Casos de Uso Essenciais e Reais Casos de uso essenciais n o levam em considera o a tecnologia Casos de Uso Reais levam tudo em considera o Apar ncia Essencial Cliente fornece a sua identifica o Sistema identifica usu rio Sistema oferece opera es dispon veis Cliente solicita saque de uma determinada quantia Sistema fornece a quantia desejada da conta do cliente Cliente recebe dinheiro e recibo 193 IX 15 2 Apar ncia Real Ns DO NO E o CI e e e e SR na A UOU N O Cliente passa seu cart o no caixa eletr nico Sistema apresenta solicita o de senha Cliente digita senha Sistema exibe menu de opera es dispon veis Cliente indica que deseja realizar um saque Sistema requisita quantia a ser
144. diz tecnologia interna perfeita Ora se a tecnologia interna perfeita n o nos custa nada fazer toda a l gica necess ria para esse controle tamb m um bom sinal Finalmente o princ pio da solu o m nima nos indica que melhor ter apenas um evento do que dois Esse racioc nio pode ser aplicado em todos os casos em que temos uma sa da opcional interessante notar que em um DFD as sa das e entradas em um processo n o s o obrigat rias mas opcionais a l gica do processo que vai decidir se elas existem ou n o Assim podemos incluir em um evento todos os casos especiais que s o identific veis pelo sistema Obviamente se o sistema n o tiver um meio de descobrir que um caso especial ent o devemos ter outro evento VIIl 1O A Mem ria do Sistema Como mem ria do modelo essencial deve ser utilizado o modelo de entidades e relacionamentos descrito no Cap tulo VI Para cada evento e atividade essencial importante definir que mem rias ser o utilizadas Isso pode ser feito por meio de uma Matriz CRUD ou por meio de DFDs e mini especifica es VIH 10 1 Eventos x Entidades Matriz CRUD A Matriz CRUD uma tabela que relaciona processos e dados podendo ser utilizada em diferentes momentos do desenvolvimento de software Nessa tabela representamos processos nas linhas e dados nas colunas preenchendo as c lulas resultantes com uma ou mais letras entre C R U e D indicando que o proc
145. do grau de formalidade do processo de desenvolvimento que deve ser escolhido em fun o de um grupo de vari veis como a complexidade do projeto prazo e caracter sticas da equipe Enquanto um produto para um nico usu rio pode ser feito por meio de prot tipos sem nenhuma fase bem definida produtos muito grandes como um sistema de informa es para toda um empresa necessitam ser realizados em passos muito bem planejados Esse livro trata de algumas metodologias usadas no processo desenvolvimento de software Dependendo da fonte que utilizamos esse processo pode envolver uma mir ade de atividades Na norma ISSO 12207 s o citadas por exemplo an lise de requisitos projeto codifica o integra o testes instala o e aceita o Outras refer ncias podem apresentar divis es distintas dessas atividades ou incluir atividades novas como testes de integra o e testes de unidades Nesse livro estamos principalmente interessados em conhecer ferramentas para realizar a an lise de um sistema de informa o 18 HI 1 An lise Por an lise entendemos a tarefa de levantar e descrever os requisitos de um sistema definindo de que forma deve funcionar para atender as expectativas de todos que nele possuem algum interesse Normalmente se diz que a an lise define o que o sistema deve fazer sem especificar como far Durante a an lise devem ser explicitadas que tarefas o sistema deve executar e que dados deve manter em
146. do n o dirigir nenhuma e uma novela dirigida por um e apenas um diretor e Um cap tulo comp e uma e apenas uma novela e uma novela tem no m nimo um cap tulo podendo ter um n mero ilimitado deles e Um ator atua em uma novela podendo n o atuar em nenhuma e uma novela tem ao menos um ator podendo ter v rios e Um ator pode ser um ator horista e um ator horista obrigatoriamente um ator e Um ator horista trabalha de zero a v rias quantidade de horas mas uma quantidade de horas trabalhada por apenas um ator Dirige Novela Cap tulo Comp e 141 Ator Horista Figura 54 Exemplo de modelo conceitual No modelo anterior n o apresentamos nenhum atributo A nota o original para atributos o uso de c rculos ligados aos ret ngulos que representam as entidades complica muito o diagrama As nota es mais modernas anotam os atributos dentro dos ret ngulos 1 6 Desenvolvendo o Modelo Conceitual Desenvolver um modelo conceitual correto para um sistema completo e consistente n o uma tarefa f cil J desenvolver um modelo conceitual razoavelmente correto que d uma id ia do sistema e do neg cio e que de forma evolutiva resulte em um modelo conceitual correto uma tarefa razoavelmente f cil para um analista experiente Para o analista de sistemas iniciante por m parece uma tarefa extremamente dif cil Isso acontece porque o modelo conceitual de dados exige duas coisas um alto
147. do o conhecimento do entrevistado sobre as pessoas objetos fatos e procedimentos com os quais interage Os objetivos s o os mais diversos por exemplo estabelecer expectativas do consumidor verificar n veis de satisfa o e necessidades atuais e futuras estudar tend ncias na satisfa o do cliente ao longo do tempo ou avaliar programas em andamento O primeiro passo de uma entrevista determinar entre outros aspectos seus prop sitos ou objetivos a informa o necess ria e de quem obter para alcan ar esses objetivos e os recursos dispon veis para implementar e manter o processo de pesquisa Outros fatores merecem destaque precis o na determina o da amostra abrang ncia e relev ncia do conte do da pesquisa e essencial a valida o Os resultados da entrevista s o sumariados em um relat rio interpretativo que inclui relato sobre os achados e as recomenda es mais importantes A an lise pode ser qualitativa ou quantitativa Normalmente as entrevistas abertas est o no primeiro caso enquanto que os question rios s o analisados quantitativamente A responsabilidade do entrevistador tamb m grande Normalmente al m das entrevistas ele quem integra as diferentes interpreta es objetivos metas estilos de comunica o e o uso de terminologia H tamb m outras tarefas complexas como decidir a oportunidade ou n o de incluir certo tipo de informa o no conjunto inicial de requisitos Finalmente entrevi
148. do que o tempo est acabando e pergunte se gostaria de adicionar alguma informa o Solicite ao candidato que responda as perguntas de conclus o Se necess rio marque outra entrevista Entregue ao candidato o formul rio de avalia o de entrevista e o envelope correspondente Ensine o a enviar a avalia o preenchida Despe a se educadamente agradecendo a aten o e o tempo dispensado Muitas vezes a entrevista precedida por um bate papo informal de apresenta o Tente manter essa conversa o em um tempo m nimo razo vel IV 8 3 3 Documentando a Entrevista A entrevista deve ser documentada logo ap s sua realiza o Ao document la rapidamente estar garantindo que recuperar mais informa o A documenta o da entrevista deve fornecer a seguinte informa o A data hora e local da entrevista Nome do entrevistador Cargo do entrevistador Nome do entrevistado Fun o do entrevistado e a descri o desse cargo 52 e Se necess rio informa es de background do entrevistado como experi ncia no cargo ou com computadores e Organograma do entrevistado superior imediato colegas do mesmo n vel subordinados e O objetivo da entrevista e Nomes e t tulos de todos os outros presentes na entrevista e Uma descri o completa dos fatos descritos e opini es do entrevistado e Opcionalmente uma transcri o da entrevista possivelmente expurgada das falas que n o tinham rela o com o assunto
149. dos fornecidos pelo iniciador Um bom teste para verificar se o agente externo o verdadeiro iniciador do evento ou apenas um transportador no contexto de um neg cio perguntar se ele pode realizar por sua vontade aquele evento Vemos que no caso de um vendedor ele n o pode vender sem receber um pedido de um comprador a n o ser no caso espec fico onde ele estar pagando a compra sendo um comprador ele mesmo Logo o vendedor n o o agente externo iniciador podendo por m receber alguma sa da do sistema para ele destinada Na verdade de uma forma mais essencial por m pouco reconhecida o vendedor parte do sistema pois apenas uma implementa o da interface com o comprador Ao fazer a an lise n o estamos preocupados com os motivos dos agentes externos ou em modificar suas a es ou com o que eles fazem com os dados que obt m do sistema Por isso eles n o s o estudados definindo a fronteira do sistema e os limites do trabalho de an lise Normalmente agentes externos s o descritos por nomes que representam classes ou tipos de usu rio dentro de um neg cio Assim um sistema para uma loja que apresenta os usu rios gerente vendedor e cliente ter agentes externos com esses nomes Nunca usamos o nome pessoal de um usu rio mas sim seu papel ao utilizar o sistema ou seu cargo na empresa Outro tipo comum de agente externo aquele que representa uma institui o ou departamento ext
150. e um fluxo saindo da mem ria em dire o ao processo indica uma consulta a uma mem ria possivelmente usando opera es equivalentes a sele es e proje es da l gica relacional sem modific la Por outro lado um fluxo saindo de um processo e entrando em uma mem ria indica uma altera o dessa mem ria que pode significar a cria o a altera o ou a elimina o de um ou mais registros Finalmente temos fluxos de dados entre processos Esses fluxos querem dizer apenas que os dados utilizados em um processo s o fornecidos por outro processo por m n o h nenhum compromisso no DFD que isso seja feito dinamicamente Um fluxo desse tipo a priori equivalente ao primeiro processo salvar os dados em uma mem ria e o segundo processo ler dessa mem ria As implementa es podem ser v rias incluindo o primeiro processo ativar o segundo o segundo ativar o primeiro ou os dois serem ativados de forma 90 ER f Nos diagramas particionados isso um ou exclusivo ou seja um fluxo de dados pode partir ou chegar em uma atividade mas n o ambos Nos outros diagramas um fluxo pode indicar a comunica o entre dois processos 237 ass ncrona Devemos notar que n o aparecem fluxos de dados entre processos em DFDs particionados por eventos XII 6 3 Entendendo as Mem rias Na an lise de sistemas fazemos a modelagem de dados simultaneamente a modelagem funcional Isso permite que as mem rias do modelo essencial sejam mod
151. e nessa atualiza o Chega um momento ent o que passa a valer a pena o investimento em moderniza o Outro motivo importante a mudan a de premissas b sicas do neg cio causada pela atua o da firma no mercado Essas mudan as tanto podem de dentro da empresa quanto podem ser provocadas por mudan as na legisla o ou por a o dos concorrentes Por exemplo h alguns anos atr s no Brasil foram feitas v rias modifica es nos sistemas financeiros das empresas para aceitar a mudan a de moedas e o conv vio com moedas diferentes simultaneamente Em outro exemplo com a inven o e grande aceita o dos sistemas de premia o por viagens ou por milhas as companhias a reas tiveram que desenvolver sistemas espec ficos interagindo com seus sistemas de passagens para tratar do assunto Muito comum tamb m a mudan a de uma atividade da empresa seja por um processo cont nuo como o de qualidade total quanto por processos radicais como os de reengenharia e downsizing Os sistemas de informa o tamb m s o importantes por oferecerem as empresas uma capacidade maior de competi o Com a informa o correta e com os processos corretos de tratamento da informa o uma empresa pode ter um diferencial de qualidade no mercado Por outro lado se todo um mercado j adotou um tipo de sistema ou se pelo menos um concorrente j o fez a empresa que n o tem um sistema equivalente fica prejudicada na competi o Esse tipo de efe
152. e op es dispon veis Requisita quantia a ser sacada Fornece dinheiro e recibo 178 IX 4 Tipos de detalhamento Os casos de uso podem ser descritos em diversos n veis de detalhe do mais abstrato e geral at detalhes passo a passo De modo geral podemos considerar tr s n veis de detalhes adequados em fases diferentes do projeto Breve onde usamos apenas uma frase ou par grafo descrevendo o processo principal e t pico Casual onde descrevemos diferentes cen rios mas cada descri o composta por apenas um par grafo Expandido todos os passos e varia es s o detalhadamente descritos incluindo pr condi es e p s condi es de sucesso IX 4 1 Exemplo de caso de uso Breve Caso de uso Alugar Fitas Um cliente solicita a loca o de algumas fitas Ap s identificar se e identificar as fitas ele pode lev las para casa ciente do prazo de devolu o e do valor a ser pago IX 4 2 Exemplo de caso de uso casual Caso de uso Alugar Fitas Um cliente solicita a loca o de algumas fitas Ap s identificar se e identificar as fitas se n o houver problemas no seu cadastro e se as fitas n o estiverem reservadas para outro cliente ele pode lev las para casa ciente do prazo de devolu o e do valor a ser pago IX 4 3 Exemplo de caso de uso expandido Caso de Uso Alugar Fitas Fluxo Principal 1 O cliente chega ao balc o com as fitas que deseja alugar 2 O clien
153. e regras de neg cio Esses m todos podem substituir na sua totalidade o uso de DFDs para modelar a encarna o de um sistema sendo na pr tica mais adequados para o mapeamento do funcionamento real de uma organiza o O s timo cap tulo trata da modelagem conceitual de dados baseado no modelo de entidades e relacionamentos necessidade primordial para uma boa an lise de sistemas O oitavo cap tulo trata da modelagem funcional essencial Juntos esses dois modelos definem o funcionamento esperado do novo sistema Esta edi o apresenta a primeira vers o de um cap tulo sobre Casos de Uso o nono Casos de Uso s o provavelmente a forma mais indicada hoje em dia para levantar requisitos funcionais de uma aplica o Por m o conhecimento da An lise Essencial ainda me parece importante para poder trabalhar com Casos de Uso que s o mais informais Por outro lado j h alguns anos n o vejo projetos usando DFDs e resolvi definitivamente relega los a um ap ndice Esses modelos s o completados com um modelo da interface do sistema preferivelmente na forma de um prot tipo que discutido no capitulo dez Finalmente o cap tulo onze trata de formas de prever o esfor o necess rio para desenvolver um sistema de software usando como fator de determina o os documentos previamente gerados Al m disso apresentamos ao final alguns projetos para os alunos usarem nos exerc cios Recomenda se que os cap tulos sejam apresent
154. e ser clara de forma a permitir uma defini o r pida do seu escopo isto da fronteira que define o que faz parte e o que n o faz parte do sistema Deve tamb m esclarecer a raz o do projeto existir e ser necess rio Alguns objetivos razo veis s o e O Sistema dever controlar a recep o e envio de pacotes pelo setor de cargas e O Sistema permitir o gerenciamento de card pios em uma rede de restaurantes populares definindo pratos e receitas e verificando sua aceita o e O Sistema controlar a entrada e sa da de funcion rios realizando o servi o de ponto e fornecendo dados para a folha de pagamento Em todos esses objetivos podemos at certo ponto que tarefas podem fazer parte e que tarefas n o devem fazer parte do sistema O objetivo deve identificar junto ao cliente de forma mais padronizada poss vel frente ao mercado que tipo de sistema est sendo desenvolvido Ao mesmo tempo deve fornecer informa es suficientes que caracterizem de que forma esse sistema especial Assim um bom objetivo exemplo o seguinte Desenvolver um sistema de controle de vendas para uma loja de materiais de constru o que permita encomenda de mercadorias Nesse exemplo descrevemos o sistema de forma bastante geral e reconhecida no mercado sistema de controle de vendas permitindo uma imediata compreens o do escopo b sico do projeto Logo ap s declaramos que ele deve ser espec fi
155. e um estoque outras vezes s o descritos como documentos que guardam alguma informa o como uma nota fiscal outras vezes s o abstratos como um curso No discurso fluente durante uma entrevista entidades s o geralmente substantivos ocupando o papel de sujeito ou objeto enquanto relacionamentos geralmente s o encontrados na forma de verbo Muitas vezes uma regra de neg cio como alunos cursam turmas ou clientes fazem pedidos nos indica entidades e relacionamentos Outro sinal importante da necessidade de uma entidade o fato de algo que precisa ser lembrado representar um conceito ou id ia completa Em um sistema acad mico precisamos nos lembrar do nome do aluno da data de matr cula do aluno do curso em que est o aluno etc O aluno a nossa id ia completa que aparece v rias vezes algumas vezes caracterizado por seu nome outras vezes por seu curso E um bom candidato a entidade Alguns autores prop em uma determina o bottom up das entidades sugerindo que elas sejam constru das pela parti o de todos os dados at micos que o sistema deve lembrar nome de aluno data de matr cula do aluno etc Assim construir amos uma lista de atributos para depois agrup los em entidades Preferimos por m uma abordagem de busca direta das entidades Um sistema com poucas dezenas de entidades pode ter centenas de atributos o que torna tudo bem mais confuso Segundo Shlaer e Mellor
156. ecem que sistemas complexos se alteram com o tempo usando a itera o do ciclo de desenvolvimento para acompanhar a evolu o do sistema 11 2 2 1 1 Processo Incremental Pode ser visto como combinando o linear com a prototipagem Tem o foco principal na entrega do produto Para realiz lo repetimos a sequ ncia linear em v rios calend rios defasados no tempo Busca implementar funcionalidades essenciais o mais cedo poss vel 23 An lise Projeto An lise Codifica o j Projeto An lise An li TA n lise Testes Codifica o E Ie Projeto Testes its CT Codifica o ificac Codifica o o Urso ia a estes Figura 6 O Ciclo de Vida Incremental 1 2 2 2 Processo Espiral O Processo Espiral se caracteriza pelo desenvolvimento por uma s rie de produtos desenvolvidos em segi ncia cada vez mais complexos e mais pr ximos do produto final desejado Ele se diferencia do Processo incremental porque os produtos de cada ciclo n o s o subsistemas do sistema original mas sim produtos espec ficos que atendem necessidades espec ficas do projeto como por exemplo teste de viabilidade e defini o da interface com o usu rio Em cada ciclo da espiral algumas atividades s o realizadas em ordem sequencial comunica o com o cliente planejamento an lise de riscos engenharia const
157. ecer uma resposta a um problema de neg cio existente como a contrata o de um servi o A partir do prop sito podemos determinar o tipo de contagem S o considerados tr s tipos de contagem e Projeto de Desenvolvimento onde medimos as funcionalidades entregues ao usu rio em uma vers o onde o software desenvolvido desde o in cio Inclui as funcionalidades necess rias para a convers o de dados mesmo que usadas uma nica vez e Projeto de Melhoria onde medimos as modifica es que alteram adicionam ou removem funcionalidades em uma aplica o existente Inclui as funcionalidades necess rias para a convers o de dados mesmo que usadas uma nica vez e Aplica o onde medimos uma aplica o j instalada Tamb m chamada de baseline e normalmente realizada no fim de um projeto de desenvolvimento e mantida atualizada nos projetos de melhoria 216 O escopo da contagem define um conjunto ou um subconjunto do sistema e permite dizer se uma funcionalidade deve ou n o ser contada A fronteira da aplica o delimita o software medido definindo sua interface com o mundo exterior Ela servir n o s para considerarmos se uma fun o deve ou n o ser contada mas tamb m para considerar se um arquivo l gico deve ser contado como interno ou externo a aplica o Definido o tipo de contagem a fronteira e o escopo da contagem que influenciar o a forma final de contagem identificamos as fun es de neg
158. eceu um tratamento especial em muitos m todos o relacionamento parte de Esse relacionamento equivale abstra o de composi o normal que utilizemos esse relacionamento apenas quando a parte s existe em fun o do todo por m n o uma exig ncia muito forte Relacionamentos podem unir indiferentemente entidades do mesmo tipo ou entidades de tipos diferentes Quando relaciona entidades do mesmo tipo dizemos que um auto relacionamento Ao especificar um auto relacionamento devemos ter mais cuidado em declarar os pap is das entidades no relacionamento al m de atentar para n o produzir um loop infinito no relacionamento Normalmente trabalhamos apenas com relacionamentos entre duas entidades O m todo original de Chen permitia relacionamentos m ltiplos Atualmente transformamos relacionamentos m ltiplos em entidades O mesmo acontece com o uso de atributos no relacionamento Apesar do m todo original permitir atualmente criamos uma entidade para representar esse relacionamento 120 Bertini et al B32 mostram algumas opera es que aplicadas a um modelo e r criam diagramas diferentes que podem representar uma mesma realidade Assim algo que foi representado como uma entidade em um modelo pode ser representado como duas em outro ou um relacionamento em um modelo pode ser transformado em uma entidade que se relaciona com as entidades originais ou vice versa sem que haja uma representa o falsa da rea
159. ecida pela an lise essencial na maioria dos casos suficiente para fornecer todo o arcabou o necess rio para uma boa an lise de requisitos Devemos ent o n o s seguir esse princ pio mas tamb m us lo como ferramenta de confer ncia em cada um dos nossos passos verificando se h ou n o comprometimento com uma tecnologia espec fica corrigindo cada ponto onde for encontrado esse comprometimento para uma especifica o tecnologicamente neutra VII 3 3 A Tecnologia Interna Perfeita O sistema deve ser modelado com a suposi o que a tecnologia interna ao sistema perfeita Por tecnologia interna perfeita queremos dizer que todos os recursos do sistema s o ideais A velocidade do sistema perfeito infinita significando que n o h espera para conseguir um resultado A mem ria de um sistema perfeito tamb m n o possui limita es podendo guardar qualquer quantidade de informa o por um per odo indeterminado sem 147 nenhum atraso no tempo de busco O sistema perfeito nunca apresenta falhas ou necessidade de manuten o Devemos por m lembrar que n o fazemos essa suposi o sobre a tecnologia externa ao sistema apenas sobre a tecnologia interna ao sistema Al m disso essa suposi o s feita na fase de an lise sendo esquecida na fase de projeto onde temas como velocidade tamanho de mem ria e ger ncia de riscos passam a fazer parte de nossas preocupa es junto com outras caracter sticas que apesar
160. ecutar uma resposta Essa resposta representada pela atividade essencial correspondente ao evento e produz dois tipos de resultados altera es no estado do sistema e emiss o de informa o para o ambiente altera es do estado do ambiente Uma altera o no estado do sistema significa que uma ou mais mem rias foram alteradas Nisso inclu mos a cria o de registros a mudan a de valores dentro de registros e a elimina o de registros Como emiss o de informa o temos v rias formas de emiss o de relat rios feedback para os agentes externos e comandos para atuadores externos Cada evento pode exigir uma ou mais repostas obrigat rias ou opcionais do sistema O processamento de todas essas respostas juntas a atividade essencial Algumas respostas a eventos s o bvias a partir do nome do evento como por exemplo em Gerente solicita relat rio de vendas Uma resposta bvia relat rio de vendas Por m poder amos em um caso real ter outras respostas como por exemplo aviso ao diretor Logo ap s levantar a lista de eventos importante levantar a lista de respostas para cada evento Apesar de n o ser importante classificar cada resposta recomend vel que o analista saiba se a resposta opcional ou obrigat ria e caso seja opcional estar preparado para fornecer mais tarde as regras que indicam sua necessidade VIIIL9 1 Confundindo eventos e respostas muito comum tamb m que
161. edo o analista evitar que haja desperd cio de recursos pela equipe de desenvolvimento V 10 Construindo um Gloss rio Uma das atividades mais importantes da an lise compreender o dom nio da aplica o Essa compreens o s pode acontecer se o analista souber o significado exato das palavras t picas do neg cio do cliente Assim desde o in cio da an lise o analista deve construir um gloss rio ou seja um dicion rio especializado nos termos do neg cio do cliente N o podemos enfatizar demais a import ncia de aprender a linguagem do neg cio do cliente Isso n o s facilita a comunica o como d ao cliente uma confian a maior no analista V 11 Proposta Comercial Se necess rio a proposta inicial se encerra com os termos comerciais sendo propostos ao cliente incluindo pre o tempo de desenvolvimento formas de cobran as etc E de praxe no mercado apesar de n o recomendado o cliente aceitar uma proposta e dispensar a assinatura de um contrato ou discutir os termos legais do contrato enquanto se inicia o trabalho de an lise V 11 1 Calculando Pre o e Custo Antes de come ar essa discuss o devemos deixar clara a diferen a entre pre o e custo pre o o que cobramos para fazer um sistema custo quanto gastamos para desenvolv lo N o razo vel ensinar como calcular o pre o de um sistema em um curso de an lise pois esse um problema de mercado n o um problema de desenvolvimento de sistemas
162. ee Na Pi f light goes out Pour Coffee N Ni T 1 W A O Figura 44 Exemplo de diagrama de atividades descrevendo em alto n vel o processo de defini o de um plano de moderniza o de software legado segundo a vers o 1 5 do padr o UML mar o de 2003 V1 5 4 Diagramas de Raias Qualquer diagrama que passe a id ia de um fluxo de execu o como um fluxograma ou um diagrama de atividades pode ser constru do dentro de um espa o que modele alguma parti o dessas atividades Normalmente o que se faz utilizar colunas ou linhas para modelar os agentes que realizam a atividade espec fica dando a impress o de raias de nata o ao diagrama swimlanes 94 Empresa Secretaria Comiss o Relator S Receber Documentos Pedido Acerno gt Vertica nte roteras Pedido Recusado oe a r P o Hatitata Mabltados Devolver Documentos Verificar Cansiara Avaliar Asprarte W Carc utata pa S Rec da CanSicataj Araiiar Assa o Aosta Aegista Recusada Aspirante Y v Recusada Atua o Wewa NP pr Emas Cortsicacto Emei Corsficado Aspirante Figura 45 Exemplo de diagrama de atividades com raias VI 6 Regras de Neg cio Uma regra de neg cio uma senten a que define algum aspecto do neg cio Tem o objetivo de afirmar a estrutura do neg cio ou de controlar ou influenc
163. egistrado no sistema Se ele for ator contratado deve ser impresso um aviso para o departamento de pessoal dizendo que ele est alocado na novela Quando um autor envia um cap tulo com resumo o sistema deve cadastrar esse cap tulo e produzir uma c pia para cada ator e diretor da novela Toda segunda feira o sistema deve emitir c pias para a imprensa dos 6 resumos dos cap tulos da semana No final do m s dia 25 o sistema deve gerar para a pagadoria uma listagem dos atores horistas que devem ser pagos Para isso dia 15 deve ser enviado um formul rio aos diretores com o nome de todos os atores horistas associados novela com um espa o para marcar Os diretores devem devolver esses relat rios preenchidos com o registro de horas trabalhadas por ator horista que s o registrados no sistema Se dia 23 existir um diretor que n o devolveu o relat rio deve ser enviada uma carta de notifica o ao diretor Lista de Eventos e Operador Cadastra Diretor custodial externo n o esperado e Operador Cadastra Novela custodial externo n o esperado e Operador Cadastra Ator custodial externo n o esperado e Autor Envia Cap tulo composto externo n o esperado na pr tica deveria ser esperado mas n o assim que foi descrito e E dia de enviar formul rio composto temporal e Diretor envia formul rio preenchido composto externo esperado tem um n o evento e E dia de enviar carta de notifica o ao d
164. elaciona termos em lt termo1 gt um lt termo2 gt observa es relevantes ao neg cio lt termo1 gt lt verbo gt lt termo 2 gt e Relacionamentos entre lt termot gt composto de lt termo2 gt entidades E lt termo1 gt um papel de lt termo2 gt A Relacionamentos onire lt termo1 gt tem a propriedade lt termo2 gt entidades e atributos prop Relacionamentos de heran a Computa o Senten a fornecendo um algoritmo para lt termo gt calculado como lt formula gt calcular o valor de um termo Restri o Senten a que indica restri es que lt termol gt deve ter lt no m nimo no m ximo obrigat ria devem ser verdade em informa es exatamente n gt lt termo2 gt fornecidas ao sistema input lt termo1 gt deve ser lt compara o gt lt termo2 gt ou lt valor gt ou lt lista de valores gt lt termo gt deve ser um de lt lista de valores gt lt termo gt n o pode star em lt lista de valores gt se lt regra gt ent o lt restri o gt Guideline Senten a que indica restri es que lt termol gt deveria ter lt no m nimo no m ximo exatamente n gt lt termo2 gt lt termo1 gt deveria ser lt compara o gt lt termo2 gt ou lt valor gt ou lt lista de valores gt lt termo gt deveria ser um de lt lista de valores gt lt termo gt n o poderia star em lt lista de valores gt se lt regra gt ent o lt restri o gt se lt termo1 gt lt operador gt lt termo2 valor
165. eladas diretamente nas entidades do modelo de entidades e relacionamentos uma das t cnicas recomendadas originalmente e a mais adequada para o desenvolvimento de sistemas na atualidade Ao definir as mem rias utilizamos uma regra simples toda a entidade do modelo de dados utilizada pelo processo deve ser tocada por uma seta Se a seta estiver indo do processo para a mem ria dizemos que h uma altera o dessa mem ria pela adi o exclus o ou altera o de um ou mais registros Se a seta estiver vindo da mem ria para o processo ent o dizemos que est acontecendo uma leitura na mem ria ou uma busca por m fica claro que seu conte do n o modificado E razo vel tanto utilizar como mem rias as entidades ainda n o normalizadas na terceira forma normal modelo conceitual tradicional quanto s normalizadas XI1 6 4 Tipos de DFD Em um DFD de Contexto todo o sistema representado por apenas um processo N o aparecem mem rias internas ao sistema em um DFD de Contexto apenas agentes externos e segundo alguns autores mem rias que pertencem a outros sistemas e que s o utilizadas pelo sistema sendo descrito Geralmente o DFD de Contexto o primeiro diagrama de um DFD nivelado O processo que aparece nesse diagrama geralmente tem o nome do sistema sendo implementado O DFD de contexto pode ser criado imediatamente a partir do dicion rio de eventos ou da lista de eventos e respostas Um DFD Nivelado ou Hier rquico
166. elo menos em que ordem as coisas devem ser feitas A primeira t cnica dispon vel associar a cada requisito do sistema uma import ncia Uma escala de tr s ou cinco valores adequada para isso como em Imprescind vel para o sucesso do sistema Funcionalidade Importante mas podemos esperar algum tempo Ajudaria ter mas poss vel viver sem essa funcionalidade Benef cios m nimos Desnecess rio A segunda t cnica dispon vel planejar o sistema para ser entregue em v rias vers es mesmo que nem todas as vers es estejam inclu das nesse contrato e pedir para o cliente determinar que funcionalidades devem aparecer em cada vers o Nesse caso pode ser 41 interessante dar um peso ou custo para cada requisito de modo que o cliente possa controlar seus gastos Uma terceira t cnica dispon vel dar uma moeda virtual para o cliente por exemplo 1000 dinheiros e pedir para ele distribuir quanto pagaria por cada fun o priorizando no desenvolvimento aquelas fun es que o cliente decidir pagar mais Todas essas t cnicas por m ficam dependentes de uma outra prioriza o importante dos requisitos a prioriza o por depend ncia Devem ser levados em conta os v rios fatores que influenciam nessa determina o de prioridades entre eles os citados por B13 e Diminuir o custo da implementa o e Valor para o comprador e Tempo para implementar e Facilidade t cnica de impl
167. elo nosso modelo afinal eles conhecem seu neg cio e n o precisam de um m todo como o nosso onde as limita es t m como objetivo clarificar a compreens o do sistema pelo analista Assim muitas vezes um entrevistado descreve o sistema como se fosse uma entidade m gica outros descrevem o sistema como se fizessem parte dele outros descrevem apenas as sa das do sistema etc Devemos estar preparados para isso e garantir uma modelagem condizente com o modelo essencial que atenda todos os pedidos do usu rio Devemos tamb m fazer sutilmente o usu rio compreender a nossa forma essencial de descrever os eventos Muitos usu rios entendem facilmente o conceito de eventos quando traduzidos para portugu s mais simples como entrada de dados e entrada de comandos As perspectivas b sicas que encontramos em entrevistas e reuni es s o as seguintes e Entrevistado omnisciente descreve o sistema como o sistema indicando coisas que ele deve fazer V tanto o sistema como os seus usu rios de uma perspectiva externa aparentemente conhecendo os mecanismos tanto por dentro quanto por fora Normalmente a posi o da alta ger ncia e de quem contratou o sistema comum que n o conhe a os procedimentos internos do sistema como acontecem realmente mas apenas de forma geral ou como aconteciam no passado Exige funcionalidade do sistema principalmente para atender o n vel gerencial e Entrevistado usu rio des
168. em 2000 Os dados do COCOMO 381 por m foram reaproveitados com as metodologias do COCOMO T1I 2000 para nos fornecer valores provis rios com que trabalhar Para um processo seguindo o modelo em Cascata os seguintes resultados s o esperados Fase Esfor o Tempo 7 2 15 16 24 2 30 17 24 28 64 52 56 40 27 23 Planos e Requisitos Projeto do Produto Programa o Programa o Projeto Detalhado Programa o codifica o e 37 29 Teste de unidade 19 31 20 32 12 0 20 12 5 0 20 Integra o e Testes Transi o Tabela 31 Divis o do esfor o nas fases de desenvolvimento do software segundo Boehm 215 XI 6 An lise de Pontos de Fun o Uma das mais importantes informa es que podemos ter sobre um produto de software o esfor o necess rio para desenvolv lo Usualmente definimos este esfor o pela quantidade de homens hora ou homens m s necess rios para desenvolver o produto A principal utiliza o desta informa o tem como objetivo prever e acompanhar o esfor o que ser gasto no desenvolvimento de um produto de porte semelhante Por m como saber qual o porte de um produto de software Para isso foram inventadas v rias medidas algumas delas arbitr rias outras f ceis de medir E comum que digamos o tamanho de um software pela quantidade de linhas de c digo pelo n mero de horas gasto para desenvolv lo ou pelo custo final do mesmo Por m at 1979 n o t nhamos uma bo
169. ema ou o problema mais importante Faz pouco sentido construir um sistema se o verdadeiro problema de neg cios n o for endere ado pela solu o planejada Para analisar o problema necess rio que os usu rios e Concordem com a defini o do problema e Entendam as causas do problema 35 o O problema por tr s do problema pode ser mais importante sendo que o problema visto inicialmente apenas um sintoma Identificem todos os stakeholders e usu rios e Definam a fronteira do sistema de solu o Identifiquem as restri es impostas solu o Para estabelecer o problema interessante criar uma senten a apropriada como a seguinte e O problema de lt descri o do problema gt afeta stakeholders afetados gt e resulta em lt impacto nos stakeholders gt A solu o lt indicar a solu o gt Trar os benef cios de lt lista dos principais benef cios gt Um sistema pequeno certamente produzir a solu o para uma pequena quantidade de problemas um sistema grande certamente atingir uma grande quantidade de problemas O ponto em quest o que deve existir alguma n o conformidade seja ela atual ou futura para valer a pena o investimento e o risco de tentar um sistema novo IV 5 Tipos de Requisitos IV 5 1 Requisitos Funcionais e de Informa o Uma maneira de dividir os requisitos do sistema separ los entre requisitos funcionais e n o funcionais Um requisito funcional r
170. ementar e Facilidade do neg cio para implementar e Valor para o neg cio e Obriga o por alguma autoridade externa IV 7 4 Questionando os requisitos Em v rios momentos do projeto importante tratar a lista de requisitos como uma lista a ser abertamente questionada Para isso devemos analisar as caracter sticas desejadas dos requisitos Se o IV 1 1 e verificar para cada requisito se elas s o verdade Al m disso devemos tamb m analisar de que forma os requisitos respondem as perguntas 5W2H Who When Where What Which How How much Se o requisito passar por todos os questionamentos temos um requisito muito bom Se falhar em alguns pode ser que n o seja o momento ainda no projeto ou que a pergunta n o seja pertinente por m deve ser analisado cada caso Os maiores problemas sempre ser o encontrados na ambigiiidade dos requisitos Qualquer ambigiiidade um risco por m no in cio do projeto a ambigiiidade necess ria pois decis es importantes ainda n o foram tomadas Cabe ao analista saber em que p est o projeto e qual o n vel de detalhe adequado aos requisitos IV 8 M todos de Elicita o de Requisitos A elicita o de requisitos o levantamento registro e valida o B14 das expectativas dos diversos interessados no sistema seguido da consolida o e valida o dessas expectativas em requisitos formais Contemplar essas diferentes vis es implica projetar interesses divergentes e conci
171. enciais Na modelagem essencial tudo ocorre em fun o de eventos Isso acontece porque imaginamos que o sistema possui dois estados em atividade ou esperando um evento o acontecimento do evento que faz com que o sistema entre em funcionamento e ent o realize todas as tarefas necess rias para atender aquele evento ou seja a atividade essencial correspondente ao evento E importante notar que o sistema s tem a oportunidade de funcionar quando acontece um evento Esses eventos por defini o n o s o control veis pelo sistema ou seja o sistema incapaz de gerar um evento Cada atividade iniciada com um nico evento que define um est mulo e compreende todo o conjunto de a es efetuado pelo sistema para executar a atividade ou seja a resposta planejada A atividade relativa a um evento compreende toda a cadeia de a es causada por esse evento at que o sistema tenha que parar porque todos os fluxos de dados atingiram seus objetivos agentes ou mem rias Como apenas um evento inicia a atividade ent o apenas um nico agente externo pode enviar informa es para uma atividade Isso uma regra importante da an lise essencial pois indica como o sistema ser particionado O evento funciona como um gatilho disparando uma rea o em cadeia que para apenas pela impossibilidade de realizar qualquer outra atividade Nessa rea o em cadeia n o devemos nos preocupar no modo como as a es ocorrem no sistema
172. endizado Para verificar como a modelagem de dados pode ser usada junto com a an lise essencial recomendamos o livro Complete System Analysis de James e Suzanne Robertson B34 um dos melhores livros de an lise no mercado contando com um longo exemplo completo e exerc cios Dois outros autores brasileiros trataram desse assunto Pompilho B37 e Barbieri B38 Para uma abordagem mais pr tica considerando desde o in cio alguns fatores tecnol gicos o livro de Ruble Practical Analysis amp Design for Cliente Server and GUI Systems B39 bastante til 144 Cap tulo VIII Modelo Funcional Essencial Modelagem Estruturada Modelagem Essencial Atividades Essenciais Eventos Essenciais Externo Temporal N o Evento Esperado N o esperado Mem ria Essencial 2949 O Modelo Funcional tem como objetivo definir o que o sistema deve fazer ou seja as fun es que deve realizar para atender seus usu rios Na An lise Essencial fazemos essa defini o de acordo com um conjunto de princ pios que nos permite escolher um modelo funcional espec fico entre v rios poss veis o Modelo Essencial VIII 1 Perspectiva Hist rica A modelagem funcional de sistemas teve grande desenvolvimento a partir da cria o das metodologias estruturadas de an lise e projeto Entre diferentes propostas a An lise Estruturada foi a que teve maior repercuss o sendo que o Diagrama de Fluxo de Dados DFD se tor
173. ente pois elas podem ser dubladas ou legendadas As fitas s o emprestadas para clientes em um dia e hora espec fico Um cliente pode ficar com v rias fitas ou nenhuma Uma fita pode estar com apenas um cliente ou estar na loja e n o estar com cliente nenhum importante saber para quem cada fita espec fica foi emprestada para auditar clientes que estragam fitas por isso todas as fitas s o numeradas com um c digo nico Os filmes s o dirigidos por diretores e cont m atores Observamos que o cliente um papel assumido por uma pessoa a fita de v deo um objeto f sico existente o filme uma obra de arte que est representada na fita um conceito diretor e ator s o tamb m pap is assumidos por pessoas dentro da id ia de filme e que um aluguel um contrato entre o cliente e a locadora Aten o para outro detalhe n o existe a entidade locadora pois este sistema destinado a uma s locadora Seria uma entidade nica que claramente uma constante do sistema A presen a de entidades desse tipo um erro comum nos modelos feitos por principiantes Por m se tiv ssemos um software para uma rede de locadoras seria interessante guardar em que locadora est cada fita o que exigiria essa entidade Oki A Er Figura 68 Modelo inicial da locadora nota o Information Engineering software ERWIN 3 5 131 Fita Aluguel Cliente HH C digo fita HH C
174. ente externo que envia o est mulo e Transportador i e quem inserir os dados no sistema e Dados presentes no est mulo descritos segundo alguma linguagem de dicion rio de dados como a descrita nesse texto e Atividade descri o sucinta da atividade por meio de alguma linguagem Possivelmente uma descri o algor tmica em portugu s estruturado ou como uma sequ ncia de passos Uma solu o interessante e descrever a atividade de acordo com suas pr condi es e p s condi es possivelmente em uma linguagem formal como VDM ou Z e Informa o emitida na atividade efeito da atividade no ambiente descri o de cada sa da do sistema de acordo com uma linguagem de dicion rio de dados ou equivalente e Efeito da atividade no sistema descri o em linguagem natural ou em outra linguagem das modifica es que ocorrem no estado global do sistema ou com entidades espec ficas com a execu o da atividade Efeitos colaterais das atividades s o descritos aqui Por exemplo a atividade pode cadastrar um cliente na lista de clientes inadimplentes um efeito seria o cliente est proibido de realizar outros gastos na empresa e Tempo limites de tempo do evento ligado aos eventos esperados quando devem acontecer e Lista de entidades utilizadas tiradas do modelo conceitual de dados ou Matriz CRUD Esse texto acompanhado de um software que permite a cria o de um dicion rio de eventos Na figura a seguir apresen
175. ente o que fizemos foi o que estava escrito na especifica o do programa A tarefa mais importante na verdade a valida o j que devemos atender o cliente A valida o por m geralmente mais informal e mais custosa que a verifica o Assim verificando que cada passo dado durante o processo de desenvolvimento esta conforme o passo anterior previu podemos economizar na valida o 21 11 2 2 Modelos de Processo mais Comuns 1 2 2 1 Processo em Cascata Tamb m conhecido como Linear Seqiiencial Nesse processo assumimos que as atividades de an lise projeto e implementa o podem ser feitas de forma sequencial sem que sejam necess rias intera es entre as fases Um processo em cascata t pico contaria com as seguintes fases 1 Modelagem do Sistema onde s o estabelecidos os requisitos do sistema do qual o software sendo realizado participa incluindo os requisitos de informa o e de neg cios 2 An lise de Requisitos onde s o modelados os requisitos de informa o funcionais comportamentais de desempenho e de interface do software 3 Projeto onde s o planejadas as estruturas de dados a arquitetura do sistema e o comportamento mapeado em procedimentos 4 Codifica o onde o projeto transformado em uma linguagem intelig vel pelo computador 5 Testes onde verificamos e validamos o software 6 Manuten o onde garantimos a usabilidade do software Defendido inicialmente como a fo
176. ento amplo e bem fundamentado resultante da an lise e combina o de v rios informes Cole o de fatos ou de outros dados fornecidos m quina a fim de se objetivar um processamento ou ainda Segundo a teoria da informa o medida da redu o da incerteza sobre um determinado estado de coisas por interm dio de uma mensagem Apesar de n o estarmos diretamente envolvidos com a teoria da informa o n o podemos de deixar de notar a import ncia da defini o que diz que a informa o reduz a incerteza por meio de uma mensagem Estamos interessados em criar uma diferencia o entre dados informa o e conhecimento mesmo que as palavras possam ser consideradas sin nimas em muitos contextos Apesar de serem normalmente confundidas ou utilizadas de forma intercambi vel elas podem ser mais bem entendidas e utilizadas se analisadas como representando conceitos diferentes Dados s o apenas os s mbolos que usamos para representar a informa o o registro de diferentes aspectos de um fato ou fen meno Os n meros que guardamos em um banco de dados s o como diz o nome dados Dados n o s o interpretados eles existem s o adquiridos de alguma forma via coleta pesquisa ou cria o guardados de outra forma e possivelmente apresentados em uma terceira O computador uma m quina que manipula dados Por outro lado informa o o dado com significado normalmente processado de forma a ser til Uma
177. eordena ou reorganiza um conjunto de dados P P P Tabela 32 Tipo de Fun o Transacional e l gica de processamento correspondente P poss vel O obrigat rio N N o permitido O obrigat rio alternativo Em especial por obrigat rio alternativo queremos dizer que uma das l gicas linhas deve estar presentes para caracterizar uma entrada externa ou sa da externa na coluna EE Entrada Externa SE Sa da Externa CE Consulta Externa X1 6 4 Identificando Arquivos Internos Arquivos representam um grupamento l gico requerido pelo usu rio Podem incluir uma ou mais tabelas ou entidades Esse uma das partes mais dif ceis da contagem de pontos de fun o pois devemos separar o que o usu rio pensa do modelo que criamos Nosso modelo muitas vezes usa v rios grupos de dados ou tabelas ou entidades para modelar algo que o usu rio v como um conceito nico Mesmo na modelagem conceitual a tend ncia do analista incluir entidades que o usu rio n o v naturalmente Um Tipo de Elemento de Registro RET Record Element Type um subgrupo de elementos de dados dentro de um arquivo ou interface Na pr tica em um modelo de dados um arquivo do usu rio ILF composto de um ou mais objetos do modelo Outra caracter stica dif cil de contar que cada forma de acesso a um arquivo l gico conta novamente Assim por exemplo se o usu rio exige acessar um autom vel tanto por sua placa quanto por seu n
178. epresenta algo que o sistema deve fazer ou seja uma fun o esperada do sistema que agregue algum valor a seus usu rios Exemplos t picos incluem a emiss o de relat rios e a realiza o e manuten o de cadastros Como veremos mais tarde os eventos essenciais definem todos os requisitos funcionais do sistema dado que a fun o dele responder a todos os eventos Apesar de n o ser f cil levantar corretamente os requisitos funcionais a metodologia essencial fornece um arcabou o eficiente para essa tarefa que perfeitamente adequado para sistemas de informa o Requisitos de Informa o representam a informa o que o cliente deseja obter do sistema Requisitos de informa o tamb m s o atendidos por eventos Muitas vezes o cliente expressa requisitos de informa o de forma funcional Outras vezes o cliente est preocupado em conseguir uma informa o mas n o sabe como faz lo na forma de um requisito funcional Em todo caso sempre nos preocuparemos em levantar todos os requisitos de informa o pois eles representam as respostas fundamentais do sistema IV 5 2 Requisitos n o funcionais Requisitos n o funcionais falam da forma como os requisitos funcionais devem ser alcan ados Eles definem propriedades e restri es do sistema Muitos requisitos n o funcionais s o tamb m requisitos de qualidade como exig ncias de desempenho e robustez Outros s o restri es ou exig ncias de uso de uma ou outra tecnologia
179. equipe democr tica todos falam com todos A forma mais tradicional de organizar uma equipe a forma hier rquica baseada nas teorias cl ssicas de administra o que por sua vez s o baseadas na forma de organiza o do Ex rcito e da Igreja 26 Na equipe hier rquica temos um ou mais n veis de ger ncia Cabe a ger ncia controlar o funcionamento do projeto Os n veis mais baixos s o respons veis pela execu o do projeto A equipe hier rquica boa para manter regras e padr es sendo uma escolha boa para projetos repetidos e que exigem grande estrutura Muitas empresas utilizam esse tipo de organiza o por m ele considerado fraco para o desenvolvimento de software novo pois a estrutura co be a criatividade Em rela o ao uso dos profissionais podemos indicar um defeito importante o profissional de desenvolvimento experiente transformado em gerente e tira a m o da massa Muitas vezes inclusive ele transformado em um mau gerente e quai O MM MA O COMO Figura 11 Em uma equipe hier rquica diminuem se as linhas de comunica o Brooks B7 prop e uma equipe conhecida como Equipe do Programador Chefe Nesse tipo de equipe o desenvolvedor vai recebendo cada vez mais responsabilidade em rela o ao desenvolvimento mas n o em rela o tarefa di ria de administra o que tratada a parte Cada programador chefe respons vel por parte do projeto e delega tarefas aos pr
180. ernativa determinar cen rios de pior caso caso mais prov vel e de melhor caso O valor final da estimativa dado por _ Vpc 4 Vemp Vmc 6 Equa o 5 C lculo do valor estimado Ve em fun o do valor de pior caso Vpc valor do caso mais prov vel Vcmp e do valor do melhor caso Vmo Ve 8 Ou Delphi Baseado no Or culo de Delfos nica rela o direta com a linguagem Delphi 221 X1 8 3 T cnicas baseadas em Pontos de Fun o Uma das formas de usar pontos de fun o para a estimativa de tamanho do sistema conhecida como contagem indicativa e foi proposta pela NESMA Netherlands Software Metrics Users Association Ela consiste em contar apenas os Arquivos de Interface Externa e os Arquivos L gicos Internos Consideram se 35 pontos por cada AIE e 15 pontos para cada AIL J o ISBSG International Software Benchmarking Standards Group prop e acelerar a contagem de pontos de fun o com o uso de valores m dios para projetos de desenvolvimento segundo a tabela a seguir Tipo de Fun o PFs m dios PFs m dios IBSBG NESMA Arquivo L gico Interno 7 4 7 Arquivo de Interface Externa 5 5 5 Entrada Externas 4 3 4 Sa da Externa 5 4 5 Consulta Externa 3 8 4 Tabela 40 Valores m dios recomendados pelo IBSBG e pela NESMA para contagem estimativa de Pontos de Fun o Outra forma poss vel a analogia com sistemas semelhantes com poss vel aplica o do m todo Delphi
181. erno ao ambiente de uso do sistema Nesse caso o agente externo nomeado com o nome desse departamento ou da institui o ou ainda do tipo da institui o Finalmente existem os agentes externos que s o m quinas como sensores ou sistemas sendo nomeados diretamente com o nome dos mesmos importante perceber que muitos agentes devem ser representados n o s fora do sistema mas tamb m em sua mem ria Isso acontece quando o sistema deve guardar dados sobre um agente externo de forma a poder reconhecer ou referenciar um agente externo por exemplo enviando uma conta para o agente externo Nesse caso haver pelo menos uma entidade no modelo de dados representando no total ou parcialmente o agente externo Isso n o se aplica por m no caso da seguran a pois essa n o tratada na an lise essencial Como exemplo podemos ver o caso de um sistema acad mico onde os alunos s o agentes externos pois solicitam boletins e s o entidades pois devemos guardar dados sobre os alunos J os funcion rios da secretaria da escola s o agentes externos pois podem pedir alguns documentos espec ficos guardados no sistema mas o sistema n o precisa saber quem s o 56 PA ya Atualmente f cil entender como o vendedor pode ser substitu do por uma interface Web e o sistema manter sua ess ncia 57 PEER gt 4 A modelagem essencial n o est preocupada com quest es como seguran a backup etc 151 VIII 6 Eventos Ess
182. es Isso acontece porque uma atividade por defini o n o pode ficar esperando por uma entrada de dados A regra que usamos se o sistema para s pode voltar a funcionar com um evento O mesmo racioc nio se aplica quando falamos de v rios agentes externos Segundo a an lise essencial n o existem eventos internos ao sistema isto n o dizemos que um processo do sistema se inicia por causa de um evento causado por outro processo A an lise essencial parte do conceito que eventos iniciam atividades essenciais e que essas atividades s o executadas at que todas as respostas necess rias sejam geradas O sistema ent o para e fica esperando pelo acontecimento de outro evento de essencial para voltar a funcionar Devemos ter bastante aten o regra que uma atividade cont m a resposta completa para um evento e apenas para um nico evento pois ela que vai definir o particionamento do sistema sendo modelado Outra caracter stica da an lise essencial que os eventos s o vistos por dentro do sistema Assim eles s o descritos tendo como sujeito o agente externo que os iniciam como em Aluno solicita matr cula Recapitulando os eventos acontecem fora do sistema correspondem a um est mulo que cruza a fronteira do sistema de fora para dentro e s o vistos e descritos na perspectiva de um ser imagin rio que habita sistema Tamb m importante frisar que atividades essenciais n o se comunicam diretamente is
183. es s o representadas por caixas que s o conectadas uma s outras por meio de setas com significados distintos representado dados ou objetos relacionados a cada fun o como na Figura 25 Todas as caixas e conectores s o rotulados sendo que um dicion rio deve ser usado para definir detalhadamente cada r tulo Todas as caixas devem tamb m receber um n mero no canto inferior direito Diagramas IDEFO s o constru dos de forma hier rquica a partir de um diagrama inicial chamado A 0 A menos zero que sempre cont m uma nica atividade numerada 0 2 Algumas imagens dessa se o n o s o originais por m fazem parte de um documento IFIP 183 em dom nio p blico obra do governo americano 2 A metodologia IDEFO derivada de uma metodologia anterior conhecida como SADT 21 DECR dos ds z4 O processo inicial sempre o A 0 n o existindo um processo B 0 em nenhum caso A letra A vem de atividade 74 a partir do qual s o feitos detalhamentos sucessivos Cada detalhamento representado por outro diagrama contendo atividades interligadas permitindo uma compreens o top down do processo sendo descrito O m todo limita o n mero de subfun es para uma fun o entre 3 e 6 O m todo IDEFO n o representa a segii ncia de atividades no tempo apenas as intera es entre as atividades Ele pode ser usado tanto para representar processos j existentes quanto para representar processos novos No primeiro
184. esso Cria Read ou L Update ou Altera ou Delete ou Apaga um registro No caso da modelagem essencial esta tabela se torna muito interessantes pois permite relacionar facilmente os eventos essenciais com as entidades do modelo ER Mais tarde se necess rio na fase de projeto essa tabela pode ser reconstru da utilizando os processos sendo implementados e as tabelas do banco de dados 161 Entidades Eventos ou Atividades Tabela 23 A Matriz CRUD do sistema da Rede Bobo de Televis o VIII 10 2 Verificando a consist ncia Um dos principais usos da Matriz CRUD verificar a consist ncia do modelo obrigat rio que cada entidade seja criada e lida por algum evento Com a Matriz CRUD essa verifica o muito f cil basta checar se todas as colunas possuem ao menos um C e um R Al m disso interessante mas n o obrigat rio que as entidades tamb m possam ser alteradas e apagadas Assim para cada coluna onde n o h nenhum C ou R devemos imediatamente questionar a necessidade da entidade ou buscar eventos que as justifiquem junto ao usu rio Do mesmo jeito para cada coluna sem U ou D devemos verificar se essa entidade foi tratada de forma completa em rela o aos desejos do usu rio Existe uma exce o obrigatoriedade de leitura de uma entidade que quando ela est sendo criada para guardar dados que s ser o utilizados em uma vers o futura do sistema VII1 10 3 Ma
185. essos em DFD Global buscamos apenas uma forma de organizar o DFD que facilite sua leitura e compreens o E Entidades E Entidades N lt 0 o Ko Ko Lo bo B Ke c wW W Entidade 5 Entidade 6 Entidade 2 Entidade 1 Entidade 2 Entidade 3 Entidade 4 Entidade 5 Entidade 6 Posi o inicial Passo 1 Posi o ap s troca da posi o da coluna Coluna Entidade 2 ser trocada de posi o Linha Processo E ser trocada de posi o Entidade 2 Entidade 3 Entidade 4 Entidade 5 Entidade 6 Entidade 3 Entidade 4 Entidade 5 Entidade 6 O Z O Entidade 1 D Passo 2 Posi o ap s troca da posi o da linha Passo 3 Posi o ap s troca da posi o da linha Linha Processo C ser trocada de posi o Posi o final com subsistemas marcardos Figura 83 Exemplo da manipula o de uma Matriz CRUD em busca de encontrar subsistemas VII 10 4 Extens es da Matriz CRUD poss vel estender a Matriz CRUD para incluir outros conceitos Uma id ia transform la em uma Matriz CRUDL onde L significa Listar List claro que para listar precisamos ler mas isso faz uma diferencia o entre consultas que retornam muitos registros e que possivelmente retornam apenas parte desses registros e consultas que retornam um registro inteiro Sulaiman et al prop e a cria o originalmente em modelos onde se est fazendo a an lise reversa de uma aplica o em opera o da cria o de Cubos CRUD
186. estimativa UC3 Pedir Livro 0 1 Colecionador envia um pedido 1 Colecionador envia Fax 2 Colecionador envia Carta 3 Colecionador faz Liga o inclu do 2 Vendedor recebe o Pedido 3 Vendedor envia estimativa ao Colecionador UC5 Preparar Estimativa UCs Preparar Estimativa AA O Vendedor cria uma Estimativa AA 1 O Vendedor repete os seguintes Os seguintes passos s o repetidos passos O Sistema oferece O Vendedor indica um Livro O Vendedor na O Sistema lista Livros do O Sistema lista Livros do Cat logo O Vendedor adicion i imati Completo O Sistema a Livro O Vendedor escolhe um Livro O Vendedor indica o pre o do Livro O Vendedor indica o pre o do Livro O Vendedor fecha a Estimativa 2 O Vendedor fecha a Estimativa O Sistema calcula os valores totais e impostos a n O Sistema imprime a Estimativa 3 O Sistema imprime a Estimativa 27 Bibliography 1 A Cockburn Writing Effective Use Cases Addison Wesley 2001 196 Cap tulo X Modelo de Interface Muitos autores consideram que a modelagem da interface com o usu rio uma a o caracter stica da fase de projeto de um sistema Por m a pr tica de desenvolvimento de sistemas mostra que o usu rio s tem uma verdadeira vis o da funcionalidade do sistema quando pode ter alguma amostra do seu funcionamento Sem essa vis o muito dif cil para o usu rio validar uma a
187. etada desenvolvida e suportada para funcionar em locais diferentes em diferentes organiza es A aplica o foi especialmente projetada desenvolvida e suportada para facilitar mudan as 223 X1 6 8 C lculo dos Pfs Finais Os PF s o calculados em etapas contam se os n meros de entradas sa das consultas arquivos e interfaces do sistema Para cada entrada se determina um grau de complexidade de acordo com as tabelas complexidade da fun o Tabela 33 at Tabela 37 e somando os resultados Tabela 38 se obt m a contagem b sica de pontos de fun o responde se a uma s rie de perguntas as quais fornecem cada uma um valor de O a 5 p O lt i lt s calcula se o n mero de pontos de fun o com a equa o PF total de 2 x 0 65 0 01 x X pj Devemos notar que se o c lculo de PF for usado para fazer previs es seguindo o m todo COCOMO apenas a contagem b sica necess ria s devem ser feitos os passos 1 e 2 224 Contagem Total passo 1 Sa das Externas 4 Consultas Externas a E EA Be E E EEA Arquivos de Interface 10 Externos ma o Tabela 38 Guia de c lculo para os pontos de fun o Primeiro deve ser feita a contagem total por tipo de fun o Para cada item contado deve ent o ser determinada a complexidade o que permitir encontrar o total que o total de 2 Complexa X1 6 9 Contando PFs na An lise S o tr s as principais informa es que temos
188. existente na encarna o atual pois elas podem sofrer interrup es esp rias que dividem um evento entre v rios processadores OJU9Ad Po f Sistema em Funcionamento am Figura 80 O esquema mostra como o sistema reage a um evento Um Sistema parado s pode come ar a funcionar ao receber um evento A partir desse evento realiza uma s rie de processamentos que podem envolver sa das para o mundo externo at parar novamente N o podem existir outros eventos ou entradas do mundo externo durante o funcionamento por m poss vel consultar as mem rias que s o internas ao sistema Sistema Parado Sistema Parado Tempo Muitas vezes o iniciante na an lise essencial imagina que ser travado um di logo com o usu rio durante a atividade Esse di logo interno a uma atividade n o existe na an lise essencial O est mulo relacionado ao evento isto o fluxo de dados que parte do agente 58 rx E E N o existem logo eventos essenciais internos ao sistema 59 a 2i x Yourdon n o obedece essa regra permitindo que algumas entidades externas forne am informa es sob demanda de uma atividade essencial 152 externo em dire o atividade possui toda a informa o necess ria para realizar a atividade incluindo partes opcionais Caso o di logo seja realmente necess rio para o funcionamento do sistema ent o temos na verdade dois ou mais eventos e suas respectivas atividad
189. ey can t see the problem Chesterton G K 1874 1936 in The Point of a Pin in The Scandal of Father Brown Objetivo Problemas Oportunidades Metas M tricas Requisitos Iniciais Descri o Sucinta do Sistema Atual Restri es Proposta Inicial V 1 O Primeiro Contato e Os Primeiros Resultados Quando vamos iniciar o desenvolvimento de um sistema somos em geral convidados por um cliente em potencial para conhecer seus problemas seus desejos e propor uma solu o Essa uma fase muito dif cil para o desenvolvedor pois precisa tomar muitas decis es com poucas informa es Algumas vezes obrigado a fornecer uma proposta de trabalho incluindo previs o de custos ou pre o a partir de uma entrevista curta Essa situa o est muito longe da ideal onde s ter amos que fornecer uma proposta de trabalho ap s saber exatamente o que ser preciso fazer Outro problema para o desenvolvedor que esta uma fase de investimento Entre v rias propostas apresentadas apenas algumas ser o aceitas O tempo gasto nas propostas n o aceitas um custo a mais a ser dividido por todos os projetos aceitos Esta fase inicial de negocia es deve ter um objetivo desenvolver um documento chamado Proposta Inicial A proposta inicial o primeiro passo para atingir a proposta de desenvolvimento e pode ser mantida como documento interno se o cliente n o exigir uma proposta imediatamente O objetivo dess
190. foram pr ticas apresentando problemas para serem analisados e modelados e com consulta Neste livro seguindo a an lise essencial estamos interessados em sistemas de informa o que produzem respostas planejadas isto que executam a es pr programadas em fun o de mudan as reconhec veis e previs veis no ambiente externo Chamamos essas mudan as no estado do ambiente de eventos essenciais N o estamos interessados em respostas ad hoc isto respostas que tem que ser praticamente inventadas caso a caso mas sim em eventos que podem ser previstos e para os quais podemos programar respostas em um computador digital E importante deixar claro que a an lise essencial unificada com o modelo de entidades e relacionamento uma ferramenta de grande qualidade para o desenvolvimento de sistemas de informa o Quando um cliente solicita um sistema de informa o pensa em automa o de algum processo na moderniza o de um processo j automatizado ou na cria o de um novo processo em sua empresa O cliente ent o imagina um sistema que executa algumas fun es gerencia alguns dados e fornece alguns relat rios Esse sistema imaginado pelo cliente por m raramente descreve de forma clara o que ele realmente precisa ou que precisar no dia que o sistema ficar pronto Cabe ao analista ajudar ao cliente a descobrir como o sistema realmente necess rio O segundo cap tulo faz uma pequena introdu o aos Sistemas de In
191. forma o principalmente aqueles que encontramos dentro de organiza es O terceiro cap tulo discute o desenvolvimento de software Ambos os cap tulos s o introdut rios e t m como finalidade nivelar conhecimento sendo que o ideal que o aluno envolvido nesse estudo tenha feito antes desse curso cadeiras equivalentes a Sistemas de Informa o e Introdu o a Engenharia de Software O quarto cap tulo discute o levantamento de requisitos do sistema Apresenta ao leitor dois conceitos importantes o stakeholder palavra que significa aquele que tem algum interesse aposta e que traduzimos de forma liberal para interessado e uma classifica o de tipos de requisitos de um sistema onde se sobressaem os requisitos funcionais e n o funcionais O cap tulo tamb m apresenta uma leve introdu o a m todos de elicita o de requisitos discutindo os m todos tradicionais e mais comuns a entrevista e o JAD detalhadamente O quinto cap tulo apresenta a proposta inicial O objetivo permitir ao desenvolvedor compreender de forma geral o que ser feito no projeto de desenvolvimento dando margem para a cria o de uma proposta comercial Nesse cap tulo ainda tratamos o desenvolvimento de sistemas como uma atividade informal a n vel de neg cios O sexto cap tulo trata da modelagem de neg cios partindo de modelos de alto grau de abstra o como o IDEFO para modelos detalhados do comportamento da organiza o como EPC
192. forma o mas sim de quantas formas o usu rio pode acessar essa informa o Al m disso devemos identificar as fun es seguindo certa ordem A ordem importante porque encontrar um tipo de fun o de neg cio ajuda a encontrar as fun es de outro tipo Assim em um sistema novo devemos usar a ordem sa das consultas entradas arquivos e interfaces Por outro lado em um sistema j existente devemos usar a ordem arquivos interfaces sa das consultas e entradas Para serem contados as fun es devem e Beneficiar claramente o usu rio e Ser especificamente aprovado pelo usu rio e e Influenciar em algum grau mensur vel o projeto desenvolvimento implementa o e suporta aplica o 218 No manual da IFPUG podemos encontrar v rios exemplos que nos permitem dirimir as d vidas de como realizar a contagem A t cnica simples por m dif cil de dominar Identificando Sa das Para contar as sa das necess rio contar todas as informa es que o sistema gera para o ambiente de forma procedimental Tipicamente sa das s o relat rios impressos telas janelas e arquivos gerados para outras aplica es Deve ser contadas como sa das distintas cada formato utilizado Basicamente se for necess rio fazer outro procedimento para produzir a informa o contamos como uma sa da distinta Tamb m contamos cada tipo de l gica utilizada para fazer gerar a informa o Assim se um relat rio de vendas cont m as
193. fracas em um DER associando o termo fraco ao conceito de errado 112 Nome da Entidade Atributos Empresa Identificadores Sar J Chave NomeFantasia NomeRegistro Endereco Telefone Contato Atributos Figura 51 Uma entidade pode ser representada tamb m dessa forma bem mais moderna e compacta que a proposta original Esta a nota o utilizada no software Erwin tanto no modelo IDEF1X e quanto na Engenharia da Informa o Os atributos identificadores ficam acima de uma linha divis ria Figura 52 Um exemplo simples de DER sem atributos Aluguel amp Nome do filme FK amp C digo cliente FK C digo fita FK amp C digo cliente Data de empr stimo Nome Endere o E Data de entrega E EE Observa es o tr Fita amp Nome do filme FK amp C digo fita Tipo Cliente Diretor amp Nome de ator P Ano Distribuidora Figura 53 Um exemplo de DER usando a Nota o da Engenharia da Informa o feita com o software ERWIN Os cones ajudam a identificar as chaves j identificadas pela sua posi o sobre a linha divis ria 1 5 1 Exemplo de Modelo E R O modelo a seguir utilizando a nota o de Bertini et al B32 pode ser lido da seguinte forma 113 e Entidades do modelo Diretor Novela Cap tulo Ator Ator Horista e Hora e Um diretor dirige no m ximo uma novela poden
194. gat rio mas isso s verdade dentro do fluxo onde ele ocorre IX 6 4 Extens o de Casos de Uso A rela o de extens o descreve que um caso de uso extende o comportamento e seu caso base o que acontece apenas se uma condi o de extens o for verdade A rela o de extens o origin ria do uso de patches em sistemas que n o podiam ter seus casos de uso originais alterados para aceitar novos comportamentos e pode ser compreendida como uma forma de patch do mesmo jeito que a rela o de inclus o pode ser compreendida como uma chamada de fun o A figura a seguir apresenta um exemplo de rela o de extens o em um caso de uso 4 I hn ATM Customer t X lt lt pxtend gt 1 lt lt extend gt gt F ks Withdraw stamps Fig 101 Exemplo de relacionamento de extens o 183 A rela o de extens o deve ser utilizada quando queremos fatorar de um caso de uso um comportamento excepcional ou opcional que executado apenas em algumas condi es espec ficas de forma a simplificar o evento base Tamb m usada para criar um comportamento adicional a um caso de uso j existente IX 6 5 Generaliza o de Casos de Uso O relacionamento de generaliza o como estamos habituados descreve um comportamento geral compartilhado pelo caso de uso que herda filho com o seu parente Ela descreve que o filho tem o mesmo comportamento geral do pai por m com alguma diferencia o especializa o Esse rel
195. gens de lucro e de risco previamente acordadas o verdadeiro pre o vem do valor de mercado do produto ou ainda do ganho previsto Isso pode inclusive ser uma boa oportunidade de neg cios Muitas empresas ao perceberem que um produto espec fico vai dar um lucro direto ao seu cliente prop em fazer esse produto de gra a em troca de um percentual sobre o lucro Em longo prazo isso pode ser altamente vantajoso para a empresa de desenvolvimento enquanto que para o cliente pode ser a nica forma de conseguir um sistema que exigiria um investimento inicial muito alto para seu caixa V 12 O Resumo Executivo O resumo executivo deve permitir que o leitor tenha uma vis o completa do texto do documento em uma p gina Resumos executivos t m esse nome por partir da hip tese que um executivo ao tomar uma decis o n o tem tempo para ler longos documentos Na pr tica eles leriam o resumo executivo e folheariam os documentos Se voc nunca fez an lise de sistemas essa proposta pode parecer dif cil demais Isso acontece porque para fazer a proposta inicial devemos fazer de maneira extremamente simplificada uma an lise de sistema V 13 Estrutura da Proposta Inicial Uma proposta de trabalho pode se configurar de v rias formas em fun o de que pontos desejamos ressaltar ou em que ordem desejamos apresent la A seguir apresentamos uma estrutura poss vel para uma proposta inicial que uma empresa de desenvolvimento de software p
196. grau de abstra o e a internaliza o pelo analista de conceitos bastante vagos como entidades e relacionamentos Assim o analista iniciante precisa seguir algumas estrat gias para entender melhor como desenvolver um modelo conceitual A primeira estrat gia a estrat gia dos exerc cios e exemplos Nada t o til ao aprendizado como colocar a m o na massa Os exemplos por seu lado servem n o s como orienta o geral mas tamb m como exemplos de pontos espec ficos da modelagem e de como especialistas resolvem problemas de modelagem sejam eles simples ou complicados 114 A segunda estrat gia desenvolver uma lista de dicas de trabalho Essas dicas funcionam para o analista como as pistas funcionam para um detetive mostrando que caminho seguir at encontrar a solu o do problema 1 7 Entidades Uma entidade uma pessoa objeto local animal acontecimento organiza o ou outra id ia abstrata sobre a qual o sistema deve se lembrar alguma coisa Cada inst ncia de uma determinada entidade tem caracter sticas similares mas n o iguais o mesmo comportamento e uma identidade pr pria O primeiro passo na determina o das entidades o levantamento dos candidatos entidade Durante as entrevistas e reuni es de an lise de sistema v rios objetos e conceitos ser o descritos como parte do sistema Algumas vezes esses objetos s o bastante concretos como um produto dentro d
197. h00min do dia anterior de acordo com o per odo pedido pelo cliente di rio semanal etc Mensalmente os analistas pegam os dados que guardaram diariamente e fazem os relat rios mensais de resumo Cada vez que emitido um portfolio uma c pia de portfolio ou um relat rio mensal enviado um aviso ao sistema de cobran as 234 O Diagrama de Fluxo de Dados O objetivo de um Diagrama de Fluxo de Dados DFD descrever graficamente o fluxo de informa o e as transforma es que s o aplicados nos dados B41 Ele pode ser utilizado para representar em diferentes n veis de abstra o sistemas de informa o n o necessariamente automatizados DFDs permitem a modelagem funcional de um sistema em v rios n veis de abstra o Cada diagrama de um DFD composto de 4 tipos de objetos processos mem rias agentes externos e fluxos de dados Cada um desses objetos tem um s mbolo um nome e possivelmente um r tulo associado No passado existiram duas correntes de s mbolos para desenhar DFDs Os que desenhavam processos como caixas com as bordas arredondadas baseados na proposta de Gane e Sarson B42 e os que desenhavam processos com c rculos baseados na proposta de Coad e Yourdon B43 Atualmente a forma de Yourdon a mais difundida no mercado Cada processo em um DFD pode ser expandido em outro DFD que o descreve Dessa forma DFDs s o utilizados para descrever um sistema em n veis cada vez mais detalhados
198. hor a motiva o para termos uma regra t o r gida sobre um evento s receber dado de um agente externo Imagine um sistema para uma loja de autom veis onde o mec nico um agente externo faz um pedido de pe a Esse pedido anotado e repassado pelo sistema para outro sistema o sistema de estoque que outro agente externo que responder se a pe a est dispon vel ou n o Quando o sistema de estoque responder ent o avisaremos o mec nico da disponibilidade da pe a Segundo nossa regra temos os seguintes eventos e Mec nico solicita pe a o Nesse evento enviado um pedido de pe a para o Sistema de Estoque e Sistema de Estoque avisa disponibilidade de pe a o Nesse evento o mec nico recebe um aviso da disponibilidade J segundo alguns autores fazendo uma interpreta o simplificada mas por m n o essencial apenas o primeiro evento necess rio pois nesse evento o Sistema de Estoque consultado Agora vamos nos lembrar de nossos princ pios da an lise essencial N o podemos considerar a tecnologia do sistema Tamb m seguindo nossa defini o de evento n o podemos controlar quando o mundo externo faz alguma coisa Dessa forma n o podemos controlar quando o Sistema de Estoque vai responder a pergunta que fizemos Isso devemos esperar por um evento de resposta Quanto tecnologia podemos usar v rias tecnologias como teste da essencialidade de uma solu o A solu o essencial deve permi
199. iar o comportamento do mesmo Regras de neg cio s o at micas isto n o podem ser quebradas B26 Regras de neg cio s o muito estudadas hoje em dia A maioria dos importantes autores americanos se reuniu em um grupo conhecido com Business Rule Group que produziu alguns documentos B26 B27 que forneceram a estrutura b sica que estamos apresentando aqui Todas as defini es s o ou vers es dos originais em ingl s R Originalmente The Guide Business Rules Project 95 Uma regra de neg cio pode ser de tr s categorias e Declara es Estruturais um conceito ou a declara o de um fato que expressa algum aspecto da estrutura da organiza o Podem ser termos simples ou fatos relacionando esses termos Normalmente s o descritas por meio de um diagrama de entidades e relacionamentos e Declara es de A o que descrevem aspectos din micos do neg cio sendo uma express o de uma restri o ou de uma condi o que controla as a es de uma organiza o e Deriva es a declara o de um conhecimento que derivado a partir de outro VI 6 1 Declara es Estruturais Inclui os termos de neg cios e fatos relacionando termos V1 6 1 1 Defini o de Termos de Neg cios O elemento b sico de uma regra de neg cio a linguagem utilizada para express la A defini o das palavras utilizadas nessa linguagem descreve como as pessoas pensam e falam B26 Normalmente um projeto s c
200. idade Em ambos os casos apenas um relacionamento permitido Esse relacionamento encontrado quando uma entidade possui ou controla de alguma forma outra Em alguns casos as duas entidades podem ser unidas em uma s Ele menos comum que o relacionamento 1 1 0 N Um exemplo seria uma distribui o de pap is de uma pe a de teatro em uma companhia de atores Cada ator s pode fazer um papel alguns atores podem n o ter papel mas todos os pap is t m um ator e apenas um ator o 0 1 1 1 similar ao anterior o 1 1 1 1 Esse relacionamento pouco comum pois indica que uma entidade n o pode existir sem estar relacionada com outra e tudo isso apenas uma vez Normalmente pode ser substitu do pela unifica o das duas entidades em uma s Algumas vezes utilizado para diferenciar aspectos diferentes da mesma entidade Por exemplo um avi o uma entidade que tem vis es comerciais de mec nica de opera o etc Fica muito complicado em um modelo ER colocar todos os atributos que chegam a centenas em uma s entidade assim podem ser criados relacionamentos 1 1 1 1 para tratar essa modelagem Esse relacionamento n o recomendado pois exige que ambas as entidades sejam sempre criadas juntas e Relacionamentos 1 para N o 0 1 0 N A primeira entidade pode ou n o participar do relacionamento mas apenas uma vez A segunda entidade pode ou n o participar do relacionamento e ainda po
201. idade da interface entre componentes e Manuten o da qualidade dos nomes utilizados no modelo e e Manuten o da qualidade da representa o do modelo por exemplo quanto clareza dos diagramas Um das t cnicas mais citadas para controlar a complexidade a de manter o n mero de componentes de cada modelo ou sub modelo entre 5 e 9 Isso decorre de uma pesquisa B40 que determinou que o ser humano m dio tem a capacidade de se concentrar em 7 elementos com varia o de 2 O artigo interessante apesar de antigo VIII 3 2 A Neutralidade Tecnol gica O princ pio da neutralidade tecnol gica exige que um modelo essencial n o inclua em nenhuma de suas partes ind cios da tecnologia de implementa o B17 Essa exig ncia apesar de importante das mais quebradas pelos analistas Isso acontece por que geralmente j sabemos qual a tecnologia em que vamos implementar o sistema importante manter a neutralidade n o s para permitir uma an lise mais objetiva do verdadeiro problema do usu rio mas tamb m para aumentar a durabilidade dessa an lise Alguns autores j criticam a neutralidade tecnol gica ou simplesmente passam por cima dessa quest o colocando preocupa es de tecnologia j nessa fase A quest o tem rela o com a necessidade de se assumir algumas premissas para obter solu es mais eficientes Em todo caso na defini o de sistemas de informa o a met fora evento atividade mem ria forn
202. iente interagindo com o sistema ou estar guardada em uma mem ria As atividades custodiais se destinam a criar e manter as mem rias necess rias para o funcionamento das atividades fundamentais Um sistema mesmo de tecnologia perfeita n o pode criar dados sozinho Em ambos os exemplos da folha de pagamento ou da lista de presen a precisamos saber quem s o nossos funcion rios Manter essa lista de funcion rios uma atividade custodial Atividades custodiais fique bem claro s o essenciais ao funcionamento do sistema Acontece que enquanto o usu rio conhece a grande maioria das atividades fundamentais que precisa muitas atividades custodiais ficam de fora de sua lista Assim ao analisar um sistema devemos estar sempre alerta para atividades custodiais necess rias para manter nossas mem rias em ordem 149 Algumas atividades s o custodiais e fundamentais simultaneamente sendo ent o chamadas de compostas ou mistas poss vel ter uma vis o menos funcional e mais pragm tica que perde muito da qualidade filos fica mas ganha em simplicidade atividades fundamentais t m uma sa da para o mundo externo enquanto atividades custodiais alteram mem rias Isso nos chama aten o que n o existem atividades que n o sejam fundamentais ou custodiais isso uma atividade deve pelo menos escrever em uma mem ria ou fazer um relat rio Abordagem Filos fica Pragm tica Fundamental Requisito original do cliente Emite
203. ificar um evento demonstra que ele n o foi compreendido e indica que ele pode n o estar correto tanto na sua interpreta o ou na sua descri o ou at que seja um requisito falso Al m disso a tabela permite que verifiquemos se todos os eventos esperados possuem um ou mais n o eventos correspondentes 158 Classifica o Externo Temporal N o evento N o p N mero Evento Esperado Esperado Relativo Absoluto evento Gerente cadastra distribuidora Gerente cadastra livro KM Ea 1 2 5 Distribuidora entrega livros 6 Gerente solicita relat rio de vendas 7 Gerente solicita relat rio de V livros em atraso 3 Cliente pede livros 4 Sexta feira hora de fazer requisi es de livros para as V distribuidoras A distribuidora n o entregou Tabela 22 Exemplo de uma tabela de classifica o de eventos VIII 8 2 Encontrando Eventos Os principais eventos s o os pedidos que s o feitos ao sistema Eles normalmente podem ser encontrados em formul rios memorandos documentos que chegam e observando o atendimento que os usu rios do sistema prestam Relat rios devem ser gerados por algum evento Eles por m s o as respostas aos eventos e n o os eventos propriamente ditos Todo evento externo esperado deve precisar de um e pode precisar de mais n o eventos No mundo real encontramos ainda outras caracter sticas que indicam novos eventos Pedidos normalmente podem ser cancelado
204. imeiro um fato e depois analisamos o significado dos seus termos As declara es estruturais podem declarar atributos generaliza es ou participa es Uma participa o por sua vez pode ser um papel uma agrega o ou uma associa o simples RRA f N o sendo necessariamente igual ao modelo conceitual de dados mas podendo fornecer elementos para esse 96 Exemplos Atributo DRE um atributo de aluno Aluno de gradua o um tipo de Aluno Papel Um aluno pode ser representante de classe Agrega o Uma turma precisa ter alunos Associa o Um aluno deve fazer provas simples Tabela 6 Tipos de Fatos e exemplos Declara es estruturais e o modelo de dados Termos e fatos estabelecem a estrutura de um neg cio Esta estrutura normalmente descrita em um modelo de dados Assim a maior parte do trabalho inicial com as regras de neg cio estruturais pode ser descrita por meio de um modelo de dados conceitual tema tratado no pr ximo cap tulo Exemplos A seguir damos alguns exemplos de declara es estruturais para um sistema acad mico imagin rio Alunos s o pessoas matriculadas em um curso m Aluno de Gradua o um tipo de Aluno m Aluno de P s Gradua o um tipo de Aluno ma Cadeira ministrada por um Professor U U Um Curso constru do por um conjunto de Cadeiras U U m Professor um tipo de Funcion rio Durante um Per odo Alunos podem se matricular em Cadeiras VI
205. implificada capaz de atender plenamente os objetivos desse livro Caso necess rio o leitor pode recorrer ao livro Software Cost Estimation With COCOMO IP ou ao web site http sunset usc edu research COCOMOIIindex html 8 Atualmente em sua segunda vers o COCOMO II 84 A A E P Sa S PMss um valor de pessoas m s sem considerar esfor os de tradu o autom tica e ainda sem considerar efeitos da necessidade de acelerar o desenvolvimento 214 TDEV 3 67x PM 92 Equa o 3 Equa o simplificada que pode ser usada para ter uma previs o do tempo de desenvolvimento a partir do esfor o necess rio em pessoas m s baseada no modelo COCOMO II Fica ent o a pergunta como descobrir o esfor o necess rio O modelo COCOMO II tamb m nos fornece uma f rmula desta vez baseada na quantidade de linhas de c digo previstas para o software Desta vez forneceremos logo a f rmula simplificada PM 2 94x MLDC Equa o 4 Equa o simplificada de c lculo do esfor o onde MLDC significa milhares de linhas de c digo A 2 94 B 0 91 C 3 67 D 0 28 Tabela 30 Valores atuais de A B C e D XI 5 1 Distribui o do Esfor o Uma quest o importante na previs o do esfor o a ser feito para o desenvolvimento de um software como esse esfor o ser distribu do nas fases do processo de desenvolvimento O COCOMO 81 tratava desse problema com certo detalhe que n o foi continuado no COCOMO II
206. inalidade m nima 1 O motivo que um par de entidades s pode ser colocado na mem ria do sistema em uma mesma transa o n o permitindo que primeiro coloquemos a inst ncia de uma entidade na mem ria e depois uma inst ncia relacionada da outra entidade Temos ent o os seguintes tipos de relacionamentos e Relacionamentos um para um o 0 1 0 1 Esse relacionamento significa que uma inst ncia do primeiro conjunto pode ou n o se relacionar com uma inst ncia do segundo conjunto por m pode ter apenas um relacionamento O mesmo vale do segundo conjunto para o primeiro Esse relacionamento encontrado quando poss vel formar pares entre duas entidades mas esses pares s o opcionais Um exemplo seria o caso da aloca o cabines e reboques de caminh es em uma empresa de aluguel de viaturas Cabines e reboques podem ser trocados arbitrariamente Em certo momento cada cabine s pode ter um reboque e vice versa Al m disso algumas vezes uma das partes fica guardada na garagem enquanto a outra utilizada Outro caso que podem mostrar s o auto relacionamentos desse tipo Uma igreja ou um templo por exemplo pode ter um cat logo de fregiientadores e querer saber quem casado com quem e quem solteiro ou seja n o tem nenhum relacionamento o 1 1 0 1 122 Esse relacionamento significa que a primeira entidade obrigatoriamente tem um relacionamento mas ele opcional para a segunda ent
207. incipalmente pela defini o de fronteira do sistema indicada pelas entradas incluindo controles e sa das Regras gerais de constru o O m todo sempre se inicia pela defini o da caixa inicial A 0 e sua expans o em um diagrama de primeiro n vel A0 A partir desse ponto sempre que for necess rio expandir uma fun o ser criado outro diagrama filho mantendo as seguintes regras Pierre Nancy 2004 1998 id e Cada fun o deve trazer algum valor agregado a suas entradas e controles e Cada fun o recebe um nome na forma verbo no infinitivo objeto direto e Os sub sistemas de uma fun o devem suportar diretamente a fun o e Cada seta que entra ou sai de uma fun o deve ser encontrada em seu diagrama de expans o e As setas podem entrar ou sair de uma ou mais fun es e As setas pode ser divididas de forma a transportar parte de informa o para uma fun o e parte para outra e Em casos especiais as setas podem n o aparecer em um diagrama superior em um processo conhecido como tunelamento destinado a abstrair informa es e Cada seta deve receber um nome ou um c digo que a identifique unicamente e Os mecanismos podem ser suprimidos se isso n o afetar a compreens o do modelo e S devem ser mencionados os elementos necess rios para o objetivo da constru o do modelo e As sa das indicam um valor agregado as entradas e controles ou ainda resultados colaterais sub produtos ou dejetos
208. intera o com usu rio busquem n o s a consist ncia mas tamb m facilitar a cria o do modelo mental do usu rio por meio do uso de met foras ou outras formas de indica o Cabe ao projetista da interface lidar com todas as caracter sticas do ser humano e tamb m das infinitas variedades entre os seres humanos O projetista tem um modelo mental que representa na imagem do sistema O usu rio v essa imagem e gera um novo modelo mental Os problemas das interfaces homem computador aparecem nas diferen as entre esses tr s modelos o modelo mental do projetista a imagem do sistema e o modelo mental do usu rio B44 198 X 1 2 Introdu o ao Modelo Cognitivo usado em IHC Como vimos anteriormente podemos fazer um modelo do ser humano e do computador dividindo suas atividades ao usar o computador em tr s tipos percep o respons vel pela leitura de informa es atividades cognitivas mem ria e processamento e sistema motor respons vel pela sa da de informa es Uma caracter stica importante de seres humanos que eles podem ser modelados efetivamente como possuindo duas mem rias uma mem ria de curto prazo MCP e uma mem ria de longo prazo MLP A primeira r pida e limitada com pequena dura o A segunda infinita faz associa es muito complexas e n o tem acesso confi vel Al m disso o sistema cognitivo humano tem um processamento lento apesar de ser poderoso em algumas atividades
209. io de linhas Alguns autores utilizam uma nota o levemente mais complicada com o objetivo de descrever diferen as sutis em uma organiza o Em geral o analista n o precisa levantar o organograma pois a empresa j o possui mas comum que haja algumas mudan as E importante tamb m levantar n o s a hierarquia de cargos mas tamb m quem ocupa cada cargo principalmente para apoio s tarefas de an lise A import ncia de conhecer o organograma da empresa se reflete tanto na modelagem propriamente dita pois ele fornece a descri o da empresa que ser convertida objetos do modelo como no processo de modelagem pois a partir do organograma temos o conhecimento de cargos e responsabilidades definindo pessoas a serem entrevistadas 71 Conselho Administrativo Presidente I Diretor Diretor de Diretor Comercial Produ o Administrativo ho tita O SEA E Ms Gerente de Gerente de Gerente de Gerente de Gerente Recursos Financeiro Humanos Grandes Clientes Vendas F brica Log stica Gerente de Figura 23 Um exemplo de organograma simples contendo apenas cargos Um organograma pode ser utilizado para representar diferentes formas de subordina o como a subordina o direta onde o subordinado deve cumprir as ordens de seu chefe a assessoria onde o assessor fornece conselhos e pareceres e a subordina o funcional onde o su
210. ion rios Sistemas essenciais possuem dois tipos de componentes atividades e mem rias Cada tarefa que o sistema de tecnologia perfeita tem que realizar para cumprir a finalidade do sistema uma atividade essencial Essas atividades existem em duas formas as atividades fundamentais e as atividades custodiais As atividades essenciais para poderem executar suas tarefas precisam guardar informa o Essa informa o guardada em mem rias Da forma que tratamos a an lise a mem ria do sistema vista como um todo o modelo conceitual de dados discutido no Cap tulo VI Cada atividade essencial por m pode ter apenas uma vis o parcial dessa mem ria de acordo com suas necessidades As atividades fundamentais s o aquelas que justificam a exist ncia do sistema B17 Certamente ao comprar um sistema precisamos fundamentalmente das sa das que ele nos disponibilizar Assim atividades fundamentais precisam incluir alguma sa da para agentes externos Suponha que voc deseja comprar um sistema de controle de ponto para sua empresa V rias atividades s o necess rias ou poss veis nesse sistema por m poucas s o fundamentais A atividade fundamental certamente informar a presen a de cada funcion rio pois para saber disso que voc comprou o sistema As atividades fundamentais necessitam de dados para funcionar que podem ser fornecidos diretamente por um agente externo um ser humano ou outro sistema que faz parte do amb
211. iretor n o evento esse evento n o est no diagrama por um defeito de fabrica o do mesmo mas aparecer na pr xima vers o 67 x 7 Aten o para a forma como cada evento descrito 172 dados de diretor dados de novela diretor perado perado do red e AS Ny novela N N zadastra D cadastra A diretor AS novela 4 N i N G N S Pa diretor Ag EA dados de ator tipo k ST gt perado diretor K cap tulo resumo No autor e ZO N N N sadastra aviso de aloca o 7 y q ator JA Or cap tulo N PN Ea dep ator Ei e A nn pessoal cap tulo E cap tulo ator l diretor Wai ator horista f diretor novela 4 ator horista __ EE horas eo E Es e Ae Ng O MR novela y enviar form ator horas registrar formu diretor horas a ator diretor l rio trabalh C ENLO pe ar ya o MA ator diretor ator horista ator hor horas Figura 87 Todos os componentes do DFD particionado do sistema para Rede Bobo de Televis o em uma s imagem VIII 16 VIII 16 1 Modelos Adicionais Finalizando a An lise Um dos trabalhos mais importantes e aborrecidos da fase de an lise manter todos os documentos consistentes Isso fica mais dif cil quando estamos usando m todos diferentes em ferramentas distintas Assim se temos em uma mesma ferramenta CASE o diagrama de entidades e re
212. is Requisitos Requisitos Requisitos Requisitos de de de de Desempenho Espa o Privacidade Seguran a Figura 16 Tipos de requisitos funcionais adaptado de http dme uma pt jcardoso Teaching EMR Lectures 11 8 ago 2003 e lan Sommervile Software Engineering Esse texto tem como foco requisitos funcionais e requisitos de informa o Ainda n o existe uma forma plenamente aceita de tratar requisitos n o funcionais mas o leitor interessado poder encontrar diferentes m todos na literatura de Engenharia de Software Alguns requisitos n o funcionais quando negados geram um anti requisito que nunca seria pedido por um cliente Por exemplo um requisito n o funcional comum que o software seja confi vel Ningu m pediria para ser constru do um software n o confi vel por m diferentes clientes est o interessados em diferentes n veis de confiabilidade e diferentes formas de certificar esse n vel Deve ser levado em conta que quanto mais esfor o colocado para se alcan ar um requisito maior o custo agregado ao projeto e isso servir como refer ncia para o cliente escolher o grau de confiabilidade que deseja IV 5 3 Outros tipos de Requisitos James e Susan Robertson B9 identificam mais tr s tipos de requisitos restri es de projeto temas de projeto e impulsionadores de projeto 37 e As restri es de projeto s o os limites impostos ao sistema para que funcione
213. is zero ou um um e apenas um 00 Figura 65 Nota o para a cardinalidade possui Pessoa i Apartamento possu do Figura 66 Uma pessoa possui zero ou mais apartamentos e um apartamento possu do por pelo menos uma pessoa ou mais possui 4 v Pessoa Apartamento possu do Figura 67 As setas indicam a forma de leitura do diagrama A cardinalidade indicada por tr s s mbolos usados na ponta da linha que indica o relacionamento uma linha indica 1 um c rculo indica O zero e um p de galinha indica 130 n Dessa forma podemos anotar o m nimo e o m ximo da cardinalidade usando dois s mbolos em cada ponta O nome do relacionamento colocado acima esquerda da linha que o indica sendo o nome do relacionamento inverso colocado abaixo direita Normalmente se l a nota o partindo de uma entidade lendo o nome do relacionamento lendo a cardinalidade da ponta oposta e finalmente o nome da segunda entidade Nessa nota o os atributos podem ser colocados dentro da caixa que representa as entidades como apresentado na pr xima se o 1 11 1 Exemplos de nota es Vamos descrever a seguir o seguinte modelo em v rias nota es Apresentaremos o modelo de uma locadora de v deo A locadora trabalha com fitas de v deo Cada fita de v deo cont m um filme por m cada fita deve ser identificada unicam
214. itam outros eventos apenas a consulta especifica o da atividade ou ao dicion rio de eventos pode dar essa informa o Algumas habilita es podem ser anotadas em uma mem ria Por m cuidado pois pode ser que a mem ria n o tenha sido desenvolvida no modelo de dados VIIH 7 Descrevendo Eventos Essenciais Um evento externo sempre caracterizado pela exist ncia de agente externo que a pessoa ou um outro sistema que faz com que o evento aconte a enviando para o sistema o est mulo correspondente Assim na nossa descri o de um evento externo sempre devemos colocar o nome do agente externo que o causa No caso de eventos temporais devemos colocar o fato que faz o evento acontecer Eventos temporais n o possuem um agente externo que forne a o est mulo Alguns est mulos s o bastante complicados contendo dezenas ou centenas de dados outros s o bastante simples contendo apenas um comando ou solicita o ao sistema Eventos cujo est mulo apenas um comando de execu o podem ser chamados eventos de controle A sintaxe para definir eventos externos lt agente externo sujeito gt verbo no presente gt lt objeto direto gt Como em Cliente solicita lista de produtos Opcionalmente no caso de um evento esperado pode ser usado o seguinte padr o lt agente externo sujeito gt lt verbo no presente gt lt objeto direto gt lt prazo gt Onde prazo pode ser absoluto ou relativo a outro evento
215. itar a constru o do diagrama deve ser evitada ao m ximo mas aceit vel em alguns casos como mem rias que s o claramente acessadas por um n mero grande de processos A duplica o de processos proibida O diagrama global representa um n vel intermedi rio do sistema o n vel onde cada processo representa um evento A partir do diagrama global construiremos o DFD particionado pela sele o de atividades essenciais em processos As seguintes heur sticas podem ser utilizadas para isso 239 e Agregar em um nico processo todas as atividades essenciais que usam uma mem ria espec fica Como resultado essa mem ria tamb m ser representada dentro desse processo em um n vel superior do DFD e Agregar todas as atividades de cust dia que acessem uma mem ria espec fica e Agregar funcionalidades que s o utilizadas por um agente externo espec fico e e Agregar por meio de fun es de neg cio e Manter o n vel de complexidade de cada processo criado entre n meros recomend veis 7 2 objetos em cada processo O resultado ser um conjunto de processos onde cada processo cont m v rias atividades essenciais e talvez uma ou duas mem rias interligados por sua conex o com mem rias do sistema Se o n mero resultante de processos for entre 5 e 9 alcan amos um n vel abstrato razo vel para o diagrama de n vel zero Caso contr rio repetimos esse processo at que isso aconte a Finalmente alcan ado o n vel zer
216. itas das regras de neg cio s o representadas diretamente no modelo conceitual Veremos mais tarde que termos e fatos s o candidatos naturais para serem objetos 109 nos nossos modelos conceituais N o devemos confundir por m regras de neg cio com modelos de dados Um relacionamento em uma regra de neg cio pode representar uma fun o do sistema enquanto um relacionamento no MER representa algo que deve pertencer mem ria do sistema 1 3 2 Modelo L gico O modelo l gico descreve a informa o contida no sistema de acordo com uma tecnologia adotada sem utilizar por m detalhes de implementa o Ele descreve a estrutura do banco de dados que ser processado por um SGDB Atualmente o modelo mais utilizado o modelo relacional por m existe uma tend ncia utiliza o do modelo relacional objeto ou de outros modelos relacionais estendidos Al m disso alguns modelos distintos podem ser encontrados em aplica es especiais como data warehousing e sistemas de informa o geogr fica O modelo de objetos considerado por muitos o mais moderno n o tem no momento grande aceita o no mercado 1 3 3 Modelo F sico No modelo f sico devemos levar em conta n o s a tecnologia sendo utilizada mas tamb m os produtos espec ficos e a intera o do sistema com o ambiente de desenvolvimento e opera o E nessa etapa que nos preocupamos com as principais quest es de desempenho como escolha de ndices particionament
217. ito foi visto quando as companhias a reas passaram a vender passagens via Internet No in cio era mais uma propaganda depois passou a ser um diferencial positivo Atualmente todas as companhias a reas possuem formas de vender passagens diretamente via Internet Hoje em dia um grande motivador de novos projetos e a busca por melhor tratamento da informa o que j existe em sistemas de tipo operacional como a cria o de Sistemas Suporte Executivo II 5 Exerc cios 1 Escolha um tipo de neg cio de pequeno porte como uma ag ncia de viagens e descubra ou imagine quais os principais sistemas de informa o que ela necessita ou pode usar 2 Classifique os sistemas anteriores quanto ao seu n vel na organiza o 3 Classifique os sistemas anteriores quanto ao seu tipo 4 Imagine que esse neg cio se torna um grande neg cio por exemplo uma grande cadeia de ag ncias de viagens e descubra ou imagine que novos sistemas podem ser necess rios 5 Que sistemas de informa o fazem parte de seu dia a dia Que papel voc assume ao utilizar esses sistemas 6 Que sistemas de informa o voc pode se lembrar que cont m informa es importantes sobre sua vida pessoal ou profissional 14 7 8 9 10 11 12 Imagine uma empresa de plano de sa de que possui um sistema de n vel operacional que registra e permite a aprova o pela pessoa respons vel de exames e consultas Que sistemas de informa o de out
218. izado da metodologia Volere B12 IV 7 2 Depend ncia de Requisitos importante notar que os requisitos n o s o independentes uns dos outros Muitos requisitos s podem ser implementados se outros requisitos forem implementados antes Por exemplo imposs vel fazer um relat rio de vendas sem que se cadastrem as vendas previamente no sistema Uma das atividades mais importantes da ger ncia de requisitos manter esse relacionamento de depend ncia que influenciar em todo desenvolvimento e Processo do sistema Para isso existem algumas solu es poss veis Uma delas manter uma tabela de depend ncia de requisitos outra manter um banco de dados de requisitos que inclua rela es de depend ncia Existem alguns produtos no mercado especializados na ger ncia de requisitos IV 7 3 Priorizando Requisitos Existe uma tend ncia grande de o sistema crescer muito durante a an lise Principalmente se entrevistamos um grande n mero de pessoas existe uma facilidade natural das pessoas para propor novas funcionalidades para um sistema que ainda n o existe por imaginarem alguma utilidade nessas fun es propostas Assim muitas vezes nos vemos envolvidos com uma quantidade de requisitos t o grande que bvio que o sistema a ser feito n o poder ser entregue no prazo ou pelo custo combinado ou que se pensava em combinar Nesse caso algumas t cnicas podem ser utilizadas para caracterizar o que deve ser realmente feito ou p
219. izado junto com os usu rios IV 7 Descrevendo Requisitos Normalmente as especifica es de requisitos s o escritas em linguagem natural ingl s ou portugu s por exemplo O problema claro que a forma como falamos e normalmente escrevemos bastante amb gua Isso exige que adotemos algumas t cnicas b sicas principalmente um formato padronizado um estilo de linguagem e uma organiza o que facilite a manipula o do conjunto de requisitos Algumas dicas para escrever requisitos s o B10 e Use senten as e par grafos curtos e Usea voz ativa e Use verbos no futuro e Use os termos de forma consistente e mantenha um gloss rio e Para cada requisito avalie se a partir de sua defini o poss vel determinar se ele est pronto ou n o e Garanta que todos os requisitos s o verific veis imaginando e possivelmente documentando uma forma de faz lo 66199 c6 29 e Verifique requisitos agregados termos como e e ou s o uma boa indica o e divida os e Mantenha um n vel de detalhe nico em todos os requisitos IV 7 1 Documentando os requisitos Requisitos de projeto podem ser descritos com as seguintes informa es B11 39 Esses N mero identificador o para facilitar a discuss o identificamos todos os requisitos unicamente Tipo o Classificando o como funcional n o funcional Evento que o atende6 Descri o Justificativa Fonte do requisito o A pessoa ou o grupo que o
220. l XI 8 1 A T cnica de Delfos A T cnica de Delfos uma forma de fazer com que especialistas entrem em consenso sobre uma predi o ou estimativa sem que haja uma discuss o frente a frente Segunda a t cnica a primeira a o a ser feita a defini o do produto sobre o qual a estimativa ser feita No nosso caso a pergunta em que estamos interessados quantas linhas de c digo ser o necess rias para implementar o software Normalmente a defini o faz uma divis o do software em m dulos para facilitar a estimativa S o ent o escolhidos especialistas para os quais s o distribu dos os question rios com a descri o dos m dulos Para cada m dulo os especialistas devem fazer uma predi o de tamanho Este o primeiro ciclo A partir do primeiro ciclo s o feitos ciclos sucessivos onde s o distribu dos os mesmos question rios por m com a informa o n o identificada de cada resposta dada Normalmente esta informa o dada em um gr fico indicando ainda a estimativa m nima a m xima a mediana e a m dia A partir do segundo ciclo os especialistas devem justificar suas respostas de maneira a facilitar a converg ncia de opini es Esse tipo de ciclo repetido at que o consenso seja atingido Apesar da T cnica de Delfos n o ser muito r pida compreender seu funcionamento pode ajudar a determinar como deve ser feito o trabalho de predi o de especialistas XI 8 2 Cen rios Outra t cnica alt
221. lacionamentos e todos os nossos eventos prov vel que seja poss vel nunca conseguir escrever uma especifica o inconsistente ou pelo menos verificar se existe alguma inconsist ncia Por m se utilizamos mais de uma ferramenta CASE fica mais dif cil manter essa consist ncia 68 E dad E Esse DFD particionado uma figura inexistente durante o projeto Em um documento real cada diagrama apareceria em uma p gina e n o todos agrupados Al m disso devemos notar a aus ncia de um n o evento poss vel 69 po fara Se n o utilizamos ferramentas CASE estamos incorrendo em um erro grave 173 Cap tulo IX Casos de Uso We succeed only as we identify in life or in war or in anything else a single overriding objective and make all other considerations bend to that one objective Dwight D Eisenhower Ator Casos de Uso Cen rios Fluxo Principal Fluxo Alternativo IX 1 Conceitua o Um caso de uso uma especifica o em forma de narrativa de uma segii ncia de intera es entre um sistema e os atores agentes externos que o usam Casos de uso podem ser simples ou complexos devendo descrever em um n vel de detalhe desejado algo que um usu rio ou cliente quer que o sistema fa a Eles descrevem e definem parte da funcionalidade de um sistema Casos de uso foram criados por Ivar Jacobson em 1986 Uma das melhores descri es de seu uso foi feita por Alistair Cockburn no livro Effecti
222. lemento de dados levando em conta o fato de executarem uma fun o X1 6 6 Determinando a Complexidade Para todos os tipos de fun o de neg cios importante determinar o n mero de itens de dados referenciados Para sa das consultas e entradas n s devemos contar o n mero de arquivos acessados Para arquivos e interfaces devemos contar o n mero de RET s e o n mero de campos de dados do arquivo 221 Sa das Itens de dados referenciados Arquivos 1 5 6 19 20 Referenciados 0 1 Simples 4 Simples 4 M dia 5 2 3 Simples 4 M dia 5 Complexa 7 4 M dia 5 Complexa 7 Complexa 7 Tabela 33 C lculo da complexidade de sa das externas Entradas Itens de dados referenciados Arquivos 1 4 5 15 16 Referenciados 0 1 Simples 3 Simples 3 M dia 4 2 Simples 3 M dia 4 Complexa 6 3 M dia 4 Complexa 6 Complexa 6 Tabela 34 C lculo da complexidade de entradas externas Consultas Itens de dados referenciados Arquivos 1 5 6 19 20 Referenciados 0 1 Simples 3 Simples 3 M dia 4 2 3 Simples 3 M dia 4 Complexa 6 4 M dia 4 Complexa 6 Complexa 6 Tabela 35 C lculo da complexidade de consultas externas dica analisar como sa da dar o valor como entrada Arquivos Internos Itens de dados referenciados RETs 1 19 20 50 51 1 Simples 7 Simples 7 M dia 10 2 5
223. li los Para levantar requisitos necess ria a intera o entre aqueles que conhecem os requisitos ou a necessidades dos usu rios e stakeholders e os desenvolvedores um processo interativo de comunica o onde por aproxima es sucessivas o desenvolvedor constr i um modelo aceito pelos usu rios 42 Req Ad hoc Especifica o de Req 2 a C Rejeitada P Corre o A ap A Rejeitada gt s Corre o p Desenvolvedor Cliente Cm Figura 18 A elicita o de requisitos um processo interativo onde por aproxima es sucessivas o desenvolvedor consegue a aprova o de uma especifica o de requisitos Aprova o Para exemplificar esse processo podemos imaginar a seguinte hist ria uma crian a e seu pai est o conversando em uma pra a a crian a ent o pede a seu pai Pai pega aquela pedra E o pai entrega uma pedra a primeira que v crian a N o pai a pedra pequena E o pai troca a pedra por um bem menor N o pai a pedra redonda E o pai troca a pedra por uma quase esf rica N o pai a pedra azul E o pai percebe ent o que a crian a queria uma bola de gude azul que estava na areia A crian a fica feliz O mesmo acontece na investiga o que um analista tem que fazer com o cliente em busca do requisito Inicialmente o cliente ser amb guo generalista e paulatinamente com a ajuda do analista dever chegar a uma espe
224. lidade Pode acontecer de uma ou outra representa o ser mais interessante em um contexto Relacionamentos podem ser condicionais ou incondicionais isto uma entidade pode ser obrigada a ter um relacionamento com outra ou n o Por exemplo um autom vel obrigatoriamente fabricado em uma f brica mas nem todos os livros em uma livraria j foram vendidos Como veremos adiante o fato de um relacionamento ser opcional representado pela defini o da cardinalidade m nima do relacionamento que pode ser O ou 1 Tamb m importante notar que existem tamb m rela es que ocorrem entre relacionamentos Dois relacionamentos podem ocorrer sempre juntos contingentes ou nunca ocorrer juntos mutuamente exclusivos Existem m todos que permitem anotar diretamente no diagrama essas caracter sticas por m s o pouco utilizados Tudo que n o puder ser anotado no diagrama dever ser anotado em um documento associado O principal tipo de anota es s o as regras de neg cio que funcionam como restri es como um professor s pode dar aulas para alunos da escola em que trabalha Restri es s o geralmente imposs veis de desenhar diretamente no diagrama Normalmente associamos restri es a ciclos no diagrama Por exemplo se temos que fazer pedidos de livros para uma editora ent o temos um relacionamento entre livro e pedido um entre livro e editora e um entre editora e pedido formando um ciclo A restri o que
225. ligando duas entidades ou por um losango ligado por linhas s entidades Em ambos os casos poss vel anotar os relacionamentos com nomes e com a sua cardinalidade ver exemplos mais a frente O nome escolhido para o relacionamento pode estar na voz ativa m e gera filho ou na voz passiva filho gerado por m e Algumas nota es permitem que se usem os dois nomes um por cima e um por baixo da linha de relacionamento Geralmente se usa o nome que permite a leitura do relacionamento da esquerda para a direta na parte de cima da linha ou se d prefer ncia a esse nome quando apenas um pode ser utilizado 126 Relacionamentos tamb m devem ser descritos e comentados sendo importante responder qual sua fun o no sistema o que eles representam como e quando s o estabelecidos ou destru dos Aluno Escola CPF NomeEscola NomeAluno EnderecoEscola S OH EnderecoAluno NomePai NomeMae Figura 59 Um relacionamento entre escola e alunos Como veremos mais adiante segundo a nota o da Engenharia da Informa o uma escola pode ter 0 1 ou mais alunos enquanto um aluno est em uma escola ou em nenhuma escola 1 9 Atributos Todo atributo descreve de alguma forma a inst ncia da entidade Alguns atributos s o especiais e definem a entidade mesmo que n o de forma un voca Esses s o os atributos nominativos Outros atributos permitem definir outro objeto que n o o sendo tratado s o ou atribu
226. m nimos s o objetos diferentes por m com o mesmo nome 118 Entity Editor x Entity Aluno od Name aluno Definition Note Note 2 Note 3 UDP Icon Definition I Logical Only Cancel Figura 56 Uma tela descrevendo uma entidade no software ERWIN 3 5 Aten o para o fato que apesar de n o cumprir todos os nossos requisitos em campos distintos apresenta v rios campos de anota o Aluno Escola CPF NomeEscola NomeAluno EnderecoEscola S Of EnderecoAluno NomePai NomeMae Figura 57 Como veremos mais adiante segundo a nota o da Engenharia da Informa o apresentamos nessa figura duas entidades que se relacionam Escola e Aluno 1 8 Relacionamentos A principal caracter stica das entidades que comp e um sistema se relacionarem umas com as outras imposs vel imaginar uma entidade isolada em um sistema de informa o Toda entidade deve possuir ao menos um relacionamento que a coloque em contato com as outras entidades do sistema Relacionamentos representam que existe alguma conex o entre entidades dentro do neg cio sendo analisado B34 Cada relacionamento deve ser tamb m uma regra de neg cio e utilizado em pelo menos um processo que lida com as entidades envolvidas Relacionamentos indicam a possibilidade de buscar um grupo de entidades a partir de outra entidade Assim permite encontrar os visitantes que emprestaram um livro espe
227. m caso de desacordo Se necess rio pe a desculpas Basicamente o entrevistador deve ser muito educado 51 1 8 3 2 Roteiro B sico 1 10 11 12 13 14 15 Apresente se ao entrevistado Ol muito prazer eu sou fulano de tal respons vel por parte do projeto XYZ Apresente seu cart o de visitas se for o primeiro encontro Informe ao entrevistado o motivo da entrevista e porque foi selecionado Estou aqui para levantar o funcionamento da sua rea e seu nome foi escolhido por ser o funcion rio mais experiente ou Estou aqui para levantar o funcionamento da atividade X que de sua responsabilidade Deixe clara a id ia que o conhecimento e as opini es do entrevistado s o importantes e ser o teis no processo de an lise Diga o que vai acontecer com a informa o levantada Garanta que o entrevistado ler a transcri o da entrevista e ter a oportunidade de corrigi la garanta que nada ser passado a outras pessoas sem a revis o e verifica o do entrevistado Determine os assuntos confidenciais ou restritos a serem tratados na entrevista Deixe claro que n o haver conseq ncias negativas em fun o do resultado da entrevista Solicite permiss o para gravar a entrevista Se autorizado inicie a grava o com um texto de apresenta o Entrevista realizada no dia X Fa a a entrevista at faltarem 5 ou 10 minutos para o tempo determinado Avise ao entrevista
228. m ser divididos em requisitos funcionais requisitos de informa o e requisitos n o funcionais Obviamente s estamos interessados em requisitos verdadeiros V 9 1 Oportunidades para o novo sistema Devemos incluir em nossa proposta oportunidades que detectamos a partir do nosso conhecimento do que fact vel atualmente ou em futuro pr ximo As oportunidades que detectamos para um novo sistema est o normalmente ligadas a novas tecnologias ainda n o utilizadas pelos clientes V 9 2 Pontos Cr ticos ou Pontos Chave Os pontos cr ticos ou chave de sucesso para um projeto s o aquelas quest es que n o estando diretamente relacionada ao desenvolvimento propriamente dito s o essenciais para o bom andamento do projeto Exemplos compromisso de certos funcion rios fornecimento de certa informa o chegada de alguma m quina ou software compromisso de entrega de dados ou equipamentos pelo cliente etc Os pontos cr ticos devem ser levantados detalhadamente pois os compromissos do desenvolvedor s poder o ser cumpridos caso sejam resolvidos satisfatoriamente 10 q Sistema operacional simples antecessor do Microsoft Windows 65 V 9 3 Restri es Muitos sistemas t m restri es que devemos considerar em nossas propostas Um tipo importante de restri es s o as exig ncias de implementa o como banco de dados linguagem sistema operacional etc Quanto mais cedo forem detectadas as restri es mais c
229. mediatos da obten o de informa o dos usu rios e cria um ambiente de alta sinergia na equipe onde todos se sentem comprometidos com as solu es encontradas Esse comprometimento permite que todos se considerem propriet rios e colaboradores no desenvolvimento do sistema 1V 8 4 1 O Objetivo do M todo O objetivo do m todo extrair informa es de alta qualidade dos usu rios em curto espa o de tempo atrav s de reuni es estruturadas para alcan ar decis es por consenso IV 8 4 20s Componentes O l der de sess o tem como tarefa n mero um conduzir o grupo para solu es de consenso Esse l der de sess o age como facilitador um servidor neutro dentro do grupo que n o avalia nem contribui com id ias A responsabilidade do facilitador sugerir m todos e procedimentos que ajudem o grupo a concentrar energia em tarefas espec ficas garantindo a todos os membros do grupo condi es de participar O documentador um auxiliar imparcial do l der de sess o respons vel pelo registro das decis es e especifica es produzidas Apenas as informa es relevantes s o documentadas segundo orienta o do l der de sess o O patrocinador det m a autoridade formal sobre as reas afetadas pelo sistema estabelecendo diretrizes e objetivos do projeto A equipe respons vel pelo conte do da sess o representando as reas envolvidas no projeto IV 8 4 3 A Din mica A base de trabalho a equipe presente
230. melhor ainda com o custo total de propriedade TCO Total Cost of Ownership do sistema com o valor equivalente dos benef cios trazidos pelo sistema Por exemplo um sistema que transforme um trabalho de 1 hora por dia de uma pessoa que ganha R 10 00 por hora para 15 minutos poupa R 7 50 por dia Isso corresponde a aproximadamente R 165 00 por m s ou ainda R 1980 00 por ano Como se admite que um investimento tenha retorno em dois anos o benef cio total causado apenas pela acelera o do processo em dois anos seria de R 3960 00 Caso esse fosse o nico benef cio do sistema esse valor seria ent o um limite superior para o TCO O uso de metas para nortear o desenvolvimento de sistemas uma proposta diferente das tradicionais porque as metas n o est o relacionadas a funcionalidades do sistema mas sim aos resultados obtidos quando inserimos o sistema novo no ambiente Assim devemos definir metas que possam ser verificadas quando o sistema for instalado Cada meta vir acompanhada de uma m trica uma medida objetiva que permite comprovar que a meta foi alcan ada Metas que n o possuem m tricas objetivas como satisfa o do cliente devem ser evitadas ou devem ser associadas a um instrumento de medida que permita verificar conceitos subjetivos nesse caso uma pesquisa de opini o Ao implantar um sistema de atendimento autom tico poder amos ter como metas e Acelerar o atendimento com a m trica tempo m dio
231. mem ria Para isso criamos um ou mais modelos do sistema descrevendo o com diferentes perspectivas e graus de detalhe a partir da an lise de desenvolvemos um sistema Ela simultaneamente um acordo entre os desenvolvedores e seus clientes e um mecanismo de comunica o entre os desenvolvedores Em ambos os casos a an lise define que servi os devem ser fornecidos pelo sistema a ser implementado e por conseqii ncia que servi os n o est o no escopo do sistema Segundo Pressman B5 todos os m todos de an lise devem ser capazes de suportar cinco atividades e Representar e entender o dom nio da informa o e Definir as fun es que o software deve executar e Representar o comportamento do software em fun o dos eventos externos e Separar os modelos de informa o fun o e comportamento de maneira a apresentar os detalhes de forma hier rquica e e Prover a informa o essencial em dire o determina o dos detalhes de implementa o Dessa defini o poss vel deduzir que para a an lise de um sistema ser til e de qualidade n o basta entender o que deve ser feito mas tamb m desenvolver uma representa o que permita documentar e comunicar essa informa o 1 1 1 Modelos de An lise V rios autores fizeram propostas de modelos para descrever a an lise de sistemas Dentro do conceito de an lise apresentaremos os seguintes modelos e Modelo de Neg cio que descrevem como
232. mento e resulta em reclama es que n o s o boas para a livraria 231 Claramente a primeira coisa que o sistema deve fazer suportar o nosso funcionamento di rio Estou falando da opera o b sica de atendimento aos clientes n o da cobran a ou outras coisas do g nero pois para essas vou comprar sistemas prontos A partir dessa opera o tamb m s o necess rios alguns dados para ajudar a gerenciar melhor a empresa Dois relat rios s o muito importantes para mim um relat rio de vendas em um per odo e um relat rio de gastos por fornecedor Outro relat rio que me ajudaria muito o de pedidos n o atendidos Os desenvolvedores devem se lembrar que essa empresa antiga e tradicional Tanto os funcion rios quanto a muitos dos clientes tem pouco h bito de usar computadores O sistema deve ser muito simples de ser usado Al m disso como pretendemos ter mais de um computador o sistema deve funcionar em rede Outra coisa importante que j compramos um sistema gerenciador de banco de dados por causa do sistema de ERP que instalamos O sistema tem que usar esse SGDB XI1 4 Entrevista 3 Sra L cia Pinho Funcion ria A seguir algumas informa es levantadas em uma reuni o com L cia Pinho funcion ria de confian a da Livraria ABC Fazemos as coisas do mesmo jeito aqui h muitos anos mas com a carga de trabalho aumentando concordo que um sistema de vendas pode ajudar O importante que se leve em con
233. mero do chassi temos 2 arquivos l gicos para contar Exemplos Uma nota fiscal um arquivo l gico com dois RET Ss dados da nota item de nota 220 X1 6 5 Identificando Arquivos Externos Arquivos Externos representam um grupamento l gico requerido pelo usu rio Podem incluir uma ou mais tabelas ou entidades Arquivos Externos s o mantidos por outras aplica es Arquivos importados contam tamb m como Entrada Externa arquivos exportados contam tamb m como Consulta Externa ou Sa da Externa X1 6 5 1 Identificando Itens de Dados DETs Itens de dados ou elementos de dados DET s campos nicos reconhecidos pelos usu rios desconsiderando se recurs o e repeti o DETs tamb m podem invocar a es Exemplos de DET s s o Em Entradas externas e campos de entrada de dados e mensagens de erro e valores calculados que s o guardados e bot es e mensagens de confirma o e campos repetidos contam apenas como um DET Em Sa das Externas e Campos em relat rio e Valores calculados e Mensagens de erro e Cabe alhos de coluna que s o gerados dinamicamente em um relat rio e Em Consultas Externas al m dos anteriores que se enquadrem e Campos usados em filtros de procura e O clique do mouse Em GUIs bot es onde s se pode fazer uma sele o entre muitas normalmente radio buttons devem ser contados como um DET apenas J check boxes s o normalmente contadas uma a uma Bot es de comando devem ser contados como um e
234. modelo veja o controle 2 da caixa 3 O ponto significa olhe especificamente para A42 13 A42 3 A42 3 No diagrama A32 veja a nota de modelo 3 Nota o opcional para No diagrama A32 veja a nota de modelo 3 usando barras verticais em vez de uma caixa para identificar a nota No diagrama A42 desse modelo veja a caixa 3 MFG A42 1 NO diagrama A42 do modelo MFG veja a caixa 1 Tabela 5 Nota o de refer ncia para o modelo IDEFO segundo IFIPS 183 O padr o IDEFO pede que um modelo seja publicado como no formato dado na figura a seguir Helpful text discussing current diagram This smaller diagram is the parent for the current diagram This is the current diagram Figura 34 Formato de publica o pedido pelo padr o IDEFO O tunelamento Existem duas posi es para colocar um tunelamento na forma de par nteses na extremidade pr xima a fun o ou na extremidade pr xima borda do diagrama 82 Quando colocado em torno da extremidade conectada a fun o isso significa que todas as sub fun es daquela fun o presentes no diagrama inferior possuem de forma impl cita essa seta A seta pode ser retomada se necess rio nos diagramas de n veis mais baixos sem nenhum problema ela pula um ou mais n veis do diagrama do mais abstrato para o menos abstrato Quanto colocado em torno da extremidade pr xima a borda do diagrama significa que essa seta exi
235. muito abstrato Geralmente com o objetivo de ensinar no es b sicas de geografia J uma carta n utica um mapa muito detalhado que permite a navios ou barcos menores navegarem de forma segura em uma regi o Ainda mais detalhada ser a planta de uma casa ou pr dio Os n veis de detalhe s o infinitos e s o usados de acordo com a necessidade do problema a ser resolvido 12 a Globo Terrestre b Mapa Antigo c Planta baixa decorativa Figura 24 Diferentes tipos de mapas ou seja modelos cada um com um n vel diferente de abstra o e dedicado a uma utiliza o distinta VI 3 Fun es de Neg cio As fun es de uma institui o s o os grupos de processos que gerenciam um recurso b sico da organiza o B20 Elas descrevem o que a organiza o faz devendo estar de acordo com os objetivos da empresa Fun es de neg cio mant m a organiza o em opera o formando um conjunto de atividades processos relacionadas que tem como objetivo alcan ar a miss o ou objetivos da empresa Segundo Modell B4 uma fun o deve e Seridentific vel e Ser defin vel por si s e em termos das atividades e responsabilidades associadas e N o necessariamente ser mensur vel o que influenciado pelo seu grau de abstra o e Al m disso ainda segundo Modell uma fun o pode e Ser uma rea principal de controle ou atividade da organiza o e Ser composta de uma ou mais s
236. n lise Em decorr ncia disso muito comum que um modelo de dados ou um modelo funcional desenvolvido e validado com o usu rio contenha falhas Isso acontece porque estes modelos s o modelos abstratos criados em uma linguagem mais pr xima e conhecida do desenvolvedor do que do cliente Este cap tulo n o fala profundamente sobre a quest o de como deve ser uma interface com o usu rio apenas apresenta alguns m todos de modelagem para a mesma com o intuito de fornecer aos interessados em um sistema uma vis o do seu comportamento funcionamento e apar ncia O leitor interessado nestas quest es deve procurar textos pr prios das seguintes reas Intera o Homem Computador Human Computer Interaction HCI Projeto centrado no usu rio user centered design Interface com o Usu rio User Interface UI Engenharia Cognitiva Projeto Participativo Participatory Design Ergonomia Avalia o de Interfaces com o Usu rio e ainda outras Uma boa dica consultar o site http www hcibib org X 1 A Intera o Homem Computador IHC Um sistema n o composto apenas pelo programa de computador mas tamb m por aqueles que se comunicam de programa sejam eles humanos ou outros programas Podemos mudar o projeto de um computador ou de um programa mas n o podemos mudar os seres humanos Precisamos ent o compreend los melhor para poder desenhar interfaces melhores A intera o homem computador corresponde a um ciclo onde cada
237. n o significa que n o existe restri o 121 No relacionamento 1 1 cada entidade s pode se relacionar com uma entidade do outro conjunto Geralmente indica semelhan a igualdade utiliza o conjunta etc No relacionamento 1 N cada entidade de um conjunto pode ser relacionar com v rias entidades do outro conjunto mas as entidades do segundo conjunto s podem se relacionar com uma entidade do primeiro conjunto Geralmente indicam rela es de posse hierarquia ou de composi o No relacionamento N M qualquer n mero de relacionamentos v lido Podem indicar v rias coisas como eventos contratos acordos liga es tempor rias como empr stimos e alugu is etc normal aparecerem tamb m quando o relacionamento do tipo 1 1 ou 1 N em certo momento ou per odo como o aluguel de uma fita de v deo mas se deseja manter a hist ria de todos os relacionamentos Quando falamos tamb m da cardinalidade m nima usamos nota o de par ordenado 0 1 1 N por exemplo onde o primeiro n mero do par indica a cardinalidade m nima e o segundo a m xima A cardinalidade m nima indica uma exig ncia da participa o de uma inst ncia da entidade em relacionamentos A cardinalidade m nima O em ambos os lados indica a exist ncia pr pria de ambos os objetos A cardinalidade m nima 1 pode indicar a necessidade de um objeto pertencer ou ser criado por outro comum evitarmos relacionamentos onde ambos os lados exijam como card
238. nar funcionalidades Priorizar requisitos baseados em custo e depend ncia Estudar como o sistema pode ser implementado de forma incremental investigando modelos arquiteturais apropriados Integra o e Valida o Resolver a maior quantidade poss vel de pontos em aberto Validar que os requisitos est o concordando com os objetivos iniciais Obter autoriza o e verifica o para passar ao pr ximo passo de desenvolvimento e g a demonstra o e a valida o Resolver conflitos e verificar consist ncia Tabela 2 Tarefas do processo de elicita o de requisitos adaptado de Christel e Kang B14 Existem muitas t cnicas avan adas de elicita o de requisitos que n o cabem no contexto desse livro Aqui trataremos de duas t cnicas b sicas que coleta de informa es a entrevista e reuni es de JAD IV 8 2 A entrevista Entre as t cnicas mais importantes de elicita o de requisitos est a entrevista Ela est constantemente presente dentro de outras t cnicas porque quase sempre a Elicita o de Requisitos em algum ponto exige comunica o direta com os usu rios e outros 45 interessados e a forma b sica de comunica o seja de que forma esteja disfar ada a entrevista A entrevista procura explicitar o pensamento do entrevistado a respeito das suas rela es com seu universo em determinada inst ncia tanto como indiv duo quanto como profissional revelan
239. ncarna o do sistema atual como quanto uma ferramenta de substitui o ou complementa o da an lise essencial A modelagem de processos demonstra como funciona a empresa passo a passo no seu dia a dia A partir dela pode ser poss vel levantar os pontos a serem automatizados de um processo e como os processos realmente realizados diferem dos processos normatizados da empresa A modelagem de regras de neg cio permite a compreens o da empresa de forma mais detalhada que os modelos anteriores As regras de neg cio podem ser utilizadas para ajudar a levantar o modelo essencial o modelo conceitual de dados ou para ajudar a implement los Em alguns m todos pode at mesmo ser utilizada no lugar desses modelos 15 E Does O organograma uma das formas mais simples e antigas de modelar uma empresa 70 Desenvolver T tica de Neg cio Confirmar Escopo Desenvolver Marcos de Neg cio Desenvolver Termos e Fatos Desenvolver Workflows Analisar Regras de Neg cio Analisar Produtos Servi os Capturar Regras Existentes Analizar Regras Produto Servi o Des Modelo de Terminologia Produto Servi o Formular Regras Produto Servi o Figure 22 Passos da Modelagem de Neg cios adaptado de Ross e Lam B19 VI 1 O Organograma Organogramas descrevem cargos por meio de ret ngulos e linhas hier rquicas por me
240. nciam v rios fatores como n vel cultural do entrevistado terminologia do trabalho jarg o da rea etc Devemos evitar ao m ximo usar os nossos termos t cnicos e aproveitar ao m ximo a oportunidade de aprender os termos t cnicos do entrevistado Se necess rio ler um pequeno texto esclarecedor sobre a rea e sempre ler o gloss rio do projeto O entrevistador deve sempre esclarecer com o entrevistado todas as d vidas quanto ao vocabul rio utilizado no ambiente onde o sistema ser implantado Marque a entrevista com anteced ncia com confirma o de data hora dura o e local por todas as partes As seguintes regras devem ser observadas quanto ao hor rio e As entrevistas devem ter 30 60 ou 90 minutos e no m ximo duas horas e As entrevistas iniciais podem ser mais longas enquanto as entrevistas finais devem ser mais r pidas e Evite hor rios perto da hora do almo o ou no final de expediente ou em uma tarde de sexta feira ou v spera de feriado e Obtenha o telefone do entrevistado para poder avis lo de sua aus ncia em caso de urg ncia e Chegue sempre 10 minutos adiantado e esteja preparado para esperar e para ter que encerrar a entrevista mais cedo principalmente com a alta ger ncia 49 e Se poss vel caso a entrevista seja mais curta que o combinado marque imediatamente a sua continua o e Quanto ao material necess rio para uma entrevista al m do roteiro e Prepare e teste o equipamento
241. ndo a identifica o n mero do r tulo Caixas s o retangulares com cantos arredondados 76 IDEF KIT DIAGRAM FORM Es or Re T E 37V sa Pupa Rev CT FECOMMENDED Notes O FUBLICATION a AUTHOR Norm Woki DATE 11 92 READER PROJECT Reerngneerina Quil Computers REV 385 DRAFT E RECOMMENDED NOTES 67 PUSLICATION RO Approved designs Manage Advertising 110 713 1 Take Orders 557 4722 Customer calls Request for pricing Develop Documentatio NOTE 126 945 Camera ready ads are produced proofed Intemaly and are sert electronicaly to publications Advertising Policy For any Item whose price Is expected to change whlie the ad Is running the price should be replaced with CALL FOR PRICE Pricing Policy Determined Dy activity based costing Credit Policy Credit card Approval Dy card issuing bank Checks accepted order not to be shipped until check claars TE Seil amp Market Products NUMBER TE CONTEXT E Pi o ocumentaton Work ticket preparation information Camera ready ads and product documentation Prepare Work Ticket 175 838 5 Figura 28 Um diagrama IDEFO t pico em seu formul rio padr o Segundo o software Allfusion Process Modeller previamente BPWin e Cada diagrama deve conter todas as setas que entram e saem do seu diagrama superior que podem ser indicadas pela seguinte nota o conhecida como ICOM 2 BPWin Meth
242. neg cio processo x dados utilizados ou orientados a objetos casos de uso x objetos Na pr tica uma tabela de trabalho muito interessante que permite a visualiza o r pida da rela o entre funcionalidade e dados Como usaremos esta tabela para relacionar eventos e entidades deixaremos esse tema para ser tratado mais tarde na unifica o dos modelos funcional e de dados rocesso A rocesso B rocesso C rocesso D rocesso E rocesso F o do Procesog processoc processoD Processor Processor d Figura 49 Exemplo simplificado de uma Matriz CRUD VI 7 3 Corrente Planejado Esta tabela indica que processos s o correntes e que processos est o apenas planejados Pode ser feita tanto a n vel de neg cios quanto a n vel de sistemas No primeiro 103 caso estamos interessados nos processos correntes ou implementados no dia a dia da empresa No segundo caso estamos interessados em processos automatizados Corrente x Planejado Cadastro de Corrente Fornecedor Cadastro de Pedidos Planejado Cria o de Pedidos Planejado Tabela 11 Exemplo de tabela Corrente x Planejado VI 8 Resumo da Modelagem de Neg cio N o h uma forma correta nica de se fazer a modelagem de neg cio Recomendamos que sempre seja levantado o organograma da empresa A seguir os modelos podem ser escolhidos e levantados de forma adequada a um processo ou projeto espec fico No cap tulo vimos em ordem decrescente de ab
243. nipulando a Matriz CRUD Manipula se a Matriz CRUD para se obter subsistemas Um subsistema identificado pela forma o de um cluster isto um grupo de c lulas pr ximas com as mesmas caracter sticas que no nosso caso estarem sendo usadas A manipula o feita alterando se as posi es das linhas e das colunas Com isso poss vel agrupar atividades e entidades que se relacionam mais fortemente em grupos permitindo a identifica o de subsistemas Os subsistemas interagem normalmente por meio da leitura por um processo de uma entidade mantida em outro processo A Figura 83 tenta mostrar a din mica da manipula o da Matriz CRUD com objetivo de encontrar subsistemas Essas opera es s o facilmente feitas em uma planilha eletr nica As opera es de transposi o de linha ou coluna podem ser feitas em qualquer ordem O objetivo obter uma matriz onde as c lulas pr ximas a diagonal sejam bem preenchidas formando os grupos que caracterizam os subsistemas enquanto as outras c lulas est o normalmente vazias apresentando eventualmente opera es que indicam a intera o entre dois subsistemas De certa forma manipular a Matriz CRUD dessa forma uma a o equivalente a manipular o DFD Global para se obter o DFD Hier rquico A diferen a b sica que ao tratar a Matriz CRUD estamos em busca de achar configura es da mesma que definam 162 subsistemas de maneira clara enquanto quando estamos grupando proc
244. nou uma ferramenta obrigat ria em todos os cursos de an lise de sistemas Em um DFD o sistema descrito pela composi o de quatro objetos b sicos agentes externos que interagem com o sistema processos ou fun es que caracterizam o sistema mem rias que cont m os dados necess rios o sistema funcionar e fluxos de dados entre esses objetos A An lise Estruturada e outras t cnicas equivalentes se propunham a tratar das quest es l gicas do desenvolvimento do sistema em detrimento das quest es f sicas que seriam tratadas na fase de projeto O problema que nenhuma t cnica deixava claro quais eram essas quest es ou melhor como diferenciar o f sico do l gico Al m disso ainda foram encontrados v rios problemas na An lise Estruturada entre eles a dificuldade de manter o modelo atualizado e a possibilidade de v rias pessoas fazerem modelos diferentes de um mesmo sistema O primeiro problema atendido pelo uso de ferramentas CASE importante deixar claro que imposs vel desenvolver uma verdadeira An lise Estruturada sem o uso de software para manter essa an lise atualizada e correta O segundo problema por m muito mais grave pois ele n o trata da forma de uso mas do m todo propriamente dito 49 Devemos entender que quando nos propomos a descobrir o que o sistema deve fazer estamos simultaneamente evitando nos preocupar com como o sistema deve fazer o que ser
245. o etc 1 4 Modelo de Entidades e Relacionamentos O Modelo de Entidades Relacionamentos segundo Paulo Cougo B31 descreve o mundo como cheio de coisas que possuem caracter sticas pr prias e que se relacionam entre si Essas coisas podem ser pessoas objetos conceitos eventos etc Elas s o as entidades A priori s exigimos de uma entidade que ela possa ser identificada distintamente isso tenha identidade pr pria Cada coisa distintamente identificada uma inst ncia Por exemplo o funcion rio Jos uma inst ncia da entidade funcion rio a aluna Maria uma inst ncia da entidade aluna As entidades ou melhor suas inst ncias s o classificadas em tipos ou classes No nosso caso funcion rio e aluno s o os tipos de entidade Estamos usando nesse momento a abstra o de classifica o resumir uma quantidade de caracter sticas comuns por meio da cria o de uma classe Assim sabemos que o funcion rio Jos e o funcion rio Joaquim por serem inst ncias de um mesmo tipo possuem caracter sticas comuns como trabalhar na empresa ter um sal rio etc No diagrama de entidade e relacionamentos cada tipo de entidade representado por um ret ngulo identificado pelo nome do tipo Normalmente confundimos o termo entidade com o tipo da entidade deixando o termo inst ncia e algumas vezes registro para falar de uma entidade identificada Apenas algumas entidades do mundo real ou imagin rio s o
246. o n o haveria necessidade de implementar um novo sistema Assim devemos entender que a verdadeira motiva o que o cliente tem em chamar uma equipe de desenvolvimento de sistema a de corrigir os seus problemas principalmente os que mais afetam negativamente o seu neg cio Um problema pode ser classificado como e De neg cio e Funcional e Operacional Um problema operacional ocorre quando uma funcionalidade do sistema funciona de forma errada Por exemplo na automatiza o do processo de ger ncia das contas pedido e fechamento de conta de um restaurante problemas operacionais comuns s o a dificuldade de fechar a conta e os erros de c lculo que acontecem Um problema funcional ocorre quando o sistema n o permite uma funcionalidade No mesmo sistema de contas de restaurante por exemplo pode ser imposs vel ou muito dif cil saber quanto cada gar om vendeu em um dia Finalmente os problemas de neg cio est o relacionados manuten o do neg cio propriamente dito e podem tanto ser isolados quanto causados por problemas operacionais ou funcionais Um problema operacional como a demora ao calcular o valor final de uma conta pode causar um problema de neg cio como filas na sa da do restaurante Para identificar problemas podemos adotar algumas estrat gias B15 como verificar os resultados obtidos atualmente nos processos e compar los com objetivos da empresa ou padr es do mercado observar o comportamento dos empreg
247. o podem ser os principais fornecedores de metas para o sistema Assim se o problema for lentid o o aumento do desempenho uma meta importante Da mesma forma se o problema for a dificuldade de utiliza o a meta pode ser facilitar a utiliza o do sistema e as m tricas podem estar relacionadas ao tempo de aprendizado ou ao n mero de erros na entrada de dados V 9 Vis o do novo sistema Devemos tentar responder como vai funcionar o novo sistema em uma descri o simples em linguagem corrente Chamamos essa descri o de Vis o do novo sistema Essa vis o deve ser escrita com forte apoio do cliente sen o pelo pr prio cliente Normalmente a Vis o e a descri o do sistema atual t m o mesmo n vel de abstra o dentro de uma mesma proposta inicial A vis o pode incluir o prot tipo de algumas telas do novo sistema com a finalidade de mostrar a diferen a do sistema novo para o velho ou ainda mostrar como ser o comportamento de uma nova finalidade A vis o do sistema pode incluir n o s o funcionamento do sistema mas tamb m expectativas de comportamento e de efeitos do sistema no neg cio Deve ficar claro que a vis o do sistema uma declara o do usu rio n o necessariamente um comprometimento do desenvolvedor Isso por m deve ficar claro na documenta o A vis o do sistema inclui tamb m os requisitos j detectados informalmente pelo analista Como descrito no cap tulo anterior esses requisitos pode
248. o temos que construir o DFD nivelado por meio da explos o de cada processo e cria o de um DFD espec fico para cada explos o respeitando se todas as regras normais de cria o de Diagrama de Fluxos de Dados cap tulos 240 ndice Abstra o 72 106 185 187 Classifica o 45 100 106 159 165 Composi o 106 107 Generaliza o 97 106 107 181 184 Agente Externo 235 An lise 18 19 39 An lise Essencial 4 39 145 146 princ pio da neutralidade tecnol gica 147 an lise estruturada 145 An lise Estruturada 145 146 Ator 114 162 172 174 Boehm Barry 24 25 213 226 Caso de Uso 27 150 174 179 180 182 183 184 185 186 187 190 192 193 Fluxo Alternativo 174 Fluxo Principal 174 179 188 Cen rio 188 Cen rios 174 175 176 227 Chen Peter 112 120 130 133 Comportamento 51 Cor 141 DENIM 206 207 Diagrama de Entidades e Relacionamentos 100 101 106 109 111 112 113 171 Diagrama de Fluxe de dados hier rquivo 238 Diagrama de Fluxo de Dados 145 150 156 161 162 164 167 171 173 225 235 236 237 238 239 240 de contexto 236 238 239 n vel zero 238 nivelado 238 particionado 239 Engenharia de Informa o 112 130 Entrevista 47 48 52 230 231 232 Aberta 47 Estruturada 48 por Question rio 47 EPC 5 70 87 88 90 91 104 est mulo 150 152 153 156 164 165 210 Evento 40 145 154 159 164 167
249. o Software Como medir software Pre o Esfor o Tamanho Medidas diretas Medidas indiretas Pontos de Fun o COCOMO XI 1 Qual o tamanho do sistema Uma das perguntas mais freq entes em desenvolvimento do software qual o tamanho do sistema Essa pergunta pode vir sob v rias formas e Qual o pre o do sistema e Qual o custo do sistema e Qual o esfor o para desenvolver o sistema e Quantas pessoas ser o necess rias para fazer esse software e Em quanto tempo o sistema ficar pronto e Quantas linhas de c digo tem o sistema e Quantos pontos de fun o tem o sistema e Qual o tamanho do sistema e Que recursos s o necess rios para o sistema Nesse cap tulo veremos como responder essas quest es XI 2 Pre o e Custo Quando queremos saber o pre o ou o custo do sistema a preocupa o econ mica No nosso contexto vamos separar os conceitos de custo e pre o custo quanto se gasta para desenvolver o sistema pre o quanto se cobra pelo sistema Apesar de existir uma rela o entre pre o e custo cabe aos respons veis pelo desenvolvimento prever acompanhar e calcular o custo do sistema incluindo muitas vezes n o s o desenvolvimento mas tamb m o custo de implanta o opera o e manuten o O pre o por m determinado por uma rela o comercial entre cliente e fornecedor Fica claro ent o que a principal e primeira pergunta que o desenvolvedor deve fazer
250. o a seguir onde um atributo transformado em uma entidade dependendo do momento da especifica o Muitas vezes uma entidade na verdade cont m dados que comp e duas entidades e Transforma atributo ou conjunto de atributos em entidade e relacionamento isso pode acontecer quando um atributo m ltiplo quebrando a primeira forma normal uma especifica o por exemplo uma marca ou ainda em casos que quebram a segunda e terceira forma normal e Cria o de entidades mais espec ficas algumas vezes identificamos inicialmente uma entidade que um tipo muito geral e mais tarde descobrimos tipos espec ficos que representam melhor o dom nio da aplica o e Transformar uma entidade em v rias entidades n o relacionadas isso n o muito normal pois entidades n o relacionadas normalmente n o se encontram modeladas dentro de uma mesma entidade mesmo que temporariamente Mesmo assim pode ser um primeiro passo para depois descobrirmos qual o relacionamento que as une e Transformar um relacionamento em dois relacionamentos em paralelo apesar de n o acontecer muitas vezes em um mesmo sistema uma transforma o comum Acontece quando entendemos que duas entidades s o relacionadas e apenas mais tarde compreendemos que elas s o relacionadas de v rias formas diferentes e n o de uma s forma e Transformar um relacionamento em uma entidade essa modifica o muito comum Muitas vezes nossa compreens o inicial
251. o de regras regras Pode n o ser relevante Relevante Relevante Execut vel Pode n o ser at mica At mica At mica Pode ser procedural Fragmento de conversa o de neg cios Pode n o ser declarativa Declarativa Declarativa Z Poden oserprecisa N o totalmente precisa Precisa o Z Pode ser incompleta Pode ser incompleta Completa Pode n o ser confi vel _____ Confi vel Confi vel Z Poden o ser aut ntica Aut ntica Aut ntica O e Bons Pode ser inconsistente Pode ser inconsistente Consistente Tabela 7 Formas de descrever regras de neg cio e suas caracter sticas adaptado de B29 Halle B29 prop e uma classifica o e um conjunto de templates que pode ser utilizado para descrever regras de neg cio aqui adaptado para portugu s apresentado na tabela a seguir 99 Classifica o Descri o Detalhada Template Conhecimento inferido Iniciador de a o deveriam ser verdade em informa es fornecidas ao sistema input Senten as que expressam circunst ncias que levam a novas informa es Senten a expressando condi es que levam ao in cio de uma a o Termo Nome ou senten a com uma defini o lt termo gt definido como lt texto gt acordada que pode ser e Conceito classe entidade e Propriedade detalhe atributo Valor e Conjunto de valores Fato Senten a que r
252. o iniciante confunda uma resposta a um evento com um evento Para isso podemos usar uma t tica de verifica o perguntar por que um evento acontece Se a resposta for Esse evento acontece porque o usu rio X enviou um dado ou 160 porque se passaram X dias estamos em um bom caminho e provavelmente temos um evento Por m se respondermos com algo do tipo Esse evento acontece porque o sistema ou Esse evento acontece quando verdade que ent o estamos em um mau caminho pois n o existem eventos gerados pelo sistema para o sistema Outra coisa importante verificar se existe algum motivo para o sistema come ar a funcionar sozinho o evento Se n o existe provavelmente escolhemos como evento algo que resposta para outro evento Um exemplo muito comum acontece em casos especiais Vamos supor que temos um sistema que deve produzir um relat rio a cada 100 vendas informadas por cada vendedor A resposta correta ter um evento Vendedor informa venda com uma sa da al m das outras necess rias Relat rio de Vendas Geralmente analistas iniciantes inventam um evento especial Vendedor faz cent sima venda Vamos tentar aplicar nossos princ pios Temos um que diz N o surpreenda o usu rio Seria uma surpresa para o usu rio ter que usar uma tela diferente e ele mesmo controlar sua cent sima venda Muito mais natural seria que o sistema controlasse isso Outro princ pio
253. o nenhuma informa o sobre a l gica de execu o como repeti es ou condi es Qualquer fluxo de dados ou processo presente pode De certa maneira descri es feitas com DFDs s o semelhantes a descri es feitas com diagramas IDEFO pois estes s o descendentes de uma outra nota o SADT que era usada de forma alternativa a DFDs 236 ou n o executar uma ou mais vezes Na verdade existem t cnicas especiais para derivar rela es de controle entre processos a partir da estrutura de um DFD Essas t cnicas por m n o se aplicam ao caso em estudo nesse livro pois n o s o muito eficazes para desenvolver sistemas Cliente Servidor Finalmente o DFD tamb m n o informa se algo acontece ou seja se os fluxos de dados realmente comunicam os dados entre os processos mas sim que algo pode acontecer ou seja que poss vel que um processo envie seus fluxos de dados XI1 6 1 Algumas regras sint ticas Dados s podem passar de agentes externos para mem rias por meio de um processo Agentes externos ou mem rias tamb m n o podem se comunicar diretamente Isso significa que fluxos de dados devem come ar ou acabar em um processo Processos devem ler alguma informa o de um agente externo outro processo ou mem ria e gerar alguma informa o para um agente externo outro processo ou mem ria N o existem processos que criam informa o do nada fontes nem processos que consomem informa o buraco negro
254. o principal depois das a es corretivas ou n o e Finaliza o de uma exce o o Voltar ao in cio do caso de uso o que n o muito comum o Voltar ao in cio do passo que causou a exce o e execut lo novamente o que mais comum o Depois das a es corretivas ao inv s de voltar para o mesmo passo ir para o passo seguinte Isso pode ser feito quando as a es corretivas realizam a opera o que o passo deveria ter executado Por m deve se verificar se novas exce es n o poderiam ainda ocorrer neste mesmo passo o Abortar o caso de uso Neste caso n o se retorna ao fluxo principal Requisitos Especiais e Requisitos n o funcionais associados ao caso de uso como e efici ncia desejada e tecnologia de implementa o e etc Varia es Tecnol gicas e de Dados e Seforo caso indique as diferentes formas de realizar tecnologicamente os diferentes passos do caso de uso Quest es em aberto e Tudo o que deve ser esclarecido posteriormente Um BOM caso de uso e Corresponde a um processo elementar da empresa e N O um passo nico como deletar um item ou imprimir um relat rio 189 IX 13 N O leva dias ou m ltiplas sess es como negociar um contrato E uma tarefa conclu da em uma sess o e que produz um resultado mensur vel deixando as informa es em um estado consistente Como descobrir casos de uso Estabele a o limite do sistema o que est fora e o que est dent
255. o processo de desenvolvimento de software constantemente s o propostas novas t cnicas com a finalidade de acelerar o processo de desenvolvimento Entre elas podemos citar a pr pria prototipagem Rapid Application Development RAD Adaptative Programming Extreme Programming e toda uma gama de processos geis Cumulative Cost Progress though steps Evaluate altematives Determine identihy resolve risks objectives altemaltives constraints Operational Prototype Commitment parttion Review Requitements Plan life cyde Plan Concept of Operations Development Requirements Plan Yalidation Integration and Test Plan Design validation and verification Acceptance Ites Implementation Plan nest phases Develop verify nextlevel product Figura 8 O processo espiral como definido originalmente por Boehm 1988 4 i n Em contrapartida com o caso normal onde um ganha e os outros perdem ou ainda pior com os casos onde a decis o tomada vista como uma situa o onde todos perdem 25 HI 3 A Equipe de Desenvolvimento A equipe de desenvolvimento o conjunto de pessoas respons veis por construir o software Dela fazem parte pessoas com diferentes habilidades Em sistemas de informa es tradicionais teremos gerentes de desenvolvimento analistas projetistas programadores administradores de banco de dados etc Em si
256. o que fazer e nunca com o como fazer Como estaremos seguindo os princ pios da an lise essencial esta quest o ficar inicialmente ainda mais restrita pois o modelo essencial n o pode conter nenhuma refer ncia tecnologia sob o risco de produzir requisitos falsos Isso n o quer dizer que o analista n o possua as informa es sobre a tecnologia apenas que n o as usa enquanto faz o trabalho de an lise Na pr tica estamos sempre limitados por escolhas como linguagens sistemas gerenciadores de bancos de dados arquiteturas de rede e de computador O que devemos fazer n o deixar que essas limita es influenciem nossas decis es sobre o que deve fazer o sistema Da mesma forma n o queremos dizer que o analista deve ignorar essas quest es ao trabalhar Ele deve anot las pensar em seus impactos por m n o deve traz las para o modelo criado na an lise 1 1 4 O Analista de Sistemas O Analista de Sistemas o respons vel por levantar os requisitos do sistema e transform los em uma especifica o do que deve ser feito i e a An lise do Sistema Para isso assume v rios pap is B4 rep rter detetive consultor diagnosticador investigador organizador solucionador de problemas avaliador simplificador artista escultor arquiteto auditor especialista de organiza o e m todos especialista do dom nio da aplica o gerente etc O porqu dessa longa rela o de pap is o fato de o
257. o valor de um atributo por exemplo para responder a perguntas como quanto custava uma liga o telef nica no dia 14 de novembro de 2001 como manter um hist rico de relacionamentos por exemplo para saber quais fitas o cliente alugou no passado permitindo que uma fita seja alugada v rias vezes No caso de necessitarmos de um hist rico do valor do atributo necess rio criar uma nova entidade que represente o valor e a data de validade desse valor sendo que essa entidade se relaciona com a entidade original No caso de necessitarmos que um relacionamento seja mantido no hist rico necess rio criar atributos que indiquem a validade desse relacionamento Na pr tica o relacionamento se torna uma entidade 1 14 Formas Normais As formas normais foram criadas para o modelo relacional para serem aplicadas no modelo l gico por m existem vantagens em utiliz las no modelo conceitual pois melhoram a qualidade do modelo em rela o a alguns quesitos O ato de normalizar implica na cria o de algumas tabelas que n o s o necessariamente criadas pelo analista preocupado apenas com o modelo conceitual influenciando sua longevidade e simplicidade total diminuindo a 42 a f aai Eber z Mas n o precisam ser obrigatoriamente substitu dos Modelos conceituais admitem e at ficam mais claros com a presen a de relacionamentos nxm E Principalmente relacionamentos 1 1 1 1 Qual o motivo de ter um par de en
258. odelo deve responder e Exemplos Quais as tarefas do atendente Quais as tarefas do arrumador Como os produtos circulam na loja Desenvolva o ponto de vista Defina o escopo do sistema D um nome ao sistema Use um nome condizente com o escopo definido e Normalmente o nome de um sistema utiliza termos bastante gen ricos Defina os ICOMS principais Defina as sa das incluindo as sa das que acontecem quando o processo n o acontece de forma satisfat ria e Todas as sa das poss veis do processo devem estar presente no modelo Defina as entradas e As entradas devem ser processadas para gerar as sa das e Normalmente o nome de uma entrada n o permanece o mesmo na sa da e Algumas vezes entradas recebem adjetivos como simples ou sa das recebem adjetivos como verificada para demonstrar que apesar de n o haver uma modifica o houve um processamento da entrada para a sa da Defina os mecanismos Defina os controles Lembre que todas as atividades possuem ao menos um controle 85 e Controle existem na forma de regras pol ticas procedimentos padr es etc e No caso de indecis o entre entrada e controle modele como controle 17 Numere as atividades e diagramas 18 Se necess rio decomponha as atividades 19 Repita o processo de modelagem mantendo a consist ncia 20 Se necess rio construa modelos FEO apenas para informa o e Por exemplo para indicar outro ponto de vista e Para ilu
259. odem ser usados em discuss es com o usu rio com certa facilidade Al m disso servem tamb m para dar aos desenvolvedores uma vis o geral do comportamento do sistema 208 pe q Sha Apaga OhfCencel Ine virEcitar Edita gacelar Espa Associa Usu rio A Usu rio Papel Cae Tela Iniciat Inicial g Me Ra s hzl vedar Edta Assoclar Permiss o Associa E Listar P Pap is j Permiss o fm OeCanesl mm Agags CkfCarcal DER gd PR O Cancol os n Liziar a Inelut 4rar tai tao Edita Ok Caresl Permiss o Apaga EA Asaga f Permitido Figura 115 Um diagrama de navega o de telas feito com o software PowerPoint X 5 Organizando Informa o Uma das tarefas mais dif ceis na modelagem da interface como organizar a informa o a ser apresentada De acordo com Shedroff BlJexistem 7 formas b sicas de organizar a informa o 31 Alfabetos que na pr tica n o tem nenhum significado especial mas s o ensinados desde a inf ncia Assim a ordem alfab tica apesar de totalmente artificial quem disse que a letra M vem antes da letra V se tornou natural para as pessoas 32 Locais principalmente quando podemos associar imediatamente a informa o a uma refer ncia geogr fica 33 Tempo organizando a informa o pela segii ncia em que os fatos ocorrem no tempo 34 Cont nuos na forma de n meros ou outra escala como estrelas para um hotel ou escalas c
260. oderia fazer para um cliente e Resumo Executivo e Apresenta o do Documento e Identifica o do Projeto o Objetivo o Identifica o do Cliente o Identifica o do Prestador de Servi o o Hist rico do Apresentador de Servi o e Proposta T cnica o Pequena Descri o da Solicita o do Cliente o Objetivo do projeto implementar o sistema que tem um objetivo para cumprir no neg cio 67 o Descri o Sucinta do Sistema Atual o Stakeholders o Identifica o de Problemas o Descri o do Sistema Proposto Objetivo do Sistema Objetivos de Neg cios e Interesses Metas e M tricas para avalia o das Metas Escopo Vis o Requisitos Funcionais Iniciais Requisitos de Informa o Iniciais Requisitos N o Funcionais Iniciais Pontos Cr ticos Restri es Gloss rio o Identifica o de Oportunidades e Proposta Comercial o Cronograma Proposto o Investimento Proposto o Exclusividade o Forma de pagamento o Reajustes o Renegocia o o Confidencialidade o Outras Cl usulas opcionais V 14 Exerc cio V 14 1 Projeto 1 Livraria ABC Fa a uma proposta inicial para a Livraria ABC V 14 2 Projeto de curso Os grupos devem fazer uma proposta inicial de acordo com o item V 13 e apresent la ao professor para discuss o e aprova o 14 E x Faa Sutilmente o pre o do sistema proposto como investimento o que de fato verdade na vis o da empresa cont
261. ods Guide Logic Works Inc 1997 11 Controle C1 C2 C3 contados da esquerda para a direita na caixa explodida A cada revis o deve ser marcado um n mero de revis o no diagrama ver NOTES 123 sa Caixa M e zT Detalhad no lt A Diagrama Pa e Z 7 no Detalhado 1 7 E I2 gt A m c3 l y Up Detalhado 2 gt gt 0 2 Figura 29 Exemplo de numera o ICOM e seu significado Entradas I1 I2 I3 contadas de cima para baixo na caixa explodida Sa das O1 O2 03 contadas de cima para baixo na caixa explodida Mecanismos M1 M2 contados da esquerda para a direita na caixa explodida e Setas denotam objetos ou dados por isso devem ser substantivos As setas s fazem curvas de 90 n o apresentam inclina es Setas n o representam fluxo mas sim como os dados e objetos necess rios para o funcionamento de uma fun o s o obtidos Setas podem ser tuneladas Isso significa que n o apareceram no diagrama filho de uma caixa mas apenas em diagramas netos Para tunelar uma seta coloque par nteses em torno da ponta ou da raiz da seta formando um t nel 78 parent parent diagram child Pad diagram ad This arrow position C2 is not shown on child diagram This output is not shown connecting to the parent box Figura 30 Exemplo de tunelamento e DRE na caixa 2 do diagrama A1
262. ogramadores seniores que por sua vez podem delegar tarefas aos programadores juniores Alguns desses programadores comp em uma equipe de teste O Programadores HE g ia pin Administrador PEA Senior Bibliotec ria E Junior tm Figura 12 Equipes do tipo programador chefe se baseiam na capacidade do programador chefe Os m todos mais modernos como RUP e XP falam de pap is necess rios nno processo Pap is t picos do RUP s o Analista de Sistema Arquiteto Especificador de Use Case e Projetista de Interface com o Usu rio Engenheiro de Casos de Uso e Engenheiro de Componentes J os pap is do XP s o o comprador ou GoldOwner o cliente ou GoalDonor o gerente o testador o programador o monitor ou tracker e o treinador ou coach Em ambos os casos pap is diferentes podem ser assumidos pela mesma pessoa importante notar que no caso do XP os dois primeiros pap is s o do cliente 27 Existem muitas outras formas de organizar equipes Cada tipo de produto exige um tipo especial de equipe Afinal n o desenvolver amos um software para controle de v o de um avi o com o mesmo tipo de equipe para o qual desenvolvemos um software para controle de uma biblioteca Ill 4 Exerc cios 13 Descreva de forma sucinta os seguintes processos descritos na literatura 1 RUP Rational Unified Process 2 XP eXtreme Programming 3 Adaptative Software Development 1
263. olado O 1 2 Aplica o em batch com entrada ou exclusivo impress o remota 1 1 3 Aplica o em batch com entrada e impress o remota 2 1 4 A aplica o um front end que necessita de executar coleta de dados ou teleprocessamento para um sistema de fazer o processamento em batch ou de consultas 3 1 5 A aplica o mais que um front end por m s executa um tipo de protocolo de teleprocessamento 4 1 6 A aplica o mais que um front end e executa v rios protocolos de teleprocessamento 5 Como ser tratada a distribui o de dados e processamento O usu rio exige tempos de resposta ou throughput ou seja o desempenho cr tico Qu o fortemente utilizada a plataforma hardware onde a aplica o vai ser executada Qual a fregii ncia das transa es di rias semanais altas o suficiente para exigir um estudo de desempenho Que percentagem das informa es inserida on line 6 1 Se mais de 30 das transa es forem entradas de dados interativas a nota 5 A aplica o projetada para efici ncia para o usu rio final Quantas ILFs s o alteradas por transa es on line A aplica o tem processamento l gico ou matem tico extensivo A aplica o desenvolvida para atender um ou muitos tipos de usu rios diferentes Qual a dificuldade de convers o e instala o Qual a efici ncia e grau de automa o de inicializa o backup e recupera o A aplica o foi especialmente proj
264. olu o eaturas Figura 14 Enquanto as necessidades surgem no mundo dos problemas caracter sticas e requisitos definem a solu o desejada Um problema uma diferen a entre uma situa o percebida e uma situa o desejada Mais tarde vamos analisar v rios tipos de problema No momento nos basta a no o que o problema incomoda o usu rio ou stakeholder ao ponto dele considerar necess rio investir alguma quantia de forma a evitar que o problema aconte a Z E comum ouvirmos o ditado Em time que est ganhando n o se mexe Quando somos chamados para desenvolver um sistema devemos imaginar imediatamente que se algu m deseja mexer em sua organiza o ent o porque n o est ganhando pelo menos da maneira que sup e poss vel Faz pouco sentido imaginar que algu m iria fazer um investimento de risco e sempre h risco no desenvolvimento de software sem que haja uma necessidade clara No pr ximo cap tulo veremos que um sistema precisa al m de um objetivo funcional metas de neg cio que visam determinar como ser a solu o para problemas espec ficos 4 Problema o Percebido Desejado Figura 15 O problema uma diferen a entre uma situa o percebida e uma desejada Muitas vezes o analista se depara com a necessidade de antes de definir requisitos definir propriamente qual o problema a ser tratado Para isso deve fazer com que os clientes cheguem a um acordo sobre qual o verdadeiro probl
265. ome a realmente a progredir quando a equipe de desenvolvimento compreende o discurso dos clientes Para isso nas primeiras entrevistas ou reuni es feito um esfor o para levantar um gloss rio de termos e mais tarde muitos desses termos podem aparecer no Modelo Conceitual de Dados do sistema Um exemplo tirado de um sistema governamental e Contribuinte a pessoa f sica ou jur dica respons vel pelo pagamento de um imposto A defini o de um termo muitas vezes envolve uma rela o com outros termos como no exemplo acima Um termo pode ser um tipo uma classe ou um literal uma inst ncia No caso de regras de neg cio costumamos trabalhar principalmente com tipos Um tipo especial de tipo um sensor que representa algo que detecta e reporta valores que mudam constantemente no ambiente mundo externo Existe um sensor especial o rel gio que relata a passagem do tempo cujo valor sempre o instante corrente data e hora corrente Os termos definidos s o reunidos em um gloss rio e em um dicion rio de dado Declara o de Fatos A partir dos termos devemos construir senten as que descrevam o neg cio a partir das rela es entre termos e da estrutura criada por essas rela es Normalmente esses fatos s o caracterizados nas entrevistas e reuni es a partir de declara es do cliente de como o neg cio funciona Fatos relacionando termos s o bastante f ceis de serem encontrados Muitas vezes encontramos pr
266. omparativas o alfabeto uma escala comparativa especial onde temos uma no o de ordem Organizando desta forma estamos indicando que a escala escolhida a mais importante naquele contexto 35 N meros que n o representam um cont nuo por exemplo o Sistema Decimal de Dewey N meros apresentam a vantagem de ser uma representa o mais universal que alfabetos 36 Categorias ou seja juntar objetos semelhantes 37 Aleat rios que n o uma forma de organiza o mas sim uma forma de desafiar e de apresentar dados para serem explorados ou melhorar a experi ncia do usu rio X 6 Tipos de Erros Conhecendo os poss veis tipos de erros podemos prev los e evitar que aconte am por meio de algum mecanismo de interface 209 Segundo B44 existem 6 tipos de erros e Erros de Captura e Erros de Descri o e Erros Causados por Dados Externos e Erros por Ativa o Associativa e Erros por Falta de Ativa o e Erros por Modos X 6 1 Erros de Captura Acontece por exemplo se estamos acostumados a contar cartas e vamos contar cart es de cr dito Poder amos falar algo como 1 2 3 10 valeta dama rei Esses erros acontecem quando executamos 2 segii ncias de a es diferentes com um est gio inicial comum sendo uma muito mais praticada que a outra Algumas vezes ao realizar a menos comum automaticamente passamos a executar a mais comum Dizemos que a mais comum captura a menos comum Raramente pode acontecer
267. onstruir uma narrativa numerada Na primeira forma cada passo representa uma intera o completa entre o ator e o sistema Na segunda forma cada passo representa uma a o simples do ator ou do sistema 1 Cliente passa seu cart o no caixa eletr nico e o sistema apresenta solicita o de senha 2 Cliente digita senha e o sistema exibe menu de opera es dispon veis 3 Cliente indica que deseja realizar um saque e o sistema requisita quantia a ser sacada 4 Cliente informa quantia a ser sacada e o sistema fornece dinheiro e recibo Fig 93 Caso de uso descrito na forma de uma narra o numerada onde cada passo uma intera o Cliente passa seu cart o no caixa eletr nico Sistema apresenta solicita o de senha Cliente digita senha Sistema exibe menu de opera es dispon veis Cliente indica que deseja realizar um saque Sistema requisita quantia a ser sacada Cliente informa quantia a ser sacada DO Edo ON O AR DO AD e Sistema fornece dinheiro 9 Sistema imprime recibo Fig 94 Caso de uso descrito na forma de uma narra o numerada onde cada passo uma a o IX 3 3 Descri o particionada Na narrativa particionada o caso de uso descrito em uma tabela onde cada coluna representa um ator ou o sistema e cada linha representa uma a o Tab 27Caso de uso descrito na forma de uma narra o particionada Cliente Sistema Passa o cart o Solicita senha Digita senha Exibe menu d
268. or especializado por fazer tudo que outro tipo de ator faz Um exemplo t pico o da exist ncia em uma organiza o de funcion rios e gerentes Normalmente tudo que um funcion rio pode fazer um gerente tamb m pode fazer mas a rec proca n o verdadeira Assim poss vel criar v rios casos de uso para o ator 181 funcion rio e fazer o ator gerente herdar de funcion rio adicionando se ent o os casos de uso exclusivos de gerente Tamb m poss vel usar a rela o de generaliza o para criar atores abstratos que representam um comportamento comum entre v rios atores concreto Um ator abstrato n o existe na pr tica no mundo real como o que demonstrado no exemplo a seguir A M dico E gt fAlterar Prontu rio Enfermelro Profissional de Sa de Auxliar Fig 98 Demonstra o do relacionamento de heran a sendo usado para descrever que v rios atores concretos usam um caso de uso criando um ator abstrato Profissional de Sa de IX 6 2 Rela es entre Casos de Uso Casos de uso podem se relacionar de 3 formas e Pela inclus o de outro caso de uso e Pela extens o de outro caso de uso e e Pela generaliza o especializa o de outro caso de uso Em UML esses relacionamentos s o conhecidos como include extend e a generaliza o propriamente dita sendo representados como na figura a seguir pi lt lt include gt gt Fig 99 Relacionamentos pos
269. oram representados Essa t cnica necessita que o analista possa construir um modelo abstrato em sua mente o que pode ser dif cil em grandes sistemas Heuser B36 sugere os seguintes passos para essa t cnica 134 1 Constru o de um modelo superficial e Levantamento das entidades e Identifica o dos relacionamentos com cardinalidades m ximas e Identifica o dos atributos e Determina o dos atributos identificadores e Verifica o do aspecto temporal e Constru o do modelo detalhado e Determina o dos dom nios dos atributos e Determina o das cardinalidades m nimas dos relacionamentos e Levantamento das restri es de integridade n o represent veis no modelo e Verifica o do modelo buscando constru es redundantes ou deriv veis e Valida o junto ao usu rio A seguir veremos essas transforma es tratando algumas vezes de uma quest o que s abordada um pouco mais tarde as formas normais e Transformar uma entidade em duas entidades relacionadas muitas vezes dentro de uma entidade estamos na realidade olhando duas entidades mais espec ficas Duas formas s o poss veis a entidade original existe mas cont m dentro dela outra entidade ou a entidade original na verdade dividida em duas entidades No primeiro caso estamos extraindo a nova entidade da entidade original No segundo caso estamos detalhando parte do nosso modelo O primeiro caso pode se confundir naturalmente com o cas
270. os e Comporta se de forma limitada a sua raz o de exist ncia e regular e m nimo apesar de completo e Quando falha o faz de forma graciosa e recuper vel 148 e Quando a dificuldade de utiliz lo ou modific lo e compat vel com a dificuldade da rea de aplica o Essa uma importante filosofia e que junto com os princ pios da modelagem essencial apresentados mais tarde servir de guia para todo o nosso processo de desenvolvimento Cada vez que tivermos que tomar uma decis o relacionada ao sistema ser nesses princ pios que buscaremos a nossa resposta VIII 4 A Ess ncia A ess ncia do sistema tudo que precisaria ser inclu do no sistema para que o mesmo funcionasse quando implementado em um ambiente de tecnologia perfeita Isso compreende velocidade infinita no processador tamanho infinito de mem ria custo nulo para todas as opera es infalibilidade etc Esse conceito ser de grande valia quando estivermos analisando se um requisito verdadeiro ou falso A primeira pergunta que faremos Esse requisito seria necess rio se tiv ssemos um computador perfeito Se a resposta for n o o requisito falso Um sistema de tecnologia perfeita como um g nio da l mpada Se quisermos que o g nio da l mpada pague nossos funcion rios ainda teremos de alguma forma dizer quem s o nossos funcion rios logo cadastrar funcion rios um requisito verdadeiro de um sistema de pagamentos de func
271. os de uso entender que eles podem ser descritos em diferentes n veis de abstra o desde um n vel bastante abstrato at um n vel detalhado em seus m nimos detalhes gt A id ia b sica em torno desse conceito que casos de uso de um n vel mais abstrato explicam o porqu de um caso de uso de um n vel mais baixo enquanto o caso de uso de um n vel mais baixo explica como o caso de uso do n vel mais abstrato realizado Podemos identificar cinco n veis de abstra o para casos de uso e Sum rio de alto n vel e Sum rio e Objetivo do Usu rio e Sub Fun o e Muito detalhado Cada n vel de abstra o pode ser associado um cone que o representa N vel Icone Sum rio de Alto N vel C gt Sum rio A Objetivo do Usu rio AA Sub Fun o KD N vel Muito Detalhado e Tabela 28 cones que representam o n vel de abstra o dos casos de uso segundo 1 185 IX 9 Escopo de um Caso de Uso Da mesma forma que definimos o n vel de abstra o de um caso de uso podemos tamb m definir o escopo do caso de uso em rela o a organiza o ou sistema que ele descreve e Organiza o caixa preta e Organiza o caixa branca e Sistema caixa preta e Sistema caixa branca e Componente Escopo cone Organiza o caixa preta Organiza o caixa branca Sistema caixa preta Sistema caixa branca Componente fal fal E A rem Tabela 29 cones que representam o escopo dos casos de uso
272. os exigem todo o trabalho feito no tipo anterior e de forma adicional a cria o de um modelo computacional e com certo grau de formalidade que possa ser usado pelos desenvolvedores N o h a princ pio uma guia que indique a adequa o da automa o ou que novos resultados podem ser obtidos O usu rio por n o ter acesso a sistemas de informa o que executem a mesma atividade tem pouco conhecimento sobre o que poss vel fazer ou n o tem id ia de qual o custo de produzir certos resultados J os projetos de re desenvolvimento apresentam a vantagem de possuir uma base que pode ser utilizado como refer ncia do que deve ser feito repetido do que n o deve ser mantido elimina es e das novas atividades necess rias O usu rio acostumado e experiente com um sistema existente pode fornecer informa es mais adequadas sobre o que espera do novo sistema ou da manuten o ou melhoria sendo feita 1 4 1 Porque s o feitos projetos de SI Muitos s o os motivos que influenciam o in cio de um projeto de desenvolvimento de um Sistemas de Informa o Em geral usando um racioc nio econ mico podemos dizer que um projeto iniciado quando o benef cio do retorno esperado supera o custo do projeto O problema que n o f cil converter esses valores em n meros normalmente Custo Total de Propriedade Quanto se analisa o custo de um sistema normal falar de Custo Total de Propriedade conhecido pela sigla em ingl s
273. os problemas atuais e quais oportunidades existem para um novo sistema As entrevistas iniciais para levantamento de necessidades de informa o s o geralmente feitas com executivos Um bom conjunto inicial de quest es que podem ser feitas apresentado a seguir sugeridas em Gillenson amp Goldberg e Quais seus objetivos e Quais suas responsabilidades e Que medidas voc usa e Que informa es voc precisa e Quais s o seus problemas de neg cio e Que mudan as voc v no futuro que v o impactar a infra estrutura do seu neg cio e Quais s o os fatores cr ticos de sucesso e Qual a informa o mais til que voc recebe e Como voc classificaria as informa es que recebe quanto adequa o validade dura o consist ncia custo volume etc Alguns pontos podem ser notados sobre essas perguntas A pergunta sobre objetivos muitas vezes pode n o ser muito bem respondida assim a segundo pergunta sobre responsabilidades permite uma resposta mais pr tica e mais f cil de ser dada A terceira pergunta visa buscar uma compreens o sobre os dados importantes para o entrevistado abrindo uma sequ ncia de perguntas sobre o tema A quinta pergunta sobre os problemas de neg cio a mais importante do conjunto e deve ser dada a maior aten o e quantidade de 62 tempo dispon vel interessante que o problema seja estruturado em um formato causa efeito por exemplo por causa da falta de dinheiro
274. osso conhecimento t cnico e tecnol gico normalmente ficamos vontade para oferecer oportunidades tecnol gicas Uma oportunidade tecnol gica como diz o nome a oferta de uma tecnologia espec fica de implementa o que oferecer alguma vantagem ao cliente Por exemplo ao implantar um novo sistema de estoque podemos oferecer a entrada e sa da de produtos pelo uso de c digo de barras A oportunidade tecnol gica n o altera a funcionalidade que o cliente necessita mas sim sua forma de implementa o Algumas vezes tamb m podemos oferecer oportunidades de neg cio Uma oportunidade de neg cio alguma funcionalidade n o prevista pelo cliente mas que sabemos ser poss vel implementar Devemos ter muito cuidado com oportunidades de neg cio pois elas podem ser na verdade falsos requisitos Um exemplo t pico a prolifera o de relat rios em sistemas que na pr tica usam apenas alguns Uma oportunidade de neg cio deve ser exaustivamente discutida com o cliente de forma a ficar claro que ela realmente traz benef cios que esses benef cios s o consider veis que o risco do projeto n o aumenta muito e que ela ser realmente utilizada Um exemplo que podemos dar em um controle de estoque a funcionalidade de prever que produtos est o pr ximos de sua data de vencimento Essa n o uma fun o normal de sistemas de estoque Exige um custo adicional n o s de desenvolvimento mas tamb m de opera o como iden
275. ou fax O pedido aceito se o cliente estiver previamente cadastrado Caso contr rio o pedido rejeitado com um aviso ao solicitante para se cadastrar Isso importante pois n s normalmente pagamos os livros antes de receber por eles e s o livros caros Nas sextas feiras a livraria emite requisi es de livros para os fornecedores com base nos pedidos recebidos Quando os livros s o entregues pelo fornecedor a livraria confere a nota de entrega da editora com a requisi o devolvendo as que contiverem erros Os pedidos dos clientes s o atendidos imediatamente quando completos isto quando todos os livros pedidos foram enviados pelos fornecedores ou forem cancelados O atendimento consiste na emiss o de uma nota fiscal de um boleto de pagamento que s o enviados junto com o livro C pias da nota fiscal e do boleto s o enviadas a tesouraria Se depois de 30 dias da data de entrega o fornecedor n o enviou um livro requisitado a livraria cancela o pedido junto ao fornecedor e elimina o livro do pedido do cliente enviado um aviso ao cliente desse fato junto com o restante do pedido se existir ou isoladamente pelo correio XII 3 Entrevista 2 Henrique Cupim Letrado funcion rio e filho do propriet rio patrocinador A seguir descrevemos fragmentos de uma conversa com o Sr Jos Letrado propriet rio da Livraria ABC que deseja um SI para sua empresa A livraria funciona da mesma forma h muitos anos com
276. ou lista de valores gt ent o lt termo3 gt lt operador gt lt termo4 gt Onde operador pode ser lt gt lt gt lt gt cont m n o cont m tem no m ximo tem no m nimo tem exatamente etc se lt termo1 gt lt operador gt lt termo2 valor ou lista de valores gt ent o lt a o gt Tabela 8 Classifica o para regras defini o e templates adaptada de Halle 2002 Obviamente como fizemos aqui a forma textual bastante til Uma maneira bastante comum utilizar Diagramas de Entidades e Relacionamentos B27 Deve ficar claro por m que a utiliza o de DER para definir regras de neg cio n o igual utiliza o de DER para definir o modelo conceitual de dados de um sistema DERs por m n o representam todas as caracter sticas das regras de neg cio Ross B30 prop s uma nota o mais complexa incluindo muitos novos s mbolos em um DER Essa nota o por m foge do escopo desse texto 100 Vejamos a descri o de duas regras para uma livraria Figura 46 e Um cliente deve pedir livros e Livros s o entregues por distribuidoras Cliente Livro Distribuidora Figura 46 Exemplo de duas regras de neg cio descritas utilizando uma nota o de DER simplificada Alguns autores fazem uma descri o regra a regra como na Figura 47 Cliente Livro Distribuidora Livro
277. ou resposta de evento Como em Fornecedor envia produtos pedidos at 30 dias depois do pedido A sintaxe para definir eventos temporais lt condi o temporal gt horaldialetc de lt verbo no infinitivo gt lt objeto gt ou simplesmente 63 Era a pe d pn E possuem em algumas varia es de DFD uma nota o espec fica utilizando uma seta tracejada em vez de s lida 156 lt condi o temporal gt lt verbo no infinitivo gt lt objeto gt Como em Todo dia 30 dia enviar declara o de vendas ou dia 30 enviar declara o de vendas A sintaxe para um n o evento lt condi o de n o acontecimento de um evento gt lt prazo ou condi o temporal gt lt verbo no infinitivo gt lt objeto gt Como em Fornecedor n o enviou produtos pedidos depois de 30 dias do pedido avisar comprador O objeto da ora o normalmente um objeto direto que de alguma forma representa uma informa o tratada pelo sistema e possivelmente tamb m um objeto indireto indicando para quem ou para onde a informa o enviada Vejamos alguns exemplos comuns descritos de forma correta e Cliente envia pedido de compra e Fornecedor entrega mercadoria e Fornecedor entrega mercadoria at 10 dias depois do pedido e Vendedor solicita mercadoria e Filial envia vendas di rias e Cliente aluga fita e Ao final do m s imprimir folha de pagamento e Ao fim do dia imprimir res
278. perior pode determinar fun es e m todos a outras reas Normalmente a subordina o direta representada por uma linha cheia vertical a assessoria por uma linha cheia horizontal e a subordina o funcional por uma linha pontilhada Ao levantar o organograma pode ser interessante tamb m levantar as descri es dos cargos se elas existirem o que n o comum principalmente em pequenas e m dias empresas VI 2 N veis de Abstra o e Modelos Neste cap tulo estudaremos modelos que foram projetados para trabalhar com diferentes n veis de abstra o Para melhor compreender essa no o vamos entender primeiro o que um modelo todo modelo uma abstra o de algo que existe ou se imagina que possa existir no mundo real Abstra o o processo mental de separar um ou mais elementos de uma totalidade complexa de forma a facilitar a sua compreens o por meio de um modelo No nosso dia a dia utilizamos a abstra o para poder trabalhar com toda a informa o que o mundo nos fornece Um mapa por exemplo um modelo de uma cidade Dependendo da informa o que queremos colocamos alguns s mbolos e tiramos outros do mapa Um mapa tamb m n o pode ser perfeito tem que abstrair as informa es que n o s o necess rias naquele instante ou teria que ter o mesmo tamanho da cidade Podemos usar mapas com diversos graus de detalhe ou seja mais ou menos abstratos Um globo terrestre por exemplo um mapa
279. pre o de 88 O funcionamento di rio da empresa Livraria ABC descrito no Projeto 1 232 frete Tamb m consulto a Internet para fazer essa lista Algumas vezes tenho que esperar uma cota o que vai chegar for fax ou telefone ent o eu para o servi o para come ar mais tarde Essa lista eu envio para a L cia que define o pre o de venda de cada livro Ela faz isso baseada na experi ncia dela com os clientes e as necessidades da empresa N s compramos os livros em muitas moedas s o livros caros de arte ou livros raros e antigos de colecionador e a taxa de c mbio tamb m importante Com os pre os definidos eu fa o uma estimativa do frete para o cliente e preparo uma proposta Essa proposta passada para o cliente de v rias formas fax carta telefone ou ultimamente tenho usado meu e mail pessoal para facilitar Geralmente dentro de 24h o cliente confirma a proposta ou parte dela Eu ent o separo os pedidos que ser o feitos na sexta feira Quem trata dessa parte dos pedidos para os fornecedores o pr prio Sr Letrado Muitas vezes ele consegue mais um desconto na compra dos livros Algumas das vezes esse desconto ou parte dele repassado para o cliente Quando chegam todos os livros de um cliente eu come o a trabalhar de novo Sou eu que fecha a venda Recalculo o pre o de custo e de venda Passo os casos de poss vel desconto para a L cia que decide na hora Emito uma fatura uma nota fiscal empaco
280. que representam os conceitos mais importantes de um dom nio ou aplica o A partir desses conceitos buscam se entidades relacionadas possivelmente usando tanto opera es das t cnicas top down como bottom up 1 12 4 T cnica Mista Normalmente modelos E R n o s o desenvolvidos de forma Top Down ou Bottom up mas sim de uma forma mista principalmente quando a uma grande quantidade de entidades no esquema Dessa forma um esquema inicial de alto n vel dividido de forma que cada parti o possa ser considerada separadamente 137 1 12 5 Que t cnica usar Desaconselhamos o uso da t cnica bottom up Acreditamos que a verdadeira modelagem E R deve seguir uma t cnica mista a partir da compreens o do analista do que s o as entidades e seus atributos mais parecida com a t cnica inside out 1 12 6 Equival ncia de modelos Dois modelos s o equivalentes quando representam uma mesma realidade Algumas equival ncias s o facilmente identific veis e Relacionamentos n x m podem ser substitu dos por uma entidade42 e Relacionamentos 1x1 podem ser eliminados unificando se as entidades 1 13 Representando o Aspecto Temporal Muitas vezes uma aplica o necessita que sejam representados aspectos temporais Isso acontece por exemplo quando o pre o de um contrato depende de sua data de contrata o de acordo com v rios planos Dois efeitos s o interessantes de serem discutidos a necessidade de manter um hist rico d
281. quisito define o que deve ser feito mas n o como o Um requisito n o deve refletir um projeto ou uma implementa o o Um requisito n o deve descrever uma opera o Requisitos de interface s o uma exce o a essa regra Alcan vel ou seja realiz vel a um custo definido por uma ou mais partes do sistema Completo ou seja n o precisa ser explicado ou aumentado garantindo capacidade suficiente do sistema Consistente n o contradizendo ou mesmo duplicando outro requisito e utilizando os termos da mesma forma que outros requisitos Orden vel por estabilidade ou import ncia ou ambos 31 e Aceito pelos usu rios e desenvolvedores IV 2 Stakeholders e Usu rios Usu rios s o todos aqueles que usam o sistema com algum objetivo O nome pode ser entendido de forma restrita indicando apenas aqueles usu rios finais isto que realmente usam o sistema dentro do escopo do seu objetivo ou de forma ampla indicando todos aqueles que usam o sistema ou algum de seus produtos de alguma forma o que inclui tamb m os desenvolvedores Stakeholders s o todos aqueles com algum interesse no sistema afetando ou sendo afetados por seus resultados A palavra uma composi o dos termos stake interesse ou aposta e holder possuidor Fica claro que um stakeholder uma pessoa que possui algum interesse no sistema em especial um interesse que envolve algum risco Alguns autores brasileiros traduzem o termo como interes
282. ras inst ncias da classe um conjunto de caracter sticas 29 F Um modelo tamb m pode ser um exemplo 106 Na classifica o o que estamos fazendo imaginar uma id ia nica que descreve de forma abstrata todos os objetos de uma classe Ao eliminar a necessidade de tratar cada objeto de forma nica simplificamos o problema em quest o Exemplos t picos de classifica o Inst ncias Classe Flamengo Fluminense S o Paulo Times de Futebol Brasil Estados Unidos Pa s Pel Zidane Rom rio Jogador de Futebol Tabela 12 Exemplo de classifica o O processo reverso da classifica o a instancia o O conjunto de todas as inst ncias de uma classe a extens o dessa classe A classifica o um mecanismo b sico do racioc nio humano Talvez seja o que nos permita tratar de toda informa o que recebemos diariamente importante notar que na vida real um objeto pode pertencer a v rias classes Uma pessoa pode ser um aluno um professor um policial etc Normalmente em modelos te ricos como os que vamos usar tentamos com que um objeto perten a diretamente a s uma classe de modo a facilitar a manipula o do modelo 1 2 2 Composi o ou Agrega o feito de parte de Na composi o entendemos um objeto complexo formado de um conjunto de outros objetos como um s objeto como vemos uma bicicleta ou um carro Ao eliminar a necessidade de descrever as partes
283. ratante 68 69 Cap tulo VI Modelo de Neg cio The sciences do not try to explain they hardly even try to interpret they mainly make models By a model is meant a mathematical construct which with the addition of certain verbal interpretations describes observed phenomena The justification of such a mathematical construct is solely and precisely that it is expected to work John Von Neumann Organograma Fun es de Neg cio Processos de Neg cio EPC Diagrama de Atividades Regra de Neg cio A Modelagem de Neg cio n o faz parte da modelagem essencial ou da modelagem estruturada mas cada vez mais vem sendo usada como uma ferramenta principal ou de aux lio do processo de desenvolvimento de software visando o levantamento completo dos requisitos do sistema Nesse cap tulo trataremos de diferentes formas de modelagem de neg cio e Organograma e Modelagem de Fun es de Neg cio e Modelagem de Processos e Modelagem de Regras de Neg cio Um organograma uma descri o da organiza o de uma empresa amplamente divulgada descrevendo as reas da empresa e as hierarquias entre elas O Organograma ferramenta essencial na compreens o de uma empresa e suas linhas de poder A modelagem de fun es de neg cio permite a compreens o do funcionamento da empresa sem sofrer a interven o da forma de organiza o da empresa De certa forma pode ser desenvolvido como tanto como um modelo da e
284. responsabilidades para que o ator principal alcan ar seu objetivo Os principais tipos de atores s o e pessoas e organiza es e equipamentos e e outros sistemas Genericamente falando o sistema sendo descrito tamb m um ator N o normal por m represent lo dessa forma Outro ator muitas vezes usado o tempo mas muitos autores n o recomendam seu uso Um usu rio n o a mesma coisa que um ator Um ator representa um papel dos usu rios de um sistema Tanto um ator pode representar um papel assumido por v rios usu rios como o papel de Cliente em um banco quanto um usu rio pessoa real pode ser representado por v rios atores como no caso de um funcion rio de uma Universidade que simultaneamente aluno IX 2 1 Objetivos Todo ator possui um ou mais objetivos ao usar o sistema Cada objetivo define e d nome a um caso de uso IX 2 2 Cen rios Um caso de uso pode acontecer de acordo com v rios cen rios Cada cen rio descreve como uma inst ncia espec fica do caso de uso pode acontecer ou seja que segii ncias espec ficas de intera es entre o sistema e os atores Um desses cen rios o cen rio principal conhecido como cen rio principal ou cen rio feliz happy day que narra como um ator alcan a seu objetivo da forma mais f cil ou comum O cen rio principal descrito de forma integral em todos os casos de uso Na maior parte das vezes os casos de uso tamb m possuem v
285. ret ngulos da entidade a que pertencem Finalmente como indica o nome do modelo entidades podem se relacionar entre si Essa caracter stica a principal for a do modelo de entidades e relacionamentos pois permite que de certa forma naveguemos no modelo Podemos indicar relacionamentos apenas pelas entidades envolvidas como cliente pedido ou usar um termo que descreva o relacionamento cliente solicita pedido Modelos de Entidades e Relacionamentos para serem completos exigem tamb m um conjunto de restri es Algumas dessas restri es como a cardinalidade dos relacionamentos que veremos a seguir podem ser descritas em algumas ou todas nota es Por m a maioria das descri es muito complexa para ser descrita em um diagrama Nesse caso s o necess rias anota es ao diagrama descrevendo as descri es Isso pode ser feito em linguagem natural ou em alguma nota o formal espec fica dependendo de escolhas da equipe de projeto ou do m todo utilizado 1 5 O Diagrama de Entidades e Relacionamentos Diagramas de Entidades e Relacionamentos descrevem o mundo em geral ou um sistema em particular de acordo com os objetos que o comp e e os relacionamentos entre esses objetos 111 Figura Significado Entity name Entidade Relacionamento Liga o entre entidades por meio de um relacionamento com a descri o da cardinalidade Atributo Tabela 15 Figuras
286. rma correta de desenvolver software basicamente imposs vel de ser realizado Podemos encontrar alguns exemplos de sucesso em casos onde o produto sendo desenvolvido e o ambiente de desenvolvimento s o muito bem conhecidos Devido divis o radical entre as fases dada grande nfase a documenta o Inicialmente assumia se que cada fase seria executada por uma equipe distinta de especialistas fato que est se tornando mais raro hoje em dia Tamb m havia discuss es sobre at que ponto deveria ir o projeto e onde come ava codifica o De acordo com a complexidade do sistema muitas vezes as fases de codifica o e testes eram dividas em codifica o e teste de unidades e integra o e testes de integra o Entre seus principais defeitos est o fato que o cliente s v o produto final no ltimo dia do desenvolvimento Assim imposs vel detectar falhas ou atender demandas imediatas do cliente Al m disso a participa o do usu rio muito baixa An lise Projeto Codifica o Testes Figura 4 O Modelo de Processo em Cascata ou Sequencial Prototipagem No processo de Prototipagem pura o desenvolvedor interage diretamente com o usu rio escutando seus pedidos e desenvolvendo imediatamente um prot tipo do produto desejado O usu rio ent o utiliza esse prot tipo e fornece ao desenvolvedor novas 22 informa es que o levam a modificar o p
287. ro Descubra os atores externos ao limite do sistema que realizam os processo b sicos Entreviste os para descobrir mais informa es sobre seus objetivos Possivelmente a cada objetivo corresponder um caso de uso O principal problema com casos de uso o excesso de decomposi o Funcional Seus sintomas s o Casos de Uso pequenos Muitos Casos de Uso Dificuldade de entender o modelo Nomes com opera es de baixo n vel o Opera o objecto o Fun o dados o Exemplo Inserir Cart o As a es corretivas que podem ser tomadas s o IX 14 IX 14 1 Busque um contexto mais amplo o Por que o sistema est sendo feito Se coloque no papel do usu rio o O que o usu rio quer alcan ar o Que valor esse caso de uso adiciona Como fazer casos de uso 1 Identifique os atores e seus objetivos 2 Para cada caso escreva um caso simples 3 Para cada caso escreva as condi es de falha e extens es 4 Para cada condi o de falha descreva o que acontece at que volte ao norma ou acabe em falha Resolva as falhas 5 Detalhe as varia es de dados Identifique os atores e seus objetivos Quais computadores subsistemas e pessoas v o dirigir o sistema o Um ator qualquer coisa com comportamento 190 IX 14 2 IX 14 3 IX 14 4 IX 14 5 O que cada ator precisa que o sistema fa a o Cada necessidade mostra um gatilho do sistema Resultado o Lista de casos de uso o Vis o geral do sistema
288. ros de chassi Definido um o outro est automaticamente definido mas ambos podem ser escolhidos de forma independente como identificador principal Dizemos que ambos s o chaves candidatas Uma chave candidata n o pode conter atributo que n o auxiliam na identifica o nica da inst ncia O que for escolhido ser a chave prim ria ou outros s o conhecidos como chaves alternativas 1 10 1 Atributos Identificadores Chaves Candidatas e Chaves Prim rias Alguns atributos t m o poder de distinguir as ocorr ncias das entidades isto servem para identificar univocamente uma inst ncia de entidade inst ncia do mundo real Definido o valor desse atributo os outros valores s o dependentes e n o podem ser escolhidos mas sim devem possuir um valor exato seguindo a realidade Um atributo identificador t pico em sistemas financeiros o CPF de uma pessoa f sica ou o CNPJ de uma pessoa jur dica Definido o CNPJ a empresa e todos os seus dados est o univocamente definidos nome fantasia endere o etc no mundo real e assim deve seguir o sistema que estamos construindo Muitas vezes precisamos de mais de um atributo identificador para realmente identificar uma inst ncia Dizemos ent o que a chave prim ria composta Se usarmos apenas um atributo como identificador ent o dizemos que a chave prim ria simples Aluno CPF NomeAluno EnderecoAluno NomePai NomeMae EscolaOrigem EnderecoEscolaOrigem
289. ros n veis podem ser feitos para utilizar essa informa o Que outros sistemas de informa o podem fornecer informa o para o sistema de aprova o Defina para um sistema de informa o escolhido por voc as informa es necess rias que dados s descrevem e que conhecimento pode ser obtido a partir delas Muitas lojas no Rio de Janeiro ainda utilizam sistemas de informa o feitos em MS DOS Fa a uma an lise dos custos e benef cios para mudar um sistema desse tipo para Windows ou de mant lo como est Qual a melhor op o atualmente Qual a melhor op o nos pr ximos 2 5 e 10 anos Que tipos de sistemas podem interessar a Livraria ABC Que tipos de sistemas podem interessar a Empresa de Clipping ClipTudo Uma empresa precisa comprar uma impressora nova Existem duas op es interessantes no mercado como descritas na tabela abaixo Qual impressora comprar se a empresa prev fazer 30 000 impress es com a impressora E se forem 100 000 E se forem 146 668 E se forem 500 000 Caracter stica Impressora A Impressora B Pre o da impressora sem R 300 00 R 5 000 00 tinta Pre o do cartucho de tinta R 80 00 R 250 00 N mero de c pias por 1 000 5 000 cartucho Vida til da impressora 120 000 800 000 15 17 Cap tulo III O Desenvolvimento de Software An lise 3 Exame de cada parte de um todo tendo em vista conhecer sua natureza suas propor es suas fun
290. rot tipo de maneira a atender todas as necessidades do usu rio E claramente um processo de desenvolvimento baseado em um ciclo de realimenta o de informa es com alta participa o do usu rio N o existe uma fase formal de an lise ou projeto Isso pode causar problemas graves e dif ceis de corrigir no produto final dificultando de sobremaneira a manuten o dos produtos Pouca nfase dada documenta o Atualmente quase todos os processos de desenvolvimento utilizam prot tipos mas n o um ciclo de vida de prototipagem Usamos prot tipos descart veis quando o prot tipo usado apenas para levantar alguns ou todos os requisitos e depois abandonado em troca de uma implementa o mais organizada Um prot tipo operacional um software feito rapidamente para atender uma demanda do usu rio e que usado mais tarde como modelo de especifica o para uma nova implementa o do sistema poss vel diferenciar prot tipos de mock ups Um prot tipo apresentaria o comportamento correto ou aproximadamente correto e seria caracterizado principalmente pela falta de rigor na implementa o Um mock up apresentaria apenas uma interface que serviria como pr via da interface final Contru o ou Revis o do Prot tipo Avalia o do Prot tipo Escutar o Cliente Figura 5 O Processo de Prototipagem Processos Evolucion rios Os modelos de processo evolucion rios reconh
291. ru o e finalmente avalia o dos resultados Do RUP foram derivados v rios outros processos sendo o RUP o mais conhecido deles Comunica ao com Engenharia Riscos Figura 7 O Processo em Espiral vis o abstrata 111 2 2 3 Processo Win Win O Processo Todos Ganham Espiral Win Win Spiral a unifica o de dois trabalhos distintos de Barry Boehm No primeiro o Processo espiral ele prop e que um processo de software seja feito de acordo com um ciclo de especifica es cada vez mais detalhadas que resultam em vers es incrementais das capacidades operacionais desejadas Cada ciclo envolve a elabora o dos objetivos restri es e alternativas do produto a avalia o das alternativas e riscos a elabora o da defini o do produto e do processo e o 24 planejamento do pr ximo ciclo No segundo a Teoria W ele prop e que todas as decis es tomadas em um processo gerencial devem gerar uma situa o de todos ganham As fases para esse Processo s o e Identificar X e Identificar condi es de ganho para cada X e Conciliar condi es de Ganho e Estabelecer objetivos restri es e alternativas e Avaliar alternativas de produto e processo resolver riscos e Definir produto e processo incluindo parti es e Validar produto e processo incluindo parti es e Revisar e alcan ar compromisso commit 1 2 2 4 Desenvolvimento Acelerado Devido a grande press o pela produtividade que as empresas sofrem n
292. s O que enviado pode retornar exigindo uma a o espec fica Documentos podem ser perdidos e segundas vias podem ser necess rias Fiscais ICMS ISS Trabalho podem aparecer e solicitar relat rios que podem ser obrigat rios em um sistema Processos que ocorrem em uma ordem podem ter que ser acelerados para atender um cliente preferencial 159 Pagamentos podem ser feitos com o valor errado para menos ou para mais exigindo emiss o de novas cobran as ou de cr ditos VIII 8 3 Simplificando Eventos Segundo a an lise essencial original as opera es de incluir eliminar e alterar uma mem ria exigiriam pelo menos tr s eventos distintos como em Propriet rio cadastra produto Propriet rio altera produto Propriet rio apaga produto Isso por m pode n o representar a verdade e ser muito complicado em alguns sistemas Na vida real f cil termos um sistema com 30 a 40 entidades Isso exigiria no m nimo 90 eventos para cumprir as necessidades de manter a mem ria N o fazemos isso na pr tica Em primeiro lugar n o criamos atividades custodiais que n o s o necess rias Isso acontece quando a mem ria j gerenciada em uma atividade fundamental Em segundo lugar quando uma mem ria necessita de uma funcionalidade que permita tratar esses tr s casos podemos utilizar uma nota o mais simples Propriet rio mant m produtos VIII 9 As Respostas aos Eventos Para cada evento o sistema deve ex
293. s Existem ainda outras formas normais que s o praticamente abandonadas no dia a dia A 4NF a 5NF e a Boyce Codd BCNF Todas elas lidam com fatos multivalorados que devem corresponder a relacionamentos N M ou N 1 De acordo com o modelo relacional temos as defini es e explica es que se seguem 142 Uma tabela est na 4NF se al m de estar na 3NF n o cont m depend ncias multivaloradas Uma depend ncia funcional multivalorada ocorre quando um atributo de uma tabela implica na exist ncia de uma lista de valores para outro atributo na mesma tabela coluna dependente Uma rela o R est na BCNF se sempre que X gt A for verdade em R e A n o estiver contido em X ent o X uma chave candidata para R Finalmente a quinta forma normal trata da possibilidade de reconstruir uma informa o a partir de um modelo composto de partes menores com chaves prim rias diferentes Se isso n o for poss vel e o modelo est na 4NF ent o estar tamb m na 5NF Por exemplo a tabela a seguir pode ser substitu da por tr s outras que a seguem Vendedor Empresa Modelo Jo o Ford Caminh o Jo o Ford Autom vel Jo o GM Caminh o Jo o GM Autom vel Jos Ford Autom vel Tabela 19 Rela o que n o est na 5NF Vendedor Empresa Empresa Produto Vendedor Produto Jo o Ford Ford Caminh o Jo o Caminh o Jo o GM Ford
294. s e Um comando pode ser um comando estruturado ou um comando simples e Um comando estruturado pode ser 2 Um bloco 2 Um comando se ent o 2 Um comando se ent o sen o 2 Um comando fa a caso 1 Um comando fa a enquanto 2 Um comando repita at 1 Um comando para cada fa a a Outro comando acertado entre o grupo e Um comando simples pode ser 2 Um comando de atribui o 2o Um comando de busca em mem ria 2 Um comando de escrita em mem ria o Um comando de leitura na interface 2o Um comando de escrita na interface a Outro comando acertado entre o grupo O importante manter a consist ncia Veja o exemplo a seguir PROCESSO Preparar Segunda Via IN CIO LER tipo pessoa SE tipo pessoa FISICA ENT O IN CIO LER cpf pessoa BUSCAR quem EM Contribuinte COM quem cpf cpf pessoa codigo cont quem codigo FIM SEN O IN CIO LER cgc empresa BUSCAR empresa EM Contribuinte COM empresa cgc cgc empresa codigo cont empresa codigo FIM FIM DO SE LER ano BUSCAR iptu EM impostos COM iptu ano ano E iptu codigo codigo cont 168 IMPRIMIR iptu FIM VI1 13 4 O Diagrama de Transi o de Estados Um diagrama de transi o de estados ou simplesmente diagrama de estados ou ainda DTE uma das abstra es mais gerais que temos para um sistema ou objeto O objetivo de um DTE descrever como um sistema ou objeto muda de estado em fun o de eventos q
295. s veis entre casos de uso generaliza o extens o e inclus o IX 6 3 Inclus o de Casos de Uso O relacionamento de inclus o o mais simples de se compreender pois representa uma rela o entre um caso de uso b sico e um caso de uso inclu do Isso significa que caso de uso inclu do explicitamente inserido no caso de uso base de forma semelhante a uma chamada de fun o 182 O diagrama a seguir demonstra o uso da rela o de inclus o Identify Customer Pd e lt lt include gt Ea gt include p I Ssinclude gt gt r 1 e lt include gt gt L a Ce GD Cose ATM Customer Fig 100 Exemplo do uso do relacionamento de inclus o O relacionamento de inclus o usado para fatorar um comportamento comum entre dois ou mais casos de uso Ele evita que tenhamos que descrever o mesmo comportamento duas vezes dentro dos respectivos casos de uso aumentando a consist ncia e permitindo o reuso Tamb m poss vel usar o relacionamento de inclus o apenas para fatorar e encapsular comportamento de um caso de uso base de forma a simplificar fluxo complexo de eventos ou remover da parte principal do caso de uso um comportamento que n o parte do objetivo prim rio importante entender que um caso de uso inclu do executado totalmente quando chamado e se n o deve ser executado a decis o do caso de uso chamador Alguns autores dizem que o caso de uso inclu do obri
296. s de gold plating 38 mascarar um requisito verdadeiro Al m disso o ac mulo de requisitos falsos aumenta a complexidade do sistema de tal modo que pode tornar sua implementa o invi vel Assim a busca dos requisitos verdadeiros e apenas esses deve ser uma das principais formas de garantir o sucesso de um projeto Para que tenhamos um sistema apenas com requisitos verdadeiros imaginamos que ele ser implementado com uma tecnologia perfeita Assim evitamos os requisitos falsos causados pela tecnologia seja ela passada ou antecipada Em um sistema de tecnologia perfeita como diz o nome os processadores s o infinitamente velozes n o gastam energia e n o cometem erros as mem rias s o infinitamente grandes os dados s o transportados sem gastar tempo A An lise Essencial fornece conceitos importantes para que possamos nos guiar na descoberta de todos os requisitos verdadeiros e para que evitemos a inclus o de requisitos falsos em nossos sistemas IV 6 1 O Usu rio n o Sabe Tudo Um problema comum o usu rio pedir algo como requisito porque ele pensa que esta a forma de implementar um funcionalidade desejada Esse erro al m de comum provavelmente prejudicial ao sistema se n o for detectado A verdade que apesar do analista ter que atender aos stakeholders ele n o tem que atender exatamente ao que eles dizem mas sim ao que eles realmente precisam O trabalho de an lise um trabalho investigativo real
297. s desse texto 7 McConnell Steve Rapid Development Taming Wild Software Schedules Microsoft Press Redmond Washington 1996 202 por m pode trazer como risco a confian a demasiada e um otimismo exagerado em rela o a prazos como uma decep o proporcional a seguir Com certeza prot tipos facilitam em muito a valida o de sistemas principalmente de novos sistemas onde h certo grau de explora o da solu o mais adequada Al m disso podem facilitar a encontrar fun es desnecess rias ou fun es esquecidas principalmente com usu rios j acostumados com sistemas semelhantes Prot tipos podem ser criados de forma parcial Por exemplo se um sistema exige a manuten o incluir excluir e alterar de v rias entidades como aluno professor e funcion rio em um sistema acad mico a prototipagem de uma dessas intera es pode servir de forma de valida o para todas as outras X 3 1 Prot tipos de Baixa Fidelidade amp StoryBoarding A constru o de prot tipos de baixa fidelidade algo que muitos fazemos sem nem mesmo nos darmos conta Um prot tipo de baixa fidelidade PBF um desenho provavelmente feito a m o usado por uma pessoa para demonstrar o comportamento do sistema para outra pessoa Esse tipo de prot tipo totalmente diferente do prot tipo tradicional proposto normalmente e que inclui a constru o de um software PBF podem ser desenhados em quadros negros quadros brancos sobre papel
298. s vagas recomenda es que nos auxiliam a escolher esse caminho na modelagem essencial temos princ pios espec ficos que nos orientam nessa escolha Os princ pios da An lise Essencial s o e O or amento para a complexidade e A neutralidade tecnol gica e A tecnologia interna perfeita e O modelo essencial m nimo 56 4 r PRES x e E impressionante que tanto tempo depois da cria o e divulga o da Modelagem Essencial e da An lise Estruturada Moderna tantas pessoas ainda trabalhem com as t cnicas anteriores e surpresos declarem ser totalmente ineficazes E o equivalente a esperar obter rendimento e velocidade de modelos atuais em autom veis de 30 anos atr s 146 A esses princ pios somaremos um quinto j apresentado o princ pio da aus ncia de surpresas por acreditarmos que perfeitamente condizente com os princ pios essenciais VIII 3 1 O Or amento para a Complexidade Esse princ pio nos orienta a modelar um sistema que possamos compreender Para isso devemos manipular a complexidade do modelo de forma a manter tanto o todo como cada uma de suas partes em um n vel de complexidade compat vel com a intelig ncia humana Para isso utilizamos t cnicas de particionamento do sistema e o controle de caracter sticas que aumento a complexidade do modelo entre elas e Controle do n mero de componentes de cada parte do modelo e Controle da complexidade interna de cada parte do modelo e Controle da complex
299. sacada Cliente informa quantia a ser sacada Sistema solicita re inser o do cart o Cliente insere o cart o Sistema fornece dinheiro Cliente retira dinheiro Sistema fornece recibo Cliente retira recibo Sistema libera cart o Cliente recupera cart o 194 IX 16 Verbos para usar em casos de uso Analisar Descobrir Buscar Identificar Informar Monitorar Verbos Informativos e Notificar e Encontrar e Consultar e Requisitar e Selecionar Especificar Ver Conseguir Permitir Arranjar Mudar Classificar Definr Entregar Projetar Garantir Estabelecer Alcan ar Avaliar Verbos Performativos Questionar Fazer Realizar Executar Providenciar Preencher Solicitar Aprontar Preparar Especificar Recuperar Completar IX 17 Uma solu o para o Problema da Livraria UCD re Colecionador 195 UC1 Cliente usa Livraria e Ator Principal Colecionador e N vel e Cen rio Principal Colecionador solicita Cadastro Colecionador compra Livro UC2 Comprar Livro Z e Colecionador pede Livro e Livraria ABC aprova Pedido e Livraria ABC solicita Livro ao Fornecedor Fornecedor entrega Encomenda e Livraria ABC atende Colecionador UC4 Receber Pedido 24 e Vendedor lista os Livros e Vendedor investiga os Pre os e Vendedor envia proposta para Funcion ria e Funcion ria aprova a Proposta e Vendedor prepara a
300. sados mas esse termo n o tem todo o significado do termo em ingl s que adotaremos na falta de um melhor em portugu s O grupo de stakeholders bem maior que o grupo de usu rios pois envolve n o s estes mas tamb m desenvolvedores financiadores e outros Um tipo de stakeholder que muitas vezes esquecido formado por aquelas pessoas que s o afetadas indiretamente pelo funcionamento do sistema mesmo sem saber que ele existe ou est funcionando Dizemos que essas pessoas est o na sombra do sistema Como exemplo podemos citar o caso de um sistema hospitalar destinado a indicar que paciente deve tomar que rem dio a que horas Nesse sistema enfermeiras e m dicos seriam usu rios Claramente os pacientes mesmo n o sendo usu rios s o stakeholders pois seu interesse no bom funcionamento do sistema direto Uma falha pode causar at mesmo a morte de um ou mais pacientes A fam lia e os acompanhantes do paciente por m est o na sombra do sistema sendo afetados apenas indiretamente Abordagens simplificadas permitem identificar imediatamente tr s tipos de stakeholders desenvolvedores compradores e usu rios Uma investiga o mais profunda pode achar muitos outros interessados como gerentes dos usu rios finais auditores respons veis pela opera o respons veis pela manuten o usu rios de sistemas que enviam ou recebem dados para o sistema espec fico etc interessante que seja feito um esfor o
301. sagens de notifica o por outro lado s o processos elementares e devem ser contados como uma sa da a parte Por exemplo ao tentar comprar um produto que n o existe e receber uma mensagem com essa notifica o foi feito um processamento que contado como uma sa da externa adicional X1 6 3 Entendendo as L gicas de Processamento A l gicas de processamento ou formas de processamento l gico s o as caracter sticas que uma transa o tem de acordo com os requisitos solicitados especificamente pelo usu rio A partir dessas l gicas de processamento podemos determinar como indicado na Tabela 32 qual o tipo de fun o transacional que deve ser contado 219 Forma de Processamento L gico Tipo de Fun o Transacional E E E Realiza valida o dos dados P P P Realiza c lculos ou f rmulas matem ticas P O N Converte valores equivalentes P P P Filtra dados e seleciona usando crit rios espec ficos para P P P comparar m ltiplos conjuntos de dados Analisa condi es para determinar qual aplic vel P P P Altera ou inclui ao menos um ILF O O N Referencia ao menos um ILF ou EIF O Recupera dados ou informa o de controle O Cria dados derivados P O N Altera o comportamento do sistema O O N Prepara e apresenta informa o fora das fronteiras do sistema P O capaz de aceitar dados ou informa o de controle que entra O P P pela fronteira da aplica o R
302. sar do tempo do projeto o objetivo se torna mais detalhado como em Levantar os documentos utilizados no processo de compra ou Avaliar as telas relativas ao cadastro de bens A escolha do entrevistado o segundo aspecto importante Devem ser escolhidas as pessoas que permitam obter no final das entrevistas uma vis o clara e o mais completa poss vel do problema das diversas formas de analis lo e solucion lo Nunca se deve tratar um problema a partir de um nico n vel funcional nem de uma nica vis o organizacional pois estar amos correndo o s rio risco de obter uma vis o distorcida Devemos lembrar que o sistema afetar todos os n veis funcionais e departamentos da institui o Dependendo do tipo de entrevista ser necess rio um roteiro ou um question rio No in cio da an lise os roteiros levam a execu o de entrevistas abertas no final geralmente temos entrevistas por question rios Entrevistas estruturadas s o preparadas principalmente para esclarecimento de processos e atividades Todos os roteiros e question rios devem seguir um modelo padr o incluindo a apresenta o e a conclus o da entrevista Quanto maior o n mero de entrevistadores maior a import ncia de seguir um padr o Outros aspectos fundamentais a serem preparados s o e A linguagem e A coer ncia das perguntas e A programa o dos hor rios importante estar preparado para a linguagem a ser usada na entrevista Nisso influe
303. se Essencial descobrir e documentar todos os requisitos funcionais verdadeiros de um sistema e apenas esses requisitos Para que isso seja poss vel adotamos um conjunto de princ pios e conceitos que nos permitem identificar esses requisitos dentro de toda a informa o levantada durante um processo de an lise O M todo Essencial n o eficaz em qualquer tipo de projeto Na verdade estamos preocupados basicamente com sistemas de informa o que sejam sistemas interativos de respostas planejadas Esses sistemas funcionam sempre em resposta a algum evento fora do seu controle para o qual possamos definir uma resposta planejada Deve ficar claro que n o estamos interessados em eventos que exigem respostas ad hoc isto caso a caso Usaremos o exemplo cl ssico do vendedor de passagens de avi o podemos fazer um sistema capaz de responder as perguntas t picas como qual o pre o da passagem para S o Paulo ou Quando sai o pr ximo v o para Bras lia por m n o podemos considerar com esse m todo um sistema que responda a absolutamente todas as perguntas que um ser humano poderia responder como Qual foi o resultado do ltimo jogo do Am rica VIII 3 Os princ pios da Modelagem Essencial Os princ pios da modelagem essencial ser o os nossos guias no processo de an lise O que acontece nesse processo que v rias vezes temos a op o de tomar dois ou mais caminhos Na modelagem estruturada tradicional temos apena
304. segundo 1 Fronteiras Fig 104 Diferentes fronteiras de um sistema levam a diferentes escopos segundo 1 186 IX 10 Escopo x Abstra o A AA DDS FOR Fig 105 Compatibilidade entre as combina es entre escopo e abstra o de um caso de uso pek NNE moea Fig 106 S mbolos mais adequados a utiliza o de acordo com a compatibilidade na descri o de casos de uso IX 11 Partes de Um Caso de Uso IX 11 1 Poss veis Se es para um Caso de Uso Expandido e Atores e Interessados e Pr condi es 187 IX 11 2 P s condi es de sucesso Cen rio principal de sucesso ou fluxo principal Extens es ou fluxos alternativos Requisitos Especiais Varia es tecnol gicas e de dados Freqii ncia Quest es em aberto Atores S o as classes de pessoas e sistemas externos que interagem com o sistema de alguma forma IX 11 3 IX 11 4 IX 11 5 IX 11 6 IX 11 7 Interessados Stakeholders A quem serve o caso de uso Quem tira proveito de seus resultados Muitas vezes n o s o apenas os atores Pr condi es O que deveria ser sempre verdadeiro para que o caso de uso possa acontecer Pr condi es N O s o testadas dentro do caso de uso Elas s o assumidas como verdadeiras antes do in cio dele Devem comunicar APENAS quest es dignas de nota que constituam informa o til sobre o funcionamento do sistema P s Condi es ou Garanti
305. senciais deve ser especificados por meio de uma mini especifica o ou refinado por meio de outro DFD Uma mini especifica o pode ser escrita em portugu s estruturado usando tabelas ou rvores de decis o Qualquer que seja a linguagem escolhida deve permitir o entendimento claro do que deve ser feito durante aquele processo Por exemplo Especifica o do Processo Cadastrar Cliente o Se CGC V lido Ent o o Salvar Cliente VIIL 13 3 Mini especifica es Uma especifica o de um processo mini especifica o tem como objetivo especificar o que o processo deve fazer e n o como Uma especifica o em portugu s estruturado deve ser clara Em geral cada empresa ou projeto deve determinar como escrever sua mini especifica o Portugu s Estruturado Algumas regras b sicas e Toda a l gica deve ser expressa na forma de estruturas segiienciais estruturas de decis o estruturas de case ou itera es e As palavras chaves devem ser destacadas negrito ou letras mai sculas e Identar claramente os blocos de comando mostrando sua hierarquia e Destaque as palavras ou frases definidas no dicion rio de dados para indicar que t m um significado espec fico sublinhe ou it lico 99 6619 39 e Seja atento no uso das condi es ou e maior maior ou igual 167 e Sintaticamente falando e Uma mini especifica o composta de uma segii ncia de comando
306. sendo essa uma decis o de an lise J Coad ao buscar uma forma mais objetiva de modelar objetos sugere que busquemos inicialmente 4 tipos de objetos que podemos entender como entidades e Momentos ou Intervalos um momento ou um intervalo representa qualquer coisa que precisa ser acompanhada por motivos de neg cio ou legais e que acontecem em um instante de tempo ou por um per odo de tempo Muitas vezes pode ser mais f cil come ar nossa an lise por esse tipo de entidade pois estamos tratando de atividades de neg cio que devem exigir a participa o das outras entidades Exemplos s o aulas consultas contrata o etc e Pap is representam pap is assumidos pelas pessoas que est o envolvidas com o sistema sendo analisado Cuidado pois n o s o apenas os usu rios nem representam os cargos que as pessoas ocupam nas empresas necessariamente Exemplos s o aluno professor e Pessoas Locais ou Coisas representam os objetos tang veis e localidades Exemplos s o sala autom vel e Descri es s o basicamente as especifica es propostas por Shlaer e Mellor Modelos de um produto um bom exemplo Ross B28 sugere tr s tipos de entidade e Entidades N cleo Kernel que representam is conceitos mais b sicos do dom nio do problema e que n o dependem de outras entidades para existir e Entidades Dependentes que representam conceitos que s o naturalmente dependentes de outra entidade espec fica e apen
307. simplificamos a compreens o do objeto analisado Exemplos t picos de composi o Partes Pneus motor etc Capa centenas de folhas etc Cabelo pele ossos etc Tabela 13 Partes Objeto na rela o de composi o O processo reverso da composi o a decomposi o Normalmente em modelagem de dados usamos o conceito de composi o para dizer que uma classe como endere o uma caracter stica de outra classe descrevendo um entre seus atributos 1 2 3 Generaliza o um como Com a generaliza o n s somos capazes de entender como uma classe pode ser descrita por outra classe mais geral importante ver a diferen a entre a classifica o e a generaliza o a primeira trata da rela o entre objeto e classes enquanto a segunda trata da rela o entre classes Com a generaliza o podemos compreender uma rela o muito comum entre classes que a que permite que qualquer objeto de uma classe possa ser visto de uma forma mais geral como um objeto de outra classe Utilizando judiciosamente a generaliza o podemos simplificar a forma de tratar objetos de classes similares 107 Exemplos t picos de generaliza o Classes Classe mais geral Funcion rio Aluno Professor Pessoa Autom vel Avi o Navio Meio de Transporte Computador R dio Televis o Aparelhos Eletr nicos Tabela 14 Exemplo de generaliza o O processo reverso da generaliza
308. st ncia de uma entidade espec fica seja classificada em duas ou mais de suas subclasses temos alguns problemas que devem ser resolvidos na modelagem l gica Por exemplo uma pessoa pode ser aluno e professor simultaneamente em uma faculdade Tamb m poss vel que existam inst ncias que n o fazem parte de nenhum dos tipos de entidade especializados mas fazem parte do tipo geral Isso tamb m exige um tratamento especial durante a modelagem l gica N s dizemos ent o que e A cobertura total se cada elemento da classe gen rica mapeado em ao menos um elemento das subclasses e A cobertura parcial se existe ao menos um elemento da classe gen rica n o mapeado nas estruturas das subclasses P4 e A cobertura exclusiva se cada elemento da superclasse mapeado em no m ximo um elemento das subclasses e A cobertura sobreposta se existe um elemento da superclasse mapeado em mais de um elemento das subclasses Devemos tentar obter apenas heran as totais e exclusivas pois s o mais f ceis de serem tratadas Dado um grupo de entidades candidatas a construir um relacionamento de heran a devemos analisar se existe um atributo ou relacionamento que aplic vel a apenas um subconjunto dessas entidades se simplificamos o modelo e se aumentamos sua compreens o Ou seja devemos usar a heran a para aumentar a sem ntica do modelo sem causar excesso de informa o Outro relacionamento t o comum que mer
309. star e integrar toma tempo Como os requisitos s o vol teis quanto mais longo o processo mais facilmente os requisitos deixam de atender as necessidades e expectativas dos interessados Todos esses encargos recomendam que o analista conhe a tanto as t cnicas de desenvolvimento quanto o dom nio no qual se insere Existem v rios tipos de entrevistas Durante o processo de an lise elas normalmente seguem o seguinte processo 1 Introdu o inicial Familiariza o com o ambiente Busca de fatos Verifica o de informa es conseguidas de outras formas Confirma o de informa es conseguidas com os candidatos Acompanhamento amplifica o ou clarifica o de entrevistas anteriores Outra grande vari vel da entrevista o seu objetivo entre outros Levantar informa es sobre a organiza o OA md ON e O Levantar informa es sobre uma fun o de neg cio 10 Levantar informa es sobre um processo ou atividade 11 Descobrir problemas 12 Verificar fatos previamente levantados 13 Fornecer informa o 14 Obter dicas para entrevistas futuras 46 H v rias formas de entrevista entre elas entrevista por question rio entrevista aberta entrevista estruturada IV 8 2 1 Entrevista por Question rio O question rio muito usado como t cnica de entrevista principalmente em pesquisas de mercado e opini o Exige prepara o elaborada Alguns aspectos particulares do processo merecem destaque emprego de vo
310. ste implicitamente em todas as fun es mais abstratas diagramas superiores que a fun o sendo descrita VI 4 2 Constru o de um modelo IDEFO Um modelo IDEFO deve ser constru do normalmente da forma top down partindo do mais abstrato para o mais detalhado O m todo top down permite que nos preocupemos primeiro com quest es gerais do sistema como a sua justificativa que fun es deve realizar e mais tarde com sua realiza o Outra caracter stica importante a necessidade de delimitar o escopo de an lise e descri o do sistema o que tamb m apoiado pela t cnica top down do IDEFO j que ela exige que uma descri o abstrata do sistema tenha sua fronteira bem definida na forma de entradas sa das controles e mecanismos Pierre Nancy 2004 1998 fid Um conjunto de diagramas IDEFO conhecido como um kit IDEFO tem que responder a duas perguntas para que serve o sistema e como ele funciona Objetivo Para come ar a modelagem IDEFO o analista deve primeiro determinar e descrever de forma clara qual o objetivo do modelo em que ponto de vista as atividades ser o descritas e em que contexto isso feito Isso funciona como uma especifica o de requisitos do modelo que est sendo feito Quando o objetivo do modelo atingido o modelo est completo Um objetivo poss vel por exemplo identificar oportunidades para consolidar fun es j existentes de forma a melhorar o desempenho da organiza o Claro
311. stema fornece ao neg cio o comportamento adequado Todos os requisitos funcionais foram atendidos pelos casos de uso Que casos de uso v o suportar e manter o sistema Que informa o precisa ser modificada ou criada Casos de Uso Especiais In cio e Parada do sistema Manuten o do sistema Manuten o da informa o Normalmente aparece mais tarde Adicionar nova funcionalidade a sistema funcionando Sistemas que n o podem parar Portar o sistema rodando para um novo ambiente Quando o ator a organiza o desenvolvedora Coment rios O valor dos casos de falha detectar situa es anormais e manter a completude Todo cen rio vai do in cio ao fim sem ses mas a descri o pode ser abreviada Os requisitos cobrem as falhas recuper veis ou n o Mas n o s o falhas do sistema interno mas do ambiente O cen rio ideal ajuda a descrever as falhas Um cen rio pode se referir a objetivos de n vel inferior Caso de uso subordinados Fun es comuns Um caso de uso superior s se interessa se o caso de uso inferior alcan a o sucesso ou falha N o analisa os detalhes Cada passo de um cen rio um sub objetivo 192 1X 14 9 IX 14 10 IX 14 11 IX 15 IX 15 1 Oie n ad DO D Esconde um sub caso de uso Pode ser t o profundo que n o descrito Cada senten a em cada n vel um objetivo Casos de uso N O Mostram requisitos de interface o Colete por caso de uso Mostram requisitos de
312. stemas mais modernos como sistemas multim dia e websites podemos ainda ter profiss es novas como artistas e professores E importante verificar que as pessoas em uma equipe de desenvolvimento se comunicam de alguma forma Seguindo a regra de quanto maior o projeto maior o n mero de pessoas muito maior o n mero de formas em que essas pessoas podem se comunicar A figura a seguir tenta demonstrar essa id ia Como uma pessoa n o h nenhuma comunica o Com duas pessoas s h uma maneira delas se comunicarem Com 3 pessoas escolhendo apenas a comunica o entre duas pessoas j existem 3 formas Com 4 pessoas s o 6 formas com 5 pessoas s o 10 formas Basicamente com N pessoas existem Nx N 1 2 formas delas se comunicarem duas a duas Em projetos enormes se todos puderem falar com todos para fazer algo a situa o fica incontrol vel Por isso temos que organizar a equipe de desenvolvimento de alguma forma Figura 9 As linhas de comunica o entre as pessoas crescem rapidamente segundo uma explos o combinat ria Em uma equipe com organiza o democr tica todos podem se comunicar com todos Esse tipo de equipe razo vel para projetos pequenos com equipes de at 5 ou 6 pessoas onde a comunica o incentivar a descoberta Normalmente essas equipes s o encontradas em universidades e no desenvolvimento de pequenos projetos de alta tecnologia um web site por exemplo TRI OMC Figura 10 Em uma
313. stra o m todos que podem ser utilizados tanto de forma isolada como unificada Deve ser levado em considera o que o m todo IDEFO faz parte de uma fam lia de m todos que podem ser utilizados juntos no caso de modelagem de processo existe o m todo IDEF3 que n o usaremos nesse texto por considerarmos o EPC um m todo superior VI 9 Exerc cios VI 9 1 Projeto 1 Livraria ABC Fa a todos os modelos de neg cios descritos nesse cap tulo para a Livraria ABC da forma mais completa poss vel 104 Cap tulo VII Modelo Conceitual de Dados Models are to be used not believed H Theil Principles of Econometrics Data is not information Information is not knowledge Knowledge is not understanding Understanding is not wisdom Cliff Stoll amp Gary Schubert Modelo de Dados Entidades Relacionamentos Atributos Chave Candidata Chave Prim ria Formas Normais O Modelo Conceitual de Dados como o nome diz um modelo abstrato que descreve as informa es contidas no sistema O objetivo final do modelo de dados a cria o do banco de dados do sistema seja ele por meio de simples arquivos ou sofisticados sistemas de gerenciamento de banco de dados Em geral as informa es contidas no modelo ser o aquelas que o sistema precisa ter para executar uma fun o e que n o s o fornecidas pelo mundo exterior no momento que a fun o solicitada mas sim anteriormente O modelo de dados um tipo
314. strar detalhes que n o s o suportados pela nota o IDEFO 21 Controle o tamanho do diagrama a partir do escopo principalmente controlando a extens o do diagrama 22 Controle a profundidade do diagrama a partir do detalhe necess rio para o objetivo do modelo VI 5 Processos de Neg cio Processos de neg cio s o grupos de decis es e atividades logicamente relacionadas requeridas para o gerenciamento de recursos da empresa Podemos entender processos de neg cio como uma seqgii ncia de passos e decis es iniciadas em resposta a um evento de neg cio que alcan a um resultado espec fico e mensur vel tanto para o consumidor do processo como para outros interessados stakeholder B22 Al m disso necess rio que identifiquemos inst ncias espec ficas dos resultados N o trivial identificar processos pois eles acontecem dentro da organiza o de forma esparsa provavelmente envolvendo diversas pessoas e departamentos Tamb m n o trivial representar processos pois corremos v rios riscos como fazer uma representa o muito complexa ou muito simples ser impreciso ou utilizar o m todo de forma errada Normalmente sistemas de informa o s o utilizados para automatizar processos de neg cios Pode ser necess rio antes de fazer o levantamento de requisitos de um sistema levantar como funciona o processo onde ele est inserido ou que vai substituir Nesse tipo de modelagem estamos preocupados com a
315. ta que estamos comprando outros sistemas de informa o n o espec ficos para a Livraria ABC no mercado Por exemplo teremos um sistema de contas a pagar e a receber que dever receber as informa es do sistema que voc s v o fazer O que eu mais preciso melhorar o nosso relacionamento com o cliente Para isso a informa o que vem do sistema de vendas essencial Uma coisa importante por exemplo saber que clientes frequentes n o compram mais na frequ ncia que compravam Outro classificar os clientes de acordo com o tipo de livro que gostam para podermos fazer ofertas de livros novos Outra coisa importante que com os problemas de entrega acabamos com um pequeno estoque de livros que compramos mas os clientes n o compraram da gente Ent o eu quero fazer algo com isso Uma mala direta de promo o por exemplo Tenho pensado muito em como um sistema pode nos ajudar At mesmo pensei se n o seria interessante vender livros pela Internet o que voc s acham disso Seria uma grande novidade para n s e nossos clientes XII 5 Entrevista 4 Enron Lando Nopapo vendedor Sou eu que fa o as vendas mesmo aqui Normalmente eu recebo um pedido do cliente com uma lista de livros Ent o eu vou nos v rios cat logos que possu mos alguns de editoras outros de distribuidoras e procuro os livros desejados Fa o uma lista com cada livro onde podemos compr los o prazo de entrega e o pre o de custo e uma estimativa de
316. tamos a tela para o dicion rio 165 5 Dicion rio de Eventos w Rm Peste pa OS E piada Figura 85 Tela complementar indicando as entidades mem rias envolvidas em cada evento VII 13 Especificando Processos O nome de cada processo incluindo as atividades essenciais formado de um verbo no infinitivo e de um objeto direto que indicam como o sistema responde ao evento Exemplos 166 Evento Atividade Gerente solicita relat rio de Vendas Emitir Relat rio de Vendas Aluno solicita boletim Emitir Boletim Fornecedor entrega mercadoria Receber mercadoria Tabela 24 Nomes de atividades para alguns eventos VIIL 13 1 Especifica o do Tipo Caixa Preta A primeira especifica o que devemos fazer de um processo ou atividade essencial deve enxergar esse processo ou atividade como uma caixa preta Dessa forma a descri o deve discutir apenas seus efeitos nas mem rias e as entradas e sa das dos agentes externos Esta especifica o inicial deve ser feita utilizando a linguagem do cliente Por exemplo e Especifica o do Processo Cadastrar Cliente Ap s conferir se o CGC v lido deve registrar as informa es passadas pelo cliente na mem ria CLIENTE VIII 13 2 Especifica o do Tipo Caixa Branca A especifica o de processo na modelagem essencial chamada de mini especifica o Cada processo e nisso se incluem as atividades es
317. te informa seu nome e entrega as fitas ao funcion rio 3 O funcion rio registra o nome do cliente e inicia a loca o 4 O funcion rio registra cada uma das fitas 5 O funcion rio finaliza a loca o devolve as fitas ao cliente e lhe informa a data de devolu o e o valor total da loca o 6 O cliente vai embora com as fitas Fluxos Alternativos 3a O cliente n o possui cadastro 3a 1 O cliente deve informar seus dados para cadastro 3a 2 O funcion rio registra o cadastro 3a 3 Retorna ao fluxo principal no passo 3 179 3b O cliente possui pend ncias no cadastro loca o anterior n o foi paga 3b 1 O cliente paga seu d bito 3b 2 O funcion rio registra a quita o do d bito eliminando assim a pend ncia 3b 3 Retorna ao passo 3 4a Uma fita est reservada para outro cliente 4a 1 O funcion rio informa que a fita n o est dispon vel para loca o 4a 2 Prossegue a loca o do passo 4 sem incluir a fita reservada 4b Uma fita est danificada 4b 1 O funcion rio informa que a fita est danificada 4b 2 O funcion rio registra que a fita est danificada 4b 2 O funcion rio verifica se existe outra fita dispon vel com o mesmo filme 4b 3 Se existir o funcion rio substitui a fita e segue no passo 4 sen o segue do passo 4 sem incluir a fita danificada IX 5 Diagramas de Caso de Uso Um diagrama de caso de uso representa de forma muito abstrata o fato de q
318. tem a possibilidade de ser violada em um ou mais eventos do sistema A quest o do que um evento ser respondida mais a frente nesse texto no Cap tulo VII por m no momento basta entendermos que um evento algo que exige que alteremos os fatos conhecidos pelo sistema ou seja um evento exige a altera o de algum dado na base de dados ou que consultemos esses fatos a fim de inform los de alguma forma processada ao usu rio Analisando uma regra podemos ver que tipos de eventos s o prov veis de necessitarem de alguma aten o do sistema Por exemplo suponha que um sistema de vendas para uma empresa possua as regras B28 e Um aluno cliente solicita um produto e Um vendedor designado para atender um cliente permanentemente A descri o acima faz com que nos perguntemos e O que acontece quando um cliente faz seu primeiro pedido e n o tem ainda um vendedor associado e Oque acontece quando um vendedor se desliga da empresa Em todo evento um conjunto de regras deve ser ativado e cada erro deve ser reportado ao usu rio VI 6 5 Descrevendo Regras de Neg cio Existem muitas formas de descrever regras de neg cio de acordo com o grau de formalismo e a necessidade de execu o ou compreens o por serem humanos que desejamos A tabela a seguir define quatro formas b sicas de descri o 98 Vers o em uma Vers o em uma Vers o em linguagem linguagem de linguagem de natural especifica o de implementa
319. tema de reservas de hotel que se propunha a aumentar a ocupa o dos quartos Ora o n vel de ocupa o dos quartos de um hotel depende de muitos fatores inclusive da economia geral Entendemos que o sistema poderia ter como meta por exemplo diminuir o n mero de reservas n o cumpridas Essa meta mensur vel e pode ser diretamente influenciada pelo sistema por meio de verifica es com o cliente por exemplo interessante notar que a meta selecionada um dos fatores que afeta a meta proposta inicialmente Essa outra armadilha comum escolher uma meta e uma m trica que na verdade derivada da meta e da m trica que o sistema tem condi es de atingir Se n o poss vel nenhuma medida n o ser poss vel tamb m saber se a meta foi alcan ada o que a torna sup rflua V 6 1 Metas subjetivas E poss vel que sejam definidas metas n o mensur veis de forma objetiva Isso pode ser resolvido por meio de avalia es subjetivas 2 Por exemplo uma meta comum melhorar o atendimento ao usu rio Essa meta pode em alguns casos ser transformada em outra meta como diminuir o tempo de atendimento diretamente mensur vel Mas tamb m pode ser medida por meio de entrevistas com avalia es subjetivas ou observa o do servi o V 6 2 Levantando Objetivos e Metas A melhor maneira de levantar objetivos e metas entender simultaneamente o que o cliente deseja o que est funcionando agora quais
320. tidades que s podem existir juntas no sistema e considerar como entidades distintas h Se voc tem d vidas sobre a diferen a entre o modelo relacional e o modelo de entidades e relacionamentos o modelo relacional fala sobre a representa o de dados como tuplas rela es matem ticas em tabelas o modelo de entidades e relacionamentos fala da representa o do mundo real em um modelo abstrato composto de tipos de entidades e relacionamentos entre essas entidades 45 x i EPOa Alguns autores n o sugerem as formas normais em seus modelos conceituais e normalizam apenas seus modelos l gicos Essa pr tica pode ser prejudicial ao entendimento do problema pois as formas normais nos auxiliam a desenvolver um modelo mais correto 138 redund ncia e favorecendo a possibilidade de dois analistas chegarem ao mesmo modelo por vias independentes ou concordarem em adotar um modelo nico Tamb m permitem que algumas discuss es do tipo X entidade ou atributo sejam decididas imediatamente Essas caracter sticas s o objetivos claros da modelagem essencial e por isso nos parece bastante adequado utilizar modelos conceituais normalizados O tratamento dado s formas normais nesse texto apenas introdut rio devendo o leitor se referir a livros de bancos de dados ou de modelagem de dados para uma abordagem mais completa 1 14 1 Primeira Forma Normal 1FN Algumas defini es equivalentes pr prias do modelo relacional
321. tificar a data de vencimento controlar diferentes datas para um produto etc Em muitos contextos essa fun o pode parecer interessante mais ser na pr tica in til Em uma oficina mec nica por exemplo ela pode ser totalmente in til Em um grande mercado ela pode ser bastante til Por m em um pequeno mercado onde o propriet rio tem na verdade um controle mental do estoque e precisa do sistema de estoque apenas para fazer um controle legal ou financeiro essa funcionalidade pode parecer til a princ pio mas nunca ser usado no dia a dia As oportunidades devem produzir resultados teis para a empresa como acelerar processos eliminar passos desnecess rios reduzir erros na entrada e sa da de dados aumentar a integra o entre sistemas aumentar a satisfa o do usu rio e facilitar a intera o com os parceiros externos da organiza o fornecedores representantes e clientes B15 60 V 6 Metas e suas m tricas Enquanto o objetivo define o que far o sistema as metas justificam a sua exist ncia para o neg cio Uma meta um efeito positivo no neg cio do cliente que esperado com a implanta o do novo sistema Metas s o benef cios trazidos pelo novo sistema ao neg cio A an lise das metas permite ao cliente verificar qual a rela o custo benef cio da implanta o de um novo sistema Baseado nas metas o cliente capaz de fazer uma avalia o econ mico financeira comparando o pre o do sistema ou
322. tir que o pedido seja enviado ao estoque com qualquer tecnologia por exemplo cartas telefone pombo correio ou computadores ligados na Internet Por m fica claro ao analisar um pedido feito por cartas que o sistema ficar parado esperando a resposta logo a resposta outro evento que faz com que o sistema volte a funcionar 155 VIII 6 4 Habilitando Eventos Da mesma forma que um evento esperado pode precisar de um n o evento interessante tamb m perceber que muitos eventos esperados s podem acontecer caso outro evento aconte a antes Por exemplo em um sistema de controle de presta es Cliente paga parcela de presta o normalmente um evento esperado por m ele s pode acontecer depois que Cliente solicita cr dito ocorre Dizemos que um evento habilita o outro Isso equivale a uma mudan a no estado do sistema que deve ser anotada em alguma mem ria Em muitos sistemas podemos ver eventos sendo habilitados por outros eventos Novamente devemos tomar cuidado para n o confundir o fato de um evento poder habilitar outro evento com as respostas de um evento Uma resposta algo que essencialmente pode ser realizada em fun o do acontecimento do evento Um evento habilitado necessita de um outro est mulo para acontecer por m ele imposs vel sem que algum evento anterior o libere para funcionar Um evento desse tipo altera o estado do sistema N o h uma nota o especial para eventos que habil
323. to n o se comunicam por meio de fluxos de dados Toda comunica o entre atividades essenciais feita por meio do uso da mem ria do sistema VIII 6 1 Propriedades dos eventos Um evento pode ser caracterizados pelas seguintes propriedades e Um evento deve ocorrer em um momento espec fico no tempo e Um evento deveocorrer no ambiente e n o dentro do sistema e A ocorr ncia do evento deve estar sob o controle do ambiente e n o do sistema e O sistema pode detectar que o evento ocorre e O evento relevante isto o sistema deve fazer alguma quando ele ocorre VIII 6 2 Tipos de Eventos Cada evento pode ser externo ou temporal Um evento externo quando parte do ambiente para dentro do sistema Um comando ou um pedido do usu rio por exemplo Um evento temporal quando provocado por uma mudan a no tempo como um alarme de rel gio ou uma data no calend rio 60 i a ta E A frase pode ser lida como significando Aluno solicita matr cula ao sistema l Ruble D A Use Cases that Work Using Event Modelling to infuse rigor and discipline in Use Case Analysis White Paper Olumpic Consulting Group http www ocgworld com doc Use 20Cases 20that 20Work pdf 29 9 2005 153 Originalmente s trat vamos esses dois tipos de eventos externos e temporais Com o tempo por m fomos aprendendo a trabalhar e a classific los mais detalhadamente de forma a melhorar nosso trabalho Eventos temporais po
324. to e preparo para os entregadores a gente usa a DHD ou a XPS Muitas vezes eu telefono ou mando um e mail para avisar o cliente que o pedido est sendo enviado XII 6 Nesse Exerc cio 1 Levante os stakeholders 2 Levante interesses e objetivos dos stakeholders 3 Levante os atores 4 Levante os casos de uso de n vel sum rio nuvem e n vel empresarial caixa preta en Levante os casos de uso de n vel sum rio pipa e n vel empresarial branca Liste os casos de uso de n vel usu rio e n vel sistema caixa preta a Descreva de forma breve e casual um desses os casos de uso b Descreva de forma detalhada um desses casos de uso 7 Desenhe os Diagramas de Atividade para todos os casos de uso 8 Define as condi es de exce o 233 Projeto 2 Empresa de Clipping ClipTudo A empresa de clipping ClipTudo trabalha coletando mat rias de jornal que s o de interesse de seus clientes preparando um portfolio peri dico contendo c pias de todas as mat rias uma pequena avalia o de cada mat ria segundo alguns crit rios espec ficos e ainda um relat rio mensal global A empresa funciona da seguinte maneira Com um entrevistador o cliente define t picos de interesse Cada t pico uma palavra ou uma senten a que pode ser identificada facilmente como o nome da empresa do cliente ou um termo como reforma da previd ncia ou venda de bebidas A partir desses termos iniciais o entrevistador cria uma lista
325. tor Figura 73 Mesma figura anterior agora usando a nota o participativa com m nimos e m ximos de cardinalidade proposta por Ceri Aten o que as cardinalidades ficam na posi o contr ria nota o anterior software Visio 2000 1 11 2 Nota o adotada Podemos adotar qualquer nota o contanto que seja utilizada de forma consistente em um projeto ou em uma empresa No curso que ministramos por m sugerimos as seguintes nota es IDEFIX ou IE N o recomendamos mais o uso de nota es com losangos Se escolher a ferramenta Erwin utilize a nota o de information engineering Se escolher o Visio 2002 utilize a nota o que utiliza crow foot Apresente os tipos dos atributos e as chaves prim rias mas n o represente as chaves estrangeiras Na prova Muitas vezes melhor representar os atributos como c rculos do que dentro das caixas 1 12 T cnicas de Desenvolvimento do Modelo A seguir apresentamos quatro estrat gicas b sicas para desenvolver o modelo ER de um sistema Nenhuma estrat gia melhor que as outras em todos os casos nem todas as estrat gias v o levar a mesma solu o 1 12 1 T cnica Top Down Na t cnica top down desenvolvemos o modelo ER partindo de entidades altamente abstratas e aplicando transformadas que permitem encontrar entidades menos abstratas e mais representativas do sistema sendo desenvolvido O processo termina quando todos os requisitos f
326. tos referenciais Um exemplo de atributo referencial f brica para autom vel referenciando a f brica onde foi constru do uma op o do analista criar ou n o entidades que permitem a substitui o de um atributo referencial por um relacionamento 1 9 1 Descrevendo Atributos Devemos definir as seguintes caracter sticas e Nome e Descri o e Dom nio valores v lidos como inteiro real string ou uma lista de valores ou ainda tipos criados pelo projetista e Tipos de nulos aceitos e Exemplos Na descri o devemos nos preocupar em explicar qual a finalidade do atributo como s o atribu dos os valores o que significa cada valor quem define a escolha do valor quando por que e por quem o valor atribu do ou alterado etc Atributos s o atualmente denotados no mesmo ret ngulo da entidade como mostrado nos exemplos a seguir 1 10 Identificando Entidades Como vimos no in cio do cap tulo uma abstra o importante a identifica o No caso de modelos ER essencial que cada inst ncia de uma entidade possa ser identificada unicamente com um objeto ou conceito do mundo real Para fazer essa identifica o s o utilizados atributos e relacionamentos identificadores 38 E Mae Rr Especifica es ou descri es 127 Algumas vezes mais de um atributo ou relacionamento serve como identificador nico por m de forma independente No Brasil esse o caso das placas de carro e dos n me
327. tp guir cs berkeley edu projects denim foi projetado para isso Ele permite que um grupo de pessoas desenhe a interface a m o e associe algum comportamento que executado pelo automaticamente Na verdade o software mais adequado a ambientes que usam canetas como um tablet PC do que mouse Uma das vantagens de usar um software desse tipo que ele pode executar a interface automaticamente DENIM fornece essa possibilidade por meio do comando Run No futuro DENIM deve permitir a identifica o autom tica dos widgets mais comuns em ambientes de desenvolvimento 7 Imagem ilustrativa usada pelos princ pios de fair use N o se aplicam a essa imagem os mesmos direitos desse texto 206 Figura 113 O software DENIM para desenho de prot tipos de baixa fidelidade e constru o de storyboards Landay amp intivrolpartesidenim dam Run Denimi loj xi amp Back D Forward o Refresh Relat rios Home Filtros Cadastros Fornecedor Material yr Produto Vad audi Relat rios Ma Am Vu Ma m M in Mjm w W w da O M an w Mo Figura 114 Uma p gina sendo executada em DENIM Landay X 4 Modelos de Navega o Modelos funcionais e de dados tamb m n o representam uma caracter stica importante que o comportamento esperado do sistema pelos usu rios Novamente alguns autores defendem que essa modelagem deve ser feita na fase do projeto e provavelmente ela realmente
328. tudo feito de forma manual Por m com a possibilidade cada vez maior de trabalhar com livros do mundo todo nosso trabalho aumentou muito Meu pai das antigas mas eu o convenci a come ar a mudar as coisas para eu poder tocar melhor o neg cio sozinho quando ele se aposentar Primeiro pensei em contratar mais pessoas por m isso n o ia diminuir a confus o de pap is com que estamos lidando e a falta de informa es ent o resolvi que seria necess rio informatizar a empresa para se necess rio crescer Hoje nosso processo como todo manual tem muitos defeitos Temos muita informa o repetida pois temos que controlar os pedidos dos clientes e as requisi es aos fornecedores que se cruzam Muitas vezes recebemos um livro e por um problema de anota o n o sabemos para qual cliente se destina Ent o gastamos um bom tempo procurando cliente por cliente quem pediu aquele livro Mantemos tamb m v rios arquivos de clientes o que facilita em certos casos mas dificulta em outros Temos os clientes com pedido em andamento aqueles com pedidos atendidos mas n o pagos os freq entes e os outros clientes que n o se enquadram em nenhuma dessas categorias E tem a lista dos clientes expulsos pois nos deram calote e ainda tem a cara de pau de pedir outro livro Como estamos sempre manipulando fichas algumas vezes esquecemos de requisitar a um fornecedor um ou mais livros pedidos pelo cliente Isso atrasa o atendi
329. ubfun es e Ser realizada em uma ou mais reas 1 Images copyright O 2000 by Cartography Associates Images may be reproduced or transmitted but not for commercial use For commercial use or commercial republication contact carto O luna img com This work is licensed under a Creative Commons License OGO http creativecommons org licenses by nc sa 2 0 17 Images copyright O 2000 by Cartography Associates Images may be reproduced or transmitted but not for commercial use For commercial use or commercial republication contact carto O luna img com This work is licensed under a Creative Commons License CX http creativecommons org licenses by nc sa 2 0 18 NA H s N o h necessariamente um mapeamento direto entre fun es e o organograma 73 e Ser realizada por um indiv duo um grupo grupos de grupos reas da organiza o ou at por toda a organiza o e Envolver um ou mais atividades distintas sejam elas dependentes ou independentes e Ser identificada e definida mesmo que n o seja executada Tamb m poss vel entender dois tipos de fun es as de neg cio ou seja aquelas presentes na cadeia de valor da empresa e que t m rela o com o aspecto operacional do neg cio e as de administra o ou suporte VI 4 Modelagem de Fun es com IDEFO IDEFO Integration Definition Language 0 ou Integration Method for Function Modelling B21 uma forma de representar sistemas des
330. ue ocorrem no ambiente e que respostas est o associadas a cada mudan a de estado Diagramas de estados s o compostos de dois s mbolos b sicos estados c rculos ou caixas e transi es setas Os estados t m um nome ou um n mero enquanto as transi es s o indicadas com um evento que ativa a transi o e uma sa da provocada pela transi o Apesar de sua simplicidade DTEs s o ferramentas muito poderosas para modelagem Podem ser usados de diferentes formas na modelagem essencial para descrever o funcionamento do sistema como um todo ou de parte dele para descrever os estados poss veis de uma entidade Mesmo uma mini especifica o pode em alguns casos ser mais bem representada por um diagrama de estados Yourdon B43 sugere que as seguintes perguntas devem ser feitas para verificar um DTE Todos os estados foram definidos Todos os estados podem ser atingidos Todos os estados t m uma sa da Em cada estado o sistema reage adequadamente a todos os eventos Existem no mercado diferentes ferramentas gratuitas ou comerciais de desenho e verifica o de DTEs Existem tamb m outras formas similares de modelagem como Redes de Petri e StateCharts In cio i a N J Evento a PS SS e Sa da 1 N 7 N o j p Sae Evento c S Enie Ba N Sa da 2 y N Estado 1 Estado wo Ed k Ean Nao 1 N Z Eventod D Figura 86 Um diagrama de estados simples N o existe uma nota
331. ue o problema constrangedor 50 demais para ser tratado O analista deve constatar esse fato no processo de an lise mas n o durante a entrevista Observe e anote as interrup es casadas por fatores externos telefone pessoas que entram e que saem etc Separe o que fato do que opini o Conclua a entrevista de forma positiva 1V 8 3 1 O Comportamento do Entrevistador Esteja atento ao pr prio comportamento Lembre se que n o importa sua inten o ao fazer ou deixar de fazer algo mas a interpreta o que o entrevistado dar ou que fizer ou n o fizer No passado era comum que consultores sempre se vestissem de terno at mesmo apenas ternos escuros A maioria das empresas hoje utiliza um c digo de vestimenta informal A regra mais atual que o entrevistador ou consultor tome cuidado para n o provocar um grande desn vel entre a sua roupa e a roupa do entrevistado ou cliente se adaptando as normas de vestimenta do cliente ou do mercado ao qual o cliente pertence Fisicamente n o fa a movimentos desnecess rios como bater o l pis na mesa mexer as chaves no bolso etc Movimentos autom ticos e cacoetes distraem o entrevistado e al m disso podem ser interpretados como falta de aten o N o fume mas tamb m n o evite que seu entrevistado fume N o constranja o entrevistado comentado sobre os males do fumo N o pe a caf mas pode aceitar o oferecido Se necess rio pode pedir gua Estabele
332. ue um ator usa um caso de uso de um sistema Seus principais componentes s o atores e casos de uso Atores s o representados por bonecos e casos de uso por elipses Nas figuras a seguir exemplificamos os objetos b sicos utilizados no desenho de um diagrama de caso de uso s Comunica o Ator usa de Comunica o Indicando Caso de Uso Inlcla o Sistema Fig 95 Artefatos gr ficos usados na cria o de um diagrama de casos de uso Comprador Banco Executar Relat rios Manter M quinas ATM Manuten o ATM Fig 96 Exemplo de um diagrama de caso de uso IX 6 Rela es entre casos de uso Os objetos que comp e um diagrama de caso de uso podem se relacionar de diferentes formas como descrito na figura a seguir Fig 97 Tipos de relacionamentos entre objetos do diagrama de casos de uso IX 6 1 Generaliza o entre Atores Muitas vezes diferentes atores tem caracter sticas comuns Se estas caracter sticas comuns puderem ser descritas como uma rela o de especializa o generaliza o podemos representar isso diretamente em um diagrama de caso de uso por meio da rela o de generaliza o usando uma seta com ponta triangular e linha cheia M ltiplos atores podem ter pap is comuns ao interagir com um caso de uso A rela o de generaliza o pode ser usada para simplificar rela es entre muitos atores e um caso de uso Ela tamb m mostra que uma inst ncia de um at
333. um pedido s pode conter livros da editora indicada no pedido poss vel desenhar o diagrama sem ciclos eliminado por exemplo a liga o entre pedido e editora por m aconteceriam duas coisas primeiro ter amos que escrever uma restri o que possivelmente mais complexa um pedido s pode conter livros da mesma editora segundo n o ter amos nenhuma indica o no diagrama que o pedido feito para a editora exigindo uma nova regra Finalmente a falta do ciclo funciona tamb m como falta de indica o que existe uma restri o pois todo ciclo um aviso de restri o 1 8 1 Cardinalidade Para bem representar um relacionamento devemos indicar a cardinalidade desse relacionamento isto quantas vezes uma inst ncia da entidade pode se relacionar com inst ncias de outras entidades Veja por exemplo o relacionamento m e filha Uma filha s pode ter uma m e mas uma m e pode ter v rias filhas Existem tr s tipos b sicos de relacionamentos o 1 1 um para um o 1 N um para muitos e o N M muitos para muitos Nesse caso s estamos falando da cardinalidade m xima A cardinalidade m xima indica quantas vezes uma entidade pode aparecer em um relacionamento ao Ross por m prop e uma linguagem gr fica que permite a defini o de restri es A linguagem muito complexa e n o existe ainda nenhuma ferramenta CASE que a suporte 37 agua da g ai ip oa MORN AR Mas a aus ncia de um ciclo
334. uma lista Dentro Fora in out list B16 Essa lista simplesmente uma tabela contendo t picos e a indica o se aquele t pico est dentro ou n o do escopo do sistema 63 Escopo do Sistema T pico Receber pedido do cliente Enviar nota fiscal Atender pedido parcialmente Analisar cr dito Tabela 4 Exemplo de uma tabela de defini o de escopo V 7 2 Documentando os requisitos iniciais No Error Reference source not found discutimos como levantar e descrever os requisitos de um sistema Esses requisitos mesmo em forma informal e superficial devem ser levantados j nessa fase inicial O uso de cart es para cada requisito uma abordagem interessante pois permite a manipula o dos mesmos de v rias formas como compara o corre o e prioriza o V 8 O sistema atual Uma das tarefas mais importantes compreender perfeitamente como funciona o sistema atual Desprezar o sistema atual por mais antigo ou mal feito que ele seja um dos erros mais freq entes dos desenvolvedores S podemos criar um sistema novo ap s conhecer perfeitamente o sistema atual como funciona e porque funciona dessa forma Idealmente dever amos recuperar o Modelo Ambiental do sistema atual Isso por m nem sempre poss vel devido s press es de tempo e custo que sofremos na vida real Uma descri o em portugu s pode ser bastante satisfat ria para sistemas pequenos Para sistemas maiores pode
335. uma mem ria Com a Modelagem Conceitual de Dados damos a forma abstrata a essa mem ria de maneira a entender o que deve estar guardado na mem ria sem decidir prematuramente sua localiza o e estrutura 1 3 1 Modelo Conceitual MC O objetivo da modelagem conceitual fornecer aos desenvolvedores uma descri o abstrata de alto n vel independente de tecnologia da informa o contida no sistema Essa descri o conhecida como o esquema conceitual da base de dados A Modelagem Conceitual de Dados pode ser feita de muitas formas algumas vezes com sutis diferen as Alguns autores defendem a modelagem do dom nio onde tentamos descrever o dom nio de aplica o sendo utilizados outros tratam diretamente do sistema sendo desenvolvido Neste texto trabalharemos com uma abordagem mais pr xima do sistema sendo desenvolvido pois estamos buscando uma ferramenta que se encaixe com a an lise essencial O modelo conceitual constru do a partir da an lise de requisitos em geral simultaneamente ao desenvolvimento da an lise essencial Na pr tica o primeiro modelo essencial usar como mem rias os objetos descritos no DER Mundo Observado Requisitos Modelo Conceitual Esquema Conceitual Modelo L gico Esquema L gico Modelo F sico Esquema F sico Figura 50 Etapas da Modelagem de Dados Um dos subs dios mais importantes para a cria o do DER o conjunto de regras de neg cio levantadas Mu
336. umo de vendas e Gerente solicita relat rio de produ o e Caso o cliente n o pague a conta 20 dias depois invocar departamento jur dico e Caso o aluno n o apresente o boletim assinado 10 dias depois enviar aviso aos pais Vejamos agora alguns eventos descritos de forma incorreta e Enviar pedido sem agente externo ou indica o de tempo e Gerente imprime relat rio quem imprime o sistema o gerente solicita al m disso relat rio um termo muito vago VIII 8 Levantando os Eventos Essenciais A primeira e mais importante tarefa da modelagem funcional o levantamento dos eventos essenciais Isso feito n s teremos uma id ia bastante clara do tamanho do sistema Geralmente nossa estrat gia deve ser levantar uma lista inicial de eventos e refinar essa lista enquanto analisa a resposta para cada evento Duas s o as formas b sicas de levantamento de requisitos funcionais entrevistas e reuni es JAD V rias s o as formas de descrever uma lista de eventos Uma maneira partir dos eventos fundamentais e depois listar todos os eventos necess rios para que os eventos fundamentais funcionem Outra maneira seguir uma abordagem sequencial partindo dos eventos que geram dados para chegar aos eventos que geram relat rios no final 157 Alguns sistemas s o muito segiienciais facilitando claramente a segunda abordagem Nesse caso importante numerar os eventos no tempo para garantir que a sequ ncia ficou
337. ura 26 Exemplo em um fragmento de IDEFO dos usos de controles e entradas Algumas regras sint ticas Diagramas s o identificados Node na forma An onde n um n mero O diagrama A 0 A menos zero cont m s uma caixa a caixa zero que expandida no diagrama AO A zero Pode existir opcionalmente um diagrama que coloque o diagrama A O dentro de um contexto maior chamado A 1 A menos 1 O n mero de um diagrama formado pelas iniciais do autor e um n mero sequencial Um diagrama por ser FEO ver abaixo ou conter apenas texto ou gloss rio Nesse caso o n recebe o seu identificador seguido respectivamente das letras F T ou G Os diagramas s o desenhados em formul rios padronizados ver Figura 27 Caixas denotam atividades por isso devem ser ou conter verbos em seu nome Cada caixa numerada adicionando mais um n mero inteiro entre 1 e 6 n mero m ximo de caixas em um diagrama ao n mero da caixa pai As caixas dos diagramas s o numeradas 1 2 3 As caixas s o indicadas pelo nome do diagrama adicionadas do n mero da caixa a caixa 1 do diagrama Al se chama Al 1 2 Quando uma caixa detalhada em outro diagrama colocada uma refer ncia a esse diagrama abaixo do canto inferior esquerdo Essa refer ncia conhecida como DRE Cada caixa fun o representada por um r tulo centralizado formado por um verbo ou um verbo objeto e um segundo r tulo no canto inferior direito representa
338. ve Use Cases Um caso de uso bem escrito deve descrever de forma completa um processo executado pelo sistema contando uma hist ria completa de como o usu rio tenta alcan ar um objetivo espec fico ao usar o sistema Na sua forma mais completa um caso de uso apresenta v rios cen rios poss veis de sucesso ou falha na busca por esse objetivo Os casos de uso formam a especifica o funcional de um sistema Essa especifica o facilmente leg vel por usu rios ou desenvolvedores permitindo tamb m sua valida o e verifica o importante notar que os diagramas de caso de uso t m um valor muito pequeno frente ao documento textual que o caso de uso Casos de uso tratam o sistema sendo descrito como uma caixa preta As intera es entre os usu rios e o sistema s o descritas como percebidas pelo usu rio Um caso de uso deve e Descrever um tarefa de neg cio que serve a um nico objetivo de neg cio e N o ser orientado a uma linguagem de programa o e Tero n vel de detalhe apropriado e Ser curto o suficiente para ser implementado por um desenvolvedor de software em um vers o do produto IX 2 Ator Um ator uma entidade externa ao sistema com comportamento pr prio Os atores interagem com o sistema para alcan ar seus objetivos Em cada Caso de Uso um ator o ator principal que visa um objetivo principal naquele caso de uso Muitas vezes o sistema 174 invocar outros atores que dever o cumprir suas
339. vel conviver com ela sem ferir convic es ou valores essenciais 55 IV 9 Mind Map Necess rio N o ambiguo Verific vel Conciso Independente da Essenciais ernadaros Implementa o Caracter sticas P CJ Falsos Alcan vel Completo Stakeholders Interesses Consistente man Requisitos Orden vel E CEE Omnisciente Tipo a Externo ao Sistema Usu rios Interno ao Sistema Produto i Interesses Organiza o N o Funcionais A Objetivos Externo gt o Tipos Funcionais Figura 21 Principais t picos do cap tulo na forma de um mind map IV 10 Exerc cios IV 10 1 Projeto 1 Livraria ABC Baseado em todos os textos dispon veis sobre a Livraria ABC fa a 1 Uma lista de requisitos funcionais preliminares 2 Uma lista de requisitos n o funcionais preliminares 3 Uma lista de requisitos de informa o preliminares IV 10 2 Projeto de Curso Para o seu projeto de curso fa a uma lista com 1 Requisitos funcionais preliminares 2 Requisitos de informa o preliminares 3 Requisitos n o funcionais preliminares 4 Documente cada requisito dessa lista de acordo os descritores de requisitos mostrados nesse cap tulo 5 Para o seu projeto de curso prepare 6 Um roteiro de uma entrevista inicial do projeto 7 Um question rio a ser feito com os usu rios atuais do servi o com a finalidade de descobrir sua qualidade 56 Cap tulo V Uma Proposta Inicial It isn t that they can t see the solution It is that th

Modelagem de Sistemas de Informações

Contents

Download Pdf Manuals

Related Search

Related Contents

Modelagem de Sistemas de Informa&ccedil;&otilde;es

Contents

Download Pdf Manuals

Related Search

Related Contents

Modelagem de Sistemas de Informações