Home

ENGENHARIA DE SOFTWARE

1. 125 PASSO A PASSO PARA A ELABORA O DO DIAGRAMA DE CLASSES 127 DOCUMENTO DE REQUISITOS CONTROLE DE ESTOQUE 133 UNIDADE V PROJETO TESTES E EVOLU O DE SOFTWARE PROJETO DE SOR INARE meea sntisa tese ei 140 FORMATOS DE ENTRADAS SA DAS snescomeeminieiiitieniipiasisai die ce pia mensrie niasaimnrtads 155 VALIDA O DE SOFTINARE sgasassssesiieatittasasoiisepeicianigadadodieciitubiiandeguiieejeie cesiiadossfetisaitnedo 158 TPOS DE TESTES ipa prisional dai Sn aa 159 EVOLU O DE SOFTWARE us ntesijiass nara p ion ASen da Saia 162 CONCUIS O E A E Ri EE 166 REFERENCIAS naun ias id e a aeee 168 UNIDADE INTRODU O ENGENHARIA DE SOFTWARE Professora Me M rcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Entender o que engenharia de software e qual a sua import ncia Estudar os conceitos b sicos de orienta o a objetos necess rios para o entendi mento da UML Abordar a import ncia da utiliza o da UML para a modelagem de sistemas Plano de Estudo A seguir apresentam se os t picos que voc estudar nesta unidade Conceitos b sicos sobre Software e Engenharia de Software Tipos de Aplica es de Software Ferramentas CASE Conceitos B sicos de Orienta o a Objetos Introdu o UML CESUMAR CENTROUNIVERSIT RIO DE MARING INTRODU O dedicat e n ne e jedicated computer Sience toctni
2. lt RO gt C requisitos J 1 Valida o de requisitos Relat rio de J Viabilidade Modelos de sistema Requisitos de usu rio e de sistema Y gt Documento de gt requisitos Fonte Somerville 2011 p 24 As atividades de engenharia de requisitos mostradas nessa figura dizem respeito ao levantamento documenta o e verifica o dos requisitos Por m necess rio deixar claro que em praticamente em todos os sistemas os requisitos se modificam as pessoas interessadas desenvolvem melhor compreens o do que elas querem que o software fa a a organiza o compradora do sistema sofre modifica es e s o feitas altera es no hardware no software e no ambiente organizacional do sistema SOMMERVILLE 2007 p 95 ESTUDO DE VIABILIDADE Segundo Sommerville 2007 p 97 para todos os sistemas novos o processo de engenharia de requisitos de sistemas deve se iniciar com um estudo de viabilidade ou elicita o de requisitos O estudo de viabilidade inicia se com uma descri o geral do sistema e de como ele ser utilizado dentro de uma organiza o sendo que o resultado desse estudo deve ser um relat rio que recomenda se vale a pena ou n o realizar o processo de engenharia de requisitos e consequentemente o processo de desenvolvimento de sistemas Um estudo de viabilidade um estudo r pido direcionado que se destina a responder a Anota es 1X
3. DATA 99 99 9999 N PEDIDO NOME FORNECEDOR TOTAL COM PRADO 999999 XXXXXXXXXXXXXXXXXXXXXXXX 99 999 999 99 999999 XXXXXXXXXXXXXXXXXXXXXXXX 999 999 999 99 e Vendas di rias por cliente sint tico Este relat rio ser solicitado e recebido pelo Departamento de Vendas DATA 99 99 9999 TOTAL VEN DIDO 999999 XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX 99 999 999 99 999999 XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX 99 999 999 99 N NF NOME CLIENTE VENDEDOR 1 34 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING e Vendas por vendedor num determinado intervalo de data Este relat rio ser solicitado e recebido pelo Departamento de Vendas PER ODO 99 99 9999 A 99 99 9999 VENDEDOR XXXXXXXXXXXXXXXXXXXXXXXXXX DATA N NF NOME CLIENTE TOTAL VLR COMIS VENDIDO SAO 99 99 9999 999999 XXXXXXXXXXXXXX 9 999 999 99 999 999 99 99 99 9999 999999 XXXXXXXXXXXXXX 9 999 999 99 999 999 99 99 99 9999 999999 XXXXXXXXXXXXXX 9 999 999 99 999 999 99 ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 Jo UNIDADE V PROJETO TESTES E EVOLU O DE SOFTWARE Professora Me M rcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Expor a import ncia do projeto de software mostrando os artefatos que ser o cria dos durante o projeto Estudar os formatos de entradas e sa das de informa es atrav s da interface do sistema Entender o processo de valida o de software ou
4. REQUISITOS DE SOFTWARE Professora Me M rcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Entender os diversos tipos de requisitos relacionados ao desenvolvimento de sof tware Expor a import ncia do documento de requisitos Compreender o processo de engenharia de requisitos Plano de Estudo A seguir apresentam se os t picos que voc estudar nesta unidade Tipos de Requisitos de Software Documento de Requisitos Engenharia de Requisitos CESUMAR CENTROUNIVERSIT RIO DE MARING INTRODU O Caro a aluno a na segunda unidade voc aprendeu os conceitos relacionados a processo de software e viu que um processo composto de quatro atividades fundamentais especifica o de software projeto e implementa o de software valida o de software e finalmente evolu o de software Esta unidade vai tratar especificamente sobre requisitos de software e no final desta unidade voc vai compreender por que os requisitos s o importantes e devem ser muito bem definidos para que o software desenvolvido alcance seus objetivos Uma das tarefas mais dif ceis que os desenvolvedores de software enfrentam entender os requisitos de um problema Os requisitos definir o o que o sistema deve fazer suas propriedades emergentes desej veis e essenciais e as restri es quanto opera o do sistema Essa defini o de requisitos somente poss vel com a comunica o entre os clientes e os us
5. demonstrar que de fato um conjunto de requisitos atende s necessidades de um usu rio Os usu rios devem pensar no sistema em opera o e imaginar como esse sistema se adequaria ao seu trabalho N o f cil para profissionais habilitados de computa o conseguir realizar esse tipo de an lise abstrata imagina s como ser dif cil para os usu rios de sistema Sendo assim a valida o de requisitos n o consegue descobrir todos os problemas com os requisitos implicando em modifica es para corrigir essas omiss es e falhas de compreens o depois que o documento de requisitos foi aceito SOMMERVILLE 2011 p 77 Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 91 CESUMAR CENTROUNIVERSIT RIO DE MARING Gastamos um bom tempo a maior parte do esfor o de um projeto n o implementando ou testan do mas sim tentando decidir o que construir Brian Lawrence ex jogador de beisebol da Major League E Saiba mais sobre o Assunto Uso de prot tipos de interface como idioma durante a Valida o de requisitos Uma an lise semi tica Por Carlos Eduardo Marquioni M Sc PMP Fonte lt http www marquioni com br artigos php id artigo 148titulo Uso de prot tipos de interface como idioma durante a Valida o de requisitos Uma an lise semi tica gt Acesso em 12 jun 2012 ii CONSIDERA ES FINAIS Caro a aluno a chegamos ao final da terceira unidade na
6. es do objeto todo precisam ser complementadas pelas informa es contidas em um ou mais objetos de outra classe chamados objeto parte sendo que os objetos parte n o podem ser destru dos por um objeto diferente do objeto todo GUEDES 2007 p 57 O s mbolo de agrega o difere do de associa o por conter um losango na extremidade da classe que cont m os objetos todo A figura abaixo demonstra um exemplo de agrega o em que existe uma classe Pedido que armazena os objetos todo e uma classe Item Pedido em que s o armazenados os objetos parte numero pedido int FO data pedido Date 4 Item Pedido quantidade pedida String valor unitario String Produto codigo int descricao String preco venda float estoque atual float Exemplo de agrega o Anota es LX 1 1 8 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Neste exemplo um pedido pode possuir apenas um item como v rios n o sendo poss vel determinar o n mero m ximo de itens que um pedido pode ter Por isso as informa es da classe Pedido est o incompletas possuindo apenas atributos que n o se repetem Os atributos que podem se repetir devem ser armazenados em uma classe dependente da classe Pedido Dessa forma sempre que uma inst ncia da classe Pedido for pesquisada todas as inst ncias da classe Item Pedido relacionadas inst ncia da classe Pedido pesquisad
7. informar um intervalo de datas dessa forma ele poder emitir o relat rio de um nico dia de uma semana de um m s ou seja do per odo que ele desejar Este tipo de filtro torna o relat rio mais flex vel No exemplo abaixo ser o emitidos os pagamentos das consultas efetuadas a partir da data inicial at a data final informadas na tela de filtro Relat rio de Pagamento de Consultas Mikl E4 Data Inicial Data Final Imprimir Fechar Tela de Filtro do Relat rio de Pedido de Exame na tela abaixo s o oferecidos dois filtros primeiro o usu rio dever escolher se ele que selecionar por nome do paciente ou pelo seu c digo Depois ele poder escolher de qual data ele quer emitir o pedido de exame As op es que dever o aparecer na tela de filtro dos relat rios dever o ser discutidas com o usu rio pois o objetivo facilitar o andamento do seu trabalho quando o mesmo estiver utilizando o sistema FILTRO Pedido de Exame Iof x Preencha os campos a seguir Paciente Nome ou C digo Pedido Data ne oe sa Imprimir Visualizar Fechar ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 51 CESUMAR CENTROUNIVERSIT RIO DE MARING e Tela de Filtro do Relat rio de Contas a Pagar por Fornecedor no exemplo abaixo o usu rio poder escolher al m do per odo tamb m o fornecedor que ele deseja emitir o relat rio de contas a pagar Relat rio de Contas a P
8. o Lower CASE ou L CASE ou Back End praticamente o oposto das anteriormente citadas oferecem suporte nas ltimas fases do desenvolvimento como codifica o testes e manuten o Integrated CASE ou I CASE este tipo de ferramenta al m de englobar caracter s ticas das Upper e Lower CASE s ainda oferecem outras caracter sticas como por exemplo controle de vers o Entretanto esse tipo de ferramenta somente utilizado em projetos de desenvolvimento muito grandes por serem bastante caras e dif ceis de operar Best in Class ou Kit de Ferramenta semelhante as CASE os Kits de Ferramen ta tamb m acompanham todo o ciclo de desenvolvimento entretanto possuem a propriedade de conjugar sua capacidade a outras ferramentas externas comple mentares que variam de acordo com as necessidades do usu rio Para um melhor entendimento podemos compar las a um computador sem o kit multim dia as Best in Class seriam o computador que funciona normalmente e as outras ferramentas fariam o papel do kit multim dia promovendo um maior potencial de trabalho m Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 23 CESUMAR CENTROUNIVERSIT RIO DE MARING quina S o mais usadas para desenvolvimento corporativo apresentando controle de acesso vers o reposit rios de dados entre outras caracter sticas A segunda forma divide as Ferramentas CASE em orientadas fun o e orientadas atividade e O
9. relativamente novo e foi proposto para tornar o desenvolvimento de software sistem tico podendo ser realizado com padr es de qualidade dentro do cronograma e do or amento previstos inicialmente Para Sommerville 2011 p 5 a engenharia de software importante por dois motivos 1 A sociedade cada vez mais depende de sistemas de software avan ados portanto preciso que os engenheiros de software sejam capazes de produzir sistemas con fi veis de maneira econ mica e r pida 2 A longo prazo normalmente mais barato usar m todos e t cnicas propostos pela engenharia de software ao inv s de somente escrever os programas como se fos sem algum projeto pessoal Para a maioria dos sistemas o maior custo est na sua manuten o ou seja nas altera es que s o realizadas depois que o sistema implantado Anota es LA 20 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING Leitura Complementar Alguns Fundamentos da Engenharia de Software Por Wilson de P dua Paula Filho O que Engenharia de Software a mesma coisa que Ci ncia da Computa o Ou uma entre muitas especialidades da Ci ncia da Computa o Ou dos Sistemas de Informa o ou do Processamento de Dados ou da Inform tica ou da Tecnologia da Informa o Ou uma especialidade diferente de todas as anteriores Na maioria das institui es brasileiras de ensino superior o conjunto de
10. uma das causas de muitos problemas da engenharia de software SOMMERVILLE 2011 p 60 Pode acontecer que um desenvolvedor de sistemas interprete um requisito amb guo para simplificar sua implementa o por m nem sempre isso o que o cliente quer E quando isso acontece pode ser que novos requisitos devam ser estabelecidos sendo necess rio realizar mudan as no sistema podendo atrasar a entrega final do sistema e consequente aumento de custos De acordo com Sommerville 2011 p 60 em princ pio a especifica o de requisitos funcionais de um sistema deve ser completa e consistente A completeza denota que todas as fun es requeridas pelo usu rio devem estar definidas e a consist ncia denota que os requisitos n o devem ter defini es contradit rias Na pr tica para grandes sistemas atingir a consist ncia e a completeza dos requisitos bastante dif cil por causa da complexidade inerente ao sistema e em parte porque diferentes pontos de vista apresentam necessidades inconsistentes Requisitos n o funcionais Os requisitos n o funcionais s o aqueles que n o dizem respeito diretamente s fun es espec ficas oferecidas pelo sistema Eles podem estar relacionados a propriedades como Anota es LX 70 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING confiabilidade tempo de resposta e espa o em disco Como alternativa eles podem definir restri es para
11. 2005 O trabalho de Booch Jacobson e Rumbaugh conhecidos popularmente como Os Tr s Amigos resultou no lan amento em 1996 da primeira vers o da UML propriamente dita que foi chamada de vers o 0 9 T o logo a primeira vers o foi lan ada diversas empresas de software passaram a contribuir com o projeto estabelecendo um cons rcio de UML com v rias empresas que desejavam dedicar recursos com o objetivo de trabalhar para uma defini o mais forte e completa da UML criando se assim a vers o 1 0 da UML Essa vers o foi oferecida para padroniza o ao OMG Object Management Group ou Grupo de Gerenciamento de Objetos em janeiro de 1997 De acordo com Booch 2005 entre janeiro e julho de 1997 o grupo original de parceiros cresceu e passou a incluir praticamente todos os participantes e colaboradores da resposta inicial ao OMG criando uma vers o revisada da UML vers o 1 1 que foi novamente oferecida para padroniza o ao OMG Finalmente a UML foi adotada pela OMG em novembro de 1997 como uma linguagem padr o Anota es LX 34 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING de modelagem sendo que sua manuten o ficou sob responsabilidade da RTF Revision Task Force pertencente OMG O objetivo da RTF realizar revis es nas especifica es referentes a erros inconsist ncias ambiguidades e pequenas omiss es de acordo com os coment rios da comunidade
12. De acordo com Guedes 2007 p 32 na segunda divis o da classe aparecem os atributos sendo que cada atributo deve possuir um nome e eventualmente o tipo de dado que o atributo armazena como por exemplo integer float ou char Assim a classe especifica a estrutura de um objeto sem informar quais ser o os seus valores sendo que um objeto corresponde a uma inst ncia de uma classe em um determinado momento Vou mostrar um exemplo para facilitar o entendimento Uma classe pessoa possui os atributos nome sexo e data de nascimento Essa classe pode ter um objeto ou inst ncia com os seguintes valores para cada atributo respectivamente M rcia feminino e 22 03 1969 Dessa forma em um sistema devemos trabalhar com as inst ncias objetos de uma classe pois os valores de cada atributo s o carregados nas inst ncias MELO 2004 p 17 A figura abaixo mostra um exemplo de classe com atributos nome String sexo char data nascimento Date Exemplo de Classe com Atributos Anota es LX 26 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING M todos M todos s o processos ou servi os realizados por uma classe e disponibilizados para uso de outras classes em um sistema e devem ficar armazenados na terceira divis o da classe Os m todos s o as atividades que uma inst ncia de uma classe pode executar GUEDES 2007 p 33 Um m todo pode receber ou n o par metr
13. ENGENHARIA DE SOFTWARE Educa o a Dist ncia 81 CESUMAR CENTROUNIVERSIT RIO DE MARING algumas perguntas 1 O sistema contribui para os objetivos gerais da organiza o 2 O sistema pode ser implementado com a utiliza o de tecnologia atual dentro das restri es de custo e de prazo 3 O sistema pode ser integrado com outros sistemas j em opera o A quest o sobre se o sistema contribui ou n o para os objetivos da empresa fundamental pois se um sistema n o for compat vel com esses objetivos ele n o ter nenhum valor real para a mesma Embora isso possa parecer bvio muitas organiza es desenvolvem sistemas que n o contribuem para seus objetivos seja porque n o existe uma declara o clara desses objetivos ou porque outros fatores pol ticos ou organizacionais influenciam na aquisi o do sistema SOMMERVILLE 2007 p 97 Preparar um estudo de viabilidade envolve avaliar e coletar informa es e redigir relat rios A fase de avalia o identifica as informa es exigidas para responder s tr s perguntas apresentadas anteriormente Uma vez identificadas as informa es preciso questionar as fontes de informa o a fim de encontrar as respostas para essas perguntas Eis alguns exemplos das poss veis perguntas que devem ser feitas Como a organiza o se comportaria se esse sistema n o fosse implementado Quais s o os problemas com os processos atuais e como um novo sistema ajudaria a
14. Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Segundo Booch 2005 p 13 a UML Unified Modeling Language ou Linguagem de Modelagem Unificada uma linguagem padr o para a elabora o da estrutura de projetos de software podendo ser utilizada para a visualiza o especifica o constru o e documenta o de artefatos de software por meio do paradigma de Orienta o a Objetos A UML tem sido a linguagem padr o de modelagem de software adotada internacionalmente pela ind stria de Engenharia de Software GUEDES 2007 p 13 A UML n o uma linguagem de programa o mas uma linguagem de modelagem que tem como meta auxiliar os engenheiros de software a definir as caracter sticas do software tais como seus requisitos seu comportamento sua estrutura l gica a din mica de seus processos e at mesmo suas necessidades f sicas em rela o ao equipamento sobre o qual o sistema dever ser implantado Todas essas caracter sticas s o definidas por meio da UML antes do in cio do desenvolvimento do software GUEDES 2007 p 13 De acordo com Booch 2005 p 13 a UML apenas uma linguagem de modelagem e independente de processo de software podendo ser utilizada em modelo cascata desenvolvimento evolucion rio ou qualquer outro processo que esteja sendo utilizado para o desenvolvimento do software A nota o UML utiliza diversos simbolos gr ficos existindo uma sem ntica bem definid
15. Especial Abrir Conta Poupan a Exemplo de generaliza o entre casos de uso Agora vamos entender o que este exemplo est representando em um banco existem tr s op es de abertura de contas abertura de conta comum de conta especial e de conta poupan a cada uma representada por um caso de uso diferente As aberturas de conta especial e de conta poupan a possuem todas as caracter sticas e requisitos da abertura de conta comum por m cada uma delas possui tamb m algumas caracter sticas e requisitos pr prios o que justifica coloc las como especializa es do caso de uso Abertura de Conta Comum detalhando se as particularidades de cada caso de uso especializado em sua pr pria documenta o GUEDES 2007 p 41 O relacionamento de generaliza o especializa o tamb m pode ser aplicado entre atores A figura abaixo apresenta um exemplo em que existe um ator geral chamado Cliente e dois atores especializados chamados Pessoa F sica e Pessoa Jur dica Anota es LX 1 06 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Cliente Pessoa F sica Pessoa Jur dica Generaliza o entre Atores Inclus o Este tipo de relacionamento poss vel somente entre casos de uso e utilizado quando existem a es comuns a mais de um caso de uso Quando isso ocorre a documenta o dessas a es colocada em um caso de uso espec fico permitindo que outros casos de u
16. Um dos principais recursos da orienta o a objetos a Heran a entre classes uma vez que esse recurso pode reduzir substancialmente as repeti es nos projetos e programas orientados a objetos Dentro deste contexto a Explique o que Heran a b Crie um exemplo de Heran a com no m nimo tr s classes Neste exemplo devem aparecer atributos tanto na superclasse quanto nas subclasses 38 ENGENHARIA DE SOFTWARE Educa o a Dist ncia UNIDADE Il PROCESSOS DE SOFTWARE Professora Me M rcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Compreender os conceitos de processo de software e modelos de processo de software Mostrar as atividades b sicas do processo de software Mostrar tr s modelos de processo de software Plano de Estudo A seguir apresentam se os t picos que voc estudar nesta unidade Processos de Software Modelos de Processo de Software Atividades B sicas do Processo de Software CESUMAR CENTROUNIVERSIT RIO DE MARING INTRODU O Caro a aluno a na primeira unidade voc aprendeu alguns conceitos b sicos relacionados Engenharia de Software A partir de agora voc come ar a estudar assuntos mais espec ficos da disciplina e voc ver que seu estudo ficar cada vez mais interessante Nos ltimos tempos o desenvolvimento de software uma das reas da tecnologia que mais cresceu e com esse crescimento vieram tamb m problemas que v o desde o
17. da classe e a terceira os m todos Geralmente uma classe possui atributos e m todos por m poss vel encontrar classes que contenham apenas uma dessas caracter sticas ou mesmo nenhuma quando se tratar de classes abstratas A figura abaixo apresenta um exemplo de classe Cliente Exemplo de uma Classe De acordo com Melo 2004 p 18 o ponto inicial para identifica o de classes num documento de requisitos assinalar os substantivos Note que esses substantivos podem levar a objetos f sicos como cliente livro computador ou objetos conceituais como reserva cronograma norma Em seguida preciso identificar somente os objetos que possuem import ncia para o sistema verificando o que realmente consiste em objeto e o que consiste em atributo Ainda preciso fazer uma nova an lise dos requisitos para identificar classes impl citas no contexto trabalhado excluir classes parecidas ou juntar duas classes em uma nica classe Vale a pena ressaltar que esse processo ser iterativo e n o ser poss vel definir todas as classes de uma ENGENHARIA DE SOFTWARE Educa o a Dist ncia 20 CESUMAR CENTROUNIVERSIT RIO DE MARING Atributos Uma classe normalmente possui atributos que representam as caracter sticas de uma classe que costumam variar de objeto para objeto como o nome em um objeto da classe Cliente ou a cor em um objeto da classe Carro e que permitem diferenciar um objeto de outro da mesma classe
18. digo fonte e desse modo pode se ent o executar o teste de caixa preta Este tipo de teste focaliza os requisitos funcionais do software determinando se os mesmos foram total ou parcialmente satisfeitos pelo produto Os testes de caixa preta n o verificam como ocorre o processamento mas apenas os resultados produzidos Pressman 2011 p 439 coloca que o teste de caixa preta pode encontrar fun es incorretas ou que estejam faltando erros de interface erros em estruturas de dados ou acesso a bases de dados externas erros de comportamento ou de desempenho e por ltimo erros de inicializa o e t rmino Quando a l gica e a estrutura interna do programa s o conhecidas isto depois de o programador ter escrito o programa pode se fundamentar os casos de testes na l gica do programa e executar o que muitas vezes chamado de testes de caixa de vidro ou de caixa branca Portanto os testes de caixa branca pode segundo Pressman 2011 p 431 garantir que todos os caminhos independentes de um m dulo foram exercidos pelo menos uma vez exercitar todas as decis es l gicas nos seus estados verdadeiro e falso executar todos os ciclos em seus limites e dentro de suas fronteiras operacionais e por ltimo exercitar estruturas de dados internas para assegurar a sua validade Para Pressman 2011 p 451 o teste dificilmente chega ao fim o que acontece uma transfer ncia do desenvolvedor para o seu cliente ou seja toda vez q
19. es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 79 CESUMAR CENTROUNIVERSIT RIO DE MARING ENGENHARIA DE REQUISITOS Como foi dito na unidade anterior a engenharia de requisitos um processo que envolve todas as atividades necess rias para a cria o e manuten o de um documento de requisitos de software Existem quatro atividades gen ricas de processo de engenharia de requisitos que s o de alto n vel i o estudo de viabilidade do sistema ii o levantamento e an lise de requisitos iii a especifica o de requisitos e sua documenta o e finalmente iv a valida o desses requisitos A seguir abordaremos todas as atividades com exce o da especifica o de requisitos que j foi discutida nesta unidade A figura abaixo ilustra a rela o entre essas atividades e mostra tamb m os documentos produzidos em cada est gio do processo de engenharia de requisitos de acordo com Sommerville 2011 p 24 lt http Iwww youtube com watch v P4ixBvRF4NY amp feature related gt O v deo mostra uma entrevista com Sergio Ayres consultor com vasta experi ncia em Gest o e Go vernan a Corporativa abordando a Engenharia de Requisitos LS Anota es LX 80 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING a Estudo de a Levantamento EN an lise de go Viabilidade Pag C requisitos P Especifica o c d
20. ou seja o saque deve ser recusado pelo sistema GUEDES 2007 p 37 A partir da superclasse Conta Comum uma nova classe foi derivada a subclasse Conta Especial que possui um atributo pr prio chamado limite e possui tamb m os atributos herdados da superclasse O atributo limite define o valor extra que pode ser sacado al m do valor contido no saldo da conta Por esse motivo a classe Conta Especial apresenta uma Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 31 CESUMAR CENTROUNIVERSIT RIO DE MARING redefini o do m todo Saque porque a rotina do m todo Saque da classe Conta Especial diferente a do m todo Saque declarado na classe Conta Comum pois preciso incluir o limite da conta no teste para determinar se o cliente pode ou n o retirar o valor solicitado No entanto o nome do m todo permanece o mesmo apenas no momento de executar o m todo o sistema dever verificar se a inst ncia que o chamou pertence classe Conta Comum ou classe Conta Especial executando o m todo definido na classe em quest o GUEDES 2007 p 37 lt http Iwww youtube com watch v MnJLeYAno408 amp feature relmfu gt V deo que mostra uma introdu o aos conceitos de orienta o a objetos C UML UNIFIED MODELING LANGUAGE UNIFIED MODELING LANGUAGE Fonte lt http onlywhatmatters wordpress com 2011 02 20 uml unified modeling language gt Anota es LA 32 ENGENHARIA DE SOFTWARE
21. poss veis dentro dos programas teriam que ser testados e nem sempre isso possivel O fato que a manuten o sempre vai existir e vai consumir bastante tempo da equipe de desenvolvimento Pressman 2011 p 663 coloca que de fato n o raro uma organiza o de software despender de 60 a 70 de todos os recursos com manuten o de software Uma das raz es para o problema da manuten o de software a troca das pessoas que comp em as equipes de desenvolvimento podendo acontecer que a equipe que desenvolveu o software inicialmente j n o se encontra mais por perto Ou ainda que ningu m que esteja Anota es LX 1 62 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING trabalhando atualmente na empresa tenha participado da concep o do sistema Neste caso se o sistema desenvolvido estiver bem documentado se ele tiver sido desenvolvido seguindo os preceitos da engenharia de software com certeza sua altera o se tornar mais f cil e pode se dizer que o sistema apresenta alta manutenibilidade De acordo com Pressman 2011 p 664 um software manuten vel de f cil manuten o apresenta uma modularidade eficaz utiliza padr es de projeto que permitem entend lo com facilidade foi constru do utilizando padr es e conven es de codifica o bem definidos Dessa forma tanto o projeto quanto a implementa o do software ajudar o a pessoa ou equipe que
22. AUTOESTUDO 1 Sobre relacionamento entre Casos de Uso e Atores 1 a Explique o relacionamento de Associa o association b Explique o relacionamento de Generaliza o entre casos de uso generaliza tion c Explique o relacionamento de Extens o extend d Explique o relacionamento de Inclus o include 2 Explique qual a diferen a entre os diagramas de classe abaixo Diagrama A Diagrama B G nero 1 Filme G nero 0 Filme 1 32 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING 3 Com base no documento de requisitos abaixo elaborar o Diagrama de Casos de Uso e o Diagrama de Classes DOCUMENTO DE REQUISITOS CONTROLE DE ESTOQUE A empresa Auto Pe as XYZ Ltda atua no ramo de compra e venda de pe as para ve culos automotores Atualmente a empresa n o possui sistema automatizado mas pretende informatizar se totalmente para isso est contratando os servi os de um analista de sistemas A empresa pretende come ar pelo controle de estoque pois o aumento do seu faturamento depende de um controle de estoque r gido O sistema atualmente funciona da seguinte maneira 1 Os produtos s o separados e controlados por grupos de produtos 2 A empresa compra pe as de diversos fornecedores preenchido um formul rio denominado pedido de compra no qual constam os seguintes dados n mero do
23. Aqui irei mostrar somente tr s desses modelos e em seguida mostrarei as atividades b sicas que est o presentes em praticamente todos os modelos de processos de software Os modelos de processo que mostrarei foram retirados de Sommerville 2011 p 20 e s o 1 Modelo em Cascata Esse modelo considera as atividades de especifica o desen volvimento valida o e evolu o que s o fundamentais ao processo e as representa como fases separadas como a especifica o de requisitos o projeto de software a im plementa o os testes e assim por diante SOMMERVILLE 2011 2 Desenvolvimento Incremental Esse modelo intercala as atividades de especifica o desenvolvimento e valida o Um sistema inicial rapidamente desenvolvido a partir de especifica es abstratas que s o ent o refinadas com informa es do cliente para produzir um sistema que satisfa a a suas necessidades produzindo v rias vers es do software SOMMERVILLE 2011 3 Engenharia de Software Orientada a Reuso Esse modelo parte do princ pio de que existem muitos componentes que podem ser reutiliz veis O processo de desenvolvimen to do sistema se concentra em combinar v rios desses componentes em um sistema em vez de proceder ao desenvolvimento a partir do zero com o objetivo de reduzir o tempo de desenvolvimento SOMMERVILLE 2011 O modelo em cascata REQUIREMENTS o E IMPLEMENTATION e VERIFICATION b 2 Y ENGENHARIA D
24. CESUMAR CENTROUNIVERSIT RIO DE MARING A UML foi desenvolvida inicialmente por meio da combina o de um grupo de nota es de modelagem usadas pela ind stria de software o m todo de Booch o m todo OMT Object Modeling Technique de Jacobson e o m todo OOSE Object Oriented Software Engineering de Rumbaugh Em 1997 a UML 1 0 foi oferecida para padroniza o ao OMG Object Management Group A UML 1 0 foi revisada com a ajuda de v rios segmentos da comunidade de desenvolvedores de software tornando se UML 1 1 sendo adotada pelo OML em novembro de 1997 O padr o atual a UML 2 0 sendo um padr o ISO A UML define em sua vers o 2 0 treze tipos de diferentes diagramas para uso na modelagem de software Nesta unidade veremos somente os diagramas de casos de uso e de classe Se voc quiser conhecer os outros diagramas consulte alguns livros relacionados nas refer ncias Como nosso objetivo aqui mostrar a modelagem de um sistema utilizaremos somente esses dois diagramas Primeiramente ser apresentado a voc caro a aluno a o diagrama de casos de uso Esse diagrama ajuda a determinar a funcionalidade e as caracter sticas do sistema sob o ponto de vista do usu rio sendo um dos diagramas mais gerais e informais da UML Para a elabora o do diagrama de casos de uso deve ser utilizada uma linguagem simples e de f cil compreens o para que os usu rios possam ter uma ideia geral de como o sistema ir se comportar
25. Educa o MEC Desta forma buscando atender essas necessidades dispomos de uma equipe de profissionais multidisciplinares para que independente da dist ncia geogr fica que voc esteja possamos interagir e assim fazer se presentes no seu processo de ensino aprendizagem conhecimento Neste sentido por meio de um modelo pedag gico interativo possibilitamos que efetivamente voc construa e amplie a sua rede de conhecimentos Essa interatividade ser vivenciada especialmente no ambiente virtual de aprendizagem AVA no qual disponibilizamos al m do material produzido em linguagem dial gica aulas sobre os conte dos abordados atividades de estudo enfim um mundo de linguagens diferenciadas e ricas de possibilidades efetivas para a sua aprendizagem Assim sendo todas as atividades de ensino disponibilizadas para o seu processo de forma o t m por intuito possibilitar o desenvolvimento de novas compet ncias necess rias para que voc se aproprie do conhecimento de forma colaborativa Portanto recomendo que durante a realiza o de seu curso voc procure interagir com os textos fazer anota es responder s atividades de autoestudo participar ativamente dos f runs ver as indica es de leitura e realizar novas pesquisas sobre os assuntos tratados pois tais atividades lhe possibilitar o organizar o seu processo educativo e assim superar os desafios na constru o de conhecimentos Para finalizar essa mensa
26. Em outras vezes ele uma defini o detalhada e formal de uma fun o do sistema Alguns dos problemas que surgem durante a especifica o de requisitos s o as falhas em n o fazer uma separa o clara entre os diferentes n veis de descri o dos requisitos Por isso Sommerville 2011 p 57 prop e uma distin o entre eles por meio do uso do termo requisitos de usu rio para expressar os requisitos abstratos de alto n vel e requisitos de sistema para expressar a descri o detalhada que o sistema deve fazer Dessa forma os requisitos de Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 67 CESUMAR CENTROUNIVERSIT RIO DE MARING usu rio dever o fornecer em forma de declara es quais servi os o sistema dever oferecer e as restri es com as quais o sistema deve operar J os requisitos de sistema s o descri es mais detalhadas das fun es servi os e restri es operacionais do sistema Caro a aluno a se sua empresa deseja estabelecer um contrato para o desenvolvimento de um grande sistema ela deve definir todas as necessidades requisitos de maneira suficientemente abstrata para que uma solu o n o seja predefinida ou seja essas necessidades devem ser redigidas de modo que os diversos fornecedores possam apresentar propostas oferecendo talvez diferentes maneiras de atender s necessidades organizacionais da sua empresa Uma vez estabelecido um contrato o fornece
27. Exemplo quantos telefones funcion rio voc tem no departamento d Evitar falar palavras sem sentido falar baixo fazer generaliza es termos t cnicos e Ouvir as respostas D tempo para o entrevistado responder n o saia com respostas antecipadas N o se concentre na pr xima quest o isto um erro comum dos iniciantes A lista de quest es preparada apenas um guia Tenha certeza de que as quest es s o Anota es LX 86 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING relevantes evite quest es complexas e desnecess rias f Pedir explica es para as quest es que ficarem obscuras g Pedir ideias e sugest es e descobrir se o entrevistado quer que sejam consideradas Exemplo voc tem alguma sugest o ou recomenda es relativas ao m todo para calcular o or amento Voc gostaria que os seus superiores ou os demais ficassem sabendo de suas sugest es ENCERRAMENTO se a entrevista tiver consumido mais tempo do que o previsto pe a para continuar e ofere a uma reprograma o Quando tiver toda a informa o necess ria agrade a e fa a um sum rio de todos os pontos principais Avise se for necess ria outra sess o de entrevista com a mesma pessoa Muitas vezes algumas express es corporais podem substituir ou comunicar mais informa es do que as pr prias palavras Este tipo de comunica o pode ajudar o engenheiro de software a a interpre
28. GUEDES 20007 p 15 Depois ser mostrado o diagrama de classes Esse o diagrama mais importante e tamb m o mais utilizado da UML e serve de apoio para a maioria dos outros diagramas que n o ser o abordados neste livro O diagrama de classes define a estrutura das classes identificadas para o sistema mostrando os atributos e m todos possu dos por cada uma das classes al m de estabelecer como as classes se relacionam e trocam informa es entre si Anota es LX 98 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING MODELAGEM DE SISTEMAS A necessidade de planejamento no desenvolvimento de sistemas de informa o leva ao conceito de modelagem de software ou seja antes do software ser concebido deve se criar um modelo para o mesmo Um modelo pode ser visto como uma representa o idealizada de um sistema a ser constru do Exemplos de modelos maquetes de edif cio plantas de casa fluxogramas etc A modelagem de sistemas de software consiste na utiliza o de nota es gr ficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema S o v rias as raz es para se utilizar modelos na constru o de sistemas eis algumas No desenvolvimento de software usamos desenhos gr ficos denominados de dia gramas para representar o comportamento do sistema Esses diagramas seguem um padr o l gico e possuem uma s rie de ele
29. MARING Pedido Exame 0 codigo int EE Q data realiza o exame int hora realiza o exame int data pronto int hora pronto int resultado int valor int c digo int descri o int valor int procedimentos int SS 1 c digo int descri o int CONSIDERA ES FINAIS No decorrer desta unidade estudamos sobre a import ncia da modelagem de um sistema a partir do documento de requisitos A modelagem a parte fundamental de todas as atividades dentro de um processo de software que levam implanta o de um bom software necess rio construirmos modelos para comunicar a estrutura e o comportamento desejados do sistema para melhor compreender o sistema que estamos elaborando BOOCH 2005 p 3 Esses modelos normalmente s o representados por meio de diagramas em que utilizada uma nota o gr fica que em nosso caso foi a UML A UML tem muitos tipos de diagramas apoiando a cria o de diferentes modelos de sistema no entanto conhecemos nesta unidade somente o Diagrama de Casos de Uso e o Diagrama de Classes que s o considerados por muitos autores como os principais diagramas da UML A UML n o estabelece uma ordem pr definida para a elabora o dos seus diversos diagramas ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 31 CESUMAR CENTROUNIVERSIT RIO DE MARING por m como o diagrama d
30. a hora de executar a valida o do software A etapa de valida o vai garantir que o software realmente executa as funcionalidades solicitadas pelos usu rios E finalmente depois que o software foi validado e colocado em funcionamento vir a etapa de evolu o do software pois com certeza os usu rios ter o requisitos que poder o ser alterados implicando em altera es no software Portanto para que o software continue sendo til para o usu rio necess rio que ele evolua atendendo as necessidades desse usu rio PROJETO DE SOFTWARE De acordo com Sommerville 2007 p 50 um projeto de software a descri o da estrutura de software a ser implementada dos dados das interfaces do sistema e algumas vezes dos Anota es LA 1 40 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING algoritmos utilizados que em nosso caso ser realizada por meio da Especifica o dos casos de Uso Um projeto deve ser desenvolvido de forma iterativa por meio de diferentes vers es que devem ser mostradas ao usu rio para que ele ajude a decidir se o projeto realmente atende as suas necessidades Na etapa de modelagem do sistema o engenheiro de software com base no documento de requisitos j elaborou o Diagrama de Caso de Uso e o Diagrama de Classes Agora na etapa de projeto ele dever i definir o Diagrama Geral do Sistema ii elaborar as Interfaces com o Usu rio telas e rel
31. a vis o completa do desenvolvimen to do software Com isto foi poss vel definir etapas que abrangem desde a an lise dos requisitos at a entrega do software para o cliente Fonte lt http revistas claretiano edu br index php linguagemacademica article view 40 gt Acesso em 07 jun 2012 LS ESPECIFICA O DE SOFTWARE A especifica o de software ou engenharia de requisitos a primeira atividade b sica de um processo de software e tem como objetivo definir quais fun es s o requeridas pelo sistema e Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 55 CESUMAR CENTROUNIVERSIT RIO DE MARING identificar as restri es sobre a opera o e o desenvolvimento desse sistema Essa atividade muito importante e cr tica pois se a defini o dos requisitos n o for bem realizada com certeza problemas posteriores no projeto e na implementa o do sistema ir o acontecer Segundo Sommerville 2011 p 24 o processo de engenharia de requisitos tem como objetivo produzir um documento de requisitos acordados que especifica um sistema que satisfaz os requisitos dos stakeholders O processo de engenharia de requisitos composto por quatro fases conforme descreve Sommerville 2007 p 50 A unidade seguinte tratar com mais detalhes sobre esse assunto 1 Estudo de viabilidade uma avalia o realizada para verificar se as necessidades dos usu rios que foram identificadas podem ser
32. acima e um modelo de processo de software uma representa o abstrata de um processo de software ou seja define a sequ ncia em que as atividades do processo ser o realizadas Existem v rios modelos de processo de software descritos na literatura por m nesta unidade vimos somente alguns desses modelos O primeiro foi o Modelo em Cascata que representa as atividades do processo especifica o desenvolvimento valida o e evolu o como fases separadas onde uma s pode acontecer depois que a anterior tenha sido conclu da O segundo modelo foi o Desenvolvimento Incremental que tem como base a ideia de desenvolver uma ENGENHARIA DE SOFTWARE Educa o a Dist ncia 61 CESUMAR CENTROUNIVERSIT RIO DE MARING implementa o inicial expor ao coment rio do usu rio cliente e fazer seu aprimoramento por meio de muitas vers es at que um sistema adequado tenha sido desenvolvido Nesse modelo em vez de ter as atividades de especifica o desenvolvimento e valida o em separado todo esse trabalho realizado concorrentemente O ltimo modelo que estudamos foi a Engenharia de Software Baseada em Reuso que baseia se na exist ncia de um n mero significativo de componentes reus veis sendo que o processo de desenvolvimento de sistemas se concentra na integra o desses componentes em um sistema em vez de partir do zero Mas afinal qual o melhor modelo de processo de software para uma empresa Infelizmente a re
33. ap s o seu uso pelo usu rio passa por evolu es Todas essas etapas s o muito importantes mas vimos que a especifica o do software uma etapa imprescind vel nesse conjunto pois se os requisitos n o forem esclarecidos bem especificados no in cio do desenvolvimento h uma grande chance do software n o atender as necessidades do cliente No tempo que trabalhei com desenvolvimento de sistemas vi isso acontecer algumas vezes E sabem o que acontece O usu rio acaba n o utilizando o sistema e assim o sistema acaba n o atingindo o seu objetivo Na pr xima unidade vamos tratar o assunto Requisitos de Software mais detalhadamente justamente pela import ncia que mencionei acima Ap s os requisitos estarem declarados e validados vimos que o projeto do sistema deve ser realizado Nessa etapa o sistema modelado de forma bem detalhada pois a pr xima etapa a implementa o do software Na unidade quatro trataremos com mais detalhes sobre a modelagem do sistema em especial sobre a linguagem de modelagem unificada UML Unified Modeling Language A implementa o a escrita do sistema em uma linguagem de programa o Nesta disciplina veremos somente a parte te rica relacionada implementa o pois a parte pr tica faz parte de outras disciplinas do seu curso Mas afinal qual a diferen a entre processo de software e modelo de processo de software Um processo de software o conjunto de atividades mencionadas
34. aplicados em um diagrama de casos de uso DOCUMENTO DE REQUISITOS F BRICA DE COLCH ES A f brica de colch es Mimindo Ltda compra mat ria prima fabrica os colch es casal ou solteiro e vende para seus clientes de v rias partes do pa s Ela deseja gerenciar todos os processos com a utiliza o de um sistema que voc vai desenvolver Mas o sistema ser desenvolvido em partes sendo o que a empresa precisa de imediato lan ar no sistema as compras de mat rias primas MP e cadastrar os produtos acabados PA Anota es LX 1 1 2 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Algumas informa es importantes que ajudar o entendimento do sistema 1 Quando a Mimindo Ltda comprar MP mat ria prima de um fornecedor receber uma nota de compra que deve ser lan ada no sistema Nesta nota constam as se guintes informa es o n mero da nota data emiss o nome do fornecedor CFOP c digo fiscal de opera o e as MPs com as quantidades compradas de cada uma delas bem como o seu valor unit rio Uma nota de compra pode conter N mat rias primas No lan amento da nota de compra o sistema deve atualizar o estoque de MPs automaticamente Essas MPs devem ser cadastradas separadas por grupos sendo que uma MP pode r pertencer a um nico grupo Ex tecidos espumas etc Os PAs produtos acabados s o os colch es fabricados que a Mimindo Ltda ir ven der ess
35. atendidas utilizando se as atuais tec nologias de software e hardware dispon veis na empresa Esse estudo deve indicar se o sistema proposto ser vi vel do ponto de vista comercial e tamb m se poder ser desenvolvido considerando restri es or ament rias caso as mesmas existam Um es tudo de viabilidade n o deve ser caro e demorado pois a partir do seu resultado que a decis o de prosseguir com uma an lise mais detalhada deve ser tomada 2 Levantamento e an lise de requisitos 1 nesta fase necess rio levantar os requisi tos do sistema pela observa o de sistemas j existentes pela conversa com usu rios e compradores em potencial pela an lise de tarefas e assim por diante Essa fase pode envolver o desenvolvimento de um ou mais diferentes modelos e prot tipos de sistema Isso pode ajudar a equipe de desenvolvimento a compreender melhor o sistema a ser especificado 3 Especifica o de requisitos 1 a atividade de traduzir as informa es coletadas durante a fase anterior em um documento que defina um conjunto de requisitos Tanto os requisitos dos usu rios quanto os requisitos de sistema podem ser inclu dos nesse documento De acordo com Sommerville 2011 p 24 os requisitos dos usu rios s o de clara es abstratas dos requisitos do sistema tanto para o cliente quanto para os usu rios finais do sistema os requisitos do sistema s o descri es mais detalhadas das funcio nalidades a serem fornecidas Na
36. conhecimentos e t cnicas conhecido como Engenharia de Software ensinado em uma ou duas disciplinas dos cursos que t m os nomes de Ci ncia da Computa o Inform tica ou Sistemas de Informa o Raramente em mais disciplinas muitas vezes opcionais e muitas vezes oferecidas apenas em n vel de p s gradua o Algumas institui es oferecem cursos de p s gradua o em Engenharia de Software geralmente no n vel de especializa o Neste artigo voc vai entender os fundamentos da engenharia de software O artigo completo pode ser acessado no endere o abaixo Fonte lt http www devmedia com br artigo engenharia de software alguns fundamentos da enge nharia de software 8029 gt Acesso em 02 jun 2012 CS TIPOS DE APLICA ES DE SOFTWARE Atualmente com o software sendo utilizado em praticamente todas as atividades exercidas pelas pessoas existe uma grande variedade de aplica es de software Vamos ver algumas delas e Software de sistema de acordo com Pressman 2011 p 34 s o aqueles progra mas desenvolvidos para atender a outros programas como por exemplo editores de texto compiladores e sistemas operacionais e Software de aplica o s o programas desenvolvidos para solucionar uma neces Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 21 CESUMAR CENTROUNIVERSIT RIO DE MARING sidade espec fica de neg cio processando dados comerciais ou t cnicos de forma que ajud
37. da classe possuidora do atributo ou m todo poder o utiliz lo Note que no exemplo da classe Cliente tanto os atributos quanto os m todos apresentam sua visibilidade representada esquerda de seus nomes em que os atributos nome sexo e data nascimento possuem visibilidade privada pois apresentam o s mbolo de menos esquerda da sua descri o J os m todos IncluirNovoCliente e AtualizarCliente possuem visibilidade p blica como indica o s mbolo acrescentado esquerda da sua descri o Heran a Generaliza o Especializa o A heran a permite que as classes de um sistema compartilhem atributos e m todos otimizando assim o tempo de desenvolvimento com a diminui o de linhas de c digo facilitando futuras manuten es GUEDES 2007 p 35 A heran a ou generaliza o especializa o acontece entre classes gerais chamadas de superclasses ou classes m e e classes espec ficas chamadas de subclasses ou classes filha BOOCH 2005 p 66 A heran a significa que os objetos da subclasse podem ser utilizados em qualquer local em que a superclasse ocorra mas n o vice versa A subclasse herda as propriedades da m e ou seja seus atributos e m todos e tamb m podem possuir atributos e m todos pr prios al m daqueles herdados da classe m e De acordo com Guedes 2007 p 35 a vantagem do uso da heran a que quando uma classe declarada com seus atributos e m todos espec ficos e ap s iss
38. de Casos de Uso Normalmente os nomes de casos de uso s o breves express es verbais ativas nomeando algum comportamento encontrado no vocabul rio do sistema cuja modelagem est sendo realizada a partir do documento de requisitos BOOCH 2005 p 231 Alguns verbos que podem ser usados para nomear os casos de uso efetuar cadastrar consultar emitir registrar realizar manter verificar entre outros Relacionamento entre Casos de Uso e Atores Conforme Melo 2004 p 60 os casos de uso representam conjuntos bem definidos de funcionalidades do sistema precisando relacionar se com outros casos de uso e com atores que enviar o e receber o mensagens destes Podemos ter os relacionamentos de associa o generaliza o extens o e inclus o da seguinte forma e Para relacionamentos entre atores e casos de uso somente associa o Para relacionamentos de atores entre si somente generaliza o Para relacionamentos de casos de uso entre si generaliza o extens o e inclus o Associa o A associa o o nico relacionamento poss vel entre ator e caso de uso sendo sempre bin ria ou Seja sempre envolvendo apenas dois elementos Melo 2004 p 60 diz que Representa a Anota es 15 ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 03 CESUMAR CENTROUNIVERSIT RIO DE MARING intera o do ator com o caso de uso ou seja a comunica o entre atores e casos de uso por mei
39. de cada exame data e hora em que cada exame ficar pronto valor de cada exame d Resultado de Exame descri o do resultado para cada exame do pedido de exame o resultado dever ser cadastrado e M dicos CRM nome como o documento de requisitos n o menciona nada sobre os dados dos m dicos coloquei somente os atributos que interessam para o pedido de exame f Conv nios c digo nome como o documento de requisitos n o menciona nada sobre os dados dos conv nios coloquei somente os atributos que interessam para o pedido de exame g Cidades c digo nome DDD neste caso mesmo o documento de requisitos n o mencionando nada esses atributos devem constar em qualquer classe de cidades h UF s sigla nome Grupos de Exames c digo descri o 3 Desenhar as classes relacionadas acima com seus respectivos atributos no Dia grama de Classes Faremos o desenho do diagrama tamb m utilizando a ferramenta 1 28 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Astah e no mesmo arquivo em que j desenhamos o diagrama de casos de uso Assim ficaremos com os dois diagramas em um nico arquivo 4 Para cada classe desenhada no diagrama estabelecer o seu relacionamento com as demais classes Lembre se dos tipos de relacionamentos que estudamos asso cia o un ria e bin ria generaliza o especializa o agrega o Releia tamb m a explica o sobre classes
40. de software existente tem emergido e se tornado cada vez mais utilizada A abordagem orientada a reuso conta com um grande n mero de componentes de software reutiliz veis que podem ser acessados e com um framework de integra o para esses componentes s vezes esses componentes s o sistemas propriamente ditos sistemas COTS commercial off the shelf sistemas comerciais de prateleira que podem ser utilizados para proporcionar funcionalidade espec fica como formata o de textos c lculo num rico entre outros SOMMERVILLE 2011 p 23 O modelo gen rico de processo baseado em reuso mostrado na figura abaixo SOMMERVILLE 2007 p 46 Note que embora as etapas de especifica o de requisitos e de valida o sejam compar veis com outros processos as etapas intermedi rias em um processo orientado a Modifica o de requisitos reuso s o diferentes Especifica o de An lise de requisitos componentes Projeto de sistema Desenvolvimento Valida o de com reuso e integra o sistema Anota es LX 50 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Conforme Sommerville 2011 p 23 essas etapas s o 1 An lise de componentes considerando a especifica o de requisitos feita uma busca de componentes para implementar essa especifica o Pode ser que n o sejam encontrados componentes que atendam a toda a especifica o de requisitos ou seja po
41. de software trabalham com o cliente e os usu rios finais do sistema para descobrir mais informa es sobre o dom nio da aplica o que servi os o sistema deve fornecer o desempenho exigido do sistema as restri es de hardware e assim por diante O levantamento e a an lise de requisitos podem envolver diferentes tipos de pessoas em uma organiza o O termo stakeholder utilizado para se referir a qualquer pessoa que ter alguma influ ncia direta ou indireta sobre os requisitos do sistema Dentre os stakeholders destacam se os usu rios finais que interagir o com o sistema e todo o pessoal em uma organiza o que venha a ser por ele afetado Os engenheiros que est o desenvolvendo o sistema ou fazendo a manuten o de outros sistemas relacionados os gerentes de neg cios os especialistas nesse dom nio os representantes de sindicato entre outros podem ser tamb m os stakeholders do sistema Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 83 CESUMAR CENTROUNIVERSIT RIO DE MARING O levantamento e a an lise de requisitos comp em um processo dif cil por diversas raz es SOMMERVILLE 2007 p 98 1 Os stakeholders frequentemente n o sabem na realidade o que querem do sistema computacional a n o ser em termos muito gerais eles podem achar dif cil articular o que desejam do sistema muitas vezes fazendo pedidos n o realistas por n o terem no o do custo de suas solicita es 2
42. determinada condi o for satisfeita A extens o separa um comportamento obrigat rio de outro opcional As associa es de extens o possuem uma representa o muito semelhante s associa es de inclus o sendo tamb m representadas por uma reta tracejada diferenciando se por possuir um estere tipo contendo o texto lt lt extend gt gt e pela seta apontar para o caso de uso Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 09 CESUMAR CENTROUNIVERSIT RIO DE MARING que estende ou seja neste caso a seta aponta para o caso de uso base GUEDES 2007 p 43 Veja abaixo um exemplo de relacionamento de extens o Verificar Cliente situa o conta lt lt extend gt gt _ corrente do Emitir extrato Banco Exemplo de extens o de caso de uso Neste exemplo est sendo mostrado que tanto o Cliente quanto o Banco podem Verificar a situa o da conta corrente do cliente e se for o caso pode se emitir um extrato Mas note que o extrato somente ser emitido se alguma condi o do caso de uso base Verificar situa o conta corrente do cliente for satisfeita caso contr rio o extrato nunca ser emitido Agora vamos mostrar um exemplo bastante comum que acontece quando utilizamos sistemas via Internet em que para utilizar os servi os o cliente deve se logar no sistema e caso seja a primeira vez dever realizar o seu cadastro pessoal Realizar login no site O
43. diminuir esses problemas Que contribui o direta o sistema trar para os objetivos da empresa As informa es podem ser transferidas para outros sistemas organizacionais e tamb m podem ser recebidas a partir deles O sistema requer tecnologia que n o tenha sido utilizada anteriormente na organiza o Anota es LA 82 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING O que precisa e o que n o precisa ser compat vel com o sistema Entre as fontes de informa o est o os gerentes de departamentos em que o sistema ser utilizado os engenheiros de software que est o familiarizados com o tipo de sistema proposto peritos em tecnologia usu rios finais de sistema entre outros Eles devem ser entrevistados durante o estudo de viabilidade a fim de coletar as informa es exigidas O relat rio do estudo de viabilidade dever ser elaborado com base nas informa es mencionadas acima e deve recomendar se o desenvolvimento do sistema deve continuar ou n o Ele pode propor mudan as no enfoque no or amento e no cronograma al m de sugerir outros requisitos de alto n vel para o sistema LEVANTAMENTO E AN LISE DE REQUISITOS De acordo com Sommerville 2007 p 97 ap s os estudos iniciais de viabilidade a pr xima atividade do processo de engenharia de requisitos o levantamento e a an lise de requisitos Nessa atividade os membros da equipe t cnica de desenvolvimento
44. e que o sistema tem de ser novamente testado Durante a etapa de valida o de requisitos Sommerville 2007 p 106 prop e que diferentes tipos de verifica o devem ser realizados sobre os requisitos no documento de requisitos Dentre as verifica es destacam se 1 Verifica es de validade Um usu rio pode considerar que um sistema necess rio para realizar certas fun es Contudo mais estudos e an lises podem identificar fun es adicionais ou diferentes que s o exigidas Os sistemas t m diversos usu rios com necessidades diferentes e qualquer conjunto de requisitos inevitavelmente uma solu o conciliat ria da comunidade de usu rios 2 Verifica es de consist ncia Os requisitos em um documento n o devem ser con flitantes ou seja n o devem existir restri es contradit rias ou descri es diferentes para uma mesma fun o do sistema 3 Verifica es de completeza O documento de requisitos deve incluir requisitos que definam todas as fun es e restri es exigidas pelos usu rios do sistema Anota es LA 90 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Verifica es de realismo Utilizando o conhecimento da tecnologia existente os requisitos devem ser verificados a fim de assegurar que eles realmente podem ser implementados levando se tamb m em conta o or amento e os prazos para o de senvolvimento do sistema Facilidade
45. em geral MELO 2004 p 31 Por m essas revis es n o devem provocar uma grande mudan a no escopo original da proposta de padroniza o Nestes ltimos anos aconteceram as seguintes revis es em julho de 1998 a UML 1 2 no final de 1998 a UML 1 3 em maio de 2001 a UML 1 4 Em agosto de 2001 a RTF submeteu ao OMG um relat rio provis rio da UML 1 5 publicada em mar o de 2003 No in cio de 2005 a vers o oficial da UML 2 0 foi adotado pelo OMG Hoje a UML est em sua vers o 2 4 1 e sua documenta o oficial pode ser consultada atrav s do endere o lt www uml org gt A grande mudan a aconteceu na vers o 2 0 sendo que a maioria da bibliografia dispon vel atualmente inclusive a que est sendo utilizada na consulta para produ o deste livro trata dessa vers o FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML Nesta unidade j vimos que uma ferramentas CASE Computer Aided Software Engineering Engenharia de Software Auxiliada por Computador um software que de alguma forma colabora na realiza o de uma ou mais atividades realizadas durante o processo de desenvolvimento de software Agora vamos ver alguns exemplos de ferramentas CASE que suportam a UML sendo esta em geral sua principal caracter stica Existem diversas ferramentas no mercado dentre as quais podemos destacar Rational Rose a ferramenta Rational Rose foi desenvolvida pela Rational Software Corporation empresa que estimulou a cria o da UML sen
46. j efetuar o lan amento do Contas a Pagar ou seja como na Nota Fiscal de Compra normalmente j vem as informa es da data de vencimento e do valor de cada parcela quando uma compra parcelada o usu rio j pode efetuar o lan amento dessas informa es no momento em que est cadastrando as compras Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 49 CESUMAR CENTROUNIVERSIT RIO DE MARING Es al Pedido de Compra Erim Pedido C digo Data de emiss o Data de Entrada Fornecedor bs Produtos Comprados Produto Quantidade Valor Unit rio Total Contas a pagar Total Geral C digo Duplicata Vencimento Valor e Tela de Filtro do Relat rio de Consultas M dicas Efetuadas por Dia a tela de filtro de relat rio tem por objetivo oferecer ao usu rio mecanismos para a sele o dos dados que ele deseja imprimir no relat rio pois caso contr rio seriam impressos todos os dados cadastrados na base de dados referentes quele relat rio Na tela abaixo o usu rio ir informar uma data e o relat rio emitir somente as consultas efetuadas na data informada Relat rio de Consultas Efet el Data Imprimir Fechar Anota es LX 1 50 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Tela de Filtro do Relat rio de Pagamento de Consultas por Per odo note que neste filtro de relat rio o usu rio poder
47. m das funcionalidades j relacionadas importante pensar que algumas infor ma es podem ser transformadas em classes facilitando o uso e manuten o do sistema Por exemplo o sistema pode ter al m dos cadastros relacionados acima um cadastro de m dico evitando que a recepcionista precisasse digitar o nome com pleto do m dico toda vez que um pedido de exame daquele m dico fosse lan ado no sistema Seguindo esse mesmo racioc nio alguns cadastros seriam importantes para o sistema a Cadastro de m dicos b Cadastro de conv nios c Cadastro de cidades d Cadastro de UF s 1 26 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING e Cadastro de grupos de exames neste caso esse cadastro de suma import n cia pois o relat rio de exames deve ser agrupado por Grupo de Exames Com a cria o de um cadastro evita se de o usu rio cadastrar o mesmo grupo v rias vezes 6 Agora s voc utilizar a ferramenta Astah e desenhar o seu diagrama Depois que voc tiver terminado de desenhar o seu veja se ficou parecido com o meu Note que o nome do caso de uso sempre come a com um verbo codigo int descricao String codigo int descricao String qtde est int codigo int nome String codigo int cidade String qtde comprad fone int valor unitario data emissao int CFOP int PASSO A PASSO PA
48. meio das melhores pr ticas de gerenciamento dispon veis no mercado e as j adotadas pelo DATASUS Planejamento Encerramento Monitoramento e Controle Fases do PGDS O PGDS foi criado para auxiliar o DATASUS SE no planejamento execu o controle monitoramento e encerramento de seus projetos Serve como um guia para Gestores Coordenadores L deres e equipes de projetos equipe da UAPP e qualquer outro envolvido nos projetos O PGDS estruturado com base em 4 elementos b sicos que representam quem faz o qu como e quando Pap is quem Um papel define o comportamento e responsabilidades de um profissional ou grupo de profissionais que participam do desenvolvimento do projeto O comportamento representado atrav s das atividades que cada papel deve desempenhar ao longo do projeto As responsabilidades normalmente est o associadas aos artefatos que cada papel deve produzir e manter ao longo das ati vidades que realiza Na pr tica um mesmo papel pode ser desempenhado por mais de uma pessoa assim como uma mesma pessoa pode assumir v rios pap is ao longo do projeto Anota es SA 52 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Artefatos o qu Em sentido amplo o termo artefato representa um produto concreto produzido modificado ou utilizado pelas atividades de um processo O PGDS n o inclui todos os artefatos de um projeto de
49. necessidades H tamb m o fato de que o controle da evolu o do sistema fique comprometido pois as novas vers es dos componentes reus veis n o est o sob o controle da organiza o que as est utilizando De qualquer forma a abordagem baseada em reuso tem a vantagem de propiciar a entrega mais r pida do software pois reduz sensivelmente a quantidade de software que a empresa deve desenvolver reduzindo consequentemente os custos de desenvolvimento bem como OS seus riscos Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 51 CESUMAR CENTROUNIVERSIT RIO DE MARING Leitura Complementar PGDS Processo de gerenciamento e desenvolvimento de sistemas DATASUS Em busca de direcionamento e padroniza o dos seus processos e da melhoria cont nua da quali dade dos produtos e servi os de tecnologia da informa o o DATASUS elaborou suas metodologias de desenvolvimento de software PDS e de gerenciamento de projetos EGP Essas metodologias evolu ram acompanhando o desenvolvimento tecnol gico e as pr ticas de sucesso dos projetos re alizados Em 2010 com a implanta o da Unidade de Apoio a Programas e Projetos UAPP o PDS e a EGP foram unificados em uma metodologia agora denominada Processo de Gerenciamento e Desenvolvimento de Sistemas PGDS Ela foi criada para auxiliar o DATASUS na elabora o planejamento execu o controle monitora mento e encerramento de seus projetos por
50. pedido data do pedido nome do fornecedor telefone do fornecedor nome do pro duto quantidade do produto e pre o unit rio do produto E no final do pedido uma totaliza o quantidade pre o Em cada pedido de compra tem se somente um fornecedor podendo ter se v rios produtos comprados 3 Vende as pe as vista ou a prazo para os clientes Nas vendas vista s o preenchi dos os seguintes dados do cliente nome endere o completo telefone e e mail para envio de correspond ncias jornais de propaganda ofertas Nas vendas a prazo s o preenchidos os seguintes dados nome endere o completo telefone e mail RG CPF renda mensal local de trabalho Para cada venda preenchida uma nota fiscal de venda contendo os seguintes dados n mero da nota fiscal data da ven da nome do cliente nome do vendedor condi o de pagamento nome do produto quantidade do produto e pre o unit rio do produto Sendo que no final da nota fiscal feito uma totaliza o da mesma quantidade pre o unit rio Em cada nota fiscal de venda tem se somente um cliente podendo ter se v rios produtos vendidos 4 Os vendedores s o comissionados Cada vendedor pode ter um diferente de co miss o sobre as vendas efetuadas No final de cada m s as vendas s o somadas e a comiss o do vendedor calculada A empresa deseja que o sistema e Efetue o cadastro dos pedidos de compra que s o preenchidos no item 2 atualizan do automat
51. por Cliente o sistema deve ter uma consulta em que seja informado um determinado cliente e sejam mostrados todos os filmes j locados por esse cliente e mostre tamb m a data em que cada filme foi locado Consultar Reservas por Filme o sistema deve ter uma consulta em que seja in formado um determinado filme e sejam mostradas todas as reservas efetuadas para aquele filme no per odo informado Emitir os seguintes relat rios Relat rio Geral de Clientes onde conste o c digo nome endere o telefone e dependentes do cliente Etiquetas com c digos de barras para a identifica o das c pias no processo de loca o e devolu o Relat rio de filmes por g nero onde conste o c digo do filme o nome do filme o nome do diretor do filme os nomes dos atores do filme o total de c pias o total de c pias locadas e o total de c pias dispon veis O relat rio deve ser agrupado por g nero mostrando tamb m o c digo e a descri o do g nero Relat rio de filmes locados por cliente por per odo Para cada cliente devem ser emitidas todas as c pias que est o locadas para ele Deve sair no relat rio o c digo e o nome do cliente o c digo do filme o nome do filme o c digo da c pia exemplar a data de loca o e o valor da loca o O relat rio deve ser agrupado por cliente e devem sair somente as c pias locadas e n o devolvidas Relat rio de c pias n o devolvidas onde conste o c digo do filme o nome do fi
52. pr xima unidade trataremos com mais detalhes sobre requisitos 4 Valida o de requisitos 1 Essa atividade verifica os requisitos quanto a sua perti n ncia consist ncia e integralidade Durante o processo de valida o os requisitos que Anota es LA 56 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING apresentarem problemas devem ser corrigidos para que a documenta o de requisitos fique correta As atividades de an lise defini o e especifica o de requisitos s o intercaladas ou seja elas n o s o realizadas seguindo uma sequ ncia rigorosa pois com certeza novos requisitos surgem ao longo do processo PROJETO E IMPLEMENTA O DE SOFTWARE O est gio de implementa o do desenvolvimento de software o processo de convers o de uma especifica o do sistema em um sistema execut vel para Sommerville 2011 p 25 Esta etapa sempre envolve processos de projeto e programa o de software por m se uma abordagem incremental de desenvolvimento for utilizada poder tamb m envolver o aperfei oamento da especifica o de software em que os requisitos foram definidos Para Pressman 2011 p 206 o projeto de software cria uma representa o ou modelo do software fornecendo detalhes sobre a arquitetura do software as estruturas de dados interfaces e componentes fundamentais para implementar o sistema O projeto de software aplicado independentem
53. rio informe o n mero do telefone do cliente o sistema deve presumir que o c digo de rea default o seu c digo de rea local 8 Beneficie se das cores e do som mas n o exagere Os efeitos de cores e som podem ser bastante teis para a enfatiza o de tipos diferentes de entrada ou atrair a aten o do usu rio para aspectos importantes da interface humana Dessa forma poder ser utilizada a cor verde para tudo o que for exibido pelo sistema azul para todos os dados de entrada fornecidos pelo usu rio e vermelho para todas as mensagens de erro Entretanto o analista n o deve exagerar a maioria dos usu rios poder n o gostar se as telas ficarem parecendo rvores de Natal Isso tamb m vale para efeitos sonoros uma ocasional campainha ou bip til mas o usu rio n o deseja que o terminal produza todos os efeitos sonoros do filme Guerra nas Estrelas VALIDA O DE SOFTWARE 1 58 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING A valida o de software tem como objetivo mostrar que um sistema est de acordo com as especifica es descritas no documento de requisitos e que ele atende s expectativas do cliente comprador do sistema Esse processo envolve verificar processos em cada est gio do processo de software desde a defini o dos requisitos dos usu rios at o desenvolvimento de cada um dos programas que comp em o sistema Por m a maior parte dos custos de va
54. vel e informal sendo utilizado principalmente no in cio da modelagem do sistema a partir do documento de requisitos podendo ser consultado e possivelmente modificado durante todo o processo de engenharia e tamb m serve de base para a modelagem de outros diagramas GUEDES 2007 p 38 O principal objetivo deste diagrama modelar as funcionalidades e servi os oferecidos pelo sistema buscando por meio de uma linguagem simples demonstrar o comportamento externo do sistema da perspectiva do usu rio De acordo com Silva 2007 p 101 o diagrama de caso de uso incorpora o conjunto de requisitos funcionais estabelecidos para o software que est sendo modelado Esses requisitos devem estar descritos no documento de requisitos como j explicamos na unidade anterior H uma correspond ncia entre os requisitos funcionais previstos para o software e os casos de uso Os requisitos n o funcionais n o aparecem no diagrama de casos de uso pois n o constituem o foco da modelagem que estamos realizando Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 01 CESUMAR CENTROUNIVERSIT RIO DE MARING O diagrama de casos de uso composto por atores casos de uso e seus relacionamentos A seguir descreveremos cada um desses elementos Atores Um ator representa um papel que um ser humano um dispositivo de hardware ou at outro sistema desempenha com o sistema BOOCH 2005 p 231 Assim um ator pode ser qualquer
55. A subclasse Pessoa Fisica herda esses atributos e m todos al m de possuir os atributos CPF RG sexo e data nascimento e o m todo ValidarCPF A seta que aponta para a superclasse Cliente indica a heran a Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 29 CESUMAR CENTROUNIVERSIT RIO DE MARING A subclasse Pessoa Juridica tamb m herda todos os atributos e m todos da superclasse Cliente al m de possuir os atributos CNPJ inscri o estadual e raz o social e o m todo ValidarCNPF Quando olhamos a figura acima notamos que a classe Cliente a mais gen rica e as classes Pessoa Fisica e Pessoa Juridica s o as mais especializadas Ent o podemos dizer que generalizamos quando partimos das subclasses para a superclasse e especializamos quando fazemos o contr rio ou seja quando partimos superclasse para as subclasses Polimorfismo O conceito de polimorfismo est associado heran a pois o mesmo trabalha com a redeclara o de m todos previamente herdados por uma classe Esses m todos embora parecidos diferem de alguma forma da implementa o utilizada na superclasse sendo preciso implement los novamente na subclasse Mas a fim de n o ter que alterar o c digo fonte acrescentando uma chamada a um m todo com um nome diferente redeclara se o m todo com o mesmo nome declarado na superclasse GUEDES 2007 p 36 De acordo com Lima 2009 p 26 polimorfismo o princ pio em que clas
56. ARIA DE SOFTWARE Educa o a Dist ncia 1 23 CESUMAR CENTROUNIVERSIT RIO DE MARING DOCUMENTO DE REQUISITOS Laborat rio de An lises Cl nicas O Laborat rio de An lises Cl nicas S o Jo o deseja informatizar suas atividades pois hoje n o h controle sobre o hist rico de cada paciente dos exames que ele j realizou e se gasta muito tempo com atividades que poderiam ser feitas por um sistema informatizado Hoje o laborat rio funciona da seguinte forma O paciente voc chega ao laborat rio com o pedido dos exames preenchido pelo seu m dico aquele que o cl nico geral que voc acabou de consultar preencheu e Se for a primeira vez que o paciente vai fazer exames preenchida uma ficha de cadastro com os seguintes dados nome endere o cidade UF CEP telefone data de nascimento RG e CPF A recepcionista a mo a que te atendeu quando voc chegou ao laborat rio S o Jo o preenche uma ficha com o nome do paciente nome do conv nio do paciente os nomes dos exames que o paciente ir fazer e a data e hor rio da realiza o de cada exame No final da ficha anotada a data em que os exames estar o prontos A primeira via desta ficha entregue ao paciente a voc e O resultado do exame colocado no envelope para posterior retirada pelo paciente O Laborat rio deseja que o novo sistema possa fornecer informa es r pidas precisas e seguras para assim melhorar suas atividades admi
57. ASE entre elas 1 O desenvolvimento de modelos gr ficos de sistemas como parte das especifica es de requisitos ou do projeto de software 2 A compreens o de um projeto utilizando se um dicion rio de dados que cont m in forma es sobre as entidades e sua rela o em um projeto 22 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING A gera o de interfaces com usu rios a partir de uma descri o gr fica da interface que criada interativamente pelo usu rio A depura o de programas pelo fornecimento de informa es sobre um programa em execu o A tradu o automatizada de programas a partir de uma antiga vers o de uma lingua gem de programa o como Cobol para uma vers o mais recente A tecnologia CASE est atualmente dispon vel para a maioria das atividades de rotina no processo de software proporcionando assim algumas melhorias na qualidade e na produtividade de software Existe basicamente duas formas de classifica o geral para as Ferramentas CASE A primeira delas as divide em Upper CASE Lower CASE Integrated CASE e Best in Class Upper CASE ou U CASE ou Front End s o aquelas ferramentas que est o voltadas para as primeiras fases do processo de desenvolvimento de sistemas como an lise de requisitos projeto l gico e documenta o S o utilizadas por analistas e pessoas mais interessadas na solu o do problema do que na implementa
58. Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 13 CESUMAR CENTROUNIVERSIT RIO DE MARING desenvolvedores e o cliente e constitui a base para as atividades subsequentes do desenvolvimento do sistema fornecendo um ponto de refer ncia para qualquer valida o futura do software constru do Al m disso o documento de requisitos estabelece o escopo o que faz parte e o que n o faz parte do sistema abrangendo um conjunto diversificado de usu rios que vai desde a alta ger ncia da organiza o que est pagando pelo sistema at os engenheiros respons veis pelo desenvolvimento do software A tabela abaixo mostra uma poss vel organiza o de um documento de requisitos definido por Sommerville 2011 p 64 baseada em uma norma IEEE Institute of Electrical and Electronics Engineers para documentos de requisitos Tabela A estrutura de um documento de requisitos Cap tulo Pref cio Introdu o Gloss rio Defini o de requisitos de usu rio Arquitetura do sistema Anota es LX Descri o Deve definir os poss veis leitores do documento e descrever seu hist rico de vers es incluindo uma justificativa para a cria o de uma nova vers o e um resumo das mudan as feitas em cada vers o Deve descrever a necessidade para o sistema Deve descrever bre vemente as fun es do sistema e explicar como ele vai funcionar com outros sistemas Tamb m deve descrever como o
59. CEP 87050 390 Maring Paran www cesumar br NEAD N cleo de Educa o a Dist ncia bl 4 sl 1 e 2 44 3027 6363 ead Dcesumar br www ead cesumar br ENGENHARIA DE SOFTWARE Professora Me M rcia Cristina Dadalto Pascutti CESUMAR CENTROUNIVERSIT RIO DE MARING APRESENTA O DO REITOR Viver e trabalhar em uma sociedade global um grande desafio para todos os cidad os A busca por tecnologia informa o conhecimento de qualidade novas habilidades para lideran a e solu o de problemas com efici ncia tornou se uma quest o de sobreviv ncia no mundo do trabalho Cada um de n s tem uma grande responsabilidade as escolhas que fizermos por n s e pelos nossos far grande diferen a no futuro Com essa vis o o Cesumar Centro Universit rio de Maring assume o compromisso de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros No cumprimento de sua miss o promover a educa o de qualidade nas diferentes reas do conhecimento formando profissionais cidad os que contribuam para o desenvolvimento de uma sociedade justa e solid ria o Cesumar busca a integra o do ensino pesquisa ex tens o com as demandas institucionais e sociais a realiza o de uma pr tica acad mica que contribua para o desenvolvimento da consci ncia social e pol tica e por fim a democratiza o do conhecimento acad mico com a articula o e a inte
60. DE USO 1 Leia novamente o Documento de Requisitos acima e verifique quais s o os usu rios do sistema Essas pessoas ser o os atores Fa a uma lista com os atores a Recepcionista Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 25 CESUMAR CENTROUNIVERSIT RIO DE MARING a Bioqu micos b Departamento Administrativo c Departamento de Faturamento d Paciente 2 Agora fa a uma lista com as funcionalidades do sistema Algumas aparecem des critas claramente no documento de requisitos Cada relat rio que mencionado no documento ser uma funcionalidade Ent o j sabemos que teremos as seguintes funcionalidades a Emitir ficha do paciente b Emitir relat rio de exames c Emitir pedido de exame d Emitir resultados dos exames 3 Por m importante observar que al m dos relat rios um sistema precisa ter os ca dastros para que o usu rio consiga inserir os dados no sistema para da ser poss vel emitir os relat rios Ent o com base nos relat rios mencionados acima teremos os seguintes cadastros a Cadastrar pacientes b Cadastrar exames c Cadastrar pedidos de exame d Cadastrar resultados dos exames 4 Cada uma das funcionalidades relacionadas acima ser um caso de uso em nosso diagrama Ent o agora voc precisa verificar qual is ator es estar o envolvido s em cada caso de uso Isso voc descobre fazendo uma nova leitura do documento de requisitos 5 Al
61. E SOFTWARE Educa o a Dist ncia 45 CESUMAR CENTROUNIVERSIT RIO DE MARING O modelo cascata ou ciclo de vida cl ssico considerado o paradigma mais antigo da engenharia de software sugere uma abordagem sequencial e sistem tica para o desenvolvimento de software come ando com a defini o dos requisitos por parte do cliente avan ando pelas atividades de projeto e implementa o de software testes implanta o culminando no suporte cont nuo do software conclu do Segundo Sommerville 2007 p 44 os principais est gios do modelo em cascata demonstram as atividades fundamentais do desenvolvimento 1 An lise e defini o de requisitos 1 As fun es as restri es e os objetivos do sis tema s o estabelecidos por meio da consulta aos usu rios do sistema Em seguida s o definidos em detalhes e servem como uma especifica o do sistema 2 Projeto de sistemas e de software O processo de projeto de sistemas agrupa os requisitos em sistemas de hardware ou de software Ele estabelece uma arquitetura do sistema geral O projeto de software envolve a identifica o e a descri o das abstra es fundamentais do sistema de software e suas rela es 3 Implementa o e teste de unidades 1 Durante esse est gio o projeto de software compreendido como um conjunto de programas ou unidades de programa O teste de unidades envolve verificar que cada unidade atenda a sua especifica o 4 Integra o e teste d
62. ENHARIA DE SOFTWARE Educa o a Dist ncia 1 1 3 CESUMAR CENTROUNIVERSIT RIO DE MARING do colch o se solteiro casal ber o queen size ou king size Para cada produto acabado emitir a lista de mat rias primas utilizadas para fabrica o do mesmo Para cada mat ria prima emitir o seu c digo sua descri o e a quantidade utilizada na fabrica o do PA Este relat rio ser solicitado e recebido pelo Departamento de Compras e tamb m ser solicitado e recebido pelo Gerente de Compras A figura abaixo mostra uma poss vel solu o para o problema que acabamos de descrever gt Atualizar i lt lt edend gt gt 20 00 Cadastrar MP Estoque MP 1 E S f i lt lt extendr lt zestend gt gt lt lt includes 7 Es R Cadastrar j i Grupos MP Cadastrar NF de Compra 1 i 1 1 cego 1 i Cadastrar PA i gt x pi A lt lt inclyd gt gt a Ze Cadastrar MP de cada PA 4 ht Cadastrar Fornecedor Emitir Lista Produtos Acabados Emitir Lista Fornecedores Emitir Lista MP por Grupo Gerente Compras Diagrama de Casos de Uso para o Sistema F brica de Colch es Anota es 1 1 4 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING DIAGRAMA DE CLASSES O diagrama de classes tem como objetivo permitir a visualiza o das classes utilizadas pelo sistema e como essas se relaci
63. IVERSIT RIO DE MARING Lan amento de Venda RE forno pm arm le ol te g Sabonete liquido DOVE i R 28 80 E Veja Multiuso R 3 54 Sabonete Phebo sabor Ma a R 1 59 R 5 97 R 38 31 e Tela de Pedido de Exame nesta tela poss vel lan ar v rios exames em um mesmo pedido de exame Nesta mesma tela poss vel no caso do pedido de exame ser pago em parcelas lan ar o valor de cada parcela o n mero do cheque deixado pelo paciente e a data de vencimento de cada parcela Pedido de Exame Valor Total festa wrote titia 1 48 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Tela de Compras nesta tela ser o lan ados os dados da compra ou seja a data da compra o fornecedor a condi o de pagamento e os v rios produtos que est o sendo comprados Nesta tela tamb m aparecem os bot es de atalho Note que o desenho do bot o o mesmo assim o sistema fica padronizado e o usu rio quando se depara com esse bot o em qualquer lugar do sistema saber que ao clic lo o sistema o levar para o cadastro referente ao dado em que o bot o estava se referindo alo Codigo Data ERES Fornecedor Condi o de Pagamento Produto OO O Quantidade Valor Unit rio Valor Total E a gt i Total Geral Outro exemplo de Tela de Compras nesta tela al m de lan ar os produtos comprados poss vel
64. Os stakeholders em um sistema expressam naturalmente os requisitos em seus pr prios termos e com o conhecimento impl cito de sua rea de atua o dificultando a compreens o por parte dos engenheiros de software que n o t m experi ncia no dom nio do cliente 3 Diferentes stakeholders t m em mente diferentes requisitos e podem express los de maneiras distintas obrigando os engenheiros de software a descobrir todas as poss veis fontes de requisitos e a encontrar os pontos comuns e os conflitos 4 Fatores pol ticos podem influenciar os requisitos do sistema 5 O ambiente econ mico e de neg cios no qual a an lise de requisitos ocorre din mico mudando durante o processo de an lise Como consequ ncia a import ncia dos requisitos espec ficos pode mudar podendo surgir novos requisitos por parte dos novos stakeholders que n o haviam sido consultados inicialmente Saiba mais sobre o Assunto Introdu o Engenharia de Requisitos Por Rodrigo Oliveira Sp nola Doutor e Mestre em Engenharia de Sistemas e Computa o Fonte lt http Anww devmedia com br artigo engenharia de software introducao a engenharia de re quisitos 8034 gt Acesso em 13 jun 2012 mm Entrevista As entrevistas formais ou informais com os stakeholders do sistema faz parte da maioria dos Anota es LX 84 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING processos de e
65. Q AR CENTROUNIVERSIT RIO DE MARING E minado a qa eee Professora Me M rcia Cristina Dadalto Pascutti ENGENHARIA DE SOFTWARE GRADUA O CURSO MARING PR 2012 CESUMAR CENTROUNIVERSIT RIO DE MARING Reitor Wilson de Matos Silva Vice Reitor Wilson de Matos Silva Filho Pr Reitor de Administra o Wilson de Matos Silva Filho Presidente da Mantenedora Cl udio Ferdinandi NEAD N cleo de Educa o a Dist ncia Diretoria do NEAD Willian Victor Kendrick de Matos Silva Coordena o Pedag gica Gislene Miotto Catolino Raymundo Coordena o de Marketing Bruno Jorge Coordena o Comercial Helder Machado Coordena o de Tecnologia Fabr cio Ricardo Lazilha Coordena o de Curso Supervisora do N cleo de Produ o de Materiais Nalva Aparecida da Rosa Moura Capa e Editora o Daniel Fuverki Hey Fernando Henrique Mendes Jaime de Marchi Junior Jos Jhonny Coelho Luiz Fernando Rokubuiti e Thayla Daiany Guimar es Cripaldi Supervis o de Materiais N dila de Almeida Toledo Revis o Textual e Normas Cristiane de Oliveira Alves Gabriela Fonseca Tofanelo Jana na Bicudo Kikuchi Jaquelina Kutsunugi Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos Ficha catalogr fica elaborada pela Biblioteca Central CESUMAR As imagens utilizadas neste livro foram obtidas a partir dos sites PHOTOS COM e SHUTTERSTOCK COM Av Guedner 1610 Jd Aclima o 44 3027 6360
66. RA A ELABORA O DO DIAGRAMA DE CLASSES 1 Como voc j fez o diagrama de casos de uso vai ficar mais f cil elaborar o diagrama de classes Com base nos casos de uso que voc definiu voc vai fazer uma lista das poss veis classes do sistema Lembre se que os relat rios n o ser o classe por si s mas para emitir cada relat rio utilizaremos diversas classes Uma dica se o diagrama possui um caso de uso de cadastro certeza de que precisar de uma classe para armazenar os dados que ser o cadastrados nesse caso de uso Seguin do esse racioc nio ter amos as seguintes classes Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 21 CESUMAR CENTROUNIVERSIT RIO DE MARING a b 2 o D g h Paciente Exame Pedido de Exame Resultado de Exame M dicos Conv nios Cidades UF s Grupos de Exames 2 Agora para cada uma das classes listadas relacione os poss veis atributos de cada uma delas A maioria desses atributos j aparece descrita no documento de requi sitos Nunca se esque a de voltar ao documento de requisitos sempre que tiver d vidas a Paciente c digo nome endere o CEP cidade UF telefone data de nascimen to RG e CPF b Exame c digo descri o valor procedimentos grup o ao qual pertence o exa me c Pedido de Exame c digo nome do paciente nome do m dico nome do conv nio nomes dos exames que ser o realizados data e hora da realiza o
67. XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX e Relat rio de Pagamento de Consultas por Per odo NOME DA EMPRESA 99 99 9999 99 99 Relat rio de Pagamentos de Consultas de 99 99 9999 a 99 99 9999 PAG 99 o pe do ad ce NMOR DATA PAGAMENTO PACIENTE M DICO CONSULTA 99 99 9999 XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX 999 999 99 99 99 9999 XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX 999 999 99 99 99 9999 XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX 999 999 99 a nana EA O ARA ACI ACRE a SAO RA A A PR o Rn a ato CARLO mA A Especifica o de Casos de Uso A especifica o de casos de uso descreve por meio de uma linguagem bastante simples as restri es que dever o ser consideradas no momento da implementa o do caso de uso Essas especifica es devem conter detalhes suficientes para permitir a codifica o em uma linguagem de programa o qualquer Seguem alguns exemplos de especifica es de casos de uso e Especifica o de Caso de Uso Cadastrar Paciente Os dados digitados pelo usu rio dever o estar em caixa alta O c digo do paciente dever ser gerado automaticamente pelo sistema mas o usu Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 53 CESUMAR CENTROUNIVERSIT RIO DE MARING rio poder alterar Nesse ca
68. a CESUMAR CENTROUNIVERSIT RIO DE MARING FORMATOS DE ENTRADASISA DAS Um dos problemas comuns de entrada sa da inclui a organiza o f sica de elementos de dados de entrada em uma tela de v deo a natureza das mensagens de erro quando se comete em erro de entrada e a organiza o f sica de elementos de dados de sa da nas telas e em relat rios Com o imenso conjunto atual de linguagens de quarta gera o e ferramentas de prototipa o interessante dar ao usu rio diversas varia es de telas de entrada imagens de sa da e coisas desse tipo Uma vez obtido o consentimento do usu rio deve ser vinculada uma c pia das imagens de tela e formatos de relat rios documenta o do sistema claro que em muitos casos o usu rio n o ter grandes sugest es para fazer porque n o tem experi ncia anterior em trabalhar com um sistema informatizado No caso dos sistemas de informa es computadorizadas as seguintes diretrizes ajudar o a desenvolver uma interface humana amistosa ao usu rio na maioria dos casos 1 Seu sistema deve requisitar entradas e produzir sa das em uma forma consistente Isso particularmente verdadeiro nos sistemas on line em que o usu rio pode introduzir uma entre diversas transa es diferentes e ou receber uma de diversas imagens diferentes Por exemplo se o sistema solicitar a data ao usu rio sempre que uma transa o for introduzida seria desastroso se um tipo de transa o exigisse a dat
69. a o para implementar o que o analista de sistemas modelou na etapa de projeto Sendo uma atividade pessoal n o existe um processo geral que seja normalmente seguido durante a programa o do sistema Alguns programadores come ar o com os componentes que eles compreendem melhor passando depois para os mais complexos Outros preferem deixar os componentes mais f ceis para o fim porque sabem como desenvolv los Alguns desenvolvedores gostam de definir os dados no in cio do processo e ent o utilizam esses dados para dirigir o desenvolvimento do programa outros deixam os dados sem especifica o enquanto for poss vel De acordo com Sommerville 2011 p 27 normalmente os programadores testam os c digos fontes que eles mesmos desenvolveram a fim de descobrir defeitos que devem ser removidos Esse processo chamado de depura o O teste e a depura o dos defeitos s o processos diferentes O teste estabelece a exist ncia de defeitos enquanto que a depura o se ocupa em localizar e corrigir esses defeitos Em um processo de depura o os defeitos no c digo devem ser localizados e o c digo precisa ser corrigido a fim de cumprir os requisitos A fim de garantir que a mudan a foi realizada corretamente os testes dever o ser repetidos Portanto o processo de depura o parte tanto do desenvolvimento quanto do teste do software VALIDA O DE SOFTWARE A valida o de software dedica se a mostrar que um sistema
70. a dever o tamb m ser apresentadas Da mesma forma sempre que um objeto da classe Pedido for destru do todos os objetos da classe Item Pedido a ele relacionados devem tamb m ser destru dos GUEDES 2007 p 58 Note que o relacionamento entre a classe Item Pedido e Produto de associa o portanto quando o objeto da classe Item pedido for exclu do por exemplo o objeto relacionado a ele na classe Produto n o dever ser exclu do Generaliza o Especializa o Esta associa o identifica classes m e superclasse chamadas gerais e classes filhas subclasses chamadas especializadas demonstrando a ocorr ncia de heran a e possivelmente de m todos polim rficos nas classes especializadas Anteriormente nesta mesma unidade j foi explicado o conceito de heran a e polimorfismo MULTIPLICIDADE De acordo com Guedes 2007 p 54 a multiplicidade determina o n mero m nimo e m ximo de inst ncias envolvidas em cada uma das extremidades da associa o permitindo tamb m especificar o n vel de depend ncia de um objeto para com os outros Quando n o existe multiplicidade expl cita entende se que a multiplicidade 1 1 significando que uma e somente uma inst ncia dessa extremidade da associa o relaciona se com as Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 1 9 CESUMAR CENTROUNIVERSIT RIO DE MARING inst ncias da outra extremidade A tabela abaixo retirada d
71. a na forma 12 23 87 enquanto outra transa o exigisse a data na forma 87 12 23 E tamb m seria desastroso se uma parte do sistema exigisse que o usu rio especificasse o estado como um c digo de dois caracteres p ex RJ para Rio de Janeiro enquanto outra parte do sistema exigisse que o nome de estado fosse escrito por extenso De forma an loga se uma parte do sistema exigir que o usu rio forne a um c digo de rea quando introduzir um n mero de telefone todas as partes do sistema devem exigir um c digo de rea quando for introduzido um n mero de telefone 2 Pe a informa es em uma sequ ncia l gica Em muitos casos isso depende da natureza da aplica o e exigir minuciosos entendimentos com o usu rio Por exemplo se estiver sendo desenvolvido um sistema de controle de pedidos onde o usu rio especifique o nome do cliente Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 Jo CESUMAR CENTROUNIVERSIT RIO DE MARING ser necess rio especificar a sequ ncia na qual os componentes de nome de cliente seriam introduzidos Uma sequ ncia l gica seria solicitar ao usu rio que introduzisse a informa o na seguinte sequ ncia t tulo Sr Sra etc primeiro nome inicial do nome intermedi rio ltimo nome Por m o usu rio pode achar isso muito desajeitado suponha que o usu rio tenha obtido o nome do cliente de alguma fonte externa como um cat logo de telefones Nesse caso ser
72. a necessidade de tornar o desenvolvimento de software confi vel com etapas bem definidas com custo e cronograma previs veis o que at a poca de 1968 quando o termo engenharia de software foi proposto n o acontecia A proposta da engenharia de software portanto tornar o desenvolvimento de software um processo sistematizado no qual podem ser aplicados t cnicas e m todos necess rios para controlar a complexidade inerente aos grandes sistemas SOMMERVILLE 2007 p 4 Gostaria de ressaltar que software compreende al m dos programas toda a documenta o referente aos mesmos sendo que a engenharia de software a disciplina que trata dessa documenta o Sendo assim apresentarei a voc uma pequena parte dessa documenta o pois seria necess rio mais do que um livro para tratar da documenta o completa que pode ser elaborada no desenvolvimento de um software Outro ponto importante que necess rio deixar registrado que de nada vale uma documenta o desatualizada por isso importante utilizar uma ferramenta CASE para criar e manter a documenta o Uma ferramenta CASE tamb m um software s que neste caso auxilia o desenvolvedor e n o o usu rio final do sistema que est sendo desenvolvido Depois na segunda unidade come aremos a aplicar os conceitos j estudados e mostrarei a voc que um processo de software gen rico composto de algumas etapas b sicas que far o parte de qualquer modelo de proc
73. a para cada um deles sendo poss vel elaborar diversos modelos A UML tem sido empregada de maneira efetiva em sistemas cujos dom nios abrangem sistemas de informa es corporativos servi os banc rios e financeiros transportes servi os distribu dos baseados na Web entre outros Por m a UML n o se limita modelagem de software podendo modelar sistemas como o fluxo de trabalho no sistema legal a estrutura e o comportamento de sistemas de sa de e o projeto de hardware BOOCH 2005 p 17 Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 33 CESUMAR CENTROUNIVERSIT RIO DE MARING HIST RICO DA UML AUML originou se da jun o dos M todo Booch de Grady Booch M todo OMT Object Modeling Technique de Rumbaugh e do m todo OOSE Object Oriented Software Engineering de Jacobson Esses eram at meados da d cada de 1990 as tr s metodologias de modelagem orientadas a objetos mais populares entre os profissionais da rea de engenharia de software GUEDES 2007 p 13 Em outubro de 1994 Rumbaugh se juntou a Booch na Rational Software Corporation iniciando assim oficialmente os esfor os para a cria o da UML O foco inicial do projeto era a unifica o dos m todos Booch e OMT o que resultou no lan amento do M todo Unificado no final de 1995 Logo em seguida Jacobson juntou se a Booch e Rumbaugh na Rational Software e seu m todo OOSE come ou tamb m a ser incorporado nova metodologia BOOCH
74. acionamentos de associa o que pode ser un ria ou bin ria generaliza o e agrega o Existem alguns tipos especiais de relacionamentos por m n o ser o explicados aqui Com os relacionamentos citados poss vel elaborar um diagrama de classes Associa o De acordo com Melo 2004 p 109 a associa o um relacionamento que conecta duas ou mais classes demostrando a colabora o entre as inst ncias de classe Pode se tamb m ter um relacionamento de uma classe com ela mesma sendo que neste caso tem se a associa o un ria ou reflexiva Associa o Un ria ou Reflexiva Segundo Gedes 2007 p 54 a associa o un ria ocorre quando existe um relacionamento de uma inst ncia de uma classe com inst ncias da mesma classe conforme mostra o exemplo abaixo Funcionario codigo int nome char codChefe int Exemplo de Associa o Un ria Anota es LX 1 1 6 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Neste exemplo temos a classe Funcion rio cujos atributos s o c digo nome e o c digo do possivel chefe do funcion rio Como esse chefe tamb m um funcion rio a associa o chamada Chefia indica uma poss vel rela o entre uma ou mais inst ncias da classe Funcion rio com outras inst ncias da mesma classe ou seja tal associa o determina que um funcion rio pode ou n o chefiar outros funcion rios Essa associa
75. ade Exemplo de Documento de Requisitos Locadora de Filmes Uma determinada locadora possui muitos t tulos em seu acervo e n o consegue controlar Anota es e ENGENHARIA DE SOFTWARE Educa o a Dist ncia 15 CES UMAR CENTROUNIVERSIT RIO DE MARING de maneira eficiente as loca es devolu es e reservas dos filmes Portanto ela deseja ter um sistema informatizado que controle todas as loca es devolu es e reservas de maneira eficiente para aperfei oar o seu atendimento com o cliente e seu controle interno Atualmente a locadora possui uma ficha para o cadastro de clientes com os seguintes dados nome do cliente fone residencial fone celular sexo RG CPF endere o completo data de nascimento estado civil e nomes de cinco dependentes e o grau de parentesco de cada dependente o dependente pode locar filmes em nome do cliente O sistema informatizado deve 1 2 Manter o cadastro de filmes Neste cadastro dever conter os seguintes dados nome do filme dura o sinopse classifica o g nero diretor elenco Para cada c pia do filme necess rio saber o fornecedor da mesma a data da compra o valor pago e o tipo VHS ou DVD Controlar loca es A loca o feita mediante a verifica o de cadastro do cliente Se o cliente for cadastrado ent o se efetua a loca o se n o se cadastra o cliente Caso a loca o seja efetuada pelo dependente do cliente neces
76. ados para constitu rem o sistema Esse processo se dedica a encontrar erros que resultem de intera es n o previstas entre os componentes e de problemas com a interface do componente O teste de sistema tamb m utilizado para validar que o sistema atende os requisitos funcio nais e n o funcionais definidos no documento de requisitos 3 Teste de aceita o Nesse est gio o sistema testado com dados reais fornecidos pelo cliente podendo mostrar falhas na defini o de requisitos pois os dados reais podem exercitar o sistema de modo diferente dos dados de teste Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 59 CESUMAR CENTROUNIVERSIT RIO DE MARING EVOLU O DE SOFTWARE Depois que um software colocado em funcionamento ou seja depois que o mesmo implantado com certeza ocorrer mudan as que levar o altera o desse software Essas mudan as podem ser de acordo com Pressman 2011 p 662 para corre o de erros n o detectados durante a etapa de valida o do software quando h adapta o a um novo ambiente quando o cliente solicita novas caracter sticas ou fun es ou ainda quando a aplica o passa por um processo de reengenharia para proporcionar benef cio em um contexto moderno Sommerville 2011 p 29 coloca que historicamente sempre houve uma fronteira entre o processo de desenvolvimento de software e o processo de evolu o desse mesmo software manuten o de
77. agar por Fornecedor mef Forncedor gt De Cancelar B Interface Impressa Para cada relat rio do sistema definidos no Diagrama de Caso de Uso necess rio definir o seu layout Sugest o criar uma padroniza o para todos os relat rios do sistema para facilitar a utiliza o dos mesmos pelo usu rio Seguem alguns exemplos de interfaces impressas Note nos exemplos que eles possuem no cabe alho o nome da empresa o n mero da p gina do relat rio a data e em alguns o hor rio da emiss o do relat rio o t tulo do relat rio e em alguns o valor dos par metros informados na tela de filtro do relat rio para que o usu rio possa saber depois do relat rio impresso quais foram os dados informados no filtro para a emiss o do mesmo e Relat rio de Clientes por Cidade NOME DA EMPRESA DATA 999919999 Relat rio de Clientes PAG 99 C DIGO NOME ENDERECO CEP TELEFONE CIDADE 9999 XXXXXXXXXXXXXXXXXXX 9999 XXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXX XXXXXXXXXXXX 9999 XXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXX XXXXXXXXXXXX 9999 XXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXX XXXXXXXXXXXX 9999 XXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXX XXXXXXXXXXXX 1 52 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING e Relat rio de Consultas Efetuadas por Dia NOME DA EMPRESA DATA 99 99 9999 Relat rio de Consultas Efetuadas em 99 99 9999 PAG 9 aaa PACIENTE M DICO CONV NIO XXXXXXXXX
78. al tueiy Soriano E RE precision sse LN amei bli mtode coding ar AET e Liege programming ss bee developmen Sarin Eimermaiona contentious maintenance o ER actual generic ogia O nesse fiele quantnanio n Since 5 experince much amp o o gal licatio ond EE a rm becoming post graduate engineer m Mi protect degrees elinition ED professie g moms g E approaches 2 classical 5 E curriculum S sulicient E Tcentta e fields E eacualy introduction e although S compared debate so EH SE sr Caro a aluno a nesta primeira unidade trataremos alguns conceitos relacionados engenharia de software como um todo que ser o fundamentais para o entendimento de todas as unidades O termo engenharia de software foi proposto inicialmente em 1968 em uma confer ncia organizada para discutir o que era chamado de crise de software Essa crise foi originada em fun o do hardware que nessa poca tinha seu poder de processamento e mem ria aumentados sendo que o software deveria acompanhar esse avan o E o que se notou na poca que o desenvolvimento de grandes sistemas de maneira informal sem seguir regras ou etapas pr definidas n o era suficiente O software desenvolvido at ent o n o era confi vel n o era desenvolvido dentro do tempo e custos previstos inicialmente seu desempenho era insatisfat rio e era dif cil de dar manuten o ao mesmo Os custos em rela o ao hardware es
79. am v rios modelos de processos de software sendo que a empresa pode escolher o que melhor se adequa a ela Isso tem ajudado muito o desenvolvimento de software Voc vai perceber isso durante o estudo das pr ximas unidades Outro conceito importante que foi tratado nesta primeira unidade o conceito de software Algumas pessoas que conhe o acham que desenvolver software simplemesmente sentar em frente ao computador e escrever as linhas de c digo Voc percebeu que sim isso faz parte do software mas que desenvolver software muito mais abrangente pois o software envolve al m dos programas a documenta o as pessoas os procedimentos envolvidos A engenharia de software trata de todos esses aspectos mas em nosso livro trataremos mais especificamente da modelagem de um software desde o levantamento dos requisitos at a elabora o de v rios diagramas N o trataremos da implementa o propriamente dita pois isso voc ver em outras disciplinas do curso A implementa o muito importante por isso voc ter disciplinas dedicadas a essa tarefa Todas as etapas da engenharia de software podem ser desenvolvidas com o aux lio de ferramentas CASE que conforme vimos nada mais do que um software desenvolvido por alguma empresa e que tem por objetivo auxiliar o desenvolvedor nas tarefas executadas durante o desenvolvimento desde o seu in cio at a implanta o do software para o usu rio Em nossa disciplina de enge
80. as pequenos com menos de 100 mil linhas de c digo ou para sistemas de porte m dio com at 500 mil linhas de c digo com tempo de vida razoavelmente curto a abordagem incremental de desenvolvimento talvez seja a melhor op o Contudo para sistemas de grande porte de longo tempo de vida nos quais v rias equipes desenvolvem diferentes partes do sistema os problemas de se utilizar o desenvolvimento incremental se tornam particularmente graves Para esses sistemas recomendado um processo misto que incorpore as melhores caracteristicas do modelo de desenvolvimento em cascata e do incremental ou ainda algum outro modelo dispon vel na literatura Na literatura referente a modelos de processo de software pode se encontrar a prototipa o como um exemplo de abordagem incremental Engenharia de software orientada a reuso Na maioria dos projetos de software ocorre algum reuso de software pois normalmente Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 49 CESUMAR CENTROUNIVERSIT RIO DE MARING a equipe que trabalha no projeto conhece projetos ou c digos an logos ao que est sendo desenvolvido Ela busca esses c digos faz as modifica es conforme a necessidade do cliente e os incorporam em seus sistemas Independentemente do processo de software que est sendo utilizado pode ocorrer esse reuso informal Por m nos ltimos anos uma abordagem para desenvolvimento de software com foco no reuso
81. associativas 5 Depois disso estabelecer a multiplicidade de cada relacionamento lembrando se de eliminar atributos que podem ser obtidos por meio do relacionamento 6 Primeiro desenhe o seu diagrama de classes e depois compare com o meu Veja s como ficou o meu diagrama codigo int nome int endere o int codigo int CEP int nome int telefone int data nascimento int RG int CPF int Pedido Exame Exame Pedido Exame data_realiza o_exame int hora_realiza o_exame int c digo int nome int DDD int poe data pronto int hora pronto int resultado int valor int descri o int c digo int valor int 3 descri o int procedimentos int Seguem alguns esclarecimentos sobre o diagrama acima Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 29 CESUMAR CENTROUNIVERSIT RIO DE MARING 1 Um pedido de exame pode estar relacionado a somente um paciente um m dico e um conv nio no diagrama n o aparece a multiplicidade 1 por ser o valor default de um relacionamento 2 Um pedido de exame pode estar relacionado a um ou a v rios exames no caso desse documento de requisitos a 5 exames 3 Note que os atributos data realizacao exame hora realiza o exame data pron to hora pronto resultado e valor est o armazenados na classe associativa que
82. at rios e iii desenvolver um conjunto de especifica es de casos de uso sendo que essas especifica es devem conter detalhes suficientes para permitir a codifica o Geralmente durante o projeto o engenheiro de software ter que definir cada componente do sistema ao n vel de detalhamento que se fizer necess rio para a sua implementa o em uma determinada linguagem de programa o Diagrama Geral do Sistema Tamb m conhecido por Diagrama de M dulos apresenta os m dulos do sistema as liga es entre eles os seus subm dulos e ou itens O Diagrama Geral do Sistema deve ser condizente com o Diagrama de Caso de Uso ou seja as op es representadas no Diagrama Geral do Sistema devem aparecer como Casos de Uso no Diagrama de Casos de Uso Seguem abaixo alguns exemplos de Diagrama Geral do Sistema ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 41 CESUMAR CENTROUNIVERSIT RIO DE MARING Exemplo 1 Diagrama Geral do Sistema para um sistema de Controle de Estoque Sistema de Controle de Estoque Cadastros Movimenta es Relat rios Sair Grupos Produtos Compras Gerais Cadastro E Produtos Pedido Clientes Client
83. ata aplicado 1 Os projetos que acontecem nas empresas dificilmente seguem o fluxo sequencial pro posto pelo modelo Alguma itera o sempre ocorre e traz problemas na aplica o do paradigma 2 Na maioria das vezes o cliente n o consegue definir claramente todas as suas ne cessidades e o modelo cascata requer essa defini o no in cio das atividades Portanto esse modelo tem dificuldade em acomodar a incerteza natural que existe no come o de muitos projetos 3 Uma vers o operacional do sistema somente estar dispon vel no final do projeto ou seja o cliente n o ter nenhum contato com o sistema durante o seu desenvolvimento Isso leva a crer que se algum erro grave n o for detectado durante o desenvolvimento o sistema n o atender de forma plena as necessidades do cliente Segundo Sommerville 2011 p 21 e Pressman 2011 p 61 o modelo em cascata deve ser utilizado somente quando os requisitos s o fixos e tenham pouca probabilidade de serem alterados durante o desenvolvimento do sistema e o trabalho deve ser realizado at sua finaliza o de forma linear Sommerville 2011 p 21 ainda afirma que o modelo cascata reflete o tipo de processo usado em outros projetos de engenharia Como mais f cil usar um modelo de gerenciamento comum para todo o projeto processos de software baseados no modelo em cascata ainda s o comumente utilizados lt http www youtube com watch v vaavIT2Bqz8 gt V deo d
84. atalogue tc catalogue detail htm csnumber 22749 gt Existe tamb m adequa o dessa norma para o Brasil a NBR ISO IEC 9126 1 Verifique no endere o lt http www abnt org br gt Leitura Complementar Especifica o de requisitos no desenvolvimento de software para TV Digital Interativa no Bra sil Reflex es e Relato de Experi ncia Por Carlos Eduardo Marquioni O processo de implanta o da TV Digital no Brasil iniciou uma nova fase em 2009 relacionada defini o de mecanismos para intera o atrav s do televisor Contudo al m de viabilizar a infraes trutura tecnol gica para troca de informa es entre o telespectador e os difusores parece relevante considerar a utiliza o de processos de software para que os produtos desenvolvidos que possibilitam a intera o tenham qualidade Este trabalho apresenta conceitos do processo de Especifica o da Engenharia de Requisitos e relaciona boas pr ticas de escrita para gerar requisitos textuais que integradas com a t cnica de Casos de Uso levaram defini o de um m todo de especifica o de requisitos para a TV Digital Interativa que utiliza conceitos conhecidos pela comunidade de software O m todo foi utilizado em um projeto real e abordado no artigo como relato de experi ncia O trabalho completo pode ser encontrado no endere o abaixo Fonte lt http revistas ua pt index php prismacom article view 784 gt Acesso em 07 jun 2012 Anota
85. atende tanto as especifica es Anota es LX 58 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING relacionadas no documento de requisitos quanto s expectativas dos seus usu rios A principal t cnica de valida o de acordo com Sommerville 2011 p 27 o teste de programa em que o sistema executado com dados de testes simulados Os testes somente podem ser realizados como uma unidade isolada se o sistema for pequeno Caso contr rio se o sistema for grande e constitu do a partir de subsistemas que por sua vez s o constru dos partindo se de m dulos o processo de testes deve evoluir em est gios ou seja devem ser realizados de forma incremental iterativa Sommerville 2011 p 27 prop e um processo de teste em tr s est gios O primeiro est gio o teste de componente em seguida o sistema integrado testado e por fim o sistema testado com dados reais ou seja com dados do pr prio cliente Idealmente os defeitos de componentes s o descobertos no in cio do processo e os problemas de interface s o encontrados quando o sistema integrado Os est gios do processo de testes conforme Sommerville 2011 p 27 s o 1 Testes de desenvolvimento Para garantir que os componentes individuais est o operando corretamente necess rio test los de forma independente dos outros componentes do sistema 2 Testes de sistema Os componentes s o integr
86. de fornecer somente parte da funcionalidade requerida 2 Modifica o de requisitos no decorrer dessa etapa os requisitos s o analisados levando se em considera o as informa es sobre os componentes que foram encontra dos na etapa anterior Se for poss vel os requisitos s o ent o modificados para refletir os componentes dispon veis Quando isso n o for poss vel ou seja quando as modifica es forem imposs veis a etapa de an lise de componentes dever ser refeita a fim de pro curar outras solu es 3 Projeto do sistema com reuso durante essa etapa o framework do sistema proje tado ou ent o alguma infraestrutura existente reutilizada Os projetistas levam em con sidera o os componentes que s o reusados e organizam o framework para tratar desse aspecto Se os componentes reus veis n o estiverem dispon veis pode ser necess rio que um novo software deva ser projetado 4 Desenvolvimento e integra o nessa etapa o software que n o puder ser compra do dever ser desenvolvido e os componentes e sistemas COTS ser o integrados a fim de criar um novo sistema A integra o de sistemas nessa abordagem pode ser parte do processo de desenvolvimento em vez de uma atividade separada Deve se tomar muito cuidado ao utilizar essa abordagem pois n o se tem como evitar as altera es nos requisitos dos usu rios e isso pode acabar levando ao desenvolvimento de um sistema que n o atenda as suas reais
87. de verifica o Para diminuir as poss veis diverg ncias entre cliente e fornecedor os requisitos do sistema devem sempre ser escritos de modo que pos sam ser verificados Isso implica na defini o de um conjunto de verifica es para mostrar que o sistema entregue cumpre com esses requisitos Algumas t cnicas de valida o de requisitos podem ser utilizadas em conjunto ou individualmente A seguir s o mostradas algumas delas 1 Revis es de requisitos Os requisitos s o analisados sistematicamente por uma equipe de revisores a fim de eliminar erros e inconsist ncias Prototipa o Nessa abordagem de valida o um modelo execut vel do sistema mostrado aos usu rios finais e clientes possibilitando que os mesmos experimentem o modelo para verificar se atende s necessidades da empresa Gera o de casos de teste Como modelo ideal os requisitos deveriam ser test veis Se os testes para os requisitos s o criados como parte do processo de valida o isso muitas vezes revela problemas com os requisitos Se um teste dif cil ou imposs vel de ser projetado isso frequentemente significa que os requisitos ser o de dif cil implementa o e devem ser reconsiderados O desenvolvimento de testes a partir dos requisitos de usu rio antes da implementa o do sistema uma parte integrante da Extreme Programming As dificuldades da valida o de requisitos n o devem ser subestimadas pois muito dif cil
88. der o dom nio contexto problema que deve ser automatizado sendo que o produto do levantamento de requisitos o DOCUMENTO DE REQUISITOS ou ESPECIFICA O DE REQUISITOS que declara os diversos tipos de requisitos do sistema requisitos funcionais requisitos n o funcionais de usu rio e de sistema J tratamos desse t pico nesta unidade ENGENHARIA DE SOFTWARE Educa o a Dist ncia 89 CESUMAR CENTROUNIVERSIT RIO DE MARING VALIDA O DE REQUISITOS A valida o de requisitos tem como objetivo mostrar que os requisitos realmente definem o sistema que o cliente deseja Ela tem muito em comum com a an lise de requisitos uma vez que se preocupa em descobrir problemas nos requisitos Contudo esses s o processos distintos j que a valida o deve se ocupar da elabora o de um esbo o completo do documento de requisitos enquanto a an lise envolve trabalhar com requisitos incompletos SOMMERVILLE 2007 p 105 A valida o de requisitos importante porque a ocorr ncia de erros em um documento de requisitos pode levar a grandes custos relacionados ao retrabalho quando esses erros s o descobertos durante o desenvolvimento ou depois que o sistema estiver em opera o O custo de fazer uma altera o no sistema resultante de um problema de requisito muito maior do que reparar erros de projeto e de codifica o pois em geral significa que o projeto do sistema e a implementa o tamb m devem ser modificados
89. desenvolvimento mas todos os artefatos obrigat rios descritos no PGDS devem ser elaborados ao longo do projeto O PGDS disponibiliza modelos templates para a maioria de seus artefatos com o objetivo de orientar e facilitar a sua elabora o Atividades como Uma atividade no PGDS representa um conjunto de passos e tarefas que um profissional que desempenha o papel respons vel por aquela atividade deve executar para gerar algum resultado As atividades envolvem a produ o e modifica o de artefatos do projeto Fases quando As fases do PGDS apresentam a sequ ncia e a depend ncia entre as atividades do projeto ao longo do tempo As atividades no fluxo s o divididas em fases do ciclo de vida do projeto e nos pap is respons veis pela execu o de cada uma Dispon vel em lt http 189 28 128 113 pgds gt Acesso em 05 jun 2012 LS Caro a aluno a o DATASUS o Departamento de Inform tica do Sistema nico de Sa de do Minist rio da Sa de e voc p de perceber pelo texto acima que ele criou um processo de software pr prio muito interessante conhecer todo o material que eles disponibilizam Se voc quiser conhecer acesse o endere o lt http 189 28 128 113 pgds gt Ou ent o acesse o endere o lt http www2 datasus gov br DATASUS index php area 01 gt para ler mais sobre o DATASUS como um todo uma leitura bastante esclarecedora Dispon vel em lt http 189 28 128 113 pgds gt Acesso em 05 ju
90. do a primeira ferramenta CASE baseada na linguagem UML Atualmente essa ferramenta bastante usada pelas empresas desenvolvedoras de software Ela permite a modelagem dos diversos diagramas da UML e tamb m a constru o de modelos de dados com possibilidade de exporta o para constru o da base de dados ou realiza o de engenharia reversa de uma base de dados existente Em Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 35 CESUMAR CENTROUNIVERSIT RIO DE MARING 20 de fevereiro de 2003 a empresa Rational foi adquirida pela IBM e agora a ferramenta chama se sucedido pelo IBM Rational Architect Maiores informa es sobre esta ferramenta podem ser consultadas no endere o lt www rational com gt Astah Professional uma ferramenta para cria o de diagramas UML possuindo uma vers o gratuita o Astah Community e outras vers es pagas A vers o gratuita que pode ser obtida no endere o lt http astah net download gt possui algumas restri es de fun es por m para as que precisaremos nesta unidade ser suficiente portanto ser essa a ferramenta que utilizaremos para modelar os diagramas da UML que aprenderemos Anteriormente essa ferramenta era conhecida por Jude Visual Paradigm for UML ou VP UML esta ferramenta oferece uma vers o que pode ser baixada gratuitamente a Community Edition por m essa vers o n o suporta todos os servi os e op es dispon veis nas vers es Standard ou Pro
91. do trabalho e Rela o de tempo como o trabalho executado se relaciona a per odos espec ficos do ano ou outros ciclos comerciais Existe pico Qual o atual volume de trabalho f Formul rios procedimentos e relat rios quais s o utilizados inclua exemplo de cada formul rio relat rio e procedimento Verifique se o material tem origem no escrit rio se modificado pelo escrit rio e ou transmitido para outro escrit rio Fa a compara es que determinam se inutilizado duplicado ou incompleto Verifique a satisfa o dos usu rios com esses documentos 9 Fun es desej veis e n o existentes registre a opini o das pessoas sobre o sistema como ele existe e como poderia ser Aten o opini es mais subjetivas que objetivas h Flexibilidade dos procedimentos o sistema atual t o r gido e inflex vel que a menor modifica o requer o maior remendo Anota es LX 88 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING i Capacidade o sistema atual consegue manipular volumes maiores do que aqueles que resultam do crescimento normal Coloque tr s interessados em uma sala e pergunte a eles que tipo de sistema desejam Provavelmen te voc obter quatro ou mais opini es diferentes Autor desconhecido LS ESPECIFICA O DE REQUISITOS Durante o levantamento de requisitos levantamento de dados a equipe de desenvolvimento tenta enten
92. dor precisa preparar uma defini o de sistema para o cliente com mais detalhes de modo que o cliente compreenda e possa validar o que o software far Esses dois documentos podem ser chamados de documentos de requisitos do sistema Veremos mais adiante o documento de requisitos com mais detalhes Mas e o que pode acontecer se os requisitos n o forem definidos corretamente se ficarem errados Se isso acontecer o sistema pode n o ser entregue no prazo combinado e com o custo acima do esperado no in cio do projeto o usu rio final e o cliente n o ficar o satisfeitos com o sistema e isso pode at implicar no descarte do sistema Portanto o ideal que essa etapa seja muito bem elaborada A parte mais dif cil ao construir um sistema de software decidir o que construir Nenhuma parte do trabalho afeta tanto o sistema resultante se for feita a coisa errada Nenhuma outra parte mais dif cil de consertar depois Fred Brooks Engenheiro de Software SEA Anota es LX 68 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING REQUISITOS FUNCIONAIS E N O FUNCIONAIS Primeiramente vamos definir o que requisito independentemente da rea de inform tica Um requisito a condi o imprescind vel para a aquisi o ou preenchimento de determinado objetivo Na abordagem da engenharia de software segundo Sommerville 2011 p 57 os requisitos de um sistema s o as descr
93. e Guedes 2007 p 55 demonstra alguns dos diversos valores de multiplicidade que podem ser utilizados em uma associa o Tabela Exemplos de multiplicidade Multiplicidade Significado No m nimo zero nenhum e no m ximo um Indica que os objetos das classes associadas n o precisam obrigatoriamente estar relacionados mas se houver E relacionamento indica que apenas uma inst ncia da classe se relaciona com as inst ncias da outra classe Um e somente um Indica que apenas um objeto da classe se relaciona com os objetos da outra classe NS No m nimo nenhum e no m ximo muitos Indica que pode ou n o haver inst n cias da classe participando do relacionamento Muitos Indica que muitos objetos da classe est o envolvidos no relacionamento No m nimo 1 e no m ximo muitos Indica que h pelo menos um objeto envolvi do no relacionamento podendo haver muitos objetos envolvidos No m nimo 2 e no m ximo 5 Indica que existem pelo menos 2 inst ncias envol 2 550 vidas no relacionamento e que podem ser 3 4 ou 5 as inst ncias envolvidas mas n o mais do que isso As associa es que possuem multiplicidade do tipo muitos em qualquer de suas extremidades for am a transmiss o do atributo chave contido na classe da outra extremidade da associa o por m esse atributo chave n o aparece desenhado na classe CLASSE ASSOCIATIVA Quando um relacionamento possui multiplicidade muitos em suas duas extremidades
94. e casos de uso um dos diagramas mais gerais e informais da UML normalmente a modelagem do sistema inicia se com a elabora o desse diagrama O diagrama de casos de uso mostra as intera es entre um sistema e seu ambiente externo determinando as funcionalidades e as caracter sticas do sistema sob o ponto de vista do usu rio Conhecemos nesta unidade os conceitos necess rios para a elabora o desse diagrama atores casos de uso e os poss veis relacionamentos entre estes elementos Al m disso foi apresentado um diagrama pronto que foi elaborado a partir do documento de requisitos para uma f brica de colch es mostrando como os conceitos acima podem ser aplicados em um diagrama Depois que o diagrama de casos de uso elaborado fica bem mais f cil elaborar o diagrama de classes que o mais importante e tamb m o mais utilizado da UML e que define a estrutura das classes identificadas para o sistema mostrando os atributos e m todos possu dos por cada uma das classes e tamb m os seus relacionamentos Com base no mesmo documento de requisitos o da f brica de colch es foi mostrado como fica o diagrama de classes referente ao mesmo E para auxiliar o entendimento desses dois diagramas foi apresentado a elabora o passo a passo de cada um deles Para verificar se voc realmente entendeu todos os conceitos estou propondo mais um documento de requisitos nas atividades de autoestudo Ent o m os a obra ATIVIDADE DE
95. e demonstra o do modelo de desenvolvimento cascata simulado pelo jogo SE RPG EE Desenvolvimento incremental O desenvolvimento incremental segundo Sommerville 2011 p 21 tem como base a ideia ENGENHARIA DE SOFTWARE Educa o a Dist ncia 47 CESUMAR CENTROUNIVERSIT RIO DE MARING de desenvolver uma implementa o inicial baseada em uma reuni o com os envolvidos para definir os objetivos gerais do software mostrar para o usu rio e fazer seu refinamento por meio de v rias vers es at que um sistema adequado tenha sido desenvolvido Atividades concorrentes o gt Vers o inicial Especifica o q z Vers es Descri o do Nes E Valida o gt Vers o final Fonte Sommerville 2011 p 22 Assim as atividades de especifica o desenvolvimento e valida o s o realizadas concorrentemente com um r pido feedback entre todas as atividades A cada nova vers o o sistema incorpora novos requisitos definidos pelo cliente Para Pressman 2011 p 63 inicialmente necess rio desenvolver um projeto r pido que deve se concentrar em uma representa o daqueles aspectos do software que ser o vis veis aos usu rios finais como por exemplo o layout da interface com o usu rio O desenvolvimento incremental apresenta algumas vantagens importantes em rela o ao modelo em cascata Sommerville 2011 p 22 coloca tr s va
96. e nas opera es comerciais ou tomadas de decis o pelos administradores da empresa e Software cient fico de engenharia s o aplica es que v o da astronomia vul canologia da biologia molecular fabrica o automatizada normalmente utilizando algoritmos para processamento num rico pesado e Software embutido controla ou gerencia dispositivos de hardware como por exemplo celular painel do micro ondas controle do sistema de freios de um ve culo e Software de intelig ncia artificial utiliza algoritmos n o num ricos para solu cionar problemas complexos que n o poderiam ser solucionados pela computa o ou an lise direta como por exemplo sistemas especialistas rob tica redes neurais artificiais N o existe computador que tenha bom senso Marvin Minsky cofundador do laborat rio de intelig ncia artificial do Instituto de Tecnologia de Mas sachusetts LS FERRAMENTAS CASE COMPUTER AIDED SOFTWARE ENGINEERING Uma ferramenta CASE um software que pode ser utilizado para apoiar as atividades do processo de software como a engenharia de requisitos o projeto o desenvolvimento de programa e os testes As ferramentas CASE podem incluir editores de projeto dicion rios de dados compiladores depuradores ferramentas de constru o de sistemas entre outros SOMMERVILLE 2007 p 56 Sommerville 2007 p 56 mostra alguns exemplos de atividades que podem ser automatizadas utilizando se C
97. e puder ajudar de alguma forma estou a sua disposi o Desejo muito sucesso e paz Prof M rcia ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 67 CESUMAR CENTROUNIVERSIT RIO DE MARING REFER NCIAS BOOCH Grady UML guia do usu rio 2 ed S o Paulo Campus 2005 GUEDES Gilleanes T A UML 2 guia pr tico S o Paulo Novatec Editora 2007 LIMA Adilson da Silva UML 2 0 do requisito solu o S o Paulo rica 2009 MELO Ana Cristina Desenvolvendo Aplica es com UML 2 0 do conceitual implementa o Rio de Janeiro Brasport 2004 PRESSMAN Roger Engenharia de Software 7 ed Porto Alegre AMGH 2011 SILVA Ricardo Pereira UML 2 modelagem orientada a objetos Florian polis Visual Books 2007 SOMMERVILLE lan Engenharia de Software S o Paulo Pearson Addison Wesley 2007 SOMMERVILLE lan Engenharia de Software S o Paulo Pearson Prentice Hall 2011 YOURDON Edward An lise Estruturada Moderna Rio de Janeiro Elsevier 1990 1 68 ENGENHARIA DE SOFTWARE Educa o a Dist ncia
98. e quest es a serem seguidas se a entrevista come ar a se desviar do ponto chave Anota es SA ENGENHARIA DE SOFTWARE Educa o a Dist ncia 85 CESUMAR CENTROUNIVERSIT RIO DE MARING A entrevista deve ser marcada com anteced ncia o hor rio deve ser combinado e as quest es devem ser preparadas Uma entrevista composta de tr s partes a abertura o corpo e o fechamento ABERTURA o objetivo chave estabelecer harmonia concord ncia Comece se identificando apresentando o t pico que pretende discutir e o prop sito objetivo da entrevista Se houver necessidade quebre o gelo com conversas informais mas n o caia na perda de tempo CORPO pode se come ar com uma quest o relativamente aberta Quando eu li a documenta o para este sistema tive algum trabalho com anuncie a parte ou se o voc pode me explicar e gradualmente caminhe atrav s de quest es espec ficas Nesta fase o engenheiro de software deve a Mostrar que conhece as responsabilidades e deveres do trabalho do entrevistado Exemplo isto o que eu entendo do seu trabalho uma breve descri o est correto b Procurar saber as decis es que o entrevistado toma quais s o e como ele toma as decis es quais s o as informa es necess rias se da forma como s o apresentadas s o satisfat rias qual o tempo necess rio anteced ncia para que se possa tomar as decis es c Procurar respostas quantitativas
99. e sistema que voc est desenvolvendo agora n o tratar da venda Para fabricar um PA necess rio saber quais as mat rias primas que comp em esse PA bem como a quantidade de cada mat ria prima que utilizada na fabri ca o do PA O sistema deve permitir o cadastro dos PAs e tamb m as mat rias primas e as quantidades de cada MP usadas em cada um deles Os cadastros e a movimenta o do sistema dever o ser realizadas pelo departamen to de compras O sistema deve emitir os relat rios que est o definidos abaixo A informa o de quem solicita cada relat rio bem como de quem recebe cada relat rio est junto com a defini o do relat rio O sistema deve emitir os seguintes relat rios A B D Lista de Fornecedores contendo o c digo nome cidade e fone Este relat rio ser solicitado e recebido pelo Departamento de Compras Lista de MPs por grupo contendo o nome do grupo e para cada grupo os dados da mat ria prima c digo descri o quantidade em estoque e valor unit rio Este rela t rio ser solicitado pelo Departamento de Compras e recebido pelo Departamento de Compras e pelo Gerente de Compras Rela o de Compras por Fornecedor contendo N mero da Nota Nome do fornece dor Data da emiss o e Total da nota Este relat rio ser solicitado e recebido pelo Departamento de Compras Lista de Produtos Acabados contendo o c digo descri o valor de venda e o tipo Anota es 1X ENG
100. e sistemas As unidades de programa ou programas individuais s o integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos Depois dos testes o sistema de software entregue ao cliente 5 Opera o e manuten o 1 Normalmente embora n o necessariamente esta a fase mais longa do ciclo de vida O sistema instalado e colocado em opera o A ma nuten o envolve corrigir erros que n o foram descobertos em est gios anteriores do ciclo de vida melhorando a implementa o das unidades de sistema e aumentando as fun es desse sistema medida que novos requisitos s o descobertos Um est gio somente pode ser iniciado depois que o est gio anterior tenha sido conclu do Por m Sommerville 2011 p 21 afirma que na pr tica esses est gios acabam se sobrepondo alimentando uns aos outros de informa es Por exemplo durante o projeto os problemas com os requisitos s o identificados O que acontece que um processo de software n o Anota es LX 46 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING um modelo linear simples sequencial mas envolve itera es entre as fases Os artefatos de software que s o produzidos em cada uma dessas fases podem ser modificados para refletirem todas as altera es realizadas em cada um deles Pressman 2011 aponta alguns problemas que podem ser encontrados quando o modelo casc
101. e voc goste do que foi colocado aqui A engenharia de software possui uma gama imensa de t picos que n o seria poss vel abordar em cinco unidades como este livro est organizado ent o coloquei os assuntos iniciais sem os quais n o seria poss vel entender todo o contexto da disciplina Se voc gostar da disciplina e quiser se aprofundar pode consultar os livros que cito durante as unidades Neles com certeza voc aprender muitos outros assuntos e poder ter certeza de que a engenharia de software realmente muito importante quando tratamos de software como um todo muito importante que voc n o deixe de realizar as atividades de autoestudo para fixar os conceitos estudados durante a unidade Lembre se de que a unidade seguinte sempre est vinculada com a unidade anterior portanto saud vel que voc entenda todo o conte do de uma unidade para passar para a pr xima Se ainda ficar com d vida procure realizar pesquisas na internet e fazer as leituras complementares indicadas Pode ter certeza que isso o ajudar Este livro est organizado em cinco unidades sendo que todas est o estreitamente relacionadas Na unidade apresentarei alguns conceitos referentes disciplina Voc notar durante a leitura das outras unidades que esses conceitos s o utilizados com frequ ncia ENGENHARIA DE SOFTWARE Educa o a Dist ncia T CESUMAR CENTROUNIVERSIT RIO DE MARING A engenharia de software surgiu d
102. eaitaiianinsiinneiiaididaran a iiaeiai ii desbaste 42 MODELOS DE PROCESSO DE SOFTWARE ssssiisssssrrssrrirrsssnirsssrnrrssnrrrrssnrensssrrrnsrrrennnene 44 ATIVIDADES B SICAS DO PROCESSO DE SOFTWARE sister 54 ESPECIFICA O DE SOFTWARE emgofass tina arrean ranar r ant 55 PROJETO E IMPLEMENTA O DE SOFTWARE iss 57 VALIDA O DE SOFINARE agia soe Gao Gibbon 58 EVOLU O DE SOFTWARE soe o SG ER nnsa nrnarrar reanna n rn 60 UNIDADE III REQUISITOS DE SOFTWARE REQUISITOS DE SOFTWARE 67 REQUISITOS FUNCIONAIS E N O FUNCIONAIS 69 REQUISITOS DE USU RIO eggs se ig E E A 72 REQUISITOS DE SISTEMA 72 O DOCUMENTO DE REQUISITOS DE SOFTWARE 73 REQUISITOS DE QUALIDADE 78 ENGENHARIA DE REQUISITOS ita renren 80 ESTUDO DE VIABILIDADE ita ieeieaiatttta 81 LEVANTAMENTO E AN LISE DE REQUISITOS 83 ESPECIFICA O DE REQUISITOS eee 89 VALIDA O DE REQUISITOS cein aaa 90 UNIDADE IV MODELAGEM DE SISTEMAS O a RR RR 97 MODELAGEM DE SISTEMAS teatrais 99 DIAGRAMA DE CASOS DE USO 101 ESTUDO DE CASO tarte 112 DOCUMENTO DE REQUISITOS F BRICA DE COLCH ES is 112 DIAGRAMA DE CLASSES perpassa a tie 115 RELACIONAMENTOS i Snape a 116 MULTIPLICIDADE assriraira Soeiro tata resta pdisdps joinss dis Aini 119 CLASSE ASSOCIA MVA eiri dp a S 120 ESTUDO DE CASO icici aE E EA A E EE 122 ESTUDODE CASA pci a 123 PASSO A PASSO PARA A ELABORA O DO DIAGRAMA DE CASOS DE USO
103. elemento externo que interaja com o software sendo que o nome do ator identifica qual o papel assumido por ele dentro do diagrama GUEDES 2007 p 38 Um caso de uso sempre iniciado por um est mulo de um ator ocasionalmente outros atores podem participar do caso de uso A figura abaixo apresenta alguns exemplos de atores Cliente Departamento de Cobran a Sistema Financeiro Gerente Exemplos de Atores Casos de Uso De acordo com Booch 2005 p 227 um caso de uso especifica o comportamento de um sistema ou de parte de um sistema referindo se a servi os tarefas ou fun es apresentadas pelo sistema como cadastrar funcion rio ou emitir relat rio de produtos No diagrama de caso de uso n o poss vel documentar os casos de uso e nem a UML oferece um recurso para que isso seja feito por m indicado que cada caso de uso seja documentado demonstrando qual o comportamento pretendido para o caso de uso em quest o e quais fun es ele executar quando for solicitado Essa documenta o dever tamb m ser elaborada de acordo com o documento de requisitos e poder auxiliar o desenvolvedor na Anota es LX 1 02 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING elabora o dos demais diagramas da UML A figura abaixo apresenta alguns exemplos de casos de uso Emitir Relat rio de Produtos Cadastrar Funcion rio Efetuar Venda Exemplos
104. entam se os t picos que voc estudar nesta unidade Modelagem de Sistemas e Diagrama de Casos de Uso Diagrama de Classes CESUMAR CENTROUNIVERSIT RIO DE MARING INTRODU O Caro a aluno a na terceira unidade estudamos sobre os requisitos de um sistema e foi bastante destacada a import ncia de um documento de requisitos Nesta unidade voc ver que a partir do documento de requisitos realizaremos a modelagem de um sistema A modelagem de sistema o processo de elabora o de modelos abstratos de um sistema normalmente representado por meio de um diagrama em que cada um desses modelos apresenta uma vis o ou perspectiva diferente do sistema SOMMERVILLE 2011 p 82 Esses modelos normalmente s o elaborados utilizando se uma nota o gr fica que em nosso caso ser a UML u Unifred Modeling Language De acordo com BOOCH 2005 p 13 a UML uma linguagem padr o para a elabora o da estrutura de projetos de software Ela poder ser empregada para a visualiza o a especifica o a constru o e a documenta o de artefatos que fa am uso de sistemas complexos de software Da mesma forma que os arquitetos elaboram plantas e projetos para serem usados para a constru o de um edificio os engenheiros de software criam os diagramas UML para auxiliar os desenvolvedores de software a construir o software Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 97
105. ente do modelo de processo de software que est sendo utilizado ou seja se estiver sendo utilizado o modelo em cascata ou a abordagem incremental O in cio do projeto se d assim que os requisitos tiverem sido analisados e modelados ou seja assim que a modelagem do sistema tiver sido realizada Com base no documento de requisitos o engenheiro de software na fase de modelagem do sistema dever elaborar os diagramas da UML Unified Modeling Language como por exemplo o Diagrama de Caso de Uso e o Diagrama de Classes Na fase de projeto do sistema o engenheiro de software dever i definir o Diagrama Geral do Sistema ii elaborar as Interfaces com o Usu rio telas e relat rios e iii desenvolver um conjunto de especifica es de casos de uso sendo que essas especifica es devem conter detalhes suficientes para permitir a codifica o Geralmente Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 57 CESUMAR CENTROUNIVERSIT RIO DE MARING durante o projeto o analista de sistemas ter que definir cada componente do sistema ao n vel de detalhamento que se fizer necess rio para a sua implementa o em uma determinada linguagem de programa o A programa o normalmente come a como era de se esperar quando termina a atividade de projeto A programa o ou fase de implementa o de um projeto t pico envolve a escrita de instru es em Java C Cf ou em alguma outra linguagem de program
106. equisitos de qualidade que s o definidos pela Norma ISO IEC 9126 e que tamb m devem ser considerados quando um software est sendo projetado E por fim veremos que a engenharia de requisitos um processo que envolve quatro atividades gen ricas avaliar se o sistema que est sendo projetado ser til para a empresa estudo de viabilidade obter e analisar os requisitos levantamento e an lise especificar esses requisitos convertendo os em um documento de requisitos especifica o de requisitos e finalmente verificar se os requisitos realmente definem o sistema que o cliente deseja valida o Anota es LX 66 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING REQUISITOS DE SOFTWARE Normalmente os problemas que os desenvolvedores de software t m para solucionar s o muitas vezes imensamente complexos e se o sistema for novo entender a natureza desses problemas pode ser muito mais dif cil ainda As descri es das fun es e das restri es s o os requisitos para o sistema e o processo de descobrir analisar documentar e verificar essas fun es e restri es chamado de engenharia de requisitos De acordo com Sommerville 2011 p 57 a ind stria de software n o utiliza o termo requisito de modo consistente Muitas vezes o requisito visto como uma declara o abstrata em alto n vel de uma fun o que o sistema deve fornecer ou de uma restri o do sistema
107. eressante que voc fizesse a leitura novamente do documento antes de analisar o diagrama de classes abaixo Anota es LX 1 22 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING grupo MP ji codigo int codigo int codigo int descricao String descricao String descricao String qtde_est int valor unit int Fornecedor codigo int nome String cidade String numero nota int data emissao int CFOP int ESTUDO DE CASO 2 Neste estudo de caso vou mostrar um novo documento de requisitos agora de um Laborat rio de An lises Cl nicas Com base nesse documento de requisitos vamos elaborar o diagrama de casos de uso e tamb m o diagrama de classes mas dessa vez faremos isso passo a passo Mas antes de come armos a ler o documento de requisitos gostaria que voc imaginasse que foi a um m dico por exemplo um cl nico geral Para te dar um diagn stico preciso e correto esse m dico pediu que voc fizesse uma s rie de exames como por exemplo hemograma glicemia creatinina triglicer deos e urocultura Ele anotou essa lista de exames em um Pedido de Exames e voc de posse desse pedido vai at um laborat rio de an lises cl nicas para fazer os exames nesse caso voc vai at o Laborat rio S o Jo o a que come a o nosso documento de requisitos Anota es SA ENGENH
108. erface do sistema Para que um sistema funcione corretamente necess rio que sejam efetuados v rios testes Explique como o analista deve conduzir esta etapa de testes para que no final o sistema possa ser considerado apto a ser implantado ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 65 CESUMAR CENTROUNIVERSIT RIO DE MARING CONCLUS O Neste livro procurei mostrar a voc a import ncia da disciplina de Engenharia de Software e como ela pode ser aplicada durante o desenvolvimento de um sistema A fim de possibilitar o seu entendimento na unidade foram estudados os conceitos de software e de engenharia de software Mostrei tamb m que podemos ter v rias aplica es para o software desde o software embutido que pode estar na sua m quina de lavar roupas at o software que controla um foguete espacial Por m neste material procurei utilizar exemplos que fazem parte do nosso dia a dia pensando em facilitar o entendimento para problema e da sua poss vel solu o Ainda na unidade tratamos sobre ferramentas CASE que s o softwares que auxiliam o trabalho do desenvolvedor automatizando tarefas que s o realizadas durante o processo de software Outro assunto que estudamos nesta unidade foram alguns conceitos de orienta o a objetos e uma r pida introdu o linguagem de modelagem UML Na unidade Il trabalhamos especificamente com processos de software Mostrei que podem existir diversos modelos de processo
109. es REQUISITOS DE SISTEMA Os requisitos de sistema s o descri es mais detalhadas dos requisitos do usu rio servindo como base para um contrato destinado implementa o do sistema e portanto devem ser uma especifica o completa e consistente de todo o sistema SOMMERVILLE 2007 p 87 Eles s o utilizados pelos engenheiros de software como ponto de partida para o projeto de sistema Antes de qualquer coisa os requisitos de sistema deveriam definir o que o sistema deveria fazer e n o como ele teria de ser implementado por m no que se refere aos detalhes exigidos para especificar o sistema completamente quase imposs vel excluir todas as informa es de projeto H pelo menos duas raz es para isso 1 Uma arquitetura inicial do sistema pode ser definida para ajudar a estruturar a espe cifica o de requisitos 2 Na maioria dos casos os sistemas devem interoperar com outros sistemas exis tentes restringindo assim o projeto em desenvolvimento sendo que muitas vezes essas restri es geram requisitos para o novo sistema De acordo com Sommerville 2011 p 58 os requisitos devem ser escritos em n veis Anota es LX 72 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING diferentes de detalhamento para que diferentes leitores possam us los de formas diferentes Os poss veis leitores para os requisitos de usu rio s o gerentes clientes usu rios finai
110. es a Gg Fornecedores Pedido Vendedores Emiss o Vendedores Pedido Condi es de Pagamento Vendas Produtos Cadastro Fornecedores Nota Fiscal Lista Pre os Cancelamento Nota Fiscal Estoque Atual Emiss o Produtos mais Nota Fiscal Vendidos Fonte a autora O Diagrama de Caso de Uso referente a esse sistema deveria conter pelo menos os seguintes casos de uso Cadastrar Grupos de Produtos Cadastrar Produtos Cadastrar Clientes Cadastrar Vendedores Cadastrar Condi es de Pagamento Cadastrar Fornecedores Cadastrar Pedido Anota es LA 1 42 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING de Compra Efetuar Cancelamento de Pedido de Compra Emitir Pedido de Compra Cadastrar Nota Fiscal de Venda Efetuar Cancelamento de Nota Fiscal de Venda Emitir Nota Fiscal de Venda Emitir Relat rio de Clientes Emitir Relat rio de Fornecedores Emitir Relat rio de Vendedores Emitir Lista de Pre os de Produtos Emitir Relat rio de Estoque Atual de Produtos Emitir Relat rio de Produtos Mais Vendidos Exemplo 2 Diagrama Geral do Sistema para um sistema de Controle de Biblioteca Sistema Biblioteca Cadastros Movimenta es Relat rios Consultas Categoria Empr stimo
111. esentados na primeira unidade pois a UML Unified Modeling Language Linguagem de Modelagem Unificada que utilizaremos para realizar a modelagem baseada no paradigma da orienta o a objetos Nesta pr xima unidade trabalharemos com uma ferramenta CASE para nos auxiliar na elabora o de alguns diagramas e voc ver que o documento de requisitos realmente muito importante Vamos l ENGENHARIA DE SOFTWARE Educa o a Dist ncia 93 CESUMAR CENTROUNIVERSIT RIO DE MARING ATIVIDADE DE AUTOESTUDO 1 Identifique e descreva os quatro tipos de requisitos que podem ser definidos para um sistema Descreve tr s tipos de requisitos n o funcionais que podem ser definidos para um sistema fornecendo exemplos para cada um deles Baseando se no Documento de Requisitos da Locadora de Filmes mostrado como exemplo nesta unidade relacione os requisitos funcionais encontrados no mesmo Descreva detalhadamente as quatro atividades que fazem parte do processo de en genharia de requisitos 94 ENGENHARIA DE SOFTWARE Educa o a Dist ncia UNIDADE IV MODELAGEM DE SISTEMAS Professora Me M rcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Expor a import ncia da modelagem de sistemas Mostrar os conceitos relacionados a diagramas de casos de uso e diagramas de classes Mostrar um estudo de caso no qual s o constru dos os diagramas de casos de uso e de classes Plano de Estudo A seguir apres
112. esso de software Essas etapas b sicas s o i a especifica o dos requisitos do software a ser desenvolvido ii o projeto e a implementa o do software iii a valida o do software e finalmente iv a evolu o do software Nesta unidade abordarei tr s modelos de processo de software mas a literatura traz outros modelos como por exemplo o Rational Unified Proccess Meu objetivo mostrar alguns modelos propostos pela literatura mas ao final dessa unidade voc poder elaborar o seu pr prio modelo colocando as etapas na ordem que voc achar melhor para a sua empresa A unidade Ill bastante espec fica tratando apenas dos conceitos relacionados a requisitos de software j que para o desenvolvimento de um software da forma esperada pelo cliente fundamental que todos os requisitos tenham sido claramente definidos Nesta unidade mostrarei a voc o que um documento de requisitos e porque ele t o importante Um requisito deve estabelecer o que o sistema deve fazer bem como as restri es sobre seu funcionamento e implementa o podendo ser classificado em requisito funcional e n o funcional Os requisitos funcionais dizem respeito aos servi os que o software deve fornecer 8 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING como por exemplo o cadastro dos pacientes de uma cl nica odontol gica a emiss o de um relat rio de vendas J os requisitos n o
113. fessional da ferramenta Mas para quem deseja praticar a UML a vers o gratuita uma boa alternativa apresentando um ambiente amig vel e de f cil compreens o O download das diferentes vers es da ferramenta pode ser feito em lt http www visual paradigm com gt Enterprise Architect esta ferramenta n o possui uma edi o gratuita como as anteriores por m uma das ferramentas que mais oferecem recursos compat veis com a UML 2 Uma vers o Trial para avalia o dessa ferramenta pode ser obtida atrav s do site lt www sparxsystems com au gt CONSIDERA ES FINAIS Nesta primeira unidade foram apresentados alguns conceitos b sicos sobre engenharia de software que ser o utilizados no decorrer de todo o livro por isso muito importante que esses conceitos fiquem bem claros para voc A engenharia de software foi proposta para tentar levar a precis o da engenharia para o desenvolvimento de software pois at aquela poca desenvolver um software era algo que n o podia ser mensurado nem em rela o ao tempo nem em rela o ao custo levando se normalmente muito mais tempo do que o previsto E o que acontecia era que n o se tinha uma regra uma sequ ncia de atividades para o desenvolvimento Voc vai ver na pr xima unidade que para tentar solucionar esse problema os estudiosos da engenharia de software 36 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING propuser
114. foi originada do relacionamento muitos para muitos entre Pedido de Exame e Exame Isso se deve ao fato de que para cada exame esses atributos podem ser diferen tes Por exemplo se o atributo DATA PRONTO tivesse sido armazenado na classe PEDIDO EXAME seria poss vel cadastrar somente uma data em que os exames ficariam prontos Mas na realidade n o isso o que acontece ou seja em uma lista de exames que o paciente precisa realizar pode se ter exames que ficam prontos em 2 dias e outros que ficam prontos em 5 dias 4 Veja que n o foi criada uma classe RESULTADO EXAME pois como somente uma descri o decidiu se armazen la na classe associativa Exame Pedido Exame 5 Note tamb m que na classe Pedido Exame n o aparece o nome do paciente como relacionamos no item 2 desse Passo a Passo Isto porque o nome ser obtido por meio do relacionamento de Pedido Exame com Paciente N o desenhamos o atri buto chave de paciente na classe Pedido Exame mas ele est l ou seja por meio dele que buscaremos o nome do paciente na classe paciente quando precisarmos 6 Ao inv s de termos utilizado o recurso da classe associativa poder amos ter utilizado o relacionamento de agrega o Veja como ficaria ser o mostradas somente algu mas classes as demais n o foram mostradas pois ficariam iguais ao diagrama j mostrado anteriormente Anota es LX 1 30 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE
115. funcionais normalmente est o relacionados s propriedades emergentes do sistema podendo ser aplicados ao sistema como um todo Um exemplo de requisito n o funcional o sistema deve ser desenvolvido em seis meses Todos esses requisitos tanto os funcionais quanto os n o funcionais devem ser claramente definidos no documento de requisitos pois a partir desse documento que o sistema ser modelado projetado implementado ou seja todo o desenvolvimento do sistema ser baseado neste documento Em alguns casos o documento de requisitos pode servir como um contrato entre o cliente e a empresa desenvolvedora do software Para voc ter uma ideia de como um documento de requisitos mostrarei o de uma locadora de filmes na unidade Ill O exemplo bem simples mas cont m detalhes suficientes para a continuidade do processo de desenvolvimento de software Ent o de posse do documento de requisitos come aremos a estudar a pen ltima unidade do nosso livro a unidade que trata da modelagem do sistema Nesta unidade utilizaremos os conceitos de orienta o a objetos e de UML estudados na primeira unidade A modelagem a parte fundamental de todas as atividades relacionadas ao processo de software sendo que os modelos que s o constru dos nesta etapa servem para comunicar a estrutura e o comportamento desejados do sistema a fim de que possamos melhor compreender o sistema que est sendo elaborado Representaremos estes modelos p
116. gem de boas vindas lhe estendo o convite para que caminhe conosco na Comunidade do Conhecimento e vivencie a oportunidade de constituir se sujeito do seu processo de aprendizagem e membro de uma comunidade mais universal e igualit ria Um grande abra o e timos momentos de constru o de aprendizagem Professora Gislene Miotto Catolino Raymundo Coordenadora Pedag gica do NEAD CESUMAR 6 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING APRESENTA O Livro ENGENHARIA DE SOFTWARE Professora Me M rcia Cristina Dadalto Pascutti Prezado a acad mico a com muito prazer que apresento a voc o livro de Engenharia de Software Sou a professora M rcia Cristina Dadalto Pascutti autora deste material e pode ter certeza que o mesmo foi preparado com carinho especial para que voc possa entender o que esta disciplina pode te trazer de benef cio ao longo de sua vida como desenvolvedor de sistemas Ministro esta disciplina em cursos de gradua o h praticamente dezesseis anos Inicialmente a disciplina era chamada de An lise de Sistemas e nos ltimos anos de Engenharia de Software mas sempre com o mesmo objetivo ou seja mostrar ao aluno o processo de desenvolvimento de um software Escrever este material foi um desafio pois preciso escrever de forma clara para que voc querido a aluno a possa entender o meu racioc nio Mas foi uma experi ncia tima e espero qu
117. gra o com a sociedade Diante disso o Cesumar almeja ser reconhecido como uma institui o universit ria de refer n cia regional e nacional pela qualidade e compromisso do corpo docente aquisi o de compe t ncias institucionais para o desenvolvimento de linhas de pesquisa consolida o da extens o universit ria qualidade da oferta dos ensinos presencial e a dist ncia bem estar e satisfa o da comunidade interna qualidade da gest o acad mica e administrativa compromisso social de inclus o processos de coopera o e parceria com o mundo do trabalho como tamb m pelo compromisso e relacionamento permanente com os egressos incentivando a educa o continuada Professor Wilson de Matos Silva Reitor ENGENHARIA DE SOFTWARE Educa o a Dist ncia 5 CESUMAR CENTROUNIVERSIT RIO DE MARING Caro aluno ensinar n o transferir conhecimento mas criar as possibilidades para a sua produ o ou a sua constru o FREIRE 1996 p 25 Tenho a certeza de que no N cleo de Educa o a Dist ncia do Cesumar voc ter sua disposi o todas as condi es para se fazer um competente profissional e assim colaborar efetivamente para o desenvolvimento da realidade social em que est inserido Todas as atividades de estudo presentes neste material foram desenvolvidas para atender o seu processo de forma o e contemplam as diretrizes curriculares dos cursos de gradua o determinadas pelo Minist rio da
118. i es do que o sistema deve fazer os servi os que oferece e as restri es a seu funcionamento Esses requisitos dizem respeito s necessidades dos usu rios para um sistema que deve atender um determinado objetivo como por exemplo cadastrar um pedido de venda ou emitir um relat rio A engenharia de requisitos um processo que engloba as atividades que s o necess rias para criar e manter um documento de requisitos de sistema Essas atividades s o estudo de viabilidade levantamento e an lise de requisitos especifica o de requisitos e finalmente a valida o desses requisitos De acordo com Sommerville 2011 p 59 os requisitos de software s o normalmente classificados como funcionais ou n o funcionais 1 Requisitos funcionais define as fun es que o sistema deve fornecer de como o sistema deve reagir a entradas espec ficas e de como deve se comportar em deter minadas situa es Em alguns casos os requisitos funcionais podem tamb m expli citamente declarar o que o sistema n o deve fazer Exemplos de requisitos funcio nais o software deve possibilitar o c lculo das comiss es dos vendedores de acordo com os produtos vendidos o software deve emitir relat rios de compras e vendas por per odo o sistema deve mostrar para cada aluno as disciplinas em que o mesmo foi aprovado ou reprovado 2 Requisitos n o funcionais I s o os requisitos relacionados utiliza o do software em termos de desempenh
119. ia muito mais pr tico que o usu rio introduzisse ltimo nome inicial do nome intermedi rio t tulo 3 Evidencie ao usu rio o tipo de erro que cometeu e onde est Em muitos sistemas o usu rio fornece uma quantidade substancial de informa es ao sistema para cada evento ou transa o Em um sistema de controle de pedidos por exemplo o usu rio pode especificar o nome do cliente endere o e n mero de telefone bem como informa es sobre itens que est o sendo pedidos desconto aplic vel instru es de embarque e impostos de vendas Todas essas informa es podem ser introduzidas em uma nica tela antes de serem gravadas e certamente o sistema poder determinar em seguida que parte da entrada est errada ou toda ela O importante ter certeza de que o usu rio compreenda a esp cie de erro que foi cometido e onde o erro est localizado n o aceit vel que o sistema simplesmente emita um sinal sonoro e exiba a mensagem M ENTRADA Cada erro presumindo se que haja mais de um deve ser identificado ou com uma mensagem descritiva ou no caso de um sistema on line ressaltando ou codificando em cores os dados errados Dependendo da natureza do sistema e do n vel de sofistica o do usu rio pode ser tamb m importante exibir uma Anota es LA 1 56 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING mensagem explicativa 4 Ofere a ao usu rio um modo de a cance
120. icamente o estoque dos produtos que est o sendo comprados somando no estoque Este cadastro ser realizado pelo Departamento de Compras ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 34 CESUMAR CENTROUNIVERSIT RIO DE MARING Efetue o cadastro das notas fiscais de vendas que s o preenchidas no item 3 atua lizando automaticamente o estoque do produto que est sendo vendido diminuindo do estoque Este cadastro ser realizado pelo Departamento de Vendas Calcule automaticamente as comiss es dos vendedores de acordo com o de cada um deles Os demais cadastros ser o efetuados pelo Departamento de Vendas O sistema deve emitir os seguintes relat rios e Lista de pre o de produtos por grupo de produtos Este relat rio ser solicitado e recebido pelo Departamento de Compras e pelo Departamento de Vendas Grupo 99 XXXXXXXXXXXXXXXXXXXX C digo Produto Nome do Produto Pre o Unit rio 999999 XXXXXXXXXXXXXXXXXXXXXXXX 999 999 99 999999 XXXXXXXXXXXXXXXXXXXXXXXX 999 999 99 Quantidade dispon vel em estoque por produto e grupo de produto Este rela t rio ser solicitado e recebido pelo Departamento de Compras e pelo Departamento de Vendas Grupo 99 XXXXXXXXXXXXXXXXXXXX C digo Produto Nome do Produto Estoque Atual 999999 XXXXXXXXXXXXXXXXXXXXXXXX 9 999 99 999999 XXXXXXXXXXXXXXXXXXXXXXXX 9 999 99 e Compras di rias sint tico Este relat rio ser solicitado e recebido pelo Depar tamento de Compras
121. inuados antes de chegarem ao fim 25 Porcentagem de projetos acima do custo esperado 60 Atraso m dio nos projetos um ano Os modelos constru dos na fase de an lise devem ser cuidadosamente validados e verificados O objetivo da valida o assegurar que as necessidades do cliente est o sendo atendidas Nessa atividade os analistas apresentam os modelos criados para representar o sistema aos futuros usu rios para que esses modelos sejam validados Anota es LA 1 00 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING A verifica o tem o objetivo de analisar se os modelos constru dos est o em conformidade com os requisitos definidos Na verifica o dos modelos s o analisadas a exatid o de cada modelo em separado e a consist ncia entre os modelos A verifica o uma etapa t pica da fase de projeto que a pr xima etapa do desenvolvimento de software Caro a aluno a utilizaremos a UML para realizar a modelagem de sistemas e na primeira unidade estudamos alguns conceitos relacionados orienta o a objetos e tamb m fizemos uma introdu o linguagem UML Lembre se que os artefatos de software produzidos durante a modelagem servir o de base para a fase seguinte do ciclo de desenvolvimento de sistemas ou seja a fase projeto DIAGRAMA DE CASOS DE USO O diagrama de casos de uso Use Case Diagram dentre todos os diagramas da UML o mais abstrato flex
122. ist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Vamos estudar detalhadamente cada uma das atividades mencionadas acima durante a nossa disciplina inclusive utilizando ferramentas automatizadas ferramentas CASE j estudadas em nossa unidade para nos auxiliar na elabora o dos diversos documentos que ser o necess rios Para Sommerville 2011 p 19 os processos de software s o complexos e como todos os processos intelectuais e criativos dependem de pessoas para tomar decis es e fazer julgamentos N o existe um processo ideal a maioria das organiza es desenvolve os pr prios processos de desenvolvimento de software Mas o que acontece que nem sempre as empresas aproveitam as boas t cnicas da engenharia de software em seu desenvolvimento de software E normalmente o software n o atende aos requisitos do usu rio acaba demorando mais tempo para ser desenvolvido do que o previsto aumentando assim o valor do custo do software As atividades mencionadas por Sommerville podem ser organizadas pelas empresas da forma como ela achar melhor por m importante ressaltar que todas essas atividades s o de extrema import ncia e o processo de software adotado pela empresa n o deve deixar de considerar nenhuma das etapas Leitura Complementar O processo de desenvolvimento de software e a utiliza o de ferramentas CASE Por Maria Clara dos Santos Pinto Silveira A presente disserta o sit
123. lar parte de uma transa o e b cancelar toda uma transa o ing nuo pressupor que o usu rio sempre terminar a introdu o de uma transa o inteira sem ter interrompido O usu rio pode ter introduzido um nome e endere o de cliente antes de descobrir que estava trabalhando com o cliente errado ele desejar ser capaz de anular o que foi digitado e come ar de novo Ou o usu rio pode haver terminado a introdu o da maior parte das informa es do cliente e ent o perceber que escreveu mal o primeiro nome do cliente ele vai querer poder retornar aquele elemento de dados e corrigi lo sem perder todas as outras informa es j digitadas 5 Providencie um mecanismo pr tico de socorro Nos sistemas on line cada vez mais importante oferecer ao usu rio um mecanismo pr tico para a obten o de informa es sobre como usar o sistema Em alguns casos a facilidade do socorro simplesmente fornecer uma explica o se o usu rio cometer um erro em outros casos o socorro poderia ser usado para explicar os detalhes de v rios comandos ou transa es dispon veis ao usu rio Existem muitos meios de implementar essa facilidade e o analista e os usu rios devem examinar diversos exemplos t picos antes de tomar uma decis o 6 Se o seu sistema estiver empenhado em um processamento muito prolongado exiba uma mensagem para que o usu rio n o pense que o sistema caiu Se o seu sistema tiver de executar c lcul
124. lembrado do come o do nosso estudo de caso Esse cadastro ser realizado pelas recep cionistas Emitir a ficha do paciente contendo todos os dados cadastrados Este relat rio ser solicitado e recebido tanto pelas recepcionistas quanto pelo departamento adminis trativo do laborat rio Emitir relat rio com todos os exames que o laborat rio realiza com o c digo descri o procedimentos e valor de cada exame agrupados por grupo de exame devendo ser impresso neste relat rio o c digo e a descri o do grupo Este relat rio ser solicitado e recebido pelas recepcionistas Emitir o pedido do exame em 3 vias com todos os dados do pedido do exame O re lat rio ser emitido pela recepcionista sendo que a 1 via ser entregue ao paciente comprovante da entrega do exame a 2 via ser entregue para o departamento de faturamento para a cobran a dos exames dos conv nios e a 3 via para os bioqui micos para a realiza o dos exames e Emitir relat rio com os resultados dos exames por pedido de exame contendo o nome do paciente data e hor rio do exame da realiza o do exame nome do m dico que solicitou o exame nome do conv nio o nome e o resultado de cada exame realizado no caso de ter sido mais de um Esse relat rio ser solicitado pela recepcionista e entregue ao paciente n o necess rio que a recepcionista fique com esse relat rio PASSO A PASSO PARA A ELABORA O DO DIAGRAMA DE CASOS
125. lida o observada depois da implementa o quando o sistema operacional testado A atividade de testes uma etapa muito importante para o desenvolvimento de software normalmente inserindo tantos erros em um produto quanto a pr pria implementa o Por outro lado caso um erro seja descoberto durante o desenvolvimento o custo para sua corre o ser muito menor do que se esse mesmo erro tivesse sido descoberto somente na fase de manuten o O processo de testes pode ocupar grande parte do cronograma de desenvolvimento de sistema dependendo do cuidado com que tenham sido executadas as atividades iniciais de especifica o projeto e implementa o O que voc precisa saber sobre testes como analista de sistemas Em muitos casos o analista de sistemas trabalha em estreita associa o com o usu rio para desenvolver um conjunto completo e abrangente de casos de testes Esse processo de desenvolvimento de casos de testes de aceita o pode ser executado em paralelo com as atividades de implementa o de projeto e programa o de modo que quando os programadores tiverem terminado seus programas e executado seus pr prios testes locais a equipe usu rio analista estar pronta para seus pr prios casos de testes YOURDON 1990 p 539 TIPOS DE TESTES Para Yourdon 1990 p 540 existem diferentes estrat gias de testes por m as duas mais conhecidas s o os testes bottom up e os top down A abordagem bottom up come a po
126. lme o c digo da fita o nome do cliente o telefone do cliente a data de loca o a data prevista para devolu o e o n mero de dias em atraso Anota es 15 ENGENHARIA DE SOFTWARE Educa o a Dist ncia T1 CESUMAR CENTROUNIVERSIT RIO DE MARING e Relat rio dos filmes mais locados onde conste o c digo do filme o nome do filme a descri o do g nero e o n mero total de loca es O relat rio deve ser agrupado por m s ano ou seja para um determinado m s ano devem ser emitidos os 10 dez filmes mais locados e Relat rio de Reservas por per odo onde conste o c digo do cliente o nome do cliente o telefone do cliente o c digo do filme reservado o nome do filme a data em que foi feita a reserva data em que o cliente telefonou para a locadora dizendo que queria fazer a reserva e Relat rio dos valores das loca es mensais Dever mostrar os valores das loca es de determinado m s separado por data e somat ria de valores de cada dia somando se assim ao final uma totalidade de loca es Nele deve se conter a data e a soma das loca es desta data Todos os relat rios servir o para o processo de tomadas de decis es nos quais os Administradores poder o obter informa es sobre o andamento da locadora REQUISITOS DE QUALIDADE Quanto mais r gidos os requisitos de qualidade e mais complexo o software a ser desenvolvido aumenta se a necessidade de se aplicar teorias e ferramentas que gara
127. ltar que mesmo as empresas que possuem um processo de software bem definido e documentado para determinados softwares que ela desenvolve pode ser utilizado outro processo de software ou seja dependendo do software a ser desenvolvido pode ser utilizado um determinado processo de software Na pr xima se o veremos alguns modelos de processo de software e veremos tamb m que poss vel a empresa adotar um processo de software pr prio que atenda as suas necessidades MODELOS DE PROCESSO DE SOFTWARE Como foi discutido anteriormente um processo de software composto por um conjunto de etapas que s o necess rias para que um software seja produzido Sommerville 2007 diz que um modelo de processo de software uma representa o abstrata simplificada de um processo de software Os modelos de processo incluem as atividades que fazem parte do processo de software voc est lembrado das atividades descritas no item anterior os artefatos de software que devem ser produzidos em cada uma das atividades documentos e tamb m os pap is das pessoas envolvidas na engenharia de software Al m disso cada modelo de processo representa um processo a partir de uma perspectiva particular de uma maneira que proporciona apenas informa es parciais sobre o processo Anota es L 44 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Na literatura existem diversos modelos de processo de software
128. m como os itens que comp em cada um deles O principal objetivo do DGS mostrar como esses m dulos e seus itens est o relacionados Cada item que aparece no diagrama deve aparecer como um caso de uso no Diagrama de Casos de Uso Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 39 CESUMAR CENTROUNIVERSIT RIO DE MARING Depois que o DGS est definido pode se partir para a defini o das interfaces com o usu rio tanto as de v deo quanto as impressas Para cada item que aparece no DGS voc deve pensar em como o usu rio ir interagir com o sistema Cada dado que dever ser informado ao sistema ser por meio de uma interface que isso ir acontecer portanto quando a interface for definida dever ser verificado se os dados colocados na mesma est o definidos no Diagrama de Classes A interface do usu rio um dos elementos mais importantes de um sistema e quando essa interface mal projetada a capacidade de o usu rio aproveitar todo o potencial do sistema pode ser seriamente afetada portanto uma interface fraca pode fazer com que toda uma aplica o falhe PRESSMAN 2011 p 313 Nesta unidade na se o Formatos de Entradas Sa das s o mostradas algumas diretrizes importantes que o ajudar o a definir uma interface humana que seja de mais f cil compreens o para o usu rio Depois que a interface foi definida e que o software foi implementado em alguma linguagem de programa o chegou
129. menda se vale a pena ou n o realizar o processo de engenharia de requisitos e consequentemente o processo de desenvolvimento de sistemas Ap s o estudo de viabilidade parte se para a descoberta dos requisitos ou seja realizado o levantamento e a an lise dos requisitos envolvendo diferentes tipos de pessoas stakeholders na organiza o Existem diversas formas para que esse levantamento seja realizado al m da entrevista que foi mostrada nesta unidade A entrevista a forma mais utilizada por isso optamos em descrev la A terceira atividade do processo de engenharia de requisitos a convers o dos requisitos levantados em uma forma padr o ou seja em um documento de requisitos de software Por meio do exemplo mostrado que foi um documento de requisitos para uma locadora de filmes pode se perceber que ele deve trazer detalhes suficientes para dar continuidade ao processo de desenvolvimento do sistema E finalmente a ltima atividade a verifica o de que os requisitos realmente definem o sistema que o cliente quer ou seja deve ser realizada a valida o dos requisitos anotados no documento de requisitos Note que nem sempre f cil validar os requisitos pois s vezes o pr prio cliente n o sabe definir com precis o o que ele deseja o que acaba dificultando essa etapa Na pr xima unidade vamos conhecer como se d o processo de modelagem de um sistema e vamos usar os conceitos de orienta o a objetos apr
130. mentos gr ficos que possuem um significado pr definido Apesar de um diagrama conseguir expressar diversas informa es de forma gr fica em diversos momentos h a necessidade de adicionar informa es na forma de texto com o objetivo de explicar ou definir certas partes desse diagrama A mode lagem de um sistema em forma de diagrama juntamente com a informa o textual associada formam a documenta o de um sistema de software O r pido crescimento da capacidade computacional das m quinas resultou na de manda por sistemas de software cada vez mais complexos que tirassem proveito de tal capacidade Por sua vez o surgimento desses sistemas mais complexos resultou na necessidade de reavalia o da forma de desenvolver sistemas Desde o apareci mento do primeiro computador at os dias de hoje as t cnicas para constru o de sistemas computacionais t m evolu do para suprir as necessidades do desenvolvi mento de software D cada de 1950 60 os sistemas de software eram bastante simples e dessa forma as t cnicas de modelagem tamb m Era a poca dos fluxogramas e diagramas de m dulos D cada de 1970 nessa poca houve uma grande expans o do mercado compu tacional Sistemas complexos come avam a surgir e por consequ ncia modelos Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 99 CESUMAR CENTROUNIVERSIT RIO DE MARING mais robustos foram propostos Nesse per odo surge a programa o es
131. n 2012 Saiba mais sobre o Assunto Modelos de Processos de Engenharia de Software lt http xps project googlecode com svn history r43 trunk outros 02 Artigo pdf gt LS Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 53 CESUMAR CENTROUNIVERSIT RIO DE MARING ATIVIDADES B SICAS DO PROCESSO DE SOFTWARE Caro a aluno a estudando os modelos de processo de software apresentados anteriormente poss vel notar que algumas atividades est o presentes em todos eles somente s vezes essas atividades est o organizadas de forma diferente dependendo do processo de software que est sendo considerado Sommerville 2011 p 24 afirma que no modelo cascata essas atividades s o organizadas de forma sequencial ao passo que no desenvolvimento incremental as mesmas s o intercaladas A forma como essas atividades ser o realizadas depende do tipo de software das pessoas e da organiza o envolvida S o quatro as atividades b sicas do processo de software especifica o projeto e implementa o valida o e evolu o E a partir de agora iremos detalhar de forma gen rica sem considerar um processo de software em espec fico cada uma dessas atividades 54 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING Leitura Complementar ESTUDO DO CICLO DE VIDA DO SOFTWARE EM UMA EMPRESA DE DESENVOLVIMENTO DE SISTEMAS Por Fabr cio Luis Ma
132. n o cumprimento dos prazos estabelecidos para o seu desenvolvimento at a falta de qualidade do software desenvolvido Um software n o pode ser desenvolvido de qualquer jeito sem seguir crit rios sem que se saiba qual o pr ximo passo a ser dado Por isso que os conceitos relacionados engenharia de software devem ser utilizados Hoje em dia a empresa precisa definir qual o seu processo de software Nesta unidade voc aprender o que um processo de software e conhecer alguns modelos de processo que j existem em nossa literatura e que s o utilizados por muitas empresas Esses modelos s o modelo em cascata desenvolvimento incremental e engenharia de software baseada em componentes Mas importante ressaltar que n o preciso seguir um Anota es SA ENGENHARIA DE SOFTWARE Educa o a Dist ncia 41 CESUMAR CENTROUNIVERSIT RIO DE MARING desses modelos que j est o prontos ou seja a empresa que vai desenvolver software pode criar o seu pr prio modelo imprescind vel que esse modelo seja seguido Existem algumas atividades b sicas que fazem parte de um processo de software Estudaremos cada uma dessas atividades especifica o de software projeto e implementa o de software valida o de software e evolu o de software Voc perceber que os modelos de processo de software apresentados nesta unidade possuem todas essas atividades e que s vezes a atividade possui um nome diferente ma
133. necess rio criar uma classe associativa para guardar os objetos envolvidos nessa associa o Na classe associativa s o definidos o conjunto de atributos que participam da associa o e n o s classes que participam do relacionamento Neste caso pelo menos os atributos chave devem fazer parte da classe associativa por m a classe associativa tamb m pode possuir atributos pr prios Uma classe associativa representada por uma reta tracejada partindo do meio da associa o e atingindo uma classe A figura abaixo apresenta um exemplo de classe associativa que 1 20 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING possui atributos pr prios al m dos atributos chave das classes que participam da associa o s que nesse caso esses atributos chave n o s o representados no diagrama nome int e E area int E Disciplina Curso P nome int 5 i I i Disciplina Curso carga horaria int serie int Exemplo de classe associativa Neste exemplo uma inst ncia da classe Curso pode se relacionar com muitas inst ncias da classe Disciplina e uma inst ncia da classe Disciplina pode se relacionar com muitas inst ncias da classe Curso Como existe a multiplicidade muitos nas extremidades de ambas as classes da associa o n o h como reservar atributos para armazenar as informa es decorrentes da associa o pois n o h como determinar um limite para a qua
134. ngenharia de requisitos a fonte mais importante para o levantamento dos requisitos desde que o entrevistado confie no entrevistador A sumariza o durante e no final da entrevista necess ria primeiro para garantir que toda informa o apresentada foi anotada e segundo que foi corretamente entendida Antes de tentar uma entrevista o engenheiro de software deve prepar la a Comece por definir os objetivos Verifique a documenta o formal e desenvolva um esquema do sistema existente ou proposto Identifique quest es partes omitidas e am b guas Estes fatos ou componentes desconhecidos representam um esbo o inicial dos objetivos Pode ser necess rio entrevistar v rias pessoas para atingir o objetivo b Selecionar a pessoa ou grupo a ser entrevistado claro que voc quer encontrar a pessoa que melhor possa responder sobre o assunto Pode se encontr la utilizando o organograma uma an lise do fluxo de trabalho ou uma lista de distribui o de relat rios Comece pelo organograma e pelo gerente que parece ser o melhor para responder s quest es Al m disso as pessoas ficam menos hesitantes se souberem que a entrevista foi autorizada pelo chefe c Ler a documenta o relevante conhecer a posi o e as responsabilidades do entrevis tado ocupar se com documentos ou procedimentos relevantes d Preparar quest es espec ficas Selecione quest es espec ficas que podem ser respon didas Desenvolva uma lista d
135. nharia de software vamos utilizar a ferramenta Astah que voc pode baixar gratuitamente no endere o mencionado nesta unidade Sua instala o bastante simples e voc j pode deixar a ferramenta instalada para uso nas pr ximas unidades Estudamos tamb m v rios conceitos de orienta o a objetos que utilizaremos em nossa disciplina e com certeza voc tamb m vai utilizar quando for estudar por exemplo alguma linguagem orientada ao objeto como Java Portanto o entendimento desses conceitos ser de suma import ncia para todo o curso E finalmente apresentei a voc um breve hist rico do que a UML e como ela foi concebida Utilizaremos a linguagem UML para a elabora o de diversos diagramas Note que essa uma linguagem padr o universal ou seja um diagrama produzido em nossa disciplina pode ser lido por algu m que conhe a UML e que esteja do outro lado do mundo Essa primeira unidade foi somente um aperitivo Agora vamos passar a estudar assuntos espec ficos da disciplina e voc vai perceber que a engenharia de software muito importante ENGENHARIA DE SOFTWARE Educa o a Dist ncia 37 CESUMAR CENTROUNIVERSIT RIO DE MARING para o desenvolvimento de um software ATIVIDADE DE AUTOESTUDO 1 Uma classe um conjunto de objetos que compartilham os mesmos atributos m to dos e relacionamentos Sendo assim a Explique o que significa instanciar uma classe b Descreva o que s o atributos 2
136. nistrativas e o atendimento a seus pacientes e neste caso voc vai demorar bem menos no laborat rio pois os processos estar o automatizados Para tanto o novo sistema deve e Permitir o cadastro dos pacientes do laborat rio com todos os dados preenchidos hoje na ficha de cadastro Esse cadastro ser realizado pelas recepcionistas e Permitir o cadastro dos exames que o laborat rio pode realizar Cada exame per tence a um Grupo de Exames Por exemplo o exame HEMOGRAMA pertence ao grupo SANGUE Para cada exame preciso saber o seu c digo descri o valor e procedimentos para a realiza o do mesmo Por exemplo hemograma deve estar em jejum Esse cadastro ser realizado pelos Bioqu micos e Permitir o cadastro dos pedidos de exames dos pacientes necess rio saber qual o nome do paciente o nome do m dico que est solicitando os exames o nome Anota es LA 1 24 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING do conv nio que o paciente ir utilizar para este pedido data e hor rio dos exames aten o cada exame pode ser realizado em datas e hor rios diferentes os nomes dos exames a serem feitos data e hor rio em que cada exame ficar pronto aten o cada exame pode ficar pronto em uma data e hor rio diferente e o valor de cada um deles Lembrando que o m dico pode solicitar mais de um exame em cada pedido no seu caso o m dico solicitou 5 exames Est
137. ntagens 1 se o cliente mudar seus requisitos o custo ser reduzido pois a quantidade de an lise e documenta o a ser refeita menor do que no modelo em cascata 2 mais f cil obter um retorno dos clientes sobre o desenvolvimento que foi feito pois os clientes v o acompanhando o desenvolvimento Anota es LX 48 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING do software medida que novas vers es s o apresentadas a eles 3 os clientes podem come ar a utilizar o software logo que as vers es iniciais forem disponibilizadas o que n o acontece com o modelo cascata Entretanto a partir de uma perspectiva de engenharia e de gerenciamento existem alguns problemas 1 O processo n o vis vel os gerentes necessitam que o desenvolvimento seja regu lar para que possam medir o progresso Se os sistemas s o desenvolvidos rapidamente n o vi vel produzir documentos que reflitam cada vers o do sistema 2 Os sistemas frequentemente s o mal estruturados a mudan a constante tende a corromper a estrutura do software Incorporar modifica es no software torna se cada vez mais dif cil e oneroso 3 Podem ser exigidas ferramentas e t cnicas especiais elas possibilitam r pido desenvolvimento mas podem ser incompat veis com outras ferramentas ou t cnicas e relativamente poucas pessoas podem ter a habilita o necess ria para utiliz las Para sistem
138. ntam que esses requisitos sejam satisfeitos A Norma ISO The International Organization for Standardization EC The International Electrotechnical Commission 9126 define seis caracter sticas de qualidade de software que devem ser avaliadas Funcionalidade a capacidade de um software fornecer funcionalidades que atendam as necessidades expl citas e impl citas dos usu rios dentro de um determinado contexto de uso Usabilidade 1 conjunto de atributos que evidenciam o esfor o necess rio para a utiliza o do software Confiabilidade indica a capacidade do software em manter seu n vel de desempenho sob determinadas condi es durante um per odo de tempo estabelecido Anota es LX 78 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING Efici ncia indica que o tempo de execu o e os recursos envolvidos s o compat veis com o n vel de desempenho do software Manutenibilidade conjunto de atributos que evidenciam o esfor o necess rio para fa zer modifica es especificadas no software incluindo tanto as melhorias extens es de funcionalidades quanto as corre es de defeitos falhas ou erros Portabilidade indica a capacidade do software de ser transferido de um ambiente para outro A ISO IEC formam o sistema especializado para padroniza o mais conhecido no mundo Voc pode obter mais informa es atrav s do endere o lt http www iso org iso iso cata logue c
139. ntidade de disciplinas que um curso pode ter e nem h como saber em quantos cursos uma disciplina pode pertencer Assim preciso criar uma classe para guardar essa informa o al m das informa es pr prias da classe que s o a carga hor ria da disciplina no curso e tamb m a qual s rie essa disciplina estar vinculada naquele curso Os atributos chave das classes Curso e Disciplina s o transmitidos de forma transparente pela associa o n o sendo portanto necess rio escrev los como atributos da classe associativa Segundo Guedes 2007 p 61 as classes associativas podem ser substitu das por classes normais que neste caso s o chamadas de classes intermedi rias mas que desempenham Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 21 CESUMAR CENTROUNIVERSIT RIO DE MARING exatamente a mesma fun o das classes associativas A figura abaixo mostra o mesmo exemplo da figura anterior por m com a classe intermedi ria ao inv s da classe associativa Disciplina Curso nome int carga horaria int E a RA nome int area int serie int E B EE Exemplo de classe intermedi ria ESTUDO DE CASO Para mostrar um diagrama de classes vamos utilizar o mesmo documento de requisitos utilizado para demonstrar o diagrama de casos de uso ou seja o documento de requisitos da F brica de Colch es N o vou colocar novamente o documento aqui mas seria int
140. o tamb m poss vel cadastrar os fornecedores que fornecem o produto ENGENHARIA DE SOFTWARE Educa o a Dist ncia 145 CESUMAR CENTROUNIVERSIT RIO DE MARING T Cadastro de Produtos 0 gt Codigo Descri o Marca un Pre o Custo Rs Pre o Venda Este bot o um BOT O DE ATALHO que chamar o cadastro de marcas caso a marca de determinado produto n o esteja cadastrada Desta forma o usu rio n o ter que sair do cadastro de produto chamar o cadastro de marcas e depois chamar novamente a tela de cadastro de produtos e Tela de Cadastro de Filmes nesta tela o usu rio poder informar os dados do filme com seu g nero e categoria e todos os atores que fazem parte do elenco do filme Note que os atores est o em uma grade em que poss vel cadastrar v rios atores Anota es LX 1 46 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Cadastro de Filmes vlaje x ea e Tela de Venda nesta tela poss vel lan ar v rios produtos em uma mesma venda pois medida que o lan amento do produto efetuado e o usu rio pressiona a tecla TAB uma nova linha acrescentada na grade de Produtos O valor total de cada produto bem como o total geral da venda devem ser calculados automaticamente pelo sistema Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 147 CESUMAR CENTROUN
141. o confiabilidade seguran a usabilidade e portabilidade entre outros Exemplos de requisitos n o funcionais o sistema deve ser protegido para acesso apenas de usu rios autorizados o tempo de resposta do sistema n o deve ultrapassar 20 segundos o tempo de desenvolvimento n o deve ultrapassar doze meses Contudo a diferencia o entre esses dois tipos de requisitos n o t o clara como sugerem as defini es acima Um requisito referente prote o pode parecer ser um requisito n o Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 69 CESUMAR CENTROUNIVERSIT RIO DE MARING funcional Por m quando desenvolvido com mais detalhes pode levar a outros requisitos que s o claramente funcionais como a necessidade de incluir recursos de autoriza o de usu rios no sistema SOMMERVILLE 2011 p 59 Portanto embora seja interessante separar os requisitos em funcionais e n o funcionais devemos lembrar que essa na verdade uma distin o artificial O que muito importante que os requisitos sejam eles funcionais ou n o funcionais sejam claramente definidos Requisitos funcionais Os requisitos funcionais devem descrever detalhadamente os servi os e a funcionalidade que devem ser fornecidas pelo sistema indicando suas entradas e sa das exce es etc Esses requisitos podem ser expressos de diversas maneiras com diferentes n veis de detalhes A imprecis o na especifica o de requisitos
142. o do envio e recebimento de mensagens Um relacionamento de associa o demonstra que o ator utiliza se da funcionalidade representada pelo caso de uso Esse tipo de relacionamento representado por uma reta ligando o ator ao caso de uso Pode ser que essa reta possua em sua extremidade uma seta que indica a navegabilidade dessa associa o ou seja se as informa es s o fornecidas pelo ator ao caso de uso nesse caso a seta aponta para o caso de uso se s o transmitidas pelo caso de uso ao ator nesse caso a seta aponta para o ator ou ambos neste ltimo caso a reta n o possui setas GUEDES 2007 p 40 A figura abaixo representa uma associa o entre um ator e um caso de uso em que o ator fornece uma informa o para o caso de uso Calcular empr stimo pessoal Correntista Associa o entre um ator e um caso de uso Veja o exemplo abaixo Nele est sendo mostrado que o ator Gerente Administrativo recebe o Relat rio de Vendas por Per odo note que ele n o solicita a emiss o do relat rio ele somente recebe o relat rio Emitir relat rio de vendas por per odo Gerente Administrativo Associa o entre um ator e um caso de uso Anota es LX 1 04 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Neste outro exemplo percebemos que o ator denominado Submissor utiliza de alguma forma o servi o de Realizar Submiss o e que a informa
143. o faz com que a classe possua o atributo codChefe para armazenar o c digo do funcion rio que respons vel pela inst ncia do funcion rio em quest o Desse modo ap s consultar uma inst ncia da classe funcion rio pode se utilizar o atributo codChefe da inst ncia consultada para pesquisar por outra inst ncia da Classe GUEDES 2007 p 54 Associa o Bin ria A associa o bin ria conecta duas classes por meio de uma reta que liga uma classe a outra A figura abaixo demonstra um exemplo de associa o bin ria nome String sexo char nome String data nascimento Date UF String endereco String E DDD int CER mi Exemplo de associa o bin ria Neste exemplo um objeto da classe Cidade pode se relacionar ou n o com inst ncias da classe Cliente conforme demonstra a multiplicidade 0 ao passo que se existir um objeto da classe Cliente ele ter que se relacionar com um objeto da classe Cidade pois como n o foi definida a multiplicidade na extremidade da classe Cidade significa que ela 1 1 Logo depois da explica o sobre os relacionamentos em um diagrama de classes explicaremos o conceito de multiplicidade Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 1 T CESUMAR CENTROUNIVERSIT RIO DE MARING Agrega o A agrega o corresponde a um tipo especial de associa o utilizada para expressar um relacionamento todo parte Ou seja as informa
144. o referente a esse processo trafega nas duas dire es Realizar submiss o Submissor Associa o entre um ator e um caso de uso Generaliza o J explicamos o conceito de generaliza o especializa o quando falamos sobre heran a Aqui no diagrama de casos de uso tamb m aplicamos esse conceito ou seja o relacionamento de generaliza o entre casos de uso pode ocorrer quando existirem dois ou mais casos de usos com caracter sticas semelhantes apresentando pequenas diferen as entre si Quando isso acontece define se um caso de uso geral que dever possuir as caracter sticas compartilhadas por todos os casos de uso em quest o e ent o relacionamos esse caso de uso geral com os casos de uso espec ficos que devem conter somente a documenta o das caracter sticas espec ficas de cada um deles Dessa forma evita se reescrever toda a documenta o para todos os casos de uso envolvidos porque toda a estrutura de um caso de uso generalizado herdada pelos casos de uso especializados incluindo quaisquer poss veis associa es que o caso de uso generalizado possua A associa o representada por uma reta com uma seta mais grossa partindo dos casos de uso especializados e atingindo o caso de uso geral como mostra a figura abaixo GUEDES 2007 p 40 Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 05 CESUMAR CENTROUNIVERSIT RIO DE MARING Abrir Conta Comum Abrir Conta
145. o sistema como a capacidade dos dispositivos de E S entrada sa da e as representa es de dados utilizadas nas interfaces de sistema SOMMERVILLE 2011 p 60 Os requisitos n o funcionais surgem conforme a necessidade dos usu rios em raz o de restri es de or amento de pol ticas organizacionais pela necessidade de interoperabilidade com outros sistemas de software ou hardware ou devido a fatores externos como por exemplo regulamentos de seguran a e legisla o sobre privacidade Sommerville 2011 p 61 faz uma classifica o dos requisitos n o funcionais em requisitos de produto requisitos organizacionais e requisitos externos Os requisitos de produto s o aqueles que especificam o comportamento do produto podendo ser subdivididos em requisitos de usabilidade de efici ncia de confian a e de prote o Os requisitos organizacionais s o aqueles derivados das pol ticas e procedimentos da organiza o do cliente e do desenvolvedor e s o subdivididos em requisitos ambientais operacionais e de desenvolvimento Finalmente os requisitos externos abrangem todos os requisitos que procedem de fatores externos ao sistema e seu processo de desenvolvimento e s o subdivididos em requisitos reguladores ticos e legais Os requisitos funcionais e n o funcionais deveriam ser diferenciados em um documento de requisitos por m na pr tica n o f cil fazer essa distin o Em nossos documentos de requisitos nos preocuparem
146. o software Essa evolu o necess ria para que o software continue sendo til ao usu rio para que ele continue atendendo as suas necessidades Se um software tiver uma vida longa passar por manuten es durante esse per odo e para que o mesmo continue manuten vel vimos que necess rio manter a aplica o das t cnicas de engenharia de software pois nem sempre quem desenvolve quem vai dar manuten o no software Com isso chegamos ao final das atividades b sicas do processo de software Espero que voc tenha conseguido entender os conceitos relacionados a essas atividades pois se voc entendeu conseguir entender qualquer processo de software que possa vir a ser adotado pela empresa que voc trabalha ou trabalhar como desenvolvedor a ATIVIDADE DE AUTOESTUDO 1 Baseando se no Documento de Requisitos Laborat rio de An lises Cl nicas mos trado na unidade IV estudo de caso 2 a Elabore o Diagrama Geral do Sistema 1 64 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING b Elabore as Interfaces de V deo dos seguintes casos de uso Cadastrar exames cadastrar m dicos e cadastrar resultados de exame c Elabore as telas de filtros dos relat rios de Ficha de Paciente e Relat rio de Exame d Elabore o layout dos relat rios de Ficha de Paciente e Exame Explique quatro diretrizes que devem ser levadas em considera o no desenvolvi mento da int
147. o uma subclasse derivada n o necess rio redeclarar os atributos e m todos j definidos ou seja por meio da heran a a subclasse os herda automaticamente permitindo a reutiliza o do c digo j pronto Assim preciso somente declarar os atributos ou m todos restritos da subclasse tornando o processo de desenvolvimento mais gil al m de facilitar as manuten es futuras pois em caso de Anota es LA 28 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING uma altera o ser necess rio somente alterar o m todo da superclasse para que todas as subclasses estejam tamb m atualizadas A figura abaixo apresenta um exemplo de heran a explicitando os pap is de superclasse e subclasse e apresentando tamb m o s mbolo de heran a da UML uma linha que liga as classes com um tri ngulo tocando a superclasse nome String endereco String cidade String UF String CEP int IncluirNovoCliente void AtualizarCliente void CPF int CNPJ int RG int inscricao_estadual String sexo char razao social String data nascimento Date ValidarCPF void ValidadeCNPJ void Exemplo de Heran a generaliza o especializa o Fonte a autora A figura acima mostra a superclasse Cliente com os atributos nome endere o cidade UF e CEP e os m todos IncluirNovoCliente e AtualizarCliente
148. onam apresentando uma vis o est tica de como essas classes est o organizadas preocupando se apenas em definir sua estrutura l gica GUEDES 2007 p 52 Ainda conforme Guedes 2007 p 52 um diagrama de classes pode ser utilizado para modelar o modelo l gico de um banco de dados parecendo se neste caso com o Diagrama de Entidade Relacionamento Modelo Entidade Relacionamento que voc estudar na disciplina de Banco de Dados No entanto deve ficar bem claro que o diagrama de classes n o utilizado unicamente para essa finalidade e mais importante que uma classe n o necessariamente corresponde a uma tabela Uma classe pode representar o reposit rio l gico dos atributos de uma tabela por m a classe n o a tabela uma vez que os atributos de seus objetos s o armazenados em mem ria enquanto uma tabela armazena seus registros fisicamente em disco Al m disso uma classe possui m todos que n o existem em uma tabela customer eustomer products customer id E pontal user ps name E E w first name customer id io street user_login pre postal code o ME Es City orde gery a ordit Ngrder id PA ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 1 5 CESUMAR CENTROUNIVERSIT RIO DE MARING RELACIONAMENTOS As classes n o trabalham sozinhas pelo contr rio elas colaboram umas com as outras por meio de relacionamentos MELO 2004 p 108 No diagrama de classes temos os rel
149. onceitos relacionados UML SOFTWARE De acordo com Sommerville 2007 p 4 o software composto n o somente pelos programas mas tamb m pela documenta o associada a esses programas Para Pressman 2011 p 32 o software possui pelo menos tr s caracter sticas que o diferenciam do hardware 1 2 Software desenvolvido ou passa por um processo de engenharia n o sendo fabri cado no sentido cl ssico Apesar de existir semelhan as entre o desenvolvimento de software e a fabrica o de hardware essas atividades s o muito diferentes Os custos de software concen tram se no processo de engenharia por causa disso os projetos de software n o podem ser conduzidos como se fossem projetos de fabrica o Software n o se desgasta Normalmente o hardware apresenta taxas de defeitos mais altas no in cio de sua vida por m esses defeitos s o corrigidos tendo assim a taxa decrescida ou seja atingindo um n vel est vel Por m com o uso o hardware pode se desgastar devido poeira m utiliza o temperaturas extremas e outros J com o software dife rente ou seja ele n o est sujeito aos problemas ambientais como o hardware Em rela o aos problemas iniciais com o software tamb m acontece assim pois alguns defeitos ainda podem passar pela etapa de valida o do software Quando um componente de hardware se desgasta ele normalmente trocado por um novo componente e o hardware volta a f
150. or meio de diagramas utilizando a UML como nota o gr fica Na primeira unidade j explicamos a import ncia da UML e agora come aremos a utiliz la de fato A UML tem diversos diagramas mas em nosso material trataremos somente do Diagrama de Casos de Uso e do Diagrama de Classes A fim de auxiliar o entendimento de cada um deles elaborei uma esp cie de tutorial explicando a elabora o dos mesmos passo a passo Isso foi feito para facilitar o seu entendimento pois esses diagramas s o os mais importantes e os mais utilizados da UML servindo de base para os demais diagramas E finalmente chegamos ltima unidade do nosso material Essa unidade o fechamento das etapas do processo de software ou seja tratar das etapas de projeto valida o e evolu o de software Assim voc compreender todo o processo de software com as etapas que o englobam ENGENHARIA DE SOFTWARE Educa o a Dist ncia 9 CESUMAR CENTROUNIVERSIT RIO DE MARING O projeto de software onde s o definidas as interfaces do sistema Voc pode fazer isso j utilizando uma linguagem de programa o de prefer ncia aquela em que voc vai implementar o sistema ou ent o alguma ferramenta CASE para prototipa o de sistema importante que o usu rio participe ativamente deste processo afinal ser ele quem vai passar a maior parte do tempo interagindo com o sistema Depois disso o sistema pode ser implementado ou seja hora de transf
151. ormar todo o trabalho realizado at o momento em c digo fonte medida que o sistema vai sendo desenvolvido cada programa vai sendo validado pelo desenvolvedor mas isso s n o basta muito importante que a etapa de valida o seja cuidadosamente realizada pela equipe de desenvolvimento pois preciso assegurar que o sistema funcionar corretamente Depois que o sistema colocado em funcionamento ele precisa evoluir para continuar atendendo as necessidades dos usu rios Em todas estas etapas importante a aplica o das t cnicas da engenharia de software Assim chegamos ao final do nosso livro Espero sinceramente que sua leitura seja agrad vel e que esse conte do possa contribuir para seu crescimento pessoal e profissional Profa M rcia 1 0 ENGENHARIA DE SOFTWARE Educa o a Dist ncia SUM RIO UNIDADE INTRODU O ENGENHARIA DE SOFTWARE SO TAVARES 19 ENGENHARIA DE SOFTWARE operado pedia e E EES 20 TIPOS DE APLICA ES DE SOFTWARE pao caiatr sons 21 FERRAMENTAS CASE COMPUTER AIDED SOFTWARE ENGINEERING 22 CONCEITOS B SICOS DE ORIENTA O A OBJETOS ii sitter 24 UML UNIFIED MODELING LANGUAGE asszsssssasecssastiiasomenisuaiasebsisansins dasesitaiiscansisan ras satapeo 32 HISTORICO DRUM a 2 arde ja6 ead a aaiae iten 34 FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML 35 UNIDADE II PROCESSOS DE SOFTWARE PROCESSOS DE SOFTWARE isic iiie
152. os valores que s o utilizados durante a execu o do m todo e pode tamb m retornar valores que podem representar o resultado da opera o executada ou somente indicar se o processo foi conclu do com sucesso ou n o Assim um m todo representa um conjunto de instru es que s o executadas quando o m todo chamado Um objeto da classe Cliente por exemplo pode executar a atividade de incluir novo cliente A figura a seguir apresenta um exemplo de uma classe com m todos nome String sexo char data nascimento Date IncluirNovoCliente void AtualizarCliente void Exemplo de Classe com Atributos e M todos Visibilidade De acordo com Guedes 2007 p 34 a visibilidade um s mbolo que antecede um atributo ou m todo e utilizada para indicar seu n vel de acessibilidade Existem basicamente tr s modos de visibilidade p blico protegido e privado e O s mbolo de mais indica visibilidade p blica ou seja significa que o atributo ou m todo pode ser utilizado por objetos de qualquer classe Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 21 CESUMAR CENTROUNIVERSIT RIO DE MARING O s mbolo de sustenido indica que a visibilidade protegida ou seja determina que apenas objetos da classe possuidora do atributo ou m todo ou de suas subclas ses podem acess lo e O s mbolo de menos indica que a visibilidade privada ou seja somente os obje tos
153. os extensos ou se ele provavelmente apresentar demoras peri dicas por causa de entradas volumosas importante exibir uma adequada mensagem para o usu rio caso contr rio poss vel que ele imagine que o seu computador congelou ou ficou preso ou que o sistema caiu ou que ocorreu uma falta de energia O sistema deve no m nimo emitir uma mensagem por exemplo SISTEMA OPERANDO POR FAVOR ESPERE em intervalos regulares Melhor ainda seria uma s rie de mensagens informando o usu rio quanto do trabalho j foi executado e aproximadamente quanto tempo falta para complet lo como acontece na maioria dos processos de instala o de aplicativos como por exemplo Microsoft Word Visio Visual Studio Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 o CESUMAR CENTROUNIVERSIT RIO DE MARING 7 Forne a defaults para entradas padronizadas Em muitos casos o sistema pode fazer uma boa suposi o sobre o prov vel valor de uma entrada fornecida pelo usu rio tornando o um default poder ser economizado um consider vel tempo do usu rio Essa abordagem v lida para todos os tipos de sistemas Um exemplo de valor default a data em muitas aplica es a data mais prov vel que o usu rio introduzir a data atual Ou suponha que voc esteja construindo um sistema de controle de pedidos e o usu rio diz que 95 dos clientes vivem nas redondezas em seguida quando for solicitado que o usu
154. os mais com os requisitos funcionais do sistema Se os requisitos n o funcionais forem definidos separadamente dos requisitos funcionais pode ser dif cil enxergar a rela o existente entre eles Se eles forem definidos com os requisitos funcionais poder ser dif cil separar considera es funcionais e n o funcionais e identificar os requisitos que correspondem ao sistema como um todo preciso encontrar um equil brio adequado e isso depende do tipo de sistema que est sendo modelado Contudo requisitos claramente relacionados s propriedades emergentes do sistema devem ser explicitamente destacados Isso pode ser feito colocando os em uma se o separada do documento de requisitos ou diferenciando os de alguma maneira dos outros requisitos de sistema Anota es 15 ENGENHARIA DE SOFTWARE Educa o a Dist ncia 11 CESUMAR CENTROUNIVERSIT RIO DE MARING REQUISITOS DE USU RIO De acordo com Sommerville 2007 p 85 os requisitos de usu rios para um sistema devem descrever os requisitos funcionais e n o funcionais de forma que usu rios do sistema que n o tenham conhecimentos t cnicos detalhados consigam entender Eles devem especificar somente o comportamento externo do sistema evitando sempre que poss vel as caracter sticas do projeto de sistema Portanto n o devem ser definidos utilizando se um modelo de implementa o e sim escritos com o uso de linguagem natural formul rios e diagramas intuitivos simpl
155. precisar realizar a altera o Sugest o de V deo lt http www youtube com watch v G6yk7ILK3JY amp eature relmfu gt V deo que mostra a import ncia dos testes e da manuten o de um software C CONSIDERA ES FINAIS Nesta ltima unidade pudemos fechar todas as etapas do processo de software ou seja j t nhamos estudado a import ncia de definirmos bem os requisitos do sistema e deixar isso devidamente anotado em um documento de requisitos Depois estudamos sobre a modelagem do sistema e aprendemos a elaborar o diagrama de casos de uso e o diagrama de classes E finalmente estudamos sobre as etapas de projeto valida o e evolu o de software A etapa de projeto de software se caracteriza por ser a defini o f sica do sistema ou seja onde podemos definir as interfaces do nosso sistema N o entrei em muitos detalhes de como elaborar essa interface pois este n o o nosso principal objetivo mas se voc tiver interesse pode estudar mais sobre o assunto Intera o Humano Computador IHC que uma mat ria interdisciplinar que relaciona a ci ncia da computa o artes design ergonomia semi tica e outras reas afins veja s como esse assunto abrangente Na etapa de projeto tamb m importante especificar cada caso de uso definido no diagrama de casos de uso Voc deve ter ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 63 CESUMAR CENTROUNIVERSIT RIO DE MARING notado que e
156. qual estudamos o assunto Requisitos de Software Nesta unidade foi mostrado que os requisitos para um software devem estabelecer o que o sistema deve fazer e definir tamb m as restri es sobre o seu funcionamento e implementa o Os requisitos de software podem ser classificados em requisitos funcionais que s o aqueles servi os que o sistema deve fornecer e requisitos n o funcionais que est o frequentemente relacionados s propriedades emergentes do sistema aplicando se ao sistema como um todo Todos os requisitos sejam eles funcionais ou n o funcionais devem ser definidos da forma mais clara poss vel para que n o haja problemas na sua interpreta o pois a partir da defini o desses requisitos que o sistema ser modelado projetado implementado testado e por fim colocado em funcionamento Um erro na defini o de requisitos pode levar a altera es 92 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING em todas essas etapas por isso essa etapa t o importante Para auxiliar todo esse processo vimos que Sommerville 2011 prop e que a engenharia de requisitos seja um processo que deve incluir quatro atividades de alto n vel A primeira atividade servir para avaliar se o sistema ser til para a empresa Isto se d por meio do estudo de viabilidade sendo que ao final desta atividade um relat rio de viabilidade deve ser elaborado no qual se reco
157. r Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 59 CESUMAR CENTROUNIVERSIT RIO DE MARING testar os m dulos pequenos de forma individual essa modalidade muitas vezes chamada de teste de unidade teste de m dulo ou teste de programa Em seguida os m dulos individuais s o agrupados com outros m dulos para serem testados em conjunto isso costuma ser chamado de teste de subsistemas Finalmente todos os m dulos do sistema s o combinados para um teste final que conhecido como teste do sistema e muitas vezes seguido pelo teste de aceita o quando o usu rio pode submeter dados reais para verificar se o sistema est funcionando corretamente A abordagem de testes top down principia com um esqueleto do sistema ou seja a estrat gia de testes presume que os m dulos de execu o de alto n vel do sistema foram desenvolvidos mas que os m dulos de baixo n vel existem apenas como simula es somente como prot tipos Como a maioria das fun es detalhadas do sistema n o foi desenvolvida os testes iniciais se tornam limitados sendo poss vel apenas testar as interfaces entre os principais subsistemas Os testes seguintes tornam se em seguida cada vez mais abrangentes testando aspectos cada vez mais detalhados do sistema Al m desses conceitos b sicos voc deve conhecer os seguintes tipos de testes e Testes funcionais Neste tipo de teste o objetivo verificar se o sistema executa cor
158. retamente suas fun es para os quais ele foi projetado Portanto os casos de testes ser o desenvolvidos e lan ados no sistema as sa das e os resultados da atualiza o da base de dados ser o examinadas para testar sua corre o YOURDON 1990 p 540 e Testes de desempenho O objetivo deste tipo de teste verificar se o sistema pode manipular o volume de dados e transa es recebidas bem como verificar se ele apresenta o tempo de resposta necess rio YOURDON 1990 p 541 Isso pode exigir que a equipe de desenvolvimento execute uma s rie de testes em que a carga do sistema aumentada at que o seu desempenho se torne inaceit vel SOMMERVILLE 2011 p 153 e Testes de Unidade T m por objetivo verificar um elemento que possa ser logicamente Anota es LA 1 60 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING tratado como uma unidade de implementa o por exemplo uma sub rotina ou um m dulo e Testes de Aceita o T m por objetivo validar o produto ou seja verificar se esse atende aos requisitos especificados Eles s o executados em ambiente o mais semelhante poss vel ao ambiente real de execu o Se os casos de teste forem desenvolvidos no final da etapa de projeto com utiliza o do diagrama de casos de uso diagrama de classes e da especifica o de casos de uso n o h meio de se saber como o programa funcionar quando o desenvolvedor escrever o c
159. rientadas fun o seriam as Upper CASE e Lower CASE Baseiam se na fun cionalidade das ferramentas ou seja s o aquelas que t m fun es diferentes no ciclo de vida de um projeto como representar apenas o Diagrama de Entidades e Relacionamentos DER ou o Diagrama de Fluxo de Dados DFD e Orientadas a atividade Seriam as Best In Class e as I CASE que processam a ativi dades como especifica es modelagem e implementa o CONCEITOS B SICOS DE ORIENTA O A OBJETOS 10 DIM ACIO O FOR X 1 to 10 A UML totalmente baseada no paradigma de orienta o a objetos 00 Sendo assim para compreend la corretamente precisamos antes estudar alguns dos conceitos relacionados orienta o a objetos Objetos Segundo Melo 2004 p 15 um objeto qualquer coisa em forma concreta ou abstrata que Anota es LX 24 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING exista f sica ou apenas conceitualmente no mundo real S o exemplos de objetos cliente professor carteira caneta carro disciplina curso caixa de di logo Os objetos possuem caracter sticas e comportamentos Classes Uma classe uma abstra o de um conjunto de objetos que possuem os mesmos tipos de caracter sticas e comportamentos sendo representada por um ret ngulo que pode possuir at tr s divis es A primeira divis o armazena o nome da classe a segunda os atributos caracter sticas
160. rinheiro Louren o e M rcio Alan Benine Um estudo do ciclo de vida do software desenvolvido em uma empresa de desenvolvimento de siste mas importante pois construir um software com qualidade demanda a utiliza o e implanta o de processos e t cnicas de engenharia de software Este processo indispens vel para que o produto seja entregue ao cliente dentro do prazo e or amento planejado alcan ando a qualidade esperada Considerando se esse procedimento realizou se um estudo utilizando se uma pesquisa bibliogr fica visando encontrar referencial te rico para dar sustenta o quest o proposta e um estudo de caso na empresa Nippon Inform tica Ltda ME Esta empresa localizada na cidade de Batatais SP atua com desenvolvimento de software para as reas Cont bil Fiscal e Recursos Humanos No estudo de caso buscou se elaborar o mapeamento dos processos existentes e ap s an lise dos mesmos propor um cen rio de solu o adequado realidade da empresa Como resultado final deste estudo foi apresentada uma proposta de implanta o do modelo de ciclo de vida do software proporcionando a constru o do software com qualidade fornecendo um modelo que atenda aos padr es da enge nharia de software e que tenha aspectos de qualidade importantes Concluiu se que cada vez mais empresas de desenvolvimento de sistemas necessitam adotar processos de software adequados A defini o do ciclo de vida de um software importante para se ter
161. s rio deixar regis trado qual o dependente e qual o cliente verificado se o filme est dispon vel e se o cliente possui pend ncias financeiras ou atraso de devolu o caso uma das alternativas seja afirmativa bloqueia se a opera o sendo liberada somente ap s a devida regulariza o Emitir comprovante de loca o com a data prevista para devolu o de cada filme discrimina o dos filmes e se o pagamento foi ou n o efetuado A data prevista para devolu o deve ser calculada desconsiderando domingos e feriados Cada categoria pode ter um prazo diferente para que o cliente possa ficar com o filme Por exemplo a categoria LAN AMENTO permite que o cliente fique com o filme por 2 dias 3 Controlar devolu es Verificar se a devolu o est no prazo correto e se o pagamento foi efetuado caso Anota es LA 76 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING o prazo esteja vencido calcular a multa incidente Efetuado o pagamento emite se o recibo de devolu o N o esquecer que n o pode ser cobrada multa caso seja domingo ou feriado Controlar reservas Verificar se o cliente j est cadastrado caso contr rio o sistema permite o cadastro do cliente no momento da reserva Tamb m verificado se o filme desejado est dispon vel para reserva Reservar somente para clientes sem pend ncias financeiras e devolu es venci das Consultar Filmes Locados
162. s com o mesmo significado Voc ver tamb m que uma atividade pode se desdobrar em v rias etapas ou subatividades PROCESSOS DE SOFTWARE Para que um software seja produzido s o necess rias diversas etapas compostas de uma s rie de tarefas em cada uma delas A esse conjunto de etapas d se o nome de processo de software Essas etapas podem envolver o desenvolvimento de software a partir do zero em uma determinada linguagem de programa o por exemplo o Java ou C ou ent o a amplia o e a modifica o de sistemas j em utiliza o pelos usu rios Segundo Sommerville 2011 existem muitos processos de software diferentes por m todos devem incluir quatro atividades fundamentais para a engenharia de software 1 Especifica o de software necess rio que o cliente defina as funcionalidades do software que ser desenvolvido bem como defina todas as suas restri es operacionais 2 Projeto e implementa o de software O software deve ser confeccionado seguindo as especifica es definidas anteriormente 3 Valida o de software O software precisa ser validado para garantir que ele faz o que o cliente deseja ou seja que ele atenda s especifica es de funcionalidade 4 Evolu o de software As funcionalidades definidas pelo cliente durante o desen volvimento do software podem mudar e o software precisa evoluir para atender a essas mudan as Anota es LA 42 ENGENHARIA DE SOFTWARE Educa o a D
163. s conceitos apresentados mas a engenharia de software pode ser aplicada a um conjunto imenso de tipos diferentes de solu es que requerem software Voc com certeza j deve ter utilizado um micro ondas Ent o quando voc pressiona a tecla pipoca um software embutido que est sendo executado Portanto com a tecnologia que temos hoje nossa disposi o poss vel encontrar o software em muitos lugares Voc vai perceber que grande parte da documenta o do sistema produzido a partir da aplica o das t cnicas e m todos da engenharia de software gr fica ou seja acontece atrav s de diagramas Como a UML Unified Modeling Language Linguagem de Modelagem Unificada a linguagem para modelagem mais utilizada atualmente vamos tamb m utiliz la neste livro Por m para entender qualquer diagrama da UML necess rio conhecer alguns conceitos relacionados orienta o a objetos como por exemplo classe objeto heran a Ap s esses conceitos serem apresentados que iniciaremos o estudo da UML Nesta unidade veremos somente uma introdu o sobre a UML Voc ver como ela surgiu Anota es LX 1 8 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING e ver tamb m que uma forma de representa o orientada a objetos bastante recente Na unidade Ill que estudaremos dois dos diagramas da UML por isso importante entender nesta unidade os c
164. s de software mas que algumas atividades b sicas est o presentes em todos eles s vezes com nomes diferentes mas est o presentes Voc est lembrado de quais s o essas atividades As atividades s o especifica o de software projeto e implementa o de software valida o de software e por ltimo evolu o de software A unidade III foi dedicada exclusivamente a explicar o que s o requisitos de software Mostrei qual a diferen a entre os requisitos funcionais e n o funcionais e a import ncia do documento de requisitos inclusive mostrando um exemplo Na unidade IV mostrei como a partir do documento de requisitos realizar a modelagem do sistema utilizando a UML Nesta unidade expliquei com detalhes os Diagramas de Casos de Uso e Diagrama de Classes dois dos mais importantes diagramas da UML Apresentei tamb m um exemplo de diagrama partindo do documento de requisitos explicando passo a passo a elabora o de cada um deles E para finalizar vimos na unidade V as etapas de projeto valida o e evolu o de software permitindo que voc pudesse entender todas as etapas envolvidas nos modelos de processos de software Espero ter alcan ado o objetivo inicial que era mostrar a import ncia da Engenharia de Software 1 66 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Desejo que voc seja muito feliz profissionalmente utilizando os conceitos apresentados aqui e s
165. s do sistema engenheiros clientes gerentes contratantes e arquitetos de software Esses leitores n o tem a preocupa o com a forma como o sistema ser implementado J para os requisitos de sistema podem se ter os seguintes leitores usu rios finais do sistema engenheiros clientes arquitetos de sistema e desenvolvedores de software Esses leitores precisam saber com mais detalhes o que o sistema far principalmente os desenvolvedores que estar o envolvidos no projeto e na implementa o do sistema As sementes das principais cat strofes de software s o normalmente semeadas nos tr s primeiros meses do projeto de software Caper Jones Especialista em Engenharia de Software SS O DOCUMENTO DE REQUISITOS DE SOFTWARE O documento de requisitos de software ou especifica o de requisitos de software a declara o oficial do que exigido dos desenvolvedores de sistema Ele deve incluir os requisitos de usu rios para um sistema e uma especifica o detalhada dos requisitos de sistema Em alguns casos os requisitos de usu rio e de sistema podem ser integrados em uma nica descri o Em outros casos os requisitos de usu rio s o definidos em uma introdu o especifica o dos requisitos de sistema Se houver um grande n mero de requisitos os requisitos detalhados de sistema poder o ser apresentados como documentos separados O documento de requisitos serve como um termo de consenso entre a equipe t cnica
166. s jd E Leitor Comprovante Empr stimos Exemplares Ror Empr stimos Leitor Assuntos Devolu es Devolu es Editoras Cat logo Livros Geral Autores Livros por Assunto Exemplares Livros em Atraso Fonte a autora O Diagrama de Caso de Uso referente a esse sistema deveria conter pelo menos os seguintes Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 43 CESUMAR CENTROUNIVERSIT RIO DE MARING casos de uso Cadastrar Categorias Cadastrar Leitores Cadastrar Assuntos Cadastrar Editoras Cadastrar Autores Cadastrar Livros Cadastrar Exemplares Registrar Empr stimos Emitir Comprovante de Empr stimos Registrar Devolu es Emitir Relat rio de Leitores por Categoria Emitir Relat rio de Empr stimos Emitir Relat rio de Devolu es Emitir Cat logo Geral de Livros Emitir Cat logo de Livros por Assunto Emitir Relat rio de Livros em Atraso Efetuar Consulta de Leitor por Exemplar Efetuar Consulta de Exemplares por Leitor Interfaces com o Usu rio Sommerville 2007 p 241 comenta que o projeto de interface com o usu rio deve ser feito cautelosamente pois uma parte fundamental de todo o processo de projeto de software A interface com o usu rio deve ser projetada para combinar as habilidades experi ncias e expectativas dos usu rios do sistema A confiabilidade do sistema aumenta se um bom proje
167. seja quais os tipos de testes que devem ser realizados no sistema Compreender a import ncia da evolu o de software para que o mesmo continue til aos seus usu rios Plano de Estudo A seguir apresentam se os t picos que voc estudar nesta unidade Projeto de Software Diagrama Geral do Sistema Interfaces e Especifica o de Casos de Uso Testes de Software Evolu o de Software CESUMAR CENTROUNIVERSIT RIO DE MARING INTRODU O Na quarta unidade estudamos sobre a modelagem do sistema e aprendemos sobre Diagrama de Casos de Uso e Diagrama de Classes Agora para a pr xima etapa do processo de software ou seja a etapa do projeto de software precisaremos desses dois diagramas e tamb m do documento de requisitos para definir uma s rie de artefatos necess rios para que posteriormente o software possa ser implementado A etapa de projeto de software segundo Pressman 2011 p 207 deve ser aplicada em qualquer modelo de processo de software que esteja sendo utilizado para o desenvolvimento do software e deve ser iniciada assim que os requisitos tiverem sido analisados e modelados constituindo a ltima a o da modelagem e preparando a cena para a constru o gera o de c digo e valida o do software O primeiro artefato de software que ser explicado nesta unidade ser o Diagrama Geral do Sistema DGS Neste diagrama devem aparecer todos os m dulos e subm dulos do sistema assi
168. ses derivadas as subclasses e uma mesma superclasse podem chamar m todos que t m o mesmo nome ou a mesma assinatura mas possuem comportamentos diferentes em cada subclasse produzindo resultados diferentes dependendo de como cada objeto implementa o m todo Ou seja podem existir dois ou mais m todos com a mesma nomenclatura diferenciando se na maneira como foram implementados sendo o sistema respons vel por verificar se a classe da inst ncia em quest o possui o m todo declarado nela pr pria ou se o herda de uma superclasse GUEDES 2007 p 36 Por ser um exemplo bastante claro para ilustrar o polimorfismo utilizaremos o mesmo exemplo de Gedues 2007 p 37 que est mostrado na figura abaixo Anota es LA 30 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING saldo double Saque void A Conta Poupan a aniversario Date PP Conta Especial limite double Saque void Exemplo de Polimorfismo Fonte Guedes 2007 p 37 No exemplo apresentado acima aparece uma classe geral chamada Conta Comum que nesse caso a superclasse que possui um atributo chamado Saldo contendo o valor total depositado em uma determinada inst ncia da classe e um m todo chamado Saque Esse m todo somente diminui o valor a ser debitado do saldo da conta se este possuir o valor suficiente Caso contr rio a opera o n o poder ser realizada
169. sistema atende aos objetivos globais de neg cio ou estrat gicos da organiza o que enco mendou o software Deve definir os termos t cnicos usados no documento Voc n o deve fazer suposi es sobre a experi ncia ou o conhecimento do leitor Deve descrever os servi os fornecidos ao usu rio Os requisitos n o funcionais de sistema tamb m devem ser descritos nessa se o Essa descri o pode usar a linguagem natural diagramas ou outras nota es compreens veis para os clientes Normas de produto e processos a se rem seguidos devem ser especificados Deve apresentar uma vis o geral em alto n vel da arquitetura do siste ma previsto mostrando a distribui o de fun es entre os m dulos do sistema Componentes de arquitetura que s o reusados devem ser des tacados 14 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING Cap tulo Descri o Deve descrever em detalhes os requisitos funcionais e n o funcionais Se necess rio tamb m podem ser adicionados mais detalhes aos requisitos n o funcionais Interfaces com outros sistemas podem ser definidas Especifica o de re quisitos do sistema Pode incluir modelos gr ficos do sistema que mostram os relacionamen tos entre os componentes do sistema o sistema e seu ambiente Exem plos de poss veis modelos s o modelos de objetos modelos de fluxo de dados ou modelo sem nticos de dados Modelos do sistema Deve descre
170. so n o pode ser menor ou igual a zero O nome do paciente n o pode ser branco Se CPF for digitado aceitar somente CPF v lido N o permitir a exclus o de um paciente que tenha pelo menos um hor rio cadastrado na agenda e Especifica o de Caso de Uso Cadastrar Agenda O O O go Os dados digitados pelo usu rio dever o estar em caixa alta O c digo do paciente n o pode ser menor ou igual a zero N o permitir que seja marcada mais de uma consulta para o mesmo m dico na mesma data e no mesmo hor rio Quando for inclu do um novo hor rio mover N para o atributo CONS_REALIZADA Quando a consulta for efetivada mover S para CONS REALIZADA Se for consulta particular pedir o valor da consulta Data da consulta n o pode ser menor que a data atual e Especifica o de Caso de Uso Emitir Relat rio de Pagamentos de Consultas por Per odo 4 Selecionar somente as inst ncias da classe AGENDAS que tenham o atributo DATA maior ou igual data inicial informada na tela de filtro do relat rio e menor ou igual data finale CONS REALIZADA igual a S e VLR CONSULTA diferente de zero N o permitir data final menor que data inicial Validar datas Caso n o exista nenhuma inst ncia selecionada mostrar mensagem de alerta N O H PAGAMENTO DE CONSULTAS NO PER ODO INFORMADO e n o mostrar re lat rio em branco Anota es LX 1 54 ENGENHARIA DE SOFTWARE Educa o a Dist nci
171. so se utilizem dessas a es evitando se descrever uma mesma sequ ncia de passos em v rios casos de uso GUEDES 2007 p 42 Um relacionamento de inclus o entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso O caso de uso inclu do nunca permanece isolado mas apenas instanciado como parte de alguma base maior que o inclui BOOCH 2005 p 235 Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 07 CESUMAR CENTROUNIVERSIT RIO DE MARING O relacionamento de inclus o pode ser comparado chamada de uma sub rotina portanto indicam uma obrigatoriedade ou seja quando um caso de uso base possui um relacionamento de inclus o com outro caso de uso a execu o do primeiro obriga tamb m a execu o do segundo GUEDES 2007 p 42 A representa o do relacionamento de inclus o feita por meio de uma reta tracejada contendo uma seta em uma de suas extremidades e rotulada com a palavra chave lt lt include gt gt A seta deve sempre apontar para o caso de uso a ser inclu do Veja um exemplo na figura abaixo que foi retirado de Guedes 2007 p 43 Cliente Banco I lt lt include gt gt I Exemplo de inclus o de caso de uso Neste exemplo sempre que um saque ou dep sito ocorrer ele deve ser registrado para fins de hist rico banc rio Como as rotinas para registro de um saque ou um dep sito s o extremamente semelhan
172. software O desenvolvimento de software visto como uma atividade criativa em que o software desenvolvido a partir de um conceito inicial at chegar ao sistema em opera o Depois que esse sistema entrou em opera o inicia se a manuten o de software no qual o mesmo modificado Normalmente os custos de manuten o s o maiores do que os custos de desenvolvimento inicial mas os processos de manuten o s o considerados menos desafiadores do que o desenvolvimento de software original ainda que tenha um custo mais elevado Por m atualmente os est gios de desenvolvimento e manuten o t m sido considerados como integrados e cont nuos em vez de dois processos separados Tem sido mais realista pensar na engenharia de software como um processo evolucion rio em que o software sempre mudado ao longo de seu per odo de vida em resposta a requisitos em constante modifica o e s necessidades do cliente Anota es LX 60 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING CONSIDERA ES FINAIS Chegamos ao final de mais uma unidade Nesta segunda unidade voc conheceu o que um processo de software e tamb m alguns modelos de processo de software Um processo de software um conjunto de atividades com resultados artefatos associados a cada uma delas que leva produ o de um software Todo software deve ser especificado projetado implementado e validado E
173. sposta para essa pergunta n o t o simples N o existe um processo ideal de software e os modelos n o s o mutuamente exclusivos e na maioria das vezes podem ser usados em conjuntos em especial para o desenvolvimento de sistemas de grande porte O aumento na demanda por software de qualidade vem causando grande press o sobre as empresas que trabalham com desenvolvimento de software As entregas de software obedecendo ao cronograma e custos previstos v m se tornando a cada dia um diferencial importante nesse ramo de atividade Por isso as empresas procuram por processos de software que propiciem o desenvolvimento de produtos com qualidade e que respeitem o custo e cronograma previstos Na pr xima unidade vamos conhecer um pouco mais sobre requisitos de software e entender por que os requisitos s o t o importantes em um processo de software ATIVIDADE DE AUTOESTUDO 1 Fa a um comparativo entre os Modelos de Processo de Software 1 Modelo Cascata e Desenvolvimento Incremental 2 Explique cada uma das atividades b sicas que comp em um processo de software Essas atividades devem ser realizadas sempre na ordem descrita nesta unidade Justifique sua resposta 3 Considerando os modelos de processo de software apresentados nesta unidade de fina um modelo de processo de software que poderia ser utilizado por uma pequena empresa de desenvolvimento de sistemas 62 ENGENHARIA DE SOFTWARE Educa o a Dist ncia UNIDADE III
174. ssa especifica o vai ajudar e muito o programador a escrever o c digo fonte de cada programa pois esta especifica o deve conter detalhes sobre as restri es que cada programa deve considerar para que o sistema como um todo atinja o seu objetivo Depois que todos os artefatos descritos na modelagem e no projeto estiverem prontos hora da equipe de desenvolvimento codificar o sistema na linguagem de programa o escolhida Tamb m n o falamos nada sobre esse assunto pois com certeza voc aprender ou j aprendeu as t cnicas de programa o em outras disciplinas do seu curso e saber que essa etapa bastante trabalhosa e deve ser muito bem realizada para que todo o esfor o despendido at aqui n o seja em v o Depois que o software foi implementado hora da sua valida o ou seja hora de verificar se ele realmente est funcionando Enquanto o sistema est sendo desenvolvido ele j est sendo testado pelas pessoas que o est o desenvolvendo mas isto s n o basta necess rio desenvolver v rios tipos de testes como mostramos nesta unidade para assegurar que o sistema funcionar corretamente A real valida o do software normalmente feita quando o mesmo est em uso pois muito dif cil testar todas as possibilidades de um sistema inteiro Ap s a implanta o e efetiva utiliza o do sistema pelo usu rio qualquer altera o que seja necess ria ser considerada como uma evolu o d
175. tar as palavras do entrevistado b determinar a atitude geral do entrevistado para as quest es que est o sendo discutidas c avaliar a confid ncia que o entrevistado demonstrou tanto ao seu redor como no tratamento da rea de abrang ncia do sistema V rios pontos devem ser aprendidos e esclarecidos na entrevista a Organiza o da empresa ambiente de trabalho Como o administrador organiza o seu pessoal Como esta organiza o se relaciona s fun es maiores que a empresa executa b Os objetivos e exig ncias do sistema declarados nos manuais de procedimentos devem ser reafirmados e esclarecidos na entrevista muitas vezes os objetivos e exig ncias Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 87 CESUMAR CENTROUNIVERSIT RIO DE MARING declarados nos manuais n o s o os mesmos que os representantes veem Quando existe uma discrep ncia poss vel que as metas representadas nos documentos possam ser irreais com o atual potencial humano O tempo e o crescimento podem ter alterado a meta declarada c Fluxo funcional para cada fun o importante determinar as etapas exigidas e descreva o significado delas d Exig ncia de recursos determinar quais s o os recursos aplicados pela organiza o para executar o trabalho Quais s o as exig ncias com Recursos humanos treinamento especializado experi ncia exigida Equipamento e material necess rio para apoiar na execu o
176. tavam caindo em fun o de que a sua produ o passou a ser em s rie por m o custo do software n o acompanhava essa queda muitas vezes sendo aumentado Aideia inicial da engenharia de software era tornar o desenvolvimento de software um processo sistematizado em que seriam aplicadas t cnicas e m todos necess rios para controlar a complexidade inerente aos grandes sistemas SOMMERVILLE 2007 p 4 Anota es ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 T CESUMAR CENTROUNIVERSIT RIO DE MARING Apresentarei a voc o conceito de software e voc ver que software muito abrangente englobando desde os programas escritos at a documenta o associada a esse software Cabe aqui ressaltar que essa documenta o deve estar sempre atualizada pois caso contr rio ela perde o seu sentido Para ajudar nessa tarefa de manter a documenta o em dia podem ser utilizadas as ferramentas CASE que tamb m veremos nessa unidade Um detalhe interessante que uma ferramenta CASE tamb m um software Depois trataremos sobre a engenharia de software como um todo Neste livro abordarei somente alguns t picos da engenharia mas com certeza precisar amos de dezenas de livros como esse para esgotar esse assunto portanto gostaria de deixar claro que aqui estudaremos somente uma pequena parte dessa abrangente disciplina Os exemplos que ser o mostrados neste livro s o simples para que seja mais f cil entendermos o
177. tes colocou se a rotina de registro em um caso de uso parte Anota es LA 1 08 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CESUMAR CENTROUNIVERSIT RIO DE MARING chamado Registrar Movimento que ser executado obrigatoriamente sempre que os casos de uso Realizar Dep sito ou Realizar Saque forem utilizados Assim s preciso descrever os passos para registrar um movimento no caso de uso inclu do GUEDES 2007 p 43 Neste exemplo temos dois casos de uso base e um caso de a ser inclu do Agora veja outro exemplo na figura abaixo Aqui est sendo apresentada a seguinte situa o em algum ponto dos casos de uso Realizar matr cula do aluno caso de uso base Cadastrar pagamento mensalidade aluno caso de uso base e Emitir hist rico escolar aluno caso de uso base necess rio Validar a matr cula caso de uso a ser inclu do do aluno Assim nestes pontos o caso de uso Validar matr cula ser internamente copiado Realizar matr cula do aluno lt lt include gt gt gt Emitir 2 lt lt gt gt E Pier Validar S lt include gt gt hist rico matr cula gt escolar aluno lt lt include gt gt Cadastrar pagamento mensalidade aluno Outro exemplo de inclus o de caso de uso Extens o O relacionamento de extens o tamb m poss vel somente entre casos de uso e utilizado para modelar rotinas opcionais de um sistema que ocorrer o somente se uma
178. to de interface com o usu rio for executado se forem consideradas as capacidades dos usu rios reais bem como o seu ambiente de trabalho O engenheiro de software dever definir todas as interfaces de v deo e as interfaces impressas do sistema que est sendo projetado Interface de V deo Para cada funcionalidade do sistema caso de uso definir o layout da tela O layout o desenho da tela e onde devem constar as informa es que o usu rio dever fornecer ao sistema Sugest o criar uma padroniza o para todas as telas do sistema para facilitar a utiliza o do mesmo pelo usu rio Seguem alguns exemplos de interfaces de v deo e Tela de Cadastro de Pacientes esta interface cont m as informa es pessoais de um paciente Note que as informa es encontram se distribu das de maneira l gica e o espa o foi otimizado para que em uma mesma tela v rias informa es pudessem ser colocadas Anota es LX 1 44 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING Cadastro de Pacientes Incluir Excluir Salvar Cancelar Consultar Sair e Outro Exemplo de Tela de Cadastro de Pacientes j nesta tela as informa es n o est o distribu das de maneira l gica Note que o nome do paciente somente solicitado depois da data de nascimento RG e telefone 3 Cadastro de Paciente k j e Tela de Cadastro de Produtos nesta tela al m de cadastrar os dados do produt
179. truturada e no final da d cada a an lise e o projeto estruturado o D cada de 1980 surge a necessidade por interfaces homem m quina mais sofisti cadas o que originou a produ o de sistemas de software mais complexos A an li se estruturada se consolidou na primeira metade dessa d cada e em 1989 Edward Yourdon lan a o livro An lise Estruturada Moderna tornando o uma refer ncia no assunto o D cada de 1990 nesse per odo surge um novo paradigma de modelagem a An li se Orientada a Objetos como resposta a dificuldades encontradas na aplica o da An lise Estruturada a certos dom nios de aplica o o Final da d cada de 90 e momento atual o paradigma da orienta o a objetos atin ge a sua maturidade Os conceitos de padr es de projetos design patterns fra meworks de desenvolvimento componentes e padr es de qualidade come am a ganhar espa o Nesse per odo surge a Linguagem de Modelagem Unificada UML que a ferramenta de modelagem utilizada no desenvolvimento atual de sistemas O processo de desenvolvimento de software uma atividade bastante complexa Isso se reflete no alto n mero de projetos de software que n o chegam ao fim ou que extrapolam recursos de tempo e de dinheiro alocados Em um estudo cl ssico sobre projetos de desenvolvimento de software realizado em 1994 foi constatado que Porcentagem de projetos que terminam dentro do prazo estimado 10 Porcentagem de projetos que s o descont
180. u rios de software e os desenvolvedores de software As prefer ncias preconceitos e recusas dos usu rios al m das quest es pol ticas e organizacionais influenciam diretamente nos requisitos do sistema portanto a engenharia de software n o simplesmente um processo t cnico SOMMERVILLE 2007 p 78 ENGENHARIA DE SOFTWARE Educa o a Dist ncia 65 CESUMAR CENTROUNIVERSIT RIO DE MARING Nesta unidade voc aprender a diferen a entre os v rios tipos de requisitos e trataremos principalmente dos requisitos funcionais e n o funcionais Os requisitos funcionais representam as descri es das diversas fun es que clientes e usu rios querem ou precisam que o software ofere a Um exemplo de requisito funcional o sistema deve possibilitar o cadastramento dos dados pessoais dos pacientes J os requisitos n o funcionais declaram as restri es ou atributos de qualidade para um software como por exemplo precis o manutenibilidade usabilidade entre outros O tempo de desenvolvimento n o deve ultrapassar seis meses um exemplo de requisito n o funcional Todos os requisitos definidos sejam eles funcionais ou n o funcionais devem estar escritos em um documento de requisitos que servir como base para todas as atividades subsequentes do desenvolvimento e tamb m fornecer um ponto de refer ncia para qualquer valida o do software constru do Tamb m estudaremos nesta unidade sobre os r
181. ua se na rea das ferramentas CASE apresentado um estudo dos concei tos fundamentais da Engenharia de Software e s o abordados diversos problemas relacionados com o desenvolvimento de software S o tamb m apresentados os paradigmas mais conhecidos e algumas metodologias para o desen volvimento de software Registra ainda as caracter sticas vantagens e desvantagens das ferramentas Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 43 CESUMAR CENTROUNIVERSIT RIO DE MARING CASE Nesta Disserta o efetuado um estudo sobre a sistematiza o do caminho a percorrer na escolha de um ambiente CASE Para tal s o analisadas quest es como metodologia a utilizar decis o a tomar quanto ao produto ou produtos que correspondem s necessidades e capacidades da organiza o sele o do fornecedor n vel de forma o exigida e custos envolvidos Para ilustrar este estudo foi desenvolvida uma aplica o que permite ao departamento de qualidade de uma ind stria de lactic nios gerir todas as amostras e an lises efetuadas ao n vel do produtor e do processo de fabrico Nesta aplica o foram usadas ferramentas CASE EasyCASE Professional 4 22 e EasyCASE Database Engineer 1 10 assim como uma base de dados Microsoft Access 2 0 Fonte lt http repositorio aberto up pt handle 10216 12914 gt Acesso em 02 jun 2012 mzmz k t k k ag importante ressa
182. ue um cliente usa o sistema um teste est sendo realizado Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 61 CESUMAR CENTROUNIVERSIT RIO DE MARING EVOLU O DE SOFTWARE Ap s a implanta o de um sistema inevit vel que ocorram mudan as sejam elas para pequenos ajustes p s implanta o para melhorias substanciais por for a da legisla o para atender novos requisitos dos usu rios e finalmente por estar gerando erros De acordo com Sommerville 2011 p 164 cerca de dois ter os de custos de software est o relacionados evolu o do software requerendo grande parte do or amento de Tecnologia da Informa o para todas as empresas Manuten o de Software O desafio da manuten o come a t o logo o software colocado em funcionamento Normalmente depois que os usu rios come am a utilizar o software eles percebem que outras funcionalidades ainda inexistentes podem ser acrescentadas ao mesmo ou seja acabam aparecendo requisitos que o usu rio n o havia mencionado pois foi com o uso do sistema que ele passou a perceber que o software pode oferecer mais do que est oferecendo Como o sistema j est em funcionamento essas novas funcionalidades s o consideradas como manuten o Ou ent o a manuten o se d para corre o de erros no sistema pois descobrir todos os erros enquanto o software est na etapa de valida o bastante complexo pois todos os caminhos
183. uncionar Com o software isso n o acontece n o tem como simplesmente trocar o componente pois quando um erro acontece no hardwa re pode ser de projeto de requisito mal definido levando o software a sofrer manuten o que pode ser considerada mais complexa que a do hardware Embora a ind stria caminhe para a constru o com base em componentes a maioria Anota es 1X ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 9 CESUMAR CENTROUNIVERSIT RIO DE MARING dos softwares continua a ser constru da de forma personalizada sob encomenda A reutiliza o de componentes de hardware parte natural do seu processo de engenha ria j para o software algo que apenas come ou a ser alcan ado PRESSMAN 2011 p 34 Os componentes reutiliz veis de software s o criados para que o desenvolvedor possa se concentrar nas partes do projeto que representam algo novo Esses compo nentes encapsulam dados e o processamento aplicado a eles possibilitando criar novas aplica es a partir de partes reutiliz veis Na unidade Il trataremos sobre Engenharia de Software Orientada a Reuso ENGENHARIA DE SOFTWARE De acordo com Sommerville 2011 p 5 a engenharia de software uma disciplina de engenharia cujo foco est em todos os aspectos da produ o de software desde os est gios iniciais da especifica o do sistema at sua manuten o Como dissemos na introdu o desta unidade o termo engenharia de software
184. utro exemplo de extens o de caso de uso Anota es LA Realizar cadastro dados pessoais lt lt exend gt gt Cliente 1 1 0 ENGENHARIA DE SOFTWARE Educa o a Dist ncia CENTROUNIVERSIT RIO DE MARING No exemplo acima o caso de base o Realizar login no site e Realizar cadastro dados pessoais o caso de uso a ser estendido Calcular desconto para cliente especial lt lt extend gt gt 7 se Efetuar venda extend gt gt 4 Verificar falha na autoriza o do cart o Representa o de um Relacionamento Extend QUADRO RESUMO DE RELACIONAMENTOS ENTRE CASOS DE USO E ATORES Caso de Uso e Caso de Uso Ator e Caso de Uso ENGENHARIA DE SOFTWARE Educa o a Dist ncia 1 1 1 CESUMAR CENTROUNIVERSIT RIO DE MARING lt http Iwww youtube com watch v hfN n5fJfLc amp feature relmfu gt V deo que mostra a import ncia da modelagem de sistemas bem como trata da elabora o do dia grama de casos de uso SS ESTUDO DE CASO Vamos mostrar um documento de requisitos de uma f brica de colch es e depois o diagrama de casos de uso que foi elaborado com base neste documento A ferramenta que utilizaremos para modelar o diagrama ser o Astah como j foi dito anteriormente Outra observa o importante que esse documento de requisitos est bastante simplificado seu principal objetivo mostrar como os conceitos mostrados podem ser
185. ver os pressupostos fundamentais em que o sistema se baseia bem como quaisquer mudan as previstas em decorr ncia da Evolu o do sistema evolu o do hardware de mudan as nas necessidades do usu rio etc Essa se o til para projetistas de sistema pois pode ajud los a evitar decis es capazes de restringir poss veis mudan as futuras no sistema Deve fornecer informa es detalhadas e espec ficas relacionadas apli ca o em desenvolvimento al m de descri es de hardware e banco de dados por exemplo Os requisitos de hardware definem as configura es m nimas ideais para o sistema Requisitos de banco de dados definem a organiza o l gica dos dados usados pelo sistema e os relacionamentos entre esses dados Ap ndices V rios ndices podem ser inclu dos no documento Pode haver al m de ndice um ndice alfab tico normal um ndice de diagramas de fun es entre outros pertinentes Fonte SOMMERVILLE 2011 p 64 Para o desenvolvimento da nossa disciplina usarei modelos de documento de requisitos mais simplificados do que o apresentado na tabela acima O documento de requisitos trar detalhes de como o sistema funciona atualmente e quais funcionalidades o usu rio deseja para o novo sistema Abaixo segue um modelo de documento de requisitos para uma locadora de filmes Lembre se que deve ser a partir do documento de requisitos que faremos a modelagem do sistema que ser detalhada na pr xima unid

ENGENHARIA DE SOFTWARE

Contents

Download Pdf Manuals

Related Search

Related Contents