Eng Software

ISBN 978-85-8084-508-2
Professora Me. Mrcia Cristina Dadalto Pascutti
ENGENHARIA DE SOFTWARE
gradUao AnaLise e desenVoLViMento de sisteMas e sisteMas Para a internet
MARING-Pr 2012
Reitor: Wilson de Matos Silva Vice-Reitor: Wilson de Matos Silva Filho Pr-Reitor de Administrao: Wilson de Matos Silva Filho Pr-Reitor de EAD: Willian Victor Kendrick de Matos Silva Presidente da Mantenedora: Cludio Ferdinandi
NEAD - Ncleo de Educao a Distncia

Diretor Comercial, de Expanso e Novos Negcios: Marcos Gois Diretor de Operaes: Chrystiano Mincoff Coordenao de Sistemas: Fabrcio Ricardo Lazilha Coordenao de Polos: Reginaldo Carneiro Coordenao de Ps-Graduao, Extenso e Produo de Materiais: Renato Dutra Coordenao de Graduao: Ktia Coelho Coordenao Administrativa/Servios Compartilhados: Evandro Bolsoni Coordenao de Curso: Danillo Xavier Saes Gerente de Inteligncia de Mercado/Digital: Bruno Jorge Gerente de Marketing: Harrisson Brait Supervisora do Ncleo de Produo de Materiais: Nalva Aparecida da Rosa Moura Capa e Editorao: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, Jos Jhonny Coelho, Luiz Fernando Rokubuiti e Thayla Daiany Guimares Cripaldi Superviso de Materiais: Ndila de Almeida Toledo Reviso Textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janana Bicudo Kikuchi, Jaquelina Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.
Ficha catalogrfica elaborada pela Biblioteca Central - UniCesumar
CENTRO UNIVERSITRIO DE MARING. Ncleo de Educao a distncia: C397 Engenharia de software / Mrcia Cristina Dadalto Pascutti. Maring - PR, 2012. 168 p. Graduao Anlise e Desenvolvimento de Sistemas e Sistemas para Internet - EaD. 1. Engenharia de software. 2. Processamento eletrnico de dados. 3. EaD. I. Ttulo.
CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2
ISBN 978-85-8084-508-2
As imagens utilizadas neste livro foram obtidas a partir dos sites PHOTOS.COM e SHUTTERSTOCK.COM.
Av. Guedner, 1610 - Jd. Aclimao - (44) 3027-6360 - CEP 87050-390 - Maring - Paran - www.cesumar.br NEAD - Ncleo de Educao a Distncia - bl. 4 sl. 1 e 2 - (44) 3027-6363 - ead@cesumar.br - www.ead.cesumar.br
APRESENTAO DO REITOR
Viver e trabalhar em uma sociedade global um grande desafio para todos os cidados. A busca por tecnologia, informao, conhecimento de qualidade, novas habilidades para liderana e soluo de problemas com eficincia tornou-se uma questo de sobrevivncia no mundo do trabalho. Cada um de ns tem uma grande responsabilidade: as escolhas que fizermos por ns e pelos nossos far grande diferena no futuro. Com essa viso, o Centro Universitrio Cesumar assume o compromisso de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros. No cumprimento de sua misso promover a educao de qualidade nas diferentes reas do conhecimento, formando profissionais cidados que contribuam para o desenvolvimento de uma sociedade justa e solidria , o Centro Universitrio Cesumar busca a integrao do ensino-pesquisa-extenso com as demandas institucionais e sociais; a realizao de uma prtica acadmica que contribua para o desenvolvimento da conscincia social e poltica e, por fim, a democratizao do conhecimento acadmico com a articulao e a integrao com a sociedade. Diante disso, o Centro Universitrio Cesumar almeja reconhecimento como uma instituio universitria de referncia regional e nacional pela qualidade e compromisso do corpo docente; aquisio de competncias institucionais para o desenvolvimento de linhas de pesquisa; consolidao da extenso universitria; qualidade da oferta dos ensinos presencial e a distncia; bem-estar e satisfao da comunidade interna; qualidade da gesto acadmica e administrativa; compromisso social de incluso; processos de cooperao e parceria com o mundo do trabalho, como tambm pelo compromisso e relacionamento permanente com os egressos, incentivando a educao continuada. Professor Wilson de Matos Silva Reitor
ENGENHARIA DE SOFTWARE | Educao a Distncia
Seja bem-vindo(a), caro(a) acadmico(a)! Voc est iniciando um processo de transformao, pois quando investimos em nossa formao, seja ela pessoal ou profissional, nos transformamos e, consequentemente, transformamos tambm a sociedade na qual estamos inseridos. De que forma o fazemos? Criando oportunidades e/ou estabelecendo mudanas capazes de alcanar um nvel de desenvolvimento compatvel com os desafios que surgem no mundo contemporneo. O Centro Universitrio Cesumar, mediante o Ncleo de Educao a Distncia, o(a) acompanhar durante todo este processo, pois conforme Freire (1996): Os homens se educam juntos, na transformao do mundo. Os materiais produzidos oferecem linguagem dialgica e encontram-se integrados proposta pedaggica, contribuindo no processo educacional, complementando sua formao profissional, desenvolvendo competncias e habilidades, e aplicando conceitos tericos em situao de realidade, de maneira a inseri-lo(a) no mercado de trabalho. Ou seja, estes materiais tm como principal objetivo provocar uma aproximao entre voc e o contedo, desta forma, possibilita o desenvolvimento da autonomia em busca dos conhecimentos necessrios para a sua formao pessoal e profissional. Portanto, nossa distncia nesse processo de crescimento e construo do conhecimento deve ser apenas geogrfica. Utilize os diversos recursos pedaggicos que o Centro Universitrio Cesumar lhe possibilita. Ou seja, acesse regularmente o AVA Ambiente Virtual de Aprendizagem, interaja nos fruns e enquetes, assista s aulas ao vivo e participe das discusses. Alm disso, lembre-se de que existe uma equipe de professores e tutores que se encontra disponvel para sanar suas dvidas e auxili-lo(a) em seu processo de aprendizagem, possibilitando-lhe trilhar com tranquilidade e segurana sua trajetria acadmica. Ento, vamos l! Desejo bons e proveitosos estudos! Professora Ktia Solange Coelho Coordenadora de Graduao do NEAD - UniCesumar
APRESENTAO
Livro: ENGENHARIA DE SOFTWARE
Prezado(a) acadmico(a), com muito prazer que apresento a voc o livro de Engenharia de Software I. Sou a professora Mrcia 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 benefcio ao longo de sua vida como desenvolvedor de sistemas. Ministro esta disciplina em cursos de graduao h, praticamente, dezesseis anos. Inicialmente, a disciplina era chamada de Anlise 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 raciocnio. Mas foi uma experincia tima e espero que voc goste do que foi colocado aqui. A engenharia de software possui uma gama imensa de tpicos, que no seria possvel abordar em cinco unidades (como este livro est organizado), ento coloquei os assuntos iniciais, sem os quais no seria possvel 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 no 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, bom que voc entenda todo o contedo de uma unidade para passar para a prxima. Se ainda ficar com dvida, 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 esto estreitamente relacionadas. Na unidade I apresentarei alguns conceitos referentes disciplina. Voc notar, durante a leitura das outras unidades, que esses conceitos so utilizados com frequncia. A engenharia de software surgiu da necessidade de tornar o desenvolvimento de software
confivel, com etapas bem definidas, com custo e cronograma previsveis, o que, at a poca de 1968, quando o termo engenharia de software foi proposto, no acontecia. A proposta da engenharia de software, portanto, tornar o desenvolvimento de software um processo sistematizado, no qual podem ser aplicados tcnicas e mtodos necessrios para controlar a complexidade inerente aos grandes sistemas (SOMMERVILLE, 2007, p. 4). Gostaria de ressaltar que software compreende, alm dos programas, toda a documentao referente aos mesmos, sendo que a engenharia de software a disciplina que trata dessa documentao. Sendo assim, apresentarei a voc uma pequena parte dessa documentao, pois seria necessrio mais do que um livro para tratar da documentao completa que pode ser elaborada no desenvolvimento de um software. Outro ponto importante que necessrio deixar registrado que de nada vale uma documentao desatualizada, por isso, importante utilizar uma ferramenta CASE para criar e manter a documentao. Uma ferramenta CASE tambm um software, s que neste caso, auxilia o desenvolvedor e no o usurio final do sistema que est sendo desenvolvido. Depois, na segunda unidade, comearemos a aplicar os conceitos j estudados e mostrarei a voc que um processo de software genrico composto de algumas etapas bsicas que faro parte de qualquer modelo de processo de software. Essas etapas bsicas so: i) a especificao dos requisitos do software a ser desenvolvido; ii) o projeto e a implementao do software; iii) a validao do software e, finalmente iv) a evoluo do software. Nesta unidade, abordarei trs 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 prprio modelo, colocando as etapas na ordem que voc achar melhor para a sua empresa. A unidade III bastante especfica, 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 to importante. Um requisito deve estabelecer o que o sistema deve fazer, bem como as restries sobre seu funcionamento e implementao, podendo ser classificado em requisito funcional e no funcional. Os requisitos funcionais dizem respeito aos servios que o software deve fornecer, como, por exemplo, o cadastro dos pacientes de uma clnica odontolgica, a emisso de
um relatrio de vendas. J os requisitos no funcionais normalmente esto relacionados s propriedades emergentes do sistema, podendo ser aplicados ao sistema como um todo. Um exemplo de requisito no funcional: o sistema deve ser desenvolvido em seis meses. Todos esses requisitos, tanto os funcionais quanto os no 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 III. O exemplo bem simples, mas contm detalhes suficientes para a continuidade do processo de desenvolvimento de software. Ento, de posse do documento de requisitos, comearemos a estudar a penltima unidade do nosso livro, a unidade que trata da modelagem do sistema. Nesta unidade, utilizaremos os conceitos de orientao a objetos e de UML estudados na primeira unidade. A modelagem a parte fundamental de todas as atividades relacionadas ao processo de desenvolvimento de software, sendo que, os modelos que so construdos 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 por meio de diagramas, utilizando a UML como notao grfica. Na primeira unidade j explicamos a importncia da UML e agora comearemos 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 espcie de tutorial explicando a elaborao dos mesmos passo a passo. Isso foi feito para facilitar o seu entendimento, pois esses diagramas so 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, validao e evoluo de software. Assim, voc compreender todo o processo de software com as etapas que o englobam. O projeto de software onde so definidas as interfaces do sistema. Voc pode fazer isso j
utilizando uma linguagem de programao (de preferncia aquela em que voc vai implementar o sistema) ou ento alguma ferramenta CASE para prototipao de sistema. importante que o usurio 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 transformar todo o trabalho realizado at o momento em cdigo fonte. medida que o sistema vai sendo desenvolvido, cada programa vai sendo validado pelo desenvolvedor, mas isso s no basta. muito importante que a etapa de validao 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 usurios. Em todas estas etapas importante a aplicao das tcnicas da engenharia de software. Assim, chegamos ao final do nosso livro. Espero, sinceramente, que sua leitura seja agradvel e que esse contedo possa contribuir para seu crescimento pessoal e profissional. Prof. Mrcia.
10
SUMrio
UNIDADE I INTRODUO ENGENHARIA DE SOFTWARE SOFTWARE.............................................................................................................................19 ENGENHARIA DE SOFTWARE..............................................................................................20 TIPOS DE APLICAES DE SOFTWARE.............................................................................21 FERRAMENTAS CASE (cOmpUTEr-AIdEd sOFTwArE ENGINEErING)........................22 CONCEITOS BSICOS DE ORIENTAO A OBJETOS........................................................24 UML UNIFIED MODELING LANGUAGE..............................................................................32 HISTRICO DA UML...............................................................................................................34 FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML..................................................35 UNIDADE II PROCESSOS DE SOFTWARE PROCESSOS DE SOFTWARE...............................................................................................42 MODELOS DE PROCESSO DE SOFTWARE.........................................................................44 ATIVIDADES BSICAS DO PROCESSO DE SOFTWARE.....................................................54 ESPECIFICAO DE SOFTWARE.........................................................................................55 PROJETO E IMPLEMENTAO DE SOFTWARE..................................................................57 VALIDAO DE SOFTWARE..................................................................................................58 EVOLUO DE SOFTWARE..................................................................................................60
UNIDADE III REQUISITOS DE SOFTWARE REQUISITOS DE SOFTWARE................................................................................................67 REQUISITOS FUNCIONAIS E NO FUNCIONAIS.................................................................69 REQUISITOS DE USURIO....................................................................................................72 REQUISITOS DE SISTEMA.....................................................................................................72 O DOCUMENTO DE REQUISITOS DE SOFTWARE..............................................................73 REQUISITOS DE QUALIDADE................................................................................................78 ENGENHARIA DE REQUISITOS.............................................................................................80 ESTUDO DE VIABILIDADE.....................................................................................................81 LEVANTAMENTO E ANLISE DE REQUISITOS....................................................................83 ESPECIFICAO DE REQUISITOS........................................................................................89 VALIDAO DE REQUISITOS................................................................................................90 UNIDADE IV MODELAGEM DE SISTEMAS INTRODUO.........................................................................................................................97 MODELAGEM DE SISTEMAS.................................................................................................99 DIAGRAMA DE CASOS DE USO..........................................................................................101 ESTUDO DE CASO............................................................................................................... 112 DOCUMENTO DE REQUISITOS FBRICA DE COLCHES............................................ 112 DIAGRAMA DE CLASSES.................................................................................................... 115
RELACIONAMENTOS........................................................................................................... 116 MULTIPLICIDADE.................................................................................................................. 119 CLASSE ASSOCIATIVA.........................................................................................................120 ESTUDO DE CASO 1............................................................................................................122 ESTUDO DE CASO 2............................................................................................................123 PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE CASOS DE USO.............125 PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE CLASSES........................127 DOCUMENTO DE REQUISITOS CONTROLE DE ESTOQUE..........................................133 UNIDADE V PROJETO, TESTES E EVOLUO DE SOFTWARE PROJETO DE SOFTWARE...................................................................................................140 FORMATOS DE ENTRADAS/SADAS...................................................................................155 VALIDAO DE SOFTWARE................................................................................................158 TIPOS DE TESTES................................................................................................................159 EVOLUO DE SOFTWARE................................................................................................162
CONCLUSO.........................................................................................................................166 REFERNCIAS......................................................................................................................168
UNIDADE I
INTRODUO ENGENHARIA DE SOFTWARE

Professora Me. Mrcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Entender o que engenharia de software e qual a sua importncia. Estudar os conceitos bsicos de orientao a objetos necessrios para o entendimento da UML. Abordar a importncia da utilizao da UML para a modelagem de sistemas. Plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Conceitos bsicos sobre Software e Engenharia de Software Tipos de Aplicaes de Software Ferramentas CASE Conceitos Bsicos de Orientao a Objetos Introduo UML
INTRODUO
Fonte:SHUTTERSTOCK.com
Caro(a) aluno(a), nesta primeira unidade trataremos alguns conceitos relacionados engenharia de software como um todo que sero fundamentais para o entendimento de todas as unidades. O termo engenharia de software foi proposto, inicialmente, em 1968, em uma conferncia organizada para discutir o que era chamado de crise de software. Essa crise foi originada em funo do hardware, que nessa poca tinha seu poder de processamento e memria aumentados, sendo que o software deveria acompanhar esse avano. E o que se notou, na poca, que o desenvolvimento de grandes sistemas de maneira informal, sem seguir regras ou etapas pr-definidas, no era suficiente. O software desenvolvido at ento, no era confivel, no era desenvolvido dentro do tempo e custos previstos inicialmente, seu desempenho era insatisfatrio e era difcil de dar manuteno ao mesmo. Os custos em relao ao hardware estavam caindo, em funo de que a sua produo passou a ser em srie, porm, o custo do software no acompanhava essa queda, muitas vezes, sendo aumentado. A ideia inicial da engenharia de software era tornar o desenvolvimento de software um processo sistematizado, em que seriam aplicadas tcnicas e mtodos necessrios para controlar a complexidade inerente aos grandes sistemas (SOMMERVILLE, 2007, p. 4).
17
Apresentarei a voc o conceito de software e voc ver que software muito abrangente, englobando desde os programas escritos at a documentao associada a esse software. Cabe aqui ressaltar que essa documentao deve estar sempre atualizada, pois, caso contrrio, ela perde o seu sentido. Para ajudar nessa tarefa de manter a documentao em dia, podem ser utilizadas as ferramentas CASE, que tambm veremos nessa unidade. Um detalhe interessante que uma ferramenta CASE tambm um software. Depois, trataremos sobre a engenharia de software como um todo. Neste livro, abordarei somente alguns tpicos da engenharia, mas, com certeza, precisaramos 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 sero mostrados neste livro so simples para que seja mais fcil entendermos os conceitos apresentados, mas a engenharia de software pode ser aplicada a um conjunto imenso de tipos diferentes de solues que requerem software. Voc, com certeza, j deve ter utilizado um micro-ondas. Ento, quando voc pressiona a tecla pipoca, um software embutido que est sendo executado. Portanto, com a tecnologia que temos hoje nossa disposio, possvel encontrar o software em muitos lugares. Voc vai perceber que grande parte da documentao do sistema produzido a partir da aplicao das tcnicas e mtodos da engenharia de software, grfica, ou seja, acontece atravs de diagramas. Como a UML (Unified Modeling Language Linguagem de Modelagem Unificada) a linguagem para modelagem mais utilizada atualmente, vamos tambm utiliz-la neste livro. Porm, para entender qualquer diagrama da UML necessrio conhecer alguns conceitos relacionados orientao a objetos, como, por exemplo, classe, objeto, herana. Aps esses conceitos serem apresentados que iniciaremos o estudo da UML. Nesta unidade, veremos uma introduo sobre a UML. Voc ver como ela surgiu e ver
18
tambm que uma forma de representao orientada a objetos bastante recente. Na unidade III que estudaremos dois dos diagramas da UML, por isso importante entender, nesta unidade, os conceitos relacionados UML.
SOFTWARE
De acordo com Sommerville (2007, p. 4), o software composto no somente pelos programas, mas tambm pela documentao associada a esses programas. Para Pressman (2011, p. 32), o software possui, pelo menos, trs caractersticas que o diferenciam do hardware: 1. Software desenvolvido ou passa por um processo de engenharia, no sendo fabricado no sentido clssico. Apesar de existir semelhanas entre o desenvolvimento de software e a fabricao de hardware, essas atividades so muito diferentes. Os custos de software concentram-se no processo de engenharia, por causa disso os projetos de software no podem ser conduzidos como se fossem projetos de fabricao. 2. Software no se desgasta. Normalmente, o hardware apresenta taxas de defeitos mais altas no incio de sua vida, porm esses defeitos so corrigidos tendo assim a taxa decrescida, ou seja, atingindo um nvel estvel. Porm, com o uso, o hardware pode se desgastar devido poeira, m utilizao, temperaturas extremas e outros. J com o software diferente, ou seja, ele no est sujeito aos problemas ambientais, como o hardware. Em relao aos problemas iniciais, com o software tambm acontece assim, pois alguns defeitos ainda podem passar pela etapa de validao do software. Quando um componente de hardware se desgasta, ele normalmente trocado por um novo componente e o hardware volta a funcionar. Com o software isso no acontece, no tem como simplesmente trocar o componente, pois quando um erro acontece no hardware, pode ser de projeto, de requisito mal definido, levando o software a sofrer manuteno, que pode ser considerada mais complexa que a do hardware. Embora a indstria caminhe para a construo com base em componentes, a maioria
19
dos softwares continua a ser construda de forma personalizada (sob encomenda). A reutilizao de componentes de hardware parte natural do seu processo de engenharia, j para o software algo que apenas comeou a ser alcanado (PRESSMAN, 2011, p. 34). Os componentes reutilizveis de software so criados para que o desenvolvedor possa se concentrar nas partes do projeto que representam algo novo. Esses componentes encapsulam dados e o processamento aplicado a eles, possibilitando criar novas aplicaes a partir de partes reutilizveis. Na unidade II trataremos sobre Engenharia de Software Orientada a Reuso.
De acordo com Sommerville (2011, p. 5), a engenharia de software uma disciplina de engenharia cujo foco est em todos os aspectos da produo de software, desde os estgios iniciais da especificao do sistema at sua manuteno. Como dissemos na introduo desta unidade, o termo engenharia de software relativamente novo e foi proposto para tornar o desenvolvimento de software sistemtico, podendo ser realizado com padres de qualidade, dentro do cronograma e do oramento 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 avanados, portanto preciso que os engenheiros de software sejam capazes de produzir sistemas confiveis de maneira econmica e rpida. 2. A longo prazo, normalmente, mais barato usar mtodos e tcnicas propostos pela engenharia de software, ao invs de somente escrever os programas como se fossem algum projeto pessoal. Para a maioria dos sistemas, o maior custo est na sua manuteno, ou seja, nas alteraes que so realizadas depois que o sistema implantado.
20
Alguns Fundamentos da Engenharia de Software Por Wilson de Pdua Paula Filho O que Engenharia de Software? a mesma coisa que Cincia da Computao? Ou uma entre muitas especialidades da Cincia da Computao? Ou dos Sistemas de Informao, ou do Processamento de Dados, ou da Informtica, ou da Tecnologia da Informao? Ou uma especialidade diferente de todas as anteriores? Na maioria das instituies brasileiras de ensino superior, o conjunto de conhecimentos e tcnicas conhecido como Engenharia de Software ensinado em uma ou duas disciplinas dos cursos que tm os nomes de Cincia da Computao, Informtica ou Sistemas de Informao. Raramente, em mais disciplinas, muitas vezes opcionais, e muitas vezes oferecidas apenas em nvel de ps-graduao. Algumas instituies oferecem cursos de ps-graduao em Engenharia de Software, geralmente no nvel de especializao. Neste artigo voc vai entender os fundamentos da engenharia de software. O artigo completo pode ser acessado no endereo abaixo. Fonte: <http://www.devmedia.com.br/artigo-engenharia-de-software-alguns-fundamentos-da-engenharia-de-software/8029>. Acesso em: 02 jun. 2012.
TIPOS DE APLICAES DE SOFTWARE

Atualmente, com o software sendo utilizado em praticamente todas as atividades exercidas pelas pessoas, existe uma grande variedade de aplicaes de software. Vamos ver algumas delas, de acordo com Pressman (2011, p. 34),: Software de sistema so aqueles programas desenvolvidos para atender a outros programas, como por exemplo, editores de texto, compiladores e sistemas operacionais. Software de aplicao so programas desenvolvidos para solucionar uma neces-
21
sidade especfica de negcio, processando dados comerciais ou tcnicos de forma que ajude nas operaes comerciais ou tomadas de deciso pelos administradores da empresa. Software cientfico/de engenharia so aplicaes que vo da astronomia vulcanologia, da biologia molecular fabricao automatizada, normalmente utilizando algoritmos para processamento numrico pesado. Software embutido controla ou gerencia dispositivos de hardware, como por exemplo, celular, painel do micro-ondas, controle do sistema de freios de um veculo. Software de inteligncia artificial utiliza algoritmos no numricos para solucionar problemas complexos que no poderiam ser solucionados pela computao ou anlise direta, como por exemplo, sistemas especialistas, robtica, redes neurais artificiais.
No existe computador que tenha bom senso. Marvin Minsky, cofundador do laboratrio de inteligncia artifi cial do Instituto de Tecnologia de Massachusetts.
FERRAMENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING)

Segundo Sommerville (2007, p. 56), 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 programas e os testes. As ferramentas CASE podem incluir editores de projeto, dicionrios de dados, compiladores, depuradores, ferramentas de construo de sistemas entre outros. Sommerville ainda nos mostra alguns exemplos de atividades que podem ser automatizadas utilizando-se CASE, entre elas: 1. O desenvolvimento de modelos grficos de sistemas, como parte das especificaes de requisitos ou do projeto de software. 2. A compreenso de um projeto utilizando-se um dicionrio de dados que contm informaes sobre as entidades e sua relao em um projeto. 3. A gerao de interfaces com usurios, a partir de uma descrio grfica da interface, que criada interativamente pelo usurio.
22
4. A depurao de programas, pelo fornecimento de informaes sobre um programa em execuo. 5. A traduo automatizada de programas, a partir de uma antiga verso de uma linguagem de programao, como Cobol, para uma verso mais recente. A tecnologia CASE est atualmente disponvel 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 classificao 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: so aquelas ferramentas que esto voltadas para as primeiras fases do processo de desenvolvimento de sistemas, como anlise de requisitos, projeto lgico e documentao. So utilizadas por analistas e pessoas mais interessadas na soluo do problema do que na implementao. Lower CASE ou L-CASE ou Back-End: praticamente o oposto das anteriormente citadas, oferecem suporte nas ltimas fases do desenvolvimento, como codificao, testes e manuteno. Integrated CASE ou I-CASE: este tipo de ferramenta, alm de englobar caractersticas das Upper e Lower CASEs, ainda oferecem outras caractersticas, como por exemplo, controle de verso. Entretanto, esse tipo de ferramenta somente utilizado em projetos de desenvolvimento muito grandes, por serem bastante caras e difceis de operar. Best in Class ou Kit de Ferramenta: semelhante as I-CASE, os Kits de Ferramenta tambm acompanham todo o ciclo de desenvolvimento, entretanto, possuem a propriedade de conjugar sua capacidade a outras ferramentas externas complementares, que variam de acordo com as necessidades do usurio. Para um melhor entendimento, podemos compar-las a um computador sem o kit multimdia, as Best in Class seriam o computador que funciona normalmente, e as outras ferramentas fariam o papel do kit multimdia, promovendo um maior potencial de trabalho mquina. So mais usadas para desenvolvimento corporativo, apresentando controle de acesso, verso, repositrios de dados entre outras caractersticas.
23
A segunda forma divide as Ferramentas CASE em orientadas funo e orientadas atividade: Orientadas funo: seriam as Upper CASE e Lower CASE. Baseiam-se na funcionalidade das ferramentas, ou seja, so aquelas que tm funes 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). Orientadas a atividade: Seriam as Best In Class e as I-CASE, que processam a atividades como especificaes, modelagem e implementao.
CONCEITOS BSICOS DE ORIENTAO A OBJETOS

A UML totalmente baseada no paradigma de orientao a objetos (OO). Sendo assim, para compreend-la corretamente, precisamos antes estudar alguns dos conceitos relacionados orientao a objetos. Objetos Segundo Melo (2004, p.15), um objeto qualquer coisa, em forma concreta ou abstrata, que exista fsica ou apenas conceitualmente no mundo real. So exemplos de objetos: cliente, professor, carteira, caneta, carro, disciplina, curso, caixa de dilogo. Os objetos possuem caractersticas e comportamentos.
24
Classes Uma classe uma abstrao de um conjunto de objetos que possuem os mesmos tipos de caractersticas e comportamentos, sendo representada por um retngulo que pode possuir at trs divises. A primeira diviso armazena o nome da classe; a segunda, os atributos (caractersticas) da classe; e a terceira, os mtodos. Geralmente, uma classe possui atributos e mtodos, porm, possvel encontrar classes que contenham apenas uma dessas caractersticas ou mesmo nenhuma quando se tratar de classes abstratas. A figura abaixo apresenta um exemplo de classe.
Exemplo de uma Classe De acordo com Melo (2004, p. 18), o ponto inicial para identificao de classes num documento de requisitos (I) assinalar os substantivos. Note que esses substantivos podem levar a objetos fsicos (como cliente, livro, computador) ou objetos conceituais (como reserva, cronograma, norma). Em seguida, (II) preciso identificar somente os objetos que possuem importncia para o sistema, verificando o que realmente consiste em objeto e o que consiste em atributo. Ainda (III) preciso fazer uma nova anlise dos requisitos para identificar classes implcitas no contexto trabalhado, (IV) excluir classes parecidas ou juntar duas classes em uma nica classe. Vale a pena ressaltar que esse processo ser iterativo e no ser possvel definir todas as classes de uma s vez.
25
Atributos Uma classe, normalmente, possui atributos que representam as caractersticas 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. De acordo com Guedes (2007, p. 32), na segunda diviso 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 sero os seus valores, sendo que um objeto corresponde a uma instncia 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 instncia com os seguintes valores para cada atributo, respectivamente, Mrcia, feminino e 22/03/1969. Dessa forma, em um sistema, devemos trabalhar com as instncias (objetos) de uma classe, pois os valores de cada atributo so carregados nas instncias (MELO, 2004, p. 17). A figura abaixo mostra um exemplo de classe com atributos.
Exemplo de Classe com Atributos
26
Mtodos Mtodos so processos ou servios realizados por uma classe e disponibilizados para uso de outras classes em um sistema e devem ficar armazenados na terceira diviso da classe. Os mtodos so as atividades que uma instncia de uma classe pode executar (GUEDES, 2007, p. 33). Um mtodo pode receber ou no parmetros (valores que so utilizados durante a execuo do mtodo) e pode, tambm, retornar valores, que podem representar o resultado da operao executada ou somente indicar se o processo foi concludo com sucesso ou no. Assim, um mtodo representa um conjunto de instrues que so executadas quando o mtodo 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 mtodos.
Exemplo de Classe com Atributos e Mtodos Visibilidade De acordo com Guedes (2007, p. 34), a visibilidade um smbolo que antecede um atributo ou mtodo e utilizada para indicar seu nvel de acessibilidade. Existem basicamente trs modos de visibilidade: pblico, protegido e privado. O smbolo de mais (+) indica visibilidade pblica, ou seja, significa que o atributo ou mtodo pode ser utilizado por objetos de qualquer classe.
27
O smbolo de sustenido (#) indica que a visibilidade protegida, ou seja, determina que apenas objetos da classe possuidora do atributo ou mtodo ou de suas subclasses (conceito apresentado a seguir) podem acess-lo. O smbolo de menos (-) indica que a visibilidade privada, ou seja, somente os objetos da classe possuidora do atributo ou mtodo podero utiliz-lo.
Note que no exemplo da classe Cliente, tanto os atributos quanto os mtodos apresentam sua visibilidade representada esquerda de seus nomes, em que os atributos nome, sexo e data_nascimento possuem visibilidade privada, pois apresentam o smbolo de menos (-) esquerda da sua descrio. J os mtodos IncluirNovoCliente() e AtualizarCliente(), possuem visibilidade pblica, como indica o smbolo + acrescentado esquerda da sua descrio. Herana (Generalizao/Especializao) A herana permite que as classes de um sistema compartilhem atributos e mtodos, otimizando assim o tempo de desenvolvimento, com a diminuio de linhas de cdigo, facilitando futuras manutenes (GUEDES, 2007, p. 35). A herana (ou generalizao/especializao) acontece entre classes gerais (chamadas de superclasses ou classes-me) e classes especficas (chamadas de subclasses ou classes-filha) (BOOCH, 2005, p. 66). A herana significa que os objetos da subclasse podem ser utilizados em qualquer local em que a superclasse ocorra, mas no vice-versa. A subclasse herda as propriedades da me, ou seja, seus atributos e mtodos, e tambm podem possuir atributos e mtodos prprios, alm daqueles herdados da classe-me. De acordo com Guedes (2007, p.35), a vantagem do uso da herana que, quando uma classe declarada com seus atributos e mtodos especficos e aps isso uma subclasse derivada, no necessrio redeclarar os atributos e mtodos j definidos, ou seja, por meio da herana a subclasse os herda automaticamente, permitindo a reutilizao do cdigo j pronto. Assim, preciso somente declarar os atributos ou mtodos restritos da subclasse, tornando o processo
28
de desenvolvimento mais gil, alm de facilitar as manutenes futuras, pois, em caso de uma alterao, ser necessrio somente alterar o mtodo da superclasse para que todas as subclasses estejam tambm atualizadas. A figura abaixo apresenta um exemplo de herana, explicitando os papis de superclasse e subclasse e apresentando tambm o smbolo de herana da UML, uma linha que liga as classes com um tringulo tocando a superclasse.
Exemplo de Herana (generalizao/especializao) Fonte: a autora A figura acima mostra a superclasse Cliente com os atributos nome, endereo, cidade, UF e CEP e os mtodos IncluirNovoCliente() e AtualizarCliente(). A subclasse Pessoa_Fisica herda esses
29
atributos e mtodos, alm de possuir os atributos CPF, RG, sexo e data_nascimento e o mtodo ValidarCPF(). A seta que aponta para a superclasse Cliente indica a herana. A subclasse Pessoa_Juridica tambm herda todos os atributos e mtodos da superclasse Cliente, alm de possuir os atributos CNPJ, inscrio_estadual e razo_social e o mtodo ValidarCNPJ(). Quando olhamos a figura acima, notamos que a classe Cliente a mais genrica e as classes Pessoa_Fisica e Pessoa_Juridica so as mais especializadas. Ento, podemos dizer que generalizamos quando partimos das subclasses para a superclasse, e especializamos quando fazemos o contrrio, ou seja, quando partimos superclasse para as subclasses. Polimorfismo O conceito de polimorfismo est associado herana, pois o mesmo trabalha com a redeclarao de mtodos previamente herdados por uma classe. Esses mtodos, embora parecidos, diferem de alguma forma da implementao utilizada na superclasse, sendo preciso implement-los novamente na subclasse. Mas, a fim de no ter que alterar o cdigo-fonte, acrescentando uma chamada a um mtodo com um nome diferente, redeclara-se o mtodo com o mesmo nome declarado na superclasse (GUEDES, 2007, p. 36). De acordo com Lima (2009, p. 26), polimorfismo o princpio em que classes derivadas (as subclasses) e uma mesma superclasse podem chamar mtodos que tm o mesmo nome (ou a mesma assinatura), mas possuem comportamentos diferentes em cada subclasse, produzindo resultados diferentes, dependendo de como cada objeto implementa o mtodo. Ou seja, podem existir dois ou mais mtodos com a mesma nomenclatura, diferenciandose na maneira como foram implementados, sendo o sistema responsvel por verificar se a classe da instncia em questo possui o mtodo declarado nela prpria 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.
30
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 instncia da classe e um mtodo chamado Saque. Esse mtodo somente diminui o valor a ser debitado do saldo da conta se este possuir o valor suficiente. Caso contrrio, a operao no poder ser realizada, 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 prprio chamado limite e possui tambm os atributos herdados da superclasse. O atributo limite define o valor extra que pode ser sacado alm do valor contido no saldo da conta. Por esse motivo, a classe Conta_Especial apresenta uma
31
redefinio do mtodo Saque, porque a rotina do mtodo Saque da classe Conta_Especial diferente a do mtodo Saque declarado na classe Conta_Comum, pois preciso incluir o limite da conta no teste para determinar se o cliente pode ou no retirar o valor solicitado. No entanto, o nome do mtodo permanece o mesmo; apenas no momento de executar o mtodo, o sistema dever verificar se a instncia que o chamou pertence classe Conta_Comum ou classe Conta_Especial, executando o mtodo definido na classe em questo (GUEDES, 2007, p. 37).
<http://www.youtube.com/watch?v=MnJLeYAno4o&feature=relmfu>. Vdeo que mostra uma introduo aos conceitos de orientao a objetos.
UML UNIFIED MODELING LANGUAGE
Fonte: <http://onlywhatmatters.wordpress.com/2011/02/20/uml-unified-modeling-language/>
32
Segundo Booch (2005, p. 13), a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) uma linguagem-padro para a elaborao da estrutura de projetos de software, podendo ser utilizada para a visualizao, especificao, construo e documentao de artefatos de software, por meio do paradigma de Orientao a Objetos. A UML tem sido a linguagem-padro de modelagem de software adotada internacionalmente pela indstria de Engenharia de Software (GUEDES, 2007, p. 13). A UML no uma linguagem de programao, mas uma linguagem de modelagem, que tem como meta auxiliar os engenheiros de software a definir as caractersticas do software, tais como seus requisitos, seu comportamento, sua estrutura lgica, a dinmica de seus processos e at mesmo suas necessidades fsicas em relao ao equipamento sobre o qual o sistema dever ser implantado. Todas essas caractersticas so definidas por meio da UML antes do incio da implementao 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 evolucionrio, ou qualquer outro processo que esteja sendo utilizado para o desenvolvimento do software. A notao UML utiliza diversos smbolos grficos, existindo uma semntica bem definida para cada um deles, sendo possvel elaborar diversos modelos. A UML tem sido empregada de maneira efetiva em sistemas cujos domnios abrangem: sistemas de informaes corporativos, servios bancrios e financeiros, transportes, servios distribudos baseados na Web entre outros. Porm, a UML no se limita modelagem de software, podendo modelar sistemas como o fluxo de trabalho no sistema legal, a estrutura e o comportamento de sistemas de sade e o projeto de hardware (BOOCH, 2005, p. 17).
33
HISTRICO DA UML
A UML originou-se da juno dos Mtodo Booch de Grady Booch, Mtodo OMT (Object Modeling Technique) de Rumbaugh e do mtodo OOSE (Object-Oriented Software Engineering) de Jacobson. Esses eram, at meados da dcada de 1990, as trs 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 esforos para a criao da UML. O foco inicial do projeto era a unificao dos mtodos Booch e OMT, o que resultou no lanamento do Mtodo Unificado no final de 1995. Logo em seguida, Jacobson juntou-se a Booch e Rumbaugh na Rational Software e seu mtodo OOSE comeou tambm a ser incorporado nova metodologia (BOOCH, 2005). O trabalho de Booch, Jacobson e Rumbaugh, conhecidos popularmente como Os Trs Amigos, resultou no lanamento, em 1996, da primeira verso da UML propriamente dita, que foi chamada de verso 0.9. To logo a primeira verso foi lanada, diversas empresas de software passaram a contribuir com o projeto, estabelecendo um consrcio de UML com vrias empresas que desejavam dedicar recursos com o objetivo de trabalhar para uma definio mais forte e completa da UML, criando-se assim a verso 1.0 da UML. Essa verso foi oferecida para padronizao 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 verso revisada da UML (verso 1.1), que foi novamente oferecida para padronizao ao OMG. Finalmente, a UML foi adotada pela OMG em novembro de 1997, como uma linguagem padro
34
de modelagem, sendo que sua manuteno ficou sob responsabilidade da RTF (Revision Task Force), pertencente OMG. O objetivo da RTF realizar revises nas especificaes, referentes a erros, inconsistncias, ambiguidades e pequenas omisses, de acordo com os comentrios da comunidade em geral (MELO, 2004, p. 31). Porm, essas revises no devem provocar uma grande mudana no escopo original da proposta de padronizao. Nestes ltimos anos aconteceram as seguintes revises: 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 relatrio provisrio da UML 1.5, publicada em maro de 2003. No incio de 2005, a verso oficial da UML 2.0, foi adotado pelo OMG. Hoje, a UML est em sua verso 2.4.1 e sua documentao oficial pode ser consultada atravs do endereo <www.uml.org>. A grande mudana aconteceu na verso 2.0, sendo que a maioria da bibliografia disponvel atualmente, inclusive a que est sendo utilizada na consulta para produo deste livro, trata dessa verso.
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 realizao 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 caracterstica. 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 criao da UML, sendo 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 tambm a construo de modelos de dados com possibilidade de exportao para construo da base de dados ou realizao de engenharia reversa de uma base de dados existente. Em
35
20 de fevereiro de 2003, a empresa Rational foi adquirida pela IBM e agora a ferramenta chama-se sucedido pelo IBM Rational Architect. Maiores informaes sobre esta ferramenta podem ser consultadas no endereo <www.rational.com>. Astah Professional: uma ferramenta para criao de diagramas UML, possuindo uma verso gratuita, o Astah Community, e outras verses pagas. A verso gratuita, que pode ser obtida no endereo <http://astah.net/download>, possui algumas restries de funes, porm 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 verso que pode ser baixada gratuitamente, a Community Edition, porm essa verso no suporta todos os servios e opes disponveis nas verses Standard ou Professional da ferramenta. Mas, para quem deseja praticar a UML, a verso gratuita uma boa alternativa, apresentando um ambiente amigvel e de fcil compreenso. O download das diferentes verses da ferramenta pode ser feito em: <http://www.visual-paradigm.com>. Enterprise Architect: esta ferramenta no possui uma edio gratuita como as anteriores, porm uma das ferramentas que mais oferecem recursos compatveis com a UML 2. Uma verso Trial para avaliao dessa ferramenta pode ser obtida atravs do site <www. sparxsystems.com.au>.
CONSIDERAES FINAIS
Nesta primeira unidade foram apresentados alguns conceitos bsicos sobre engenharia de software que sero 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 preciso da engenharia para o desenvolvimento de software, pois at aquela poca, desenvolver um software era algo que no podia ser mensurado, nem em relao ao tempo, nem em relao ao custo, levando-se, normalmente, muito mais tempo do que o previsto. E o que acontecia era que no se tinha uma regra, uma sequncia de atividades para o desenvolvimento. Voc vai ver na prxima unidade que, para tentar solucionar esse problema, os estudiosos da engenharia de software
36
propuseram vrios 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 prximas unidades. Outro conceito importante que foi tratado nesta primeira unidade o conceito de software. Algumas pessoas que conheo acham que desenvolver software simplemesmente sentar em frente ao computador e escrever as linhas de cdigo. Voc percebeu que sim, isso faz parte do software, mas que desenvolver software muito mais abrangente, pois o software envolve, alm dos programas, a documentao, 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 elaborao de vrios diagramas. No trataremos da implementao propriamente dita, pois isso voc ver em outras disciplinas do curso. A implementao muito importante, por isso voc ter disciplinas dedicadas a essa tarefa. Todas as etapas da engenharia de software podem ser desenvolvidas com o auxlio de ferramentas CASE, que, conforme vimos, um software desenvolvido com o objetivo de auxiliar o desenvolvedor nas tarefas executadas durante o desenvolvimento (desde o seu incio at a implantao do software para o usurio). Em nossa disciplina de engenharia de software vamos utilizar a ferramenta Astah, que voc pode baixar gratuitamente no endereo mencionado nesta unidade. Sua instalao bastante simples e voc j pode deixar a ferramenta instalada para uso nas prximas unidades. Estudamos tambm vrios conceitos de orientao a objetos que utilizaremos em nossa disciplina e, com certeza, voc tambm vai utilizar quando for estudar, por exemplo, alguma linguagem orientada ao objeto, como Java. Portanto, o entendimento desses conceitos ser de suma importncia para todo o curso. E, finalmente, apresentei a voc um breve histrico do que a UML e como ela foi concebida. Utilizaremos a linguagem UML para a elaborao de diversos diagramas. Note que essa uma linguagem padro, universal, ou seja, um diagrama produzido em nossa disciplina pode ser lido por algum que conhea UML e que esteja do outro lado do mundo. Essa primeira unidade foi somente um aperitivo. Agora vamos passar a estudar assuntos especficos da disciplina e voc vai perceber que a engenharia de software muito importante para o desenvolvimento de um software.
37
ATIVIDADE DE AUTOESTUDO
1. Uma classe um conjunto de objetos que compartilham os mesmos atributos, mtodos e relacionamentos. Sendo assim: a) Explique o que significa instanciar uma classe. b) Descreva o que so atributos. 2. Um dos principais recursos da orientao a objetos a Herana entre classes, uma vez que esse recurso pode reduzir substancialmente as repeties nos projetos e programas orientados a objetos. Dentro deste contexto: a) Explique o que Herana. b) Crie um exemplo de Herana com no mnimo trs classes. Neste exemplo devem aparecer atributos tanto na superclasse quanto nas subclasses.
38
UNIDADE II
PROCESSOS DE SOFTWARE
Professora Me. Mrcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Compreender os conceitos de processo de software e modelos de processo de software. Mostrar as atividades bsicas do processo de software. Mostrar trs modelos de processo de software. Plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Processos de Software Modelos de Processo de Software Atividades Bsicas do Processo de Software
INTRODUO
Caro(a) aluno(a), na primeira unidade voc aprendeu alguns conceitos bsicos relacionados Engenharia de Software. A partir de agora voc comear a estudar assuntos mais especficos 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 tambm problemas que vo desde o no cumprimento dos prazos estabelecidos para o seu desenvolvimento at a falta de qualidade do software desenvolvido. Um software no pode ser desenvolvido de qualquer jeito, sem seguir critrios, sem que se saiba qual o prximo 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 so utilizados por muitas empresas. Esses modelos so: modelo em cascata, desenvolvimento incremental e engenharia de software baseada em componentes. Mas, importante ressaltar que no preciso seguir um
41
desses modelos que j esto prontos, ou seja, a empresa que vai desenvolver software pode criar o seu prprio modelo. Porm, imprescindvel que esse modelo seja seguido. Existem algumas atividades bsicas que fazem parte de um processo de software. Estudaremos cada uma dessas atividades: especificao de software, projeto e implementao de software, validao de software e evoluo 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, mas com o mesmo significado. Voc ver tambm que uma atividade pode se desdobrar em vrias etapas ou subatividades.
PROCESSOS DE SOFTWARE
Para que um software seja produzido so necessrias diversas etapas, compostas de uma srie 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 programao (por exemplo, o Java ou C) ou ento a ampliao e a modificao de sistemas j em utilizao pelos usurios. Segundo Sommerville (2011), existem muitos processos de software diferentes, porm todos devem incluir quatro atividades fundamentais para a engenharia de software: 1. Especificao de software. necessrio que o cliente defina as funcionalidades do software que ser desenvolvido, bem como defina todas as suas restries operacionais. 2. Projeto e implementao de software. O software deve ser confeccionado seguindo as especificaes definidas anteriormente. 3. Validao de software. O software precisa ser validado para garantir que ele faz o que o cliente deseja, ou seja, que ele atenda s especificaes de funcionalidade. 4. Evoluo de software. As funcionalidades definidas pelo cliente durante o desenvolvimento do software podem mudar e o software precisa evoluir para atender a essas mudanas.
42
Vamos estudar detalhadamente cada uma das atividades mencionadas acima durante a nossa disciplina, inclusive utilizando ferramentas automatizadas (ferramentas CASE, j estudadas em nossa unidade I) para nos auxiliar na elaborao dos diversos documentos que sero necessrios. Para Sommerville (2011, p. 19), os processos de software so complexos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decises e fazer julgamentos. No existe um processo ideal, a maioria das organizaes desenvolve os prprios processos de desenvolvimento de software. Mas o que acontece que nem sempre as empresas aproveitam as boas tcnicas da engenharia de software em seu desenvolvimento de software. E, normalmente, o software no atende aos requisitos do usurio, 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, porm, importante ressaltar que todas essas atividades so de extrema importncia e o processo de software adotado pela empresa no deve deixar de considerar nenhuma das etapas.
O processo de desenvolvimento de software e a utilizao de ferramentas CASE Por Maria Clara dos Santos Pinto Silveira A presente dissertao situa-se na rea das ferramentas CASE. apresentado um estudo dos conceitos fundamentais da Engenharia de Software e so abordados diversos problemas relacionados com o desenvolvimento de software. So tambm apresentados os paradigmas mais conhecidos e algumas metodologias para o desenvolvimento de software. Registra ainda as caractersticas, vantagens e desvantagens das ferramentas
43
CASE. Nesta Dissertao efetuado um estudo sobre a sistematizao do caminho a percorrer na escolha de um ambiente CASE. Para tal so analisadas questes como: metodologia a utilizar, deciso a tomar quanto ao produto ou produtos que correspondem s necessidades e capacidades da organizao, seleo do fornecedor, nvel de formao exigida e custos envolvidos. Para ilustrar este estudo foi desenvolvida uma aplicao que permite ao departamento de qualidade de uma indstria de lacticnios gerir todas as amostras e anlises efetuadas ao nvel do produtor e do processo de fabrico. Nesta aplicao 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: <http://repositorio-aberto.up.pt/handle/10216/12914>. Acesso em: 02 jun. 2012.
importante ressaltar 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 prxima seo veremos alguns modelos de processo de software e veremos tambm que possvel a empresa adotar um processo de software prprio, 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 so necessrias para que um software seja produzido. Sommerville (2007) diz que um modelo de processo de software uma representao 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 tambm os papis das pessoas envolvidas na engenharia de software. Alm disso, cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informaes parciais sobre o processo.
44
Na literatura existem diversos modelos de processo de software. Aqui irei mostrar somente trs desses modelos e, em seguida, mostrarei as atividades bsicas que esto presentes em, praticamente, todos os modelos de processos de software. Os modelos de processo que mostrarei foram retirados de Sommerville (2011, p.20) e so: 1. Modelo em Cascata. Esse modelo considera as atividades de especificao, desenvolvimento, validao e evoluo, que so fundamentais ao processo, e as representa como fases separadas, como a especificao de requisitos, o projeto de software, a implementao, os testes e assim por diante (SOMMERVILLE, 2011). 2. Desenvolvimento Incremental. Esse modelo intercala as atividades de especificao, desenvolvimento e validao. Um sistema inicial rapidamente desenvolvido a partir de especificaes abstratas, que so ento refinadas com informaes do cliente, para produzir um sistema que satisfaa as suas necessidades, produzindo vrias verses do software (SOMMERVILLE, 2011). 3. Engenharia de Software Orientada a Reuso. Esse modelo parte do princpio de que existem muitos componentes que podem ser reutilizveis. O processo de desenvolvimento do sistema se concentra em combinar vrios 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
45
O modelo cascata ou ciclo de vida clssico, considerado o paradigma mais antigo da engenharia de software, sugere uma abordagem sequencial e sistemtica para o desenvolvimento de software, comeando com a definio dos requisitos por parte do cliente, avanando pelas atividades de projeto e implementao de software, testes, implantao, culminando no suporte contnuo do software concludo. Segundo Sommerville (2007, p. 44), os principais estgios do modelo em cascata demonstram as atividades fundamentais do desenvolvimento: 1. Anlise e definio de requisitos As funes, as restries e os objetivos do sistema so estabelecidos por meio da consulta aos usurios do sistema. Em seguida, so definidos em detalhes e servem como uma especificao 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 identificao e a descrio das abstraes fundamentais do sistema de software e suas relaes. 3. Implementao e teste de unidades Durante esse estgio, 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 especificao. 4. Integrao e teste de sistemas As unidades de programa ou programas individuais so 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. Operao e manuteno Normalmente (embora no necessariamente), esta a fase mais longa do ciclo de vida. O sistema instalado e colocado em operao. A manuteno envolve corrigir erros que no foram descobertos em estgios anteriores do ciclo de vida, melhorando a implementao das unidades de sistema e aumentando as funes desse sistema medida que novos requisitos so descobertos. Um estgio somente pode ser iniciado depois que o estgio anterior tenha sido concludo. Porm, Sommerville (2011, p. 21) afirma que na prtica esses estgios acabam se sobrepondo, alimentando uns aos outros de informaes. Por exemplo, durante o projeto, os problemas com os requisitos so identificados. O que acontece que um processo de software no
46
um modelo linear simples, sequencial, mas envolve iteraes entre as fases. Os artefatos de software que so produzidos em cada uma dessas fases podem ser modificados para refletirem todas as alteraes realizadas em cada um deles. Pressman (2011) aponta alguns problemas que podem ser encontrados quando o modelo cascata aplicado: 1. Os projetos que acontecem nas empresas dificilmente seguem o fluxo sequencial proposto pelo modelo. Alguma iterao sempre ocorre e traz problemas na aplicao do paradigma. 2. Na maioria das vezes, o cliente no consegue definir claramente todas as suas necessidades e o modelo cascata requer essa definio no incio das atividades. Portanto, esse modelo tem dificuldade em acomodar a incerteza natural que existe no comeo de muitos projetos. 3. Uma verso operacional do sistema somente estar disponvel no final do projeto, ou seja, o cliente no ter nenhum contato com o sistema durante o seu desenvolvimento. Isso leva a crer que se algum erro grave no for detectado durante o desenvolvimento, o sistema no 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 so fixos e tenham pouca probabilidade de serem alterados durante o desenvolvimento do sistema e o trabalho deve ser realizado at sua finalizao 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 fcil usar um modelo de gerenciamento comum para todo o projeto, processos de software baseados no modelo em cascata ainda so comumente utilizados.
<http://www.youtube.com/watch?v=vaavIT2Bqz8>. Vdeo de demonstrao do modelo de desenvolvimento cascata simulado pelo jogo SERPG.
Desenvolvimento incremental O desenvolvimento incremental, segundo Sommerville (2011, p. 21) tem como base a ideia
47
de desenvolver uma implementao inicial, baseada em uma reunio com os envolvidos para definir os objetivos gerais do software, mostrar para o usurio e fazer seu refinamento por meio de vrias verses, at que um sistema adequado tenha sido desenvolvido.
Atividades concorrentes
Especificao Verso inicial
Descrio do esboo
Desenvolvimento
Verses intermedirias
Validao
Verso final
Fonte: Sommerville (2011, p.22)
Assim, as atividades de especificao, desenvolvimento e validao so realizadas concorrentemente com um rpido feedback entre todas as atividades. A cada nova verso, o sistema incorpora novos requisitos definidos pelo cliente. Para Pressman (2011, p. 63), inicialmente, necessrio desenvolver um projeto rpido que deve se concentrar em uma representao daqueles aspectos do software que sero visveis aos usurios finais, como, por exemplo, o layout da interface com o usurio. O desenvolvimento incremental apresenta algumas vantagens importantes em relao ao modelo em cascata. Sommerville (2011, p. 22) coloca trs vantagens: (1) se o cliente mudar seus requisitos, o custo ser reduzido, pois a quantidade de anlise e documentao a ser refeita menor do que no modelo em cascata; (2) mais fcil obter um retorno dos clientes sobre o desenvolvimento que foi feito, pois os clientes vo acompanhando o desenvolvimento
48
do software medida que novas verses so apresentadas a eles; (3) os clientes podem comear a utilizar o software logo que as verses iniciais forem disponibilizadas, o que no acontece com o modelo cascata. Entretanto, a partir de uma perspectiva de engenharia e de gerenciamento, existem alguns problemas: 1. O processo no visvel os gerentes necessitam que o desenvolvimento seja regular, para que possam medir o progresso. Se os sistemas so desenvolvidos rapidamente, no vivel produzir documentos que reflitam cada verso do sistema. 2. Os sistemas frequentemente so mal estruturados a mudana constante tende a corromper a estrutura do software. Incorporar modificaes no software torna-se cada vez mais difcil e oneroso. 3. Podem ser exigidas ferramentas e tcnicas especiais elas possibilitam rpido desenvolvimento, mas podem ser incompatveis com outras ferramentas ou tcnicas, e relativamente poucas pessoas podem ter a habilitao necessria para utiliz-las. Para sistemas pequenos (com menos de 100 mil linhas de cdigo) ou para sistemas de porte mdio (com at 500 mil linhas de cdigo), com tempo de vida razoavelmente curto, a abordagem incremental de desenvolvimento talvez seja a melhor opo. Contudo, para sistemas de grande porte, de longo tempo de vida, nos quais vrias 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 caractersticas do modelo de desenvolvimento em cascata e do incremental, ou ainda algum outro modelo disponvel na literatura. Na literatura referente a modelos de processo de software pode-se encontrar a prototipao 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,
49
a equipe que trabalha no projeto conhece projetos ou cdigos anlogos ao que est sendo desenvolvido. Ela busca esses cdigos, faz as modificaes 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. Porm, nos ltimos anos, uma abordagem para desenvolvimento de software, com foco no reuso de software existente tem emergido e se tornado cada vez mais utilizada. A abordagem orientada a reuso conta com um grande nmero de componentes de software reutilizveis, que podem ser acessados, e com um framework de integrao para esses componentes. s vezes, esses componentes so sistemas propriamente ditos (sistemas COTS commercial off-the-shelf - sistemas comerciais de prateleira), que podem ser utilizados para proporcionar funcionalidade especfica, como formatao de textos, clculo numrico, entre outros (SOMMERVILLE, 2011, p. 23). O modelo genrico de processo baseado em reuso mostrado na figura abaixo (SOMMERVILLE, 2007, p.46). Note que, embora as etapas de especificao de requisitos e de validao sejam comparveis com outros processos, as etapas intermedirias em um processo orientado a reuso so diferentes.
50
Conforme Sommerville (2011, p.23), essas etapas so: 1. Anlise de componentes considerando a especificao de requisitos, feita uma busca de componentes para implementar essa especificao. Pode ser que no sejam encontrados componentes que atendam a toda a especificao de requisitos, ou seja, pode fornecer somente parte da funcionalidade requerida. 2. Modificao de requisitos no decorrer dessa etapa, os requisitos so analisados, levando-se em considerao as informaes sobre os componentes que foram encontrados na etapa anterior. Se for possvel, os requisitos so ento modificados para refletir os componentes disponveis. Quando isso no for possvel, ou seja, quando as modificaes forem impossveis, a etapa de anlise de componentes dever ser refeita, a fim de procurar outras solues. 3. Projeto do sistema com reuso durante essa etapa, o framework do sistema projetado ou ento alguma infraestrutura existente reutilizada. Os projetistas levam em considerao os componentes que so reusados e organizam o framework para tratar desse aspecto. Se os componentes reusveis no estiverem disponveis, pode ser necessrio que um novo software deva ser projetado. 4. Desenvolvimento e integrao nessa etapa, o software que no puder ser comprado dever ser desenvolvido, e os componentes e sistemas COTS sero integrados, a fim de criar um novo sistema. A integrao 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 no se tem como evitar as alteraes nos requisitos dos usurios e isso pode acabar levando ao desenvolvimento de um sistema que no atenda as suas reais necessidades. H tambm o fato de que o controle da evoluo do sistema fique comprometido, pois as novas verses dos componentes reusveis no esto sob o controle da organizao que as est utilizando. De qualquer forma, a abordagem baseada em reuso tem a vantagem de propiciar a entrega mais rpida 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.
51
PGDS - Processo de gerenciamento e desenvolvimento de sistemas DATASUS Em busca de direcionamento e padronizao dos seus processos e da melhoria contnua da qualidade dos produtos e servios de tecnologia da informao, o DATASUS elaborou suas metodologias de desenvolvimento de software - PDS e de gerenciamento de projetos - EGP. Essas metodologias evoluram, acompanhando o desenvolvimento tecnolgico e as prticas de sucesso dos projetos realizados. Em 2010, com a implantao da Unidade de Apoio a Programas e Projetos (UAPP), o PDS e a EGP foram unifi cados em uma metodologia, agora denominada Processo de Gerenciamento e Desenvolvimento de Sistemas - PGDS. Ela foi criada para auxiliar o DATASUS na elaborao, planejamento, execuo, controle, monitoramento e encerramento de seus projetos, por meio das melhores prticas de gerenciamento disponveis no mercado e as j adotadas pelo DATASUS.
Fases do PGDS O PGDS foi criado para auxiliar o DATASUS/SE no planejamento, execuo, controle, monitoramento e encerramento de seus projetos. Serve como um guia para Gestores, Coordenadores, Lderes e equipes de projetos, equipe da UAPP e qualquer outro envolvido nos projetos. O PGDS estruturado com base em 4 elementos bsicos, que representam quem faz o qu, como e quando: Papis (quem) - Um papel defi ne o comportamento e responsabilidades de um profi ssional ou grupo de profi ssionais que participam do desenvolvimento do projeto. O comportamento representado atravs das atividades que cada papel deve desempenhar ao longo do projeto. As responsabilidades normalmente esto associadas aos artefatos que cada papel deve produzir e manter ao longo das atividades que realiza. Na prtica, um mesmo papel pode ser desempenhado por mais de uma pessoa, assim como uma mesma pessoa pode assumir vrios papis ao longo do projeto.
52
Artefatos (o qu) - Em sentido amplo, o termo artefato representa um produto concreto produzido, modifi cado ou utilizado pelas atividades de um processo. O PGDS no inclui todos os artefatos de um projeto de desenvolvimento, mas todos os artefatos obrigatrios 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 elaborao. Atividades (como) - Uma atividade no PGDS representa um conjunto de passos e tarefas que um profi ssional, que desempenha o papel responsvel por aquela atividade, deve executar para gerar algum resultado. As atividades envolvem a produo e modifi cao de artefatos do projeto. Fases (quando) - As fases do PGDS apresentam a seqncia e a dependncia entre as atividades do projeto ao longo do tempo. As atividades no fl uxo so divididas em fases do ciclo de vida do projeto e nos papis responsveis pela execuo de cada uma. Disponvel em: <http://189.28.128.113/pgds/>. Acesso em: 05 jun. 2012.
Caro(a) aluno(a), o DATASUS o Departamento de Informtica do Sistema nico de Sade do Ministrio da Sade e voc pde perceber, pelo texto acima, que ele criou um processo de software prprio. muito interessante conhecer todo o material que eles disponibilizam. Se voc quiser conhecer, acesse o endereo <http://189.28.128.113/pgds/>. Ou ento acesse o endereo <http://www2.datasus.gov.br/DATASUS/index.php?area=01> para ler mais sobre o DATASUS como um todo. uma leitura bastante esclarecedora. Disponvel em: <http://189.28.128.113/pgds/>. Acesso em 05 jun. 2012.
Modelos de Processos de Engenharia de Software <http://xps-project.googlecode.com/svn-history/r43/trunk/outros/02_Artigo.pdf>.
53
ATIVIDADES BSICAS DO PROCESSO DE SOFTWARE

Caro(a) aluno(a), estudando os modelos de processo de software apresentados anteriormente, possvel notar que algumas atividades esto presentes em todos eles, somente, s vezes, essas atividades esto organizadas de forma diferente, dependendo do processo de software que est sendo considerado. Sommerville (2011, p. 24) afirma que no modelo cascata essas atividades so organizadas de forma sequencial, ao passo que no desenvolvimento incremental as mesmas so intercaladas. A forma como essas atividades sero realizadas depende do tipo de software, das pessoas e da organizao envolvida. So quatro as atividades bsicas do processo de software: especificao, projeto e implementao, validao e evoluo. E a partir de agora, iremos detalhar, de forma simples, sem considerar um processo de software em especfico, cada uma dessas atividades.
54
ESTUDO DO CICLO DE VIDA DO SOFTWARE EM UMA EMPRESA DE DESENVOLVIMENTO DE SISTEMAS Por Fabrcio Luis Marinheiro Loureno e Mrcio Alan Benine Um estudo do ciclo de vida do software desenvolvido em uma empresa de desenvolvimento de sistemas importante, pois construir um software com qualidade demanda a utilizao e implantao de processos e tcnicas de engenharia de software. Este processo indispensvel para que o produto seja entregue ao cliente dentro do prazo e oramento planejado, alcanando a qualidade esperada. Considerando-se esse procedimento, realizou-se um estudo utilizando-se uma pesquisa bibliogrfi ca, visando encontrar referencial terico para dar sustentao questo proposta e um estudo de caso na empresa Nippon Informtica Ltda ME. Esta empresa localizada na cidade de Batatais/SP, atua com desenvolvimento de software para as reas Contbil, Fiscal e Recursos Humanos. No estudo de caso buscou-se elaborar o mapeamento dos processos existentes e aps anlise dos mesmos, propor um cenrio de soluo adequado realidade da empresa. Como resultado fi nal deste estudo, foi apresentada uma proposta de implantao do modelo de ciclo de vida do software, proporcionando a construo do software com qualidade; fornecendo um modelo que atenda aos padres da engenharia 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 defi nio do ciclo de vida de um software importante para se ter a viso completa do desenvolvimento do software. Com isto, foi possvel defi nir etapas que abrangem desde a anlise dos requisitos at a entrega do software para o cliente. Fonte: <http://revistas.claretiano.edu.br/index.php/linguagemacademica/article/view/40>. Acesso em: 07 jun. 2012.
ESPECIFICAO DE SOFTWARE
A especificao de software, ou engenharia de requisitos, a primeira atividade bsica de um processo de software e tem como objetivo definir quais funes so requeridas pelo sistema e
55
identificar as restries sobre a operao e o desenvolvimento desse sistema. Essa atividade muito importante e crtica, pois se a definio dos requisitos no for bem realizada, com certeza problemas posteriores no projeto e na implementao do sistema iro 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 avaliao realizada para verificar se as necessidades dos usurios, que foram identificadas, podem ser atendidas utilizando-se as atuais tecnologias de software e hardware, disponveis na empresa. Esse estudo deve indicar se o sistema proposto ser vivel, do ponto de vista comercial, e tambm, se poder ser desenvolvido considerando restries oramentrias, caso as mesmas existam. Um estudo de viabilidade no deve ser caro e demorado, pois a partir do seu resultado que a deciso de prosseguir com uma anlise mais detalhada deve ser tomada. 2. Levantamento e anlise de requisitos: nesta fase necessrio levantar os requisitos do sistema pela observao de sistemas j existentes, pela conversa com usurios e compradores em potencial, pela anlise de tarefas e assim por diante. Essa fase pode envolver o desenvolvimento de um ou mais diferentes modelos e prottipos de sistema. Isso pode ajudar a equipe de desenvolvimento a compreender melhor o sistema a ser especificado. 3. Especificao de requisitos: a atividade de traduzir as informaes coletadas durante a fase anterior em um documento que defina um conjunto de requisitos. Tanto os requisitos dos usurios quanto os requisitos de sistema podem ser includos nesse documento. De acordo com Sommerville (2011, p.24), os requisitos dos usurios so declaraes abstratas dos requisitos do sistema tanto para o cliente quanto para os usurios finais do sistema; os requisitos do sistema so descries mais detalhadas das funcionalidades a serem fornecidas. Na prxima unidade trataremos com mais detalhes sobre requisitos. 4. Validao de requisitos: Essa atividade verifica os requisitos quanto a sua pertinncia, consistncia e integralidade. Durante o processo de validao, os requisitos que
56
apresentarem problemas devem ser corrigidos, para que a documentao de requisitos fique correta. As atividades de anlise, definio e especificao de requisitos so intercaladas, ou seja, elas no so realizadas seguindo uma sequncia rigorosa, pois, com certeza, novos requisitos surgem ao longo do processo.
PROJETO E IMPLEMENTAO DE SOFTWARE

O estgio de implementao do desenvolvimento de software o processo de converso de uma especificao do sistema em um sistema executvel para Sommerville (2011, p. 25). Esta etapa sempre envolve processos de projeto e programao de software, porm, se uma abordagem incremental de desenvolvimento for utilizada, poder tambm envolver o aperfeioamento da especificao de software, em que os requisitos foram definidos. Para Pressman (2011, p. 206), o projeto de software cria uma representao 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 independentemente 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 incio 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 Usurio (telas e relatrios) e iii) desenvolver um conjunto de especificaes de casos de uso, sendo que, essas especificaes devem conter detalhes suficientes para permitir a codificao. Geralmente,
57
durante o projeto, o analista de sistemas ter que definir cada componente do sistema ao nvel de detalhamento que se fizer necessrio para a sua implementao em uma determinada linguagem de programao. A programao, normalmente comea como era de se esperar, quando termina a atividade de projeto. A programao, ou fase de implementao de um projeto tpico envolve a escrita de instrues em Java, C++, C# ou em alguma outra linguagem de programao para implementar o que o analista de sistemas modelou na etapa de projeto. Sendo uma atividade pessoal, no existe um processo geral que seja normalmente seguido durante a programao do sistema. Alguns programadores comearo com os componentes que eles compreendem melhor, passando depois para os mais complexos. Outros preferem deixar os componentes mais fceis para o fim, porque sabem como desenvolv-los. Alguns desenvolvedores gostam de definir os dados no incio do processo e, ento, utilizam esses dados para dirigir o desenvolvimento do programa; outros deixam os dados sem especificao enquanto for possvel. De acordo com Sommerville (2011, p. 27), normalmente, os programadores testam os cdigos fontes que eles mesmos desenvolveram, a fim de descobrir defeitos que devem ser removidos. Esse processo chamado de depurao. O teste e a depurao dos defeitos so processos diferentes. O teste estabelece a existncia de defeitos, enquanto que a depurao se ocupa em localizar e corrigir esses defeitos. Em um processo de depurao, os defeitos no cdigo devem ser localizados, e o cdigo precisa ser corrigido, a fim de cumprir os requisitos. A fim de garantir que a mudana foi realizada corretamente, os testes devero ser repetidos. Portanto, o processo de depurao parte tanto da implementao quanto da validao do software.
58
VALIDAO DE SOFTWARE
A validao de software dedica-se a mostrar que um sistema atende tanto s especificaes relacionadas no documento de requisitos, quanto s expectativas dos seus usurios. A principal tcnica de validao, 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 contrrio, se o sistema for grande e constitudo a partir de subsistemas, que, por sua vez, so construdos partindo-se de mdulos, o processo de testes deve evoluir em estgios, ou seja, devem ser realizados de forma incremental, iterativa. Sommerville (2011, p.27) prope um processo de teste em trs estgios. O primeiro estgio o teste de componente, em seguida, o sistema integrado testado e, por fim, o sistema testado com dados reais, ou seja, com dados do prprio cliente. Idealmente, os defeitos de componentes so descobertos no incio do processo, e os problemas de interface so encontrados quando o sistema integrado. Os estgios do processo de testes, conforme Sommerville (2011, p. 27) so: 1. Testes de desenvolvimento: Para garantir que os componentes individuais esto operando corretamente, necessrio test-los, de forma independente dos outros componentes do sistema. 2. Testes de sistema: Os componentes so integrados para constiturem o sistema. Esse processo se dedica a encontrar erros que resultem de interaes no previstas entre os componentes e de problemas com a interface do componente. O teste de sistema tambm utilizado para validar que o sistema atende os requisitos funcionais e no funcionais definidos no documento de requisitos. 3. Teste de aceitao: Nesse estgio, o sistema testado com dados reais fornecidos pelo cliente, podendo mostrar falhas na definio de requisitos, pois os dados reais podem exercitar o sistema de modo diferente dos dados de teste.
59
EVOLUO DE SOFTWARE
Depois que um software colocado em funcionamento, ou seja, depois que o mesmo implantado, com certeza ocorrero mudanas que levaro alterao desse software. Essas mudanas podem ser, de acordo com Pressman (2011, p. 662), para correo de erros no detectados durante a etapa de validao do software, quando h adaptao a um novo ambiente, quando o cliente solicita novas caractersticas ou funes ou ainda quando a aplicao passa por um processo de reengenharia para proporcionar benefcio 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 evoluo desse mesmo software (manuteno de 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 operao. Depois que esse sistema entrou em operao, inicia-se a manuteno de software, no qual o mesmo modificado. Normalmente, os custos de manuteno so maiores do que os custos de desenvolvimento inicial, mas os processos de manuteno so considerados menos desafiadores do que o desenvolvimento de software original, ainda que tenha um custo mais elevado. Porm, atualmente, os estgios de desenvolvimento e manuteno tm sido considerados como integrados e contnuos, em vez de dois processos separados. Tem sido mais realista pensar na engenharia de software como um processo evolucionrio, em que o software sempre mudado ao longo de seu perodo de vida, em resposta a requisitos em constante modificao e s necessidades do cliente.
60
CONSIDERAES FINAIS
Chegamos ao final de mais uma unidade. Nesta segunda unidade voc conheceu o que um processo de software e tambm alguns modelos de processo de software. Um processo de software um conjunto de atividades com resultados (artefatos) associados a cada uma delas que leva produo de um software. Todo software deve ser especificado, projetado, implementado e validado. E, aps o seu uso pelo usurio, passa por evolues. Todas essas etapas so muito importantes, mas vimos que a especificao do software uma etapa imprescindvel nesse conjunto, pois, se os requisitos no forem esclarecidos, bem especificados, no incio do desenvolvimento, h uma grande chance do software no atender s necessidades do cliente. No tempo que trabalhei com desenvolvimento de sistemas vi isso acontecer algumas vezes. E sabem o que acontece? O usurio acaba no utilizando o sistema e assim o sistema acaba no atingindo o seu objetivo. Na prxima unidade vamos tratar o assunto Requisitos de Software mais detalhadamente, justamente pela importncia que mencionei acima. Aps 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 prxima etapa a implementao 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 implementao a escrita do sistema em uma linguagem de programao. Nesta disciplina veremos somente a parte terica relacionada implementao, pois a parte prtica faz parte de outras disciplinas do seu curso. Mas, afinal, qual a diferena entre processo de software e modelo de processo de software? Um processo de software o conjunto de atividades (mencionadas acima) e um modelo de processo de software uma representao abstrata de um processo de software, ou seja, define a sequncia em que as atividades do processo sero realizadas. Existem vrios modelos de processo de software descritos na literatura, porm nesta unidade vimos somente alguns desses modelos. O primeiro foi o Modelo em Cascata, que representa as atividades do processo (especificao, desenvolvimento, validao e evoluo) como fases separadas, onde uma s pode acontecer depois que a anterior tenha sido concluda. O segundo modelo foi o Desenvolvimento Incremental, que tem como base a ideia de desenvolver uma
61
implementao inicial, expor ao comentrio do usurio/cliente e fazer seu aprimoramento por meio de muitas verses, at que um sistema adequado tenha sido desenvolvido. Nesse modelo, em vez de ter as atividades de especificao, desenvolvimento e validao em separado, todo esse trabalho realizado concorrentemente. O ltimo modelo que estudamos foi a Engenharia de Software Baseada em Reuso, que baseia-se na existncia de um nmero significativo de componentes reusveis, sendo que o processo de desenvolvimento de sistemas se concentra na integrao 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 resposta para essa pergunta no to simples. No existe um processo ideal de software e os modelos no so mutuamente exclusivos e na maioria das vezes, podem ser usados em conjunto, em especial para o desenvolvimento de sistemas de grande porte. O aumento na demanda por software de qualidade vem causando grande presso sobre as empresas que trabalham com desenvolvimento de software. As entregas de software obedecendo ao cronograma e custos previstos vm 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 prxima unidade vamos conhecer um pouco mais sobre requisitos de software e entender por que os requisitos so to importantes em um processo de software.
1. Faa um comparativo entre os Modelos de Processo de Software - Modelo Cascata e Desenvolvimento Incremental. 2. Explique cada uma das atividades bsicas que compem 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, defina um modelo de processo de software que poderia ser utilizado por uma pequena empresa de desenvolvimento de sistemas.
62
UNIDADE III
REQUISITOS DE SOFTWARE
Professora Me. Mrcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Entender os diversos tipos de requisitos relacionados ao desenvolvimento de software. Expor a importncia do documento de requisitos. Compreender o processo de engenharia de requisitos. Plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Tipos de Requisitos de Software Documento de Requisitos Engenharia de Requisitos
INTRODUO
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: especificao de software, projeto e implementao de software, validao de software e, finalmente, evoluo de software. Esta unidade vai tratar especificamente sobre requisitos de software e, no final desta unidade voc vai compreender por que os requisitos so importantes e devem ser muito bem definidos para que o software desenvolvido alcance seus objetivos. Uma das tarefas mais difceis que os desenvolvedores de software enfrentam entender os requisitos de um problema. Os requisitos definiro o que o sistema deve fazer, suas propriedades emergentes desejveis e essenciais e as restries quanto operao do sistema. Essa definio de requisitos somente possvel com a comunicao entre os clientes e/ou os usurios de software e os desenvolvedores de software. As preferncias, preconceitos e recusas dos usurios, alm das questes polticas e organizacionais influenciam diretamente nos requisitos do sistema, portanto, a engenharia de software no simplesmente um processo tcnico (SOMMERVILLE, 2007, p. 78).
65
Nesta unidade, voc aprender a diferena entre os vrios tipos de requisitos e trataremos, principalmente, dos requisitos funcionais e no funcionais. Os requisitos funcionais representam as descries das diversas funes que clientes e usurios querem ou precisam que o software oferea. Um exemplo de requisito funcional o sistema deve possibilitar o cadastramento dos dados pessoais dos pacientes. J, os requisitos no funcionais, declaram as restries ou atributos de qualidade para um software, como, por exemplo, preciso, manutenibilidade, usabilidade entre outros. O tempo de desenvolvimento no deve ultrapassar seis meses um exemplo de requisito no funcional. Todos os requisitos definidos, sejam eles funcionais ou no funcionais, devem estar escritos em um documento de requisitos, que servir como base para todas as atividades subsequentes do desenvolvimento e tambm fornecer um ponto de referncia para qualquer validao do software construdo. Tambm estudaremos nesta unidade sobre os requisitos de qualidade, que so definidos pela Norma ISO/IEC 9126 e que tambm devem ser considerados quando um software est sendo projetado. E, por fim, veremos que a engenharia de requisitos um processo que envolve quatro atividades genricas: avaliar se o sistema que est sendo projetado ser til para a empresa (estudo de viabilidade), obter e analisar os requisitos (levantamento e anlise), especificar esses requisitos, convertendo-os em um documento de requisitos (especificao de requisitos) e, finalmente, verificar se os requisitos realmente definem o sistema que o cliente deseja (validao).
66
REQUISITOS DE SOFTWARE
Normalmente, os problemas que os desenvolvedores de software tm para solucionar so, muitas vezes, imensamente complexos e se o sistema for novo, entender a natureza desses problemas pode ser muito mais difcil ainda. As descries das funes e das restries so os requisitos para o sistema; e o processo de descobrir, analisar, documentar e verificar essas funes e restries chamado de engenharia de requisitos. De acordo com Sommerville (2011, p. 57), a indstria de software no utiliza o termo requisito de modo consistente. Muitas vezes, o requisito visto como uma declarao abstrata em alto nvel, de uma funo que o sistema deve fornecer ou de uma restrio do sistema. Em outras vezes, ele uma definio detalhada e formal, de uma funo do sistema. Alguns dos problemas que surgem durante a especificao de requisitos so as falhas em no fazer uma separao clara entre os diferentes nveis de descrio dos requisitos. Por isso, Sommerville (2011, p. 57) prope uma distino entre eles por meio do uso do termo requisitos de usurio, para expressar os requisitos abstratos de alto nvel, e requisitos de sistema, para expressar a descrio detalhada do que o sistema deve fazer. Dessa forma, os requisitos de
67
usurio devero fornecer, em forma de declaraes, quais servios o sistema dever oferecer e as restries com as quais o sistema deve operar. J os requisitos de sistema so descries mais detalhadas das funes, servios e restries 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 soluo no 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 fornecedor precisa preparar uma definio 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 no forem definidos corretamente, se ficarem errados? Se isso acontecer, o sistema pode no ser entregue no prazo combinado e com o custo acima do esperado no incio do projeto; o usurio final e o cliente no ficaro 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 difcil 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 difcil de consertar depois. Fred Brooks, Engenheiro de Software.
68
REQUISITOS FUNCIONAIS E NO FUNCIONAIS

Primeiramente, vamos definir o que requisito, independentemente da rea de informtica. Um requisito a condio imprescindvel para a aquisio ou preenchimento de determinado objetivo. Na abordagem da engenharia de software, segundo Sommerville (2011, p. 57), os requisitos de um sistema so as descries do que o sistema deve fazer, os servios que oferece e as restries a seu funcionamento. Esses requisitos dizem respeito s necessidades dos usurios para um sistema que deve atender um determinado objetivo, como, por exemplo, cadastrar um pedido de venda ou emitir um relatrio. A engenharia de requisitos um processo que engloba as atividades que so necessrias para criar e manter um documento de requisitos de sistema. Essas atividades so: estudo de viabilidade, levantamento e anlise de requisitos, especificao de requisitos e, finalmente, a validao desses requisitos. De acordo com Sommerville (2011, p. 59), os requisitos de software so, normalmente, classificados como funcionais ou no funcionais: 1. Requisitos funcionais: definem as funes que o sistema deve fornecer, de como o sistema deve reagir as entradas especficas e de como deve se comportar em determinadas situaes. Em alguns casos, os requisitos funcionais podem tambm explicitamente declarar o que o sistema no deve fazer. Exemplos de requisitos funcionais: o software deve possibilitar o clculo das comisses dos vendedores de acordo com os produtos vendidos; o software deve emitir relatrios de compras e vendas por perodo; o sistema deve mostrar, para cada aluno, as disciplinas em que o mesmo foi aprovado ou reprovado. 2. Requisitos no funcionais: so os requisitos relacionados utilizao do software em termos de desempenho, confiabilidade, segurana, usabilidade e portabilidade entre outros. Exemplos de requisitos no funcionais: o sistema deve ser protegido para acesso apenas de usurios autorizados; o tempo de resposta do sistema no deve ultrapassar 20 segundos; o tempo de desenvolvimento no deve ultrapassar doze meses.
69
Contudo, a diferenciao entre esses dois tipos de requisitos no to clara como sugerem as definies acima. Um requisito referente proteo, pode parecer ser um requisito no funcional. Porm, quando desenvolvido com mais detalhes, pode levar a outros requisitos que so claramente funcionais, como a necessidade de incluir recursos de autorizao de usurios no sistema (SOMMERVILLE, 2011, p. 59). Portanto, embora seja interessante separar os requisitos em funcionais e no funcionais, devemos lembrar que essa , na verdade, uma distino artificial. O que muito importante que os requisitos, sejam eles funcionais ou no funcionais, sejam claramente definidos. Requisitos funcionais Os requisitos funcionais devem descrever detalhadamente os servios e as funcionalidades que devem ser fornecidas pelo sistema, indicando suas entradas e sadas, excees etc. Esses requisitos podem ser expressos de diversas maneiras, com diferentes nveis de detalhes. A impreciso na especificao de requisitos uma das causas de muitos problemas da engenharia de software (SOMMERVILLE, 2011, p. 60). Pode acontecer que um desenvolvedor de sistemas interprete um requisito ambguo para simplificar sua implementao, porm, nem sempre isso o que o cliente quer. E quando isso acontece, pode ser que novos requisitos devam ser estabelecidos, sendo necessrio realizar mudanas no sistema, podendo atrasar a entrega final do sistema e, consequente, ocasionando o aumento de custos do desenvolvimento. De acordo com Sommerville (2011, p. 60), em princpio, a especificao de requisitos funcionais de um sistema deve ser completa e consistente. A completeza denota que todas as funes requeridas pelo usurio devem estar definidas e a consistncia denota que os requisitos no devem ter definies contraditrias. Na prtica, para grandes sistemas, atingir a consistncia e a completeza dos requisitos bastante difcil, por causa da complexidade inerente ao sistema e, em parte, porque diferentes pontos de vista apresentam necessidades inconsistentes.
70
Requisitos no funcionais Os requisitos no funcionais so aqueles que no dizem respeito diretamente s funes especficas oferecidas pelo sistema. Eles podem estar relacionados a propriedades, como confiabilidade, tempo de resposta e espao em disco. Como alternativa, eles podem definir restries para o sistema, como a capacidade dos dispositivos de E/S (entrada/sada) e as representaes de dados utilizadas nas interfaces de sistema (SOMMERVILLE, 2011, p. 60). Os requisitos no funcionais surgem conforme a necessidade dos usurios, em razo de restries de oramento, de polticas organizacionais, pela necessidade de interoperabilidade com outros sistemas de software ou hardware ou devido a fatores externos, como por exemplo, regulamentos de segurana e legislao sobre privacidade. Sommerville (2011, p.61) faz uma classificao dos requisitos no funcionais em requisitos de produto, requisitos organizacionais e requisitos externos. Os requisitos de produto so aqueles que especificam o comportamento do produto, podendo ser subdivididos em requisitos de usabilidade, de eficincia, de confiana e de proteo. Os requisitos organizacionais so aqueles derivados das polticas e procedimentos da organizao do cliente e do desenvolvedor e so 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 so subdivididos em requisitos reguladores, ticos e legais. Os requisitos funcionais e no funcionais deveriam ser diferenciados em um documento de requisitos, porm, na prtica, no fcil fazer essa distino. Em nossos documentos de requisitos nos preocuparemos mais com os requisitos funcionais do sistema. Se os requisitos no funcionais forem definidos separadamente dos requisitos funcionais, pode ser difcil enxergar a relao existente entre eles. Se eles forem definidos com os requisitos funcionais, poder ser difcil separar consideraes funcionais e no funcionais e identificar os requisitos que correspondem ao sistema como um todo. preciso encontrar um equilbrio 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 seo separada do documento de requisitos ou diferenciando-os, de alguma maneira, dos outros requisitos de sistema.
71
REQUISITOS DE USURIO
De acordo com Sommerville (2007, p. 85), os requisitos de usurios para um sistema devem descrever os requisitos funcionais e no funcionais de forma que usurios do sistema que no tenham conhecimentos tcnicos detalhados consigam entender. Eles devem especificar somente o comportamento externo do sistema, evitando sempre que possvel as caractersticas do projeto de sistema. Portanto, no devem ser definidos utilizando-se um modelo de implementao, e sim, escritos com o uso de linguagem natural, formulrios e diagramas intuitivos simples.
REQUISITOS DE SISTEMA
Os requisitos de sistema so descries mais detalhadas dos requisitos do usurio, servindo como base para um contrato destinado implementao do sistema e, portanto, devem ser uma especificao completa e consistente de todo o sistema (SOMMERVILLE, 2007, p. 87). Eles so 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 no como ele teria de ser implementado, porm, no que se refere aos detalhes exigidos para especificar o sistema completamente, quase impossvel excluir todas as informaes de projeto. H, pelo menos, duas razes para isso: 1. Uma arquitetura inicial do sistema pode ser definida para ajudar a estruturar a especificao de requisitos. 2. Na maioria dos casos, o sistema deve interoperar com outros sistemas existentes, restringindo assim o projeto em desenvolvimento, sendo que, muitas vezes, essas restries geram requisitos para o novo sistema. De acordo com Sommerville (2011, p. 58), os requisitos devem ser escritos em nveis
72
diferentes de detalhamento para que diferentes leitores possam us-los de formas diferentes. Os possveis leitores para os requisitos de usurio so: gerentes clientes, usurios finais do sistema, engenheiros clientes, gerentes contratantes e arquitetos de software. Esses leitores no tem a preocupao com a forma como o sistema ser implementado. J para os requisitos de sistema podem-se ter os seguintes leitores: usurios 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 estaro envolvidos no projeto e na implementao do sistema.
As sementes das principais catstrofes de software so normalmente semeadas nos trs primeiros meses do projeto de software Caper Jones, Especialista em Engenharia de Software.
REQUISITOS DE QUALIDADE
Quanto mais rgidos os requisitos de qualidade e mais complexo o software a ser desenvolvido, aumenta-se a necessidade de se aplicar teorias e ferramentas que garantam que esses requisitos sejam satisfeitos. A Norma ISO (The International Organization for Standardization) / IEC (The International Electrotechnical Commission ) 9126 define seis caractersticas de qualidade de software que devem ser avaliadas: Funcionalidade: a capacidade de um software fornecer funcionalidades que atendam as necessidades explcitas e implcitas dos usurios, dentro de um determinado contexto de uso. Usabilidade: conjunto de atributos que evidenciam o esforo necessrio para a utilizao do software.
73
Confiabilidade: indica a capacidade do software em manter seu nvel de desempenho sob determinadas condies durante um perodo de tempo estabelecido. Eficincia: indica que o tempo de execuo e os recursos envolvidos so compatveis com o nvel de desempenho do software. Manutenibilidade: conjunto de atributos que evidenciam o esforo necessrio para fazer modificaes especificadas no software, incluindo tanto as melhorias/ extenses de funcionalidades quanto as correes 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 padronizao mais conhecido no mundo. Voc pode obter mais informaes atravs do endereo <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749>. Existe tambm adequao dessa norma para o Brasil a NBR ISO/IEC 9126-1. Verifique no endereo <http://www. abnt.org.br/>.
Especifi cao de requisitos no desenvolvimento de software para TV Digital Interativa no Brasil: Re exes e Relato de Experincia Por Carlos Eduardo Marquioni O processo de implantao da TV Digital no Brasil iniciou uma nova fase em 2009, relacionada defi nio de mecanismos para interao atravs do televisor. Contudo, alm de viabilizar a infraestrutura tecnolgica para troca de informaes entre o telespectador e os difusores, parece relevante considerar a utilizao de processos de software para que os produtos desenvolvidos que possibilitam a interao tenham qualidade. Este trabalho apresenta conceitos do processo de Especifi cao da Engenharia de Requisitos e relaciona boas prticas de escrita para gerar requisitos textuais que, integradas com a tcnica de Casos de Uso levaram defi nio de um mtodo de especifi cao de requisitos para a TV Digital Interativa que utiliza conceitos conhecidos pela comunidade de software. O mtodo foi utilizado em um projeto real, e abordado no artigo como relato de experincia. O trabalho completo pode ser encontrado no endereo abaixo. Fonte: <http://revistas.ua.pt/index.php/prismacom/article/view/784>. Acesso em: 07 jun. 2012.
74
O DOCUMENTO DE REQUISITOS DE SOFTWARE

O documento de requisitos de software ou especificao de requisitos de software a declarao oficial do que exigido dos desenvolvedores de sistema. Ele deve incluir os requisitos de usurios para um sistema e uma especificao detalhada dos requisitos de sistema. Em alguns casos, os requisitos de usurio e de sistema podem ser integrados em uma nica descrio. Em outros casos, os requisitos de usurio so definidos em uma introduo especificao dos requisitos de sistema. Se houver um grande nmero de requisitos, os requisitos detalhados de sistema podero ser apresentados como documentos separados. O documento de requisitos serve como um termo de consenso entre a equipe tcnica (desenvolvedores) e o cliente e constitui a base para as atividades subsequentes do desenvolvimento do sistema, fornecendo um ponto de referncia para qualquer validao futura do software construdo. Alm disso, o documento de requisitos estabelece o escopo (o que faz parte e o que no faz parte) do sistema, abrangendo um conjunto diversificado de usurios, que vai desde a alta gerncia da organizao, que est pagando pelo sistema, at os engenheiros responsveis pelo desenvolvimento do software. A tabela abaixo mostra uma possvel organizao 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
Captulo Prefcio Descrio Deve definir os possveis leitores do documento e descrever seu histrico de verses, incluindo uma justificativa para a criao de uma nova verso e um resumo das mudanas feitas em cada verso. Deve descrever a necessidade para o sistema. Deve descrever brevemente as funes do sistema e explicar como ele vai funcionar com outros sistemas. Tambm deve descrever como o sistema atende aos objetivos globais de negcio ou estratgicos da organizao que encomendou o software. Deve definir os termos tcnicos usados no documento. Voc no deve fazer suposies sobre a experincia ou o conhecimento do leitor.
Introduo
Glossrio
75
Captulo Definio de requisitos de usurio
Descrio Deve descrever os servios fornecidos ao usurio. Os requisitos no funcionais de sistema tambm devem ser descritos nessa seo. Essa descrio pode usar a linguagem natural, diagramas ou outras notaes compreensveis para os clientes. Normas de produto e processos a serem seguidos devem ser especificados. Deve apresentar uma viso geral em alto nvel da arquitetura do sistema previsto, mostrando a distribuio de funes entre os mdulos do sistema. Componentes de arquitetura que so reusados devem ser destacados. Deve descrever em detalhes os requisitos funcionais e no funcionais. Se necessrio, tambm podem ser adicionados mais detalhes aos requisitos no funcionais. Interfaces com outros sistemas podem ser definidas. Pode incluir modelos grficos do sistema que mostram os relacionamentos entre os componentes do sistema, o sistema e seu ambiente. Exemplos de possveis modelos so modelos de objetos, modelos de fluxo de dados ou modelo semnticos de dados. Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanas previstas, em decorrncia da evoluo do hardware, de mudanas nas necessidades do usurio, etc. Essa seo til para projetistas de sistema, pois pode ajud-los a evitar decises capazes de restringir possveis mudanas futuras no sistema. Deve fornecer informaes detalhadas e especficas relacionadas aplicao em desenvolvimento, alm de descries de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configuraes mnimas ideais para o sistema. Requisitos de banco de dados definem a organizao lgica dos dados usados pelo sistema e os relacionamentos entre esses dados. Vrios ndices podem ser includos no documento. Pode haver, alm de um ndice alfabtico normal, um ndice de diagramas, de funes, entre outros pertinentes.
Arquitetura do sistema
Especificao de requisitos do sistema
Modelos do sistema
Evoluo do sistema
Apndices
ndice
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
76
de como o sistema funciona atualmente e quais funcionalidades o usurio 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 prxima unidade. Exemplo de Documento de Requisitos Locadora de Filmes Uma determinada locadora possui muitos ttulos em seu acervo e no consegue controlar de maneira eficiente as locaes, devolues e reservas dos filmes. Portanto, ela deseja ter um sistema informatizado que controle todas as locaes, devolues e reservas de maneira eficiente, para aperfeioar 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, endereo 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. Manter o cadastro de filmes. Neste cadastro dever conter os seguintes dados: nome do filme, durao, sinopse, classificao, gnero, diretor, elenco. Para cada cpia do filme necessrio saber o fornecedor da mesma, a data da compra, o valor pago e o tipo (VHS ou DVD). 2. Controlar locaes A locao feita mediante a verificao de cadastro do cliente. Se o cliente for cadastrado ento se efetua a locao, se no se cadastra o cliente. Caso a locao seja efetuada pelo dependente do cliente, necessrio deixar registrado qual o dependente e qual o cliente. verificado se o filme est disponvel e se o cliente possui pendncias financeiras ou atraso de devoluo, caso uma das alternativas seja afirmativa bloqueia-se a operao, sendo liberada somente aps a devida regularizao. Emitir comprovante de locao com a data prevista para devoluo de cada filme,
77
discriminao dos filmes e se o pagamento foi ou no efetuado. A data prevista para devoluo 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 LANAMENTO permite que o cliente fique com o filme por 2 dias.
3. Controlar devolues: Verificar se a devoluo est no prazo correto e se o pagamento foi efetuado, caso o prazo esteja vencido calcular a multa incidente. Efetuado o pagamento emite-se o recibo de devoluo. No esquecer que no pode ser cobrada multa caso seja domingo ou feriado. Verificar se o cliente j est cadastrado, caso contrrio o sistema permite o cadastro do cliente no momento da reserva. Tambm verificado se o filme desejado est disponvel para reserva. Reservar somente para clientes sem pendncias financeiras e devolues vencidas.
4. Controlar reservas
5. Consultar Filmes Locados 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 tambm a data em que cada filme foi locado. 6. Consultar Reservas por Filme: o sistema deve ter uma consulta em que seja informado um determinado filme e sejam mostradas todas as reservas efetuadas para aquele filme, no perodo informado. 7. Emitir os seguintes relatrios Relatrio Geral de Clientes, onde conste o cdigo, nome, endereo, telefone e dependentes do cliente. Etiquetas com cdigos de barras para a identificao das cpias no processo de locao e devoluo. Relatrio de filmes por gnero, onde conste o cdigo do filme, o nome do filme, o nome do diretor do filme, os nomes dos atores do filme, o total de cpias, o total de cpias locadas e o total de cpias disponveis. O relatrio deve ser agrupado por
78
gnero, mostrando tambm o cdigo e a descrio do gnero. Relatrio de filmes locados por cliente por perodo. Para cada cliente devem ser emitidas todas as cpias que esto locadas para ele. Deve sair no relatrio: o cdigo e o nome do cliente, o cdigo do filme, o nome do filme, o cdigo da cpia (exemplar), a data de locao e o valor da locao. O relatrio deve ser agrupado por cliente e devem sair somente as cpias locadas e no devolvidas. Relatrio de cpias no devolvidas, onde conste o cdigo do filme, o nome do filme, o cdigo da fita, o nome do cliente, o telefone do cliente, a data de locao, a data prevista para devoluo e o nmero de dias em atraso. Relatrio dos filmes mais locados, onde conste o cdigo do filme, o nome do filme, a descrio do gnero e o nmero total de locaes. O relatrio deve ser agrupado por ms/ano, ou seja, para um determinado ms/ano, devem ser emitidos os 10 (dez) filmes mais locados. Relatrio de Reservas por perodo, onde conste o cdigo do cliente, o nome do cliente, o telefone do cliente, o cdigo 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). Relatrio dos valores das locaes mensais. Dever mostrar os valores das locaes de determinado ms, separado por data e somatria de valores de cada dia, somando-se assim ao final, uma totalidade de locaes. Nele deve-se conter a data e a soma das locaes desta data.
Todos os relatrios serviro para o processo de tomadas de decises, nos quais os Administradores podero obter informaes sobre o andamento da locadora.
ENGENHARIA DE REQUISITOS
Como foi dito na unidade anterior, a engenharia de requisitos um processo que envolve todas as atividades necessrias para a criao e manuteno de um documento de requisitos de software. Existem quatro atividades genricas de processo de engenharia de requisitos que so de alto nvel: (i) o estudo de viabilidade do sistema, (ii) o levantamento e anlise de
79
requisitos, (iii) a especificao de requisitos e sua documentao e, finalmente, (iv) a validao desses requisitos. A seguir abordaremos todas as atividades, com exceo da especificao de requisitos, que j foi discutida nesta unidade. A figura abaixo ilustra a relao entre essas atividades e mostra tambm os documentos produzidos em cada estgio do processo de engenharia de requisitos, de acordo com Sommerville (2011, p. 24).
<http://www.youtube.com/watch?v=P4ixBvRF4NY&feature=related>. O vdeo mostra uma entrevista com Sergio Ayres, consultor com vasta experincia em Gesto e Governana Corporativa, abordando a Engenharia de Requisitos.
Estudo de Viabilidade
Levantamento e anlise de requisitos
Especificao de requisitos
Relatrio de Viabilidade Modelos de sistema Requisitos de usurio e de sistema
Validao de requisitos
Documento de requisitos
Fonte: Somerville (2011, p. 24).
80
As atividades de engenharia de requisitos, mostradas nessa figura, dizem respeito ao levantamento, documentao e verificao dos requisitos. Porm, necessrio deixar claro que, em praticamente todos os sistemas, os requisitos se modificam; as pessoas interessadas desenvolvem melhor compreenso do que elas querem que o software faa; a organizao compradora do sistema sofre modificaes; e so feitas alteraes 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 elicitao de requisitos. O estudo de viabilidade inicia-se com uma descrio geral do sistema e de como ele ser utilizado dentro de uma organizao, sendo que o resultado desse estudo deve ser um relatrio que recomenda se vale a pena ou no realizar o processo de engenharia de requisitos e, consequentemente, o processo de desenvolvimento de sistemas. Um estudo de viabilidade um estudo rpido, direcionado, que se destina a responder a algumas perguntas: 1. O sistema contribui para os objetivos gerais da organizao? 2. O sistema pode ser implementado com a utilizao de tecnologia atual dentro das restries de custo e de prazo? 3. O sistema pode ser integrado com outros sistemas j em operao? A questo sobre se o sistema contribui ou no para os objetivos da empresa fundamental, pois se um sistema no for compatvel com esses objetivos, ele no ter nenhum valor real para a mesma. Embora isso possa parecer bvio, muitas organizaes desenvolvem sistemas que no contribuem para seus objetivos, seja porque no existe uma declarao clara desses objetivos ou porque outros fatores polticos ou organizacionais influenciam na aquisio do sistema (SOMMERVILLE, 2007, p. 97).
81
Preparar um estudo de viabilidade envolve avaliar e coletar informaes e redigir relatrios. A fase de avaliao identifica as informaes exigidas para responder s trs perguntas apresentadas anteriormente. Uma vez identificadas as informaes, preciso questionar as fontes de informao, a fim de encontrar as respostas para essas perguntas. Eis alguns exemplos das possveis perguntas que devem ser feitas: Como a organizao se comportaria, se esse sistema no fosse implementado? Quais so os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas? Que contribuio direta o sistema trar para os objetivos da empresa? As informaes podem ser transferidas para outros sistemas organizacionais e tambm podem ser recebidas a partir deles? O sistema requer tecnologia que no tenha sido utilizada anteriormente na organizao? O que precisa e o que no precisa ser compatvel com o sistema? Entre as fontes de informao esto os gerentes de departamentos em que o sistema ser utilizado, os engenheiros de software que esto familiarizados com o tipo de sistema proposto, peritos em tecnologia, usurios finais de sistema entre outros. Eles devem ser entrevistados durante o estudo de viabilidade, a fim de coletar as informaes exigidas. O relatrio do estudo de viabilidade dever ser elaborado com base nas informaes mencionadas acima, e deve recomendar se o desenvolvimento do sistema deve continuar ou no. Ele pode propor mudanas no enfoque, no oramento e no cronograma, alm de sugerir outros requisitos de alto nvel para o sistema.
82
LEVANTAMENTO E ANLISE DE REQUISITOS

De acordo com Sommerville (2007, p. 97), aps os estudos iniciais de viabilidade, a prxima atividade do processo de engenharia de requisitos o levantamento e a anlise de requisitos. Nessa atividade, os membros da equipe tcnica de desenvolvimento de software trabalham com o cliente e os usurios finais do sistema para descobrir mais informaes sobre o domnio da aplicao, que servios o sistema deve fornecer, o desempenho exigido do sistema, as restries de hardware e assim por diante. O levantamento e a anlise de requisitos podem envolver diferentes tipos de pessoas em uma organizao. O termo stakeholder utilizado para se referir a qualquer pessoa que ter alguma influncia direta ou indireta sobre os requisitos do sistema. Dentre os stakeholders destacamse os usurios finais que interagiro com o sistema e todo o pessoal, em uma organizao, que venha a ser por ele afetado. Os engenheiros que esto desenvolvendo o sistema ou fazendo a manuteno de outros sistemas relacionados, os gerentes de negcios, os especialistas nesse domnio, os representantes de sindicato entre outros, podem ser tambm os stakeholders do sistema. O levantamento e a anlise de requisitos compem um processo difcil, por diversas razes (SOMMERVILLE, 2007, p. 98): 1. Os stakeholders frequentemente no sabem na realidade o que querem do sistema computacional, a no ser em termos muito gerais; eles podem achar difcil articular o que desejam do sistema, muitas vezes, fazendo pedidos no realistas, por no terem noo do custo de suas solicitaes. 2. Os stakeholders em um sistema expressam naturalmente os requisitos em seus prprios termos e com o conhecimento implcito de sua rea de atuao, dificultando a compreenso por parte dos engenheiros de software que no tm experincia no domnio do cliente. 3. Diferentes stakeholders tm em mente diferentes requisitos e podem express-los de maneiras distintas, obrigando os engenheiros de software a descobrir todas as possveis fontes de requisitos e a encontrar os pontos comuns e os conflitos.
83
4. Fatores polticos podem influenciar os requisitos do sistema. 5. O ambiente econmico e de negcios, no qual a anlise de requisitos ocorre, dinmico, mudando durante o processo de anlise. Como consequncia, a importncia dos requisitos especficos pode mudar, podendo surgir novos requisitos por parte dos novos stakeholders, que no haviam sido consultados inicialmente.
Introduo Engenharia de Requisitos Por Rodrigo Oliveira Spnola, Doutor e Mestre em Engenharia de Sistemas e Computao. Fonte: <http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034>. Acesso em: 13 jun. 2012.
Entrevista As entrevistas (formais ou informais) com os stakeholders do sistema fazem parte da maioria dos processos de engenharia de requisitos. a fonte mais importante para o levantamento dos requisitos desde que o entrevistado confie no entrevistador.
84
A sumarizao durante e no final da entrevista necessria primeiro para garantir que toda informao 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 documentao formal e desenvolva um esquema do sistema existente ou proposto. Identifique questes, partes omitidas e ambguas. Estes fatos ou componentes desconhecidos representam um esboo inicial dos objetivos. Pode ser necessrio entrevistar vrias 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 anlise do fluxo de trabalho ou uma lista de distribuio de relatrios. Comece pelo organograma e pelo gerente que parece ser o melhor para responder s questes. Alm disso, as pessoas ficam menos hesitantes se souberem que a entrevista foi autorizada pelo chefe. c) Ler a documentao relevante, conhecer a posio e as responsabilidades do entrevistado, ocupar-se com documentos ou procedimentos relevantes. d) Preparar questes especficas. Selecione questes especficas que podem ser respondidas. Desenvolva uma lista de questes a serem seguidas se a entrevista comear a se desviar do ponto-chave. A entrevista deve ser marcada com antecedncia, o horrio deve ser combinado e as questes devem ser preparadas. Uma entrevista composta de trs partes: a abertura, o corpo e o fechamento. ABERTURA - o objetivo-chave estabelecer harmonia (concordncia). Comece se identificando, apresentando o tpico que pretende discutir e o propsito (objetivo) da entrevista. Se houver necessidade, quebre o gelo com conversas informais, mas no caia na perda de tempo. CORPO - pode-se comear com uma questo relativamente aberta (Quando eu li a documentao para este sistema, tive algum trabalho com (anuncie a parte ou seo) voc
85
pode me explicar?) e gradualmente, caminhe atravs de questes especficas. 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 descrio) est correto? b) Procurar saber as decises que o entrevistado toma (quais so e como ele toma as decises; quais so as informaes necessrias, se da forma como so apresentadas so satisfatrias, qual o tempo necessrio - antecedncia - para que se possa tomar as decises). c) Procurar respostas quantitativas. Exemplo: quantos telefones, funcionrio voc tem no departamento? d) Evitar falar palavras sem sentido (falar baixo, fazer generalizaes, termos tcnicos). e) Ouvir as respostas. D tempo para o entrevistado responder, no saia com respostas antecipadas. No se concentre na prxima questo (isto um erro comum dos iniciantes). A lista de questes preparada apenas um guia. Tenha certeza de que as questes so relevantes, evite questes complexas e desnecessrias. f) Pedir explicaes para as questes que ficarem obscuras. g) Pedir ideias e sugestes e descobrir se o entrevistado quer que sejam consideradas. Exemplo: voc tem alguma sugesto ou recomendaes relativas ao mtodo para calcular o oramento? Voc gostaria que os seus superiores ou os demais ficassem sabendo de suas sugestes? ENCERRAMENTO - se a entrevista tiver consumido mais tempo do que o previsto pea para continuar e oferea uma reprogramao. Quando tiver toda a informao necessria, agradea e faa um sumrio de todos os pontos principais. Avise se for necessria outra
86
sesso de entrevista com a mesma pessoa. Muitas vezes, algumas expresses corporais podem substituir ou comunicar mais informaes do que as prprias palavras. Este tipo de comunicao pode ajudar o engenheiro de software a: a) interpretar as palavras do entrevistado; b) determinar a atitude geral do entrevistado para as questes que esto sendo discutidas; c) avaliar a confidncia que o entrevistado demonstrou tanto ao seu redor como no tratamento da rea de abrangncia do sistema. Vrios pontos devem ser aprendidos e esclarecidos na entrevista: a) Organizao da empresa (ambiente de trabalho). Como o administrador organiza o seu pessoal? Como esta organizao se relaciona s funes maiores que a empresa executa? b) Os objetivos e exigncias do sistema (declarados nos manuais de procedimentos) devem ser reafirmados e esclarecidos na entrevista - muitas vezes os objetivos e exigncias declarados nos manuais no so os mesmos que os representantes veem. Quando existe uma discrepncia, possvel 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 funo importante, determinar as etapas exigidas e descreva o significado delas. d) Exigncia de recursos: determinar quais so os recursos aplicados pela organizao para executar o trabalho. Quais so as exigncias com:
Recursos humanos (treinamento especializado, experincia exigida).
87
Equipamento e material necessrio para apoiar na execuo do trabalho.
e) Relao de tempo: como o trabalho executado se relaciona a perodos especficos do ano ou outros ciclos comerciais. Existe pico? Qual o atual volume de trabalho? f) Formulrios, procedimentos e relatrios quais so utilizados? (inclua exemplo de cada formulrio, relatrio e procedimento). Verifique se o material tem origem no escritrio, se modificado pelo escritrio e/
ou transmitido para outro escritrio. Faa comparaes que determinam se inutilizado, duplicado ou incompleto. Verifique a satisfao dos usurios com esses documentos.
g) Funes desejveis e no existentes: registre a opinio das pessoas sobre o sistema, como ele existe e como poderia ser. Ateno opinies mais subjetivas que objetivas. h) Flexibilidade dos procedimentos: o sistema atual to rgido e inflexvel que a menor modificao requer o maior remendo? i) Capacidade: o sistema atual consegue manipular volumes maiores do que aqueles que resultam do crescimento normal?
Coloque trs interessados em uma sala e pergunte a eles que tipo de sistema desejam. Provavelmente voc obter quatro ou mais opinies diferentes. Autor desconhecido.
88
ESPECIFICAO DE REQUISITOS
Durante o levantamento de requisitos (levantamento de dados), a equipe de desenvolvimento tenta entender o domnio (contexto/problema) que deve ser automatizado, sendo que o produto do levantamento de requisitos o DOCUMENTO DE REQUISITOS ou ESPECIFICAO DE REQUISITOS, que declara os diversos tipos de requisitos do sistema (requisitos funcionais, requisitos no funcionais, de usurio e de sistema). J tratamos desse tpico nesta unidade.
VALIDAO DE REQUISITOS
A validao de requisitos tem como objetivo mostrar que os requisitos realmente definem o sistema que o cliente deseja. Ela tem muito em comum com a anlise de requisitos, uma vez que se preocupa em descobrir problemas nos requisitos. Contudo, esses so processos distintos, j que a validao deve se ocupar da elaborao de um esboo completo do documento de requisitos, enquanto a anlise envolve trabalhar com requisitos incompletos (SOMMERVILLE, 2007, p. 105). A validao de requisitos importante porque a ocorrncia de erros em um documento de requisitos pode levar a grandes custos relacionados ao retrabalho, quando esses erros so descobertos durante o desenvolvimento ou depois que o sistema estiver em operao. O custo
89
de fazer uma alterao no sistema, resultante de um problema de requisito, muito maior do que reparar erros de projeto e de codificao, pois, em geral, significa que o projeto do sistema e a implementao tambm devem ser modificados e que o sistema tem de ser novamente testado. Durante a etapa de validao de requisitos, Sommerville (2007, p. 106) prope que diferentes tipos de verificao devem ser realizados sobre os requisitos no documento de requisitos. Dentre as verificaes destacam-se: 1. Verificaes de validade. Um usurio pode considerar que um sistema necessrio para realizar certas funes. Contudo, mais estudos e anlises podem identificar funes adicionais ou diferentes, que so exigidas. Os sistemas tm diversos usurios com necessidades diferentes e qualquer conjunto de requisitos inevitavelmente uma soluo conciliatria da comunidade de usurios. 2. Verificaes de consistncia. Os requisitos em um documento no devem ser conflitantes, ou seja, no devem existir restries contraditrias ou descries diferentes para uma mesma funo do sistema. 3. Verificaes de completeza. O documento de requisitos deve incluir requisitos que definam todas as funes e restries exigidas pelos usurios do sistema. 4. Verificaes 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 tambm em conta o oramento e os prazos para o desenvolvimento do sistema. 5. Facilidade de verificao. Para diminuir as possveis divergncias entre cliente e fornecedor, os requisitos do sistema devem sempre ser escritos de modo que possam ser verificados. Isso implica na definio de um conjunto de verificaes para mostrar que o sistema entregue cumpre com esses requisitos. Algumas tcnicas de validao de requisitos podem ser utilizadas em conjunto ou individualmente. A seguir so mostradas algumas delas. 1. Revises de requisitos. Os requisitos so analisados sistematicamente por uma equipe de revisores, a fim de eliminar erros e inconsistncias. 2. Prototipao. Nessa abordagem de validao, um modelo executvel do sistema
90
mostrado aos usurios finais e clientes, possibilitando que os mesmos experimentem o modelo para verificar se atende s necessidades da empresa. 3. Gerao de casos de teste. Como modelo ideal, os requisitos deveriam ser testveis. Se os testes para os requisitos so criados como parte do processo de validao, isso, muitas vezes, revela problemas com os requisitos. Se um teste difcil ou impossvel de ser projetado, isso frequentemente significa que os requisitos sero de difcil implementao e devem ser reconsiderados. O desenvolvimento de testes a partir dos requisitos de usurio, antes da implementao do sistema, uma parte integrante da Extreme Programming. As dificuldades da validao de requisitos no devem ser subestimadas, pois muito difcil demonstrar que, de fato, um conjunto de requisitos atende s necessidades de um usurio. Os usurios devem pensar no sistema em operao e imaginar como esse sistema se adequaria ao seu trabalho. No fcil para profissionais habilitados de computao conseguir realizar esse tipo de anlise abstrata, imagina s como ser difcil para os usurios de sistema. Sendo assim, a validao de requisitos no consegue descobrir todos os problemas com os requisitos, implicando em modificaes para corrigir essas omisses e falhas de compreenso, depois que o documento de requisitos foi aceito (SOMMERVILLE, 2011, p. 77).
Gastamos um bom tempo a maior parte do esforo de um projeto no implementando ou testando, mas sim tentando decidir o que construir. Brian Lawrence, ex-jogador de beisebol da Major League.
91
Uso de prottipos de interface como idioma durante a Validao de requisitos Uma anlise semitica Por Carlos Eduardo Marquioni, M.Sc., PMP Fonte: <http://www.marquioni.com.br/artigos.php?id_artigo=14&titulo=Uso de prottipos de interface como idioma durante a Validao de requisitos Uma anlise semitica>. Acesso em: 12 jun. 2012.
CONSIDERAES FINAIS
Caro(a) aluno(a), chegamos ao final da terceira unidade, na 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 tambm as restries sobre o seu funcionamento e implementao. Os requisitos de software podem ser classificados em requisitos funcionais que so aqueles servios que o sistema deve fornecer e requisitos no funcionais que esto, frequentemente, relacionados s propriedades emergentes do sistema, aplicando-se ao sistema como um todo. Todos os requisitos, sejam eles funcionais ou no funcionais, devem ser definidos da forma mais clara possvel para que no haja problemas na sua interpretao, pois a partir da definio desses requisitos que o sistema ser modelado, projetado, implementado, testado e, por fim, colocado em funcionamento. Um erro na definio de requisitos pode levar a alteraes em todas essas etapas, por isso essa etapa to importante. Para auxiliar todo esse processo, vimos que Sommerville (2011) prope que a engenharia de requisitos seja um processo que deve incluir quatro atividades de alto nvel. 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 relatrio de viabilidade deve ser elaborado, no qual se recomenda se vale a pena ou no realizar o processo de engenharia de requisitos e, consequentemente, o processo de desenvolvimento de sistemas.
92
Aps o estudo de viabilidade, parte-se para a descoberta dos requisitos, ou seja, realizado o levantamento e a anlise dos requisitos, envolvendo diferentes tipos de pessoas (stakeholders) na organizao. Existem diversas formas para que esse levantamento seja realizado, alm 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 converso dos requisitos levantados em uma forma-padro, 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 verificao de que os requisitos realmente definem o sistema que o cliente quer, ou seja, deve ser realizada a validao dos requisitos anotados no documento de requisitos. Note que, nem sempre fcil validar os requisitos, pois, s vezes, o prprio cliente no sabe definir com preciso o que ele deseja, o que acaba dificultando essa etapa. Na prxima unidade vamos conhecer como se d o processo de modelagem de um sistema e vamos usar os conceitos de orientao a objetos apresentados na primeira unidade, pois a UML Unified Modeling Language (Linguagem de Modelagem Unificada), que utilizaremos para realizar a modelagem, baseada no paradigma da orientao a objetos. Nesta prxima unidade trabalharemos com uma ferramenta CASE para nos auxiliar na elaborao de alguns diagramas e voc ver que o documento de requisitos realmente muito importante. Vamos l?
1. Identifique e descreva os quatro tipos de requisitos que podem ser definidos para um sistema. 2. Descreve trs tipos de requisitos no funcionais que podem ser definidos para um sistema, fornecendo exemplos para cada um deles. 3. Baseando-se no Documento de Requisitos da Locadora de Filmes, mostrado como exemplo nesta unidade, relacione os requisitos funcionais encontrados no mesmo. 4. Descreva detalhadamente as quatro atividades que fazem parte do processo de engenharia de requisitos.
93
UNIDADE IV
MODELAGEM DE SISTEMAS
Professora Me. Mrcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Expor a importncia 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 so construdos os diagramas de casos de uso e de classes. Plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Modelagem de Sistemas Diagrama de Casos de Uso Diagrama de Classes
INTRODUO
Caro(a) aluno(a), na terceira unidade estudamos sobre os requisitos de um sistema e foi bastante destacada a importncia 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 elaborao de modelos abstratos de um sistema, normalmente representado por meio de um diagrama, em que cada um desses modelos apresenta uma viso ou perspectiva diferente do sistema (SOMMERVILLE, 2011 p. 82). Esses modelos, normalmente, so elaborados utilizando-se uma notao grfica, que, em nosso caso, ser a UML.
De acordo com BOOCH (2005, p. 13), a UML uma linguagem-padro para a elaborao da estrutura de projetos de software. Ela poder ser empregada para a visualizao, a especificao, a construo e a documentao de artefatos que faam uso de sistemas complexos de software. Da mesma forma que os arquitetos elaboram plantas e projetos para serem usados, para a construo de um edifcio, os engenheiros de software criam os diagramas UML para auxiliar os desenvolvedores de software a construir o software.
97
A UML foi desenvolvida, inicialmente, por meio da combinao de um grupo de notaes de modelagem usadas pela indstria de software: o mtodo de Booch, o mtodo OMT (Object Modeling Technique) de Jacobson e o mtodo OOSE (Object-Oriented Software Engineering) de Rumbaugh. Em 1997, a UML 1.0 foi oferecida para padronizao ao OMG (Object Management Group). A UML 1.0 foi revisada com a ajuda de vrios segmentos da comunidade de desenvolvedores de software, tornando-se UML 1.1, sendo adotada pelo OML em novembro de 1997. O padro atual a UML 2.0, sendo um padro ISO. A UML define em sua verso 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 referncias. 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 caractersticas do sistema sob o ponto de vista do usurio, sendo um dos diagramas mais gerais e informais da UML. Para a elaborao do diagrama de casos de uso, deve ser utilizada uma linguagem simples e de fcil compreenso para que os usurios possam ter uma ideia geral de como o sistema ir se comportar (GUEDES, 20007, p. 15). Depois, ser mostrado o diagrama de classes. Esse o diagrama mais importante e tambm o mais utilizado da UML, e serve de apoio para a maioria dos outros diagramas (que no sero abordados neste livro). O diagrama de classes define a estrutura das classes identificadas para o sistema, mostrando os atributos e mtodos possudos por cada uma das classes, alm de estabelecer como as classes se relacionam e trocam informaes entre si.
98
MODELAGEM DE SISTEMAS
A necessidade de planejamento no desenvolvimento de sistemas de informao 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 representao idealizada de um sistema a ser construdo. Exemplos de modelos: maquetes de edifcio, plantas de casa, fluxogramas etc. A modelagem de sistemas de software consiste na utilizao de notaes grficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema. So vrias as razes para se utilizar modelos na construo de sistemas, eis algumas: No desenvolvimento de software usamos desenhos grficos denominados de diagramas para representar o comportamento do sistema. Esses diagramas seguem um padro lgico e possuem uma srie de elementos grficos que possuem um significado pr-definido. Apesar de um diagrama conseguir expressar diversas informaes de forma grfica, em diversos momentos h a necessidade de adicionar informaes na forma de texto, com o objetivo de explicar ou definir certas partes desse diagrama. A modelagem de um sistema em forma de diagrama, juntamente com a informao textual associada, formam a documentao de um sistema de software. O rpido crescimento da capacidade computacional das mquinas resultou na demanda 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 reavaliao da forma de desenvolver sistemas. Desde o aparecimento do primeiro computador at os dias de hoje, as tcnicas para construo de sistemas computacionais tm evoludo para suprir as necessidades do desenvolvimento de software.
Dcada de 1950/60: os sistemas de software eram bastante simples e dessa forma as tcnicas de modelagem tambm. Era a poca dos fluxogramas e diagramas de mdulos. Dcada de 1970: nessa poca houve uma grande expanso do mercado computacional. Sistemas complexos comeavam a surgir e, por consequncia, modelos
99
mais robustos foram propostos. Nesse perodo, surge a programao estruturada e no final da dcada a anlise e o projeto estruturado. Dcada de 1980: surge a necessidade por interfaces homem-mquina mais sofisticadas, o que originou a produo de sistemas de software mais complexos. A anlise estruturada se consolidou na primeira metade dessa dcada e em 1989 Edward Yourdon lana o livro Anlise Estruturada Moderna, tornando-o uma referncia no assunto. Dcada de 1990: nesse perodo surge um novo paradigma de modelagem, a Anlise Orientada a Objetos, como resposta a dificuldades encontradas na aplicao da Anlise Estruturada a certos domnios de aplicao. Final da dcada de 90 e momento atual: o paradigma da orientao a objetos atinge a sua maturidade. Os conceitos de padres de projetos (design patterns), frameworks de desenvolvimento, componentes e padres de qualidade comeam a ganhar espao. Nesse perodo, 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 nmero de projetos de software que no chegam ao fim, ou que extrapolam recursos de tempo e de dinheiro alocados. Em um estudo clssico 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 so descontinuados antes de chegarem ao fim: 25%. Porcentagem de projetos acima do custo esperado: 60%. Atraso mdio nos projetos: um ano.
Os modelos construdos na fase de anlise devem ser cuidadosamente validados e verificados. O objetivo da validao assegurar que as necessidades do cliente esto sendo atendidas. Nessa atividade, os analistas apresentam os modelos criados para representar o sistema aos futuros usurios para que esses modelos sejam validados.
100 ENGENHARIA DE SOFTWARE | Educao a Distncia
A verificao tem o objetivo de analisar se os modelos construdos esto em conformidade com os requisitos definidos. Na verificao dos modelos, so analisadas a exatido de cada modelo em separado e a consistncia entre os modelos. A verificao uma etapa tpica da fase de projeto que a prxima 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 orientao a objetos e tambm fizemos uma introduo linguagem UML. Lembre-se que os artefatos de software produzidos durante a modelagem serviro 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, flexvel e informal, sendo utilizado principalmente no incio da modelagem do sistema, a partir do documento de requisitos, podendo ser consultado e possivelmente modificado durante todo o processo de engenharia e tambm serve de base para a modelagem de outros diagramas (GUEDES, 2007, p. 38). O principal objetivo deste diagrama modelar as funcionalidades e servios oferecidos pelo sistema, buscando, por meio de uma linguagem simples, demonstrar o comportamento externo do sistema da perspectiva do usurio. 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 correspondncia entre os requisitos funcionais previstos para o software e os casos de uso. Os requisitos no funcionais no aparecem no diagrama de casos de uso, pois no constituem o foco da modelagem que estamos realizando.
101
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 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 estmulo de um ator; ocasionalmente, outros atores podem participar do caso de uso. A figura abaixo apresenta alguns exemplos de atores.
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 servios, tarefas ou funes apresentadas pelo sistema, como cadastrar funcionrio ou emitir relatrio de produtos. No diagrama de caso de uso no possvel documentar os casos de uso e nem a UML oferece um recurso para que isso seja feito, porm, indicado que cada caso de uso seja documentado, demonstrando qual o comportamento pretendido para o caso de uso em questo e quais funes ele executar quando for solicitado. Essa documentao dever, tambm, ser elaborada de acordo com o documento de requisitos e poder auxiliar o desenvolvedor na
elaborao dos demais diagramas da UML. A figura abaixo apresenta alguns exemplos de casos de uso.
Exemplos de Casos de Uso Normalmente, os nomes de casos de uso so breves expresses verbais ativas, nomeando algum comportamento encontrado no vocabulrio 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 enviaro e recebero mensagens destes. Podemos ter os relacionamentos de associao, generalizao, extenso e incluso, da seguinte forma: Para relacionamentos entre atores e casos de uso somente associao; Para relacionamentos de atores, entre si somente generalizao; Para relacionamentos de casos de uso, entre si generalizao, extenso e incluso.
Associao A associao o nico relacionamento possvel entre ator e caso de uso, sendo sempre binria, ou seja, sempre envolvendo apenas dois elementos. Melo (2004, p. 60) diz que Representa a
103
interao do ator com o caso de uso, ou seja, a comunicao entre atores e casos de uso, por meio do envio e recebimento de mensagens. Um relacionamento de associao 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 associao, ou seja, se as informaes so fornecidas pelo ator ao caso de uso (nesse caso a seta aponta para o caso de uso), se so transmitidas pelo caso de uso ao ator (nesse caso a seta aponta para o ator) ou ambos (neste ltimo caso a reta no possui setas) (GUEDES, 2007, p. 40). A figura abaixo representa uma associao entre um ator e um caso de uso, em que o ator fornece uma informao para o caso de uso.
Associao entre um ator e um caso de uso Veja o exemplo abaixo. Nele est sendo mostrado que o ator Gerente Administrativo recebe o Relatrio de Vendas por Perodo (note que ele no solicita a emisso do relatrio, ele somente recebe o relatrio).
Associao entre um ator e um caso de uso
Neste outro exemplo, percebemos que o ator denominado Submissor utiliza, de alguma forma, o servio de Realizar Submisso e que a informao referente a esse processo trafega nas duas direes.
Associao entre um ator e um caso de uso Generalizao J explicamos o conceito de generalizao/especializao quando falamos sobre herana. Aqui, no diagrama de casos de uso, tambm aplicamos esse conceito, ou seja, o relacionamento de generalizao entre casos de uso pode ocorrer quando existirem dois ou mais casos de usos com caractersticas semelhantes, apresentando pequenas diferenas entre si. Quando isso acontece, define-se um caso de uso geral, que dever possuir as caractersticas compartilhadas por todos os casos de uso em questo, e ento relacionamos esse caso de uso geral com os casos de uso especficos, que devem conter somente a documentao das caractersticas especficas de cada um deles. Dessa forma, evita-se reescrever toda a documentao 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 possveis associaes que o caso de uso generalizado possua. A associao 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).
105
Exemplo de generalizao entre casos de uso Agora vamos entender o que este exemplo est representando: em um banco, existem trs opes de abertura de contas: abertura de conta comum, de conta especial e de conta poupana, cada uma representada por um caso de uso diferente. As aberturas de conta especial e de conta poupana possuem todas as caractersticas e requisitos da abertura de conta comum, porm, cada uma delas possui tambm algumas caractersticas e requisitos prprios, o que justifica coloc-las como especializaes do caso de uso Abertura de Conta Comum, detalhando-se as particularidades de cada caso de uso especializado em sua prpria documentao (GUEDES, 2007, p. 41). O relacionamento de generalizao/especializao tambm 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 Fsica e Pessoa Jurdica.
Generalizao entre Atores Incluso Este tipo de relacionamento possvel somente entre casos de uso e utilizado quando existem aes comuns a mais de um caso de uso. Quando isso ocorre, a documentao dessas aes colocada em um caso de uso especfico, permitindo que outros casos de uso se utilizem dessas aes, evitando-se descrever uma mesma sequncia de passos em vrios casos de uso (GUEDES, 2007, p. 42). Um relacionamento de incluso entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso. O caso de uso includo nunca permanece isolado, mas apenas instanciado como parte de alguma base maior que o inclui (BOOCH, 2005, p. 235).
107
O relacionamento de incluso pode ser comparado chamada de uma sub-rotina, portanto, indicam uma obrigatoriedade, ou seja, quando um caso de uso base possui um relacionamento de incluso com outro caso de uso, a execuo do primeiro obriga tambm a execuo do segundo (GUEDES, 2007, p. 42). A representao do relacionamento de incluso feita por meio de uma reta tracejada contendo uma seta em uma de suas extremidades, e rotulada com a palavra-chave <<include>>. A seta deve sempre apontar para o caso de uso a ser includo. Veja um exemplo na figura abaixo, que foi retirado de Guedes (2007, p. 43).
Exemplo de incluso de caso de uso Neste exemplo sempre que um saque ou depsito ocorrer, ele deve ser registrado para fins de histrico bancrio. Como as rotinas para registro de um saque ou um depsito so extremamente semelhantes, colocou-se a rotina de registro em um caso de uso parte,
chamado Registrar Movimento, que ser executado obrigatoriamente sempre que os casos de uso Realizar Depsito ou Realizar Saque forem utilizados. Assim, s preciso descrever os passos para registrar um movimento no caso de uso includo (GUEDES, 2007, p. 43). Neste exemplo temos dois casos de uso base e um caso de a ser includo. Agora veja outro exemplo na figura abaixo. Aqui, est sendo apresentada a seguinte situao: em algum ponto dos casos de uso Realizar matrcula do aluno (caso de uso base), Cadastrar pagamento mensalidade aluno (caso de uso base) e Emitir histrico escolar aluno (caso de uso base) necessrio Validar a matrcula (caso de uso a ser includo) do aluno. Assim, nestes pontos o caso de uso Validar matrcula ser internamente copiado.
Outro exemplo de incluso de caso de uso Extenso O relacionamento de extenso tambm possvel somente entre casos de uso e utilizado para modelar rotinas opcionais de um sistema, que ocorrero somente se uma determinada condio for satisfeita. A extenso separa um comportamento obrigatrio de outro opcional. As associaes de extenso possuem uma representao muito semelhante s associaes de incluso, sendo tambm representadas por uma reta tracejada, diferenciando-se por possuir um esteretipo contendo o texto <<extend>> e pela seta apontar para o caso de uso
109
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 extenso.
Exemplo de extenso de caso de uso Neste exemplo, est sendo mostrado que tanto o Cliente quanto o Banco podem Verificar a situao 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 condio do caso de uso base Verificar situao conta corrente do cliente for satisfeita, caso contrrio, o extrato nunca ser emitido. Agora vamos mostrar um exemplo bastante comum que acontece quando utilizamos sistemas via Internet, em que, para utilizar os servios, o cliente deve se logar no sistema e, caso seja a primeira vez, dever realizar o seu cadastro pessoal.
Outro exemplo de extenso de caso de uso
No exemplo acima, o caso de base o Realizar login no site e Realizar cadastro dados pessoais o caso de uso a ser estendido. Caro(a) aluno(a), para facilitar o entendimento do relacionamento de extenso, vamos mostrar mais um exemplo de uso do mesmo. Na figura abaixo est sendo apresentada a seguinte situao: durante a execuo do caso de uso Efetuar venda, a venda pode estar sendo realizada para um cliente especial. Neste caso, necessrio, num ponto predefinido, incluir uma complementao da rotina que ser responsvel por calcular o desconto para um cliente especial. Da mesma forma, durante o pagamento pode haver algum tipo de falha na autorizao do carto. Veja que esse no um procedimento normal, pois possvel ter pagamentos em dinheiro, cheque etc. Assim, havendo falha na autorizao, o caso de uso pertinente dever dar um tratamento situao.
Representao de um Relacionamento Extend QUADRO RESUMO DE RELACIONAMENTOS ENTRE CASOS DE USO E ATORES
Associao Caso de Uso e Caso de Uso Ator e Ator Ator e Caso de Uso --------OK Especializao/ Generalizao OK OK ----Incluso OK --------Extenso OK ---------
111
<http://www.youtube.com/watch?v=hfN6n5fJfLc&feature=relmfu>. Vdeo que mostra a importncia da modelagem de sistemas, bem como trata da elaborao do diagrama de casos de uso.
ESTUDO DE CASO
Vamos mostrar um documento de requisitos de uma fbrica de colches 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 observao importante que esse documento de requisitos est bastante simplificado, seu principal objetivo mostrar como os conceitos mostrados podem ser aplicados em um diagrama de casos de uso.
DOCUMENTO DE REQUISITOS FBRICA DE COLCHES

A fbrica de colches Mimindo Ltda compra matria-prima, fabrica os colches (casal ou solteiro) e vende para seus clientes de vrias partes do pas. Ela deseja gerenciar todos os processos com a utilizao de um sistema que voc vai desenvolver. Mas, o sistema ser desenvolvido em partes sendo o que a empresa precisa de imediato lanar no sistema as compras de matrias-primas (MP) e cadastrar os produtos acabados (PA).
Algumas informaes importantes que ajudar o entendimento do sistema Quando a Mimindo Ltda comprar MP (matria-prima) de um fornecedor receber uma nota de compra que deve ser lanada no sistema. Nesta nota constam as seguintes informaes: o nmero da nota, data emisso, nome do fornecedor, CFOP (cdigo fiscal de operao) e as MPs com as quantidades compradas de cada uma delas, bem como o seu valor unitrio. Uma nota de compra pode conter N matrias-primas. No lanamento 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 poder pertencer a um nico grupo (Ex.: tecidos, espumas etc.). Os PAs (produtos acabados) so os colches fabricados que a Mimindo Ltda ir vender (esse sistema que voc est desenvolvendo agora no tratar da venda). Para fabricar um PA necessrio saber quais as matrias-primas que compem esse PA, bem como a quantidade de cada matria-prima que utilizada na fabricao do PA. O sistema deve permitir o cadastro dos PAs e tambm as matrias-primas e as quantidades de cada MP usadas em cada um deles. Os cadastros e a movimentao do sistema devero ser realizadas pelo departamento de compras. O sistema deve emitir os relatrios que esto definidos abaixo. A informao de quem solicita cada relatrio bem como de quem recebe cada relatrio est junto com a definio do relatrio.
O sistema deve emitir os seguintes relatrios: A) Lista de Fornecedores contendo o cdigo, nome, cidade e fone. Este relatrio ser solicitado e recebido pelo Departamento de Compras. B) Lista de MPs por grupo contendo o nome do grupo e para cada grupo os dados da matria-prima: cdigo, descrio, quantidade em estoque e valor unitrio. Este relatrio ser solicitado pelo Departamento de Compras e recebido pelo Departamento de Compras e pelo Gerente de Compras. C) Relao de Compras por Fornecedor, contendo Nmero da Nota, Nome do fornecedor, Data da emisso e Total da nota. Este relatrio ser solicitado e recebido pelo Departamento de Compras. D) Lista de Produtos Acabados contendo o cdigo, descrio, valor de venda e o tipo
113
do colcho (se solteiro, casal, bero, queen size ou king size). Para cada produto acabado, emitir a lista de matrias-primas utilizadas para fabricao do mesmo. Para cada matria-prima, emitir o seu cdigo, sua descrio e a quantidade utilizada na fabricao do PA. Este relatrio ser solicitado e recebido pelo Departamento de Compras e tambm ser solicitado e recebido pelo Gerente de Compras. A figura abaixo mostra uma possvel soluo para o problema que acabamos de descrever.
Diagrama de Casos de Uso para o Sistema Fbrica de Colches
DIAGRAMA DE CLASSES
O diagrama de classes tem como objetivo permitir a visualizao das classes utilizadas pelo sistema e como essas se relacionam, apresentando uma viso esttica de como essas classes esto organizadas, preocupando-se apenas em definir sua estrutura lgica (GUEDES, 2007, p. 52). Ainda conforme Guedes (2007, p. 52), um diagrama de classes pode ser utilizado para modelar o modelo lgico 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 no o Diagrama de Entidade-Relacionamento, e mais importante, que uma classe no, necessariamente, corresponde a uma tabela. Uma classe pode representar o repositrio lgico dos atributos de uma tabela, porm, a classe no a tabela, uma vez que os atributos de seus objetos so armazenados em memria enquanto uma tabela armazena seus registros fisicamente em disco. Alm disso, uma classe possui mtodos, que no existem em uma tabela.
115
RELACIONAMENTOS
As classes no trabalham sozinhas, pelo contrrio, elas colaboram umas com as outras por meio de relacionamentos (MELO, 2004, p. 108). No diagrama de classes temos os relacionamentos de associao (que pode ser unria ou binria), generalizao e agregao. Existem alguns tipos especiais de relacionamentos, porm no sero explicados aqui. Com os relacionamentos citados possvel elaborar um diagrama de classes. Associao De acordo com Melo (2004, p. 109), a associao um relacionamento que conecta duas ou mais classes, demostrando a colaborao entre as instncias de classe. Pode-se tambm ter um relacionamento de uma classe com ela mesma, sendo que, neste caso, tem-se a associao unria ou reflexiva. Associao Unria ou Reflexiva Segundo Gedes (2007, p. 54), a associao unria ocorre quando existe um relacionamento de uma instncia de uma classe com instncias da mesma classe, conforme mostra o exemplo abaixo.
Exemplo de Associao Unria
Neste exemplo, temos a classe Funcionrio, cujos atributos so cdigo, nome e o cdigo do possvel chefe do funcionrio. Como esse chefe tambm um funcionrio, a associao chamada Chefia indica uma possvel relao entre uma ou mais instncias da classe Funcionrio com outras instncias da mesma classe, ou seja, tal associao determina que um funcionrio pode ou no chefiar outros funcionrios. Essa associao faz com que a classe possua o atributo codChefe para armazenar o cdigo do funcionrio que responsvel pela instncia do funcionrio em questo. Desse modo, aps consultar uma instncia da classe funcionrio, pode-se utilizar o atributo codChefe da instncia consultada para pesquisar por outra instncia da Classe (GUEDES, 2007, p. 54). Associao Binria A associao binria conecta duas classes por meio de uma reta que liga uma classe a outra. A figura abaixo demonstra um exemplo de associao binria.
Exemplo de associao binria Neste exemplo, um objeto da classe Cidade pode se relacionar ou no com instncias 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 no foi definida a multiplicidade na extremidade da classe Cidade, significa que ela 1..1. Logo depois da explicao sobre os relacionamentos em um diagrama de classes, explicaremos o conceito de multiplicidade.
117
Agregao A agregao corresponde a um tipo especial de associao utilizada para expressar um relacionamento todo-parte. Ou seja, as informaes do objeto-todo precisam ser complementadas pelas informaes contidas em um ou mais objetos de outra classe, chamados objeto-parte, sendo que, os objetos-parte no podem ser destrudos por um objeto diferente do objeto-todo (GUEDES, 2007, p. 57). O smbolo de agregao difere do de associao por conter um losango na extremidade da classe que contm os objetos-todo. A figura abaixo demonstra um exemplo de agregao, em que existe uma classe Pedido, que armazena os objetos-todo e uma classe Item_Pedido, em que so armazenados os objetos-parte.
Exemplo de agregao
Neste exemplo, um pedido pode possuir apenas um item como vrios, no sendo possvel determinar o nmero mximo de itens que um pedido pode ter. Por isso, as informaes da classe Pedido esto incompletas, possuindo apenas atributos que no se repetem. Os atributos que podem se repetir devem ser armazenados em uma classe dependente da classe Pedido. Dessa forma, sempre que uma instncia da classe Pedido for pesquisada, todas as instncias da classe Item_Pedido relacionadas instncia da classe Pedido pesquisada devero tambm ser apresentadas. Da mesma forma, sempre que um objeto da classe Pedido for destrudo, todos os objetos da classe Item_Pedido a ele relacionados devem tambm ser destrudos (GUEDES, 2007, p. 58). Note que o relacionamento entre a classe Item_Pedido e Produto de associao, portanto, quando o objeto da classe Item_pedido for excludo, por exemplo, o objeto relacionado a ele, na classe Produto, no dever ser excludo. Generalizao/Especializao Esta associao identifica classes-me (superclasse), chamadas gerais e classesfilhas (subclasses), chamadas especializadas, demonstrando a ocorrncia de herana e possivelmente de mtodos polimrficos nas classes especializadas. Anteriormente, na unidade I, j foi explicado o conceito de herana e polimorfismo.
MULTIPLICIDADE
De acordo com Guedes (2007, p. 54), a multiplicidade determina o nmero mnimo e mximo de instncias envolvidas em cada uma das extremidades da associao, permitindo tambm especificar o nvel de dependncia de um objeto para com os outros. Quando no existe multiplicidade explcita, entende-se que a multiplicidade 1..1, significando que uma e somente uma instncia dessa extremidade da associao relaciona-se com as
119
instncias da outra extremidade. A tabela abaixo, retirada de Guedes (2007, p. 55) demonstra alguns dos diversos valores de multiplicidade que podem ser utilizados em uma associao. Tabela Exemplos de multiplicidade
Multiplicidade 0..1 Significado No mnimo zero (nenhum) e no mximo um. Indica que os objetos das classes associadas no precisam obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instncia da classe se relaciona com as instncias da outra classe. Um e somente um. Indica que apenas um objeto da classe se relaciona com os objetos da outra classe. No mnimo nenhum e no mximo muitos. Indica que pode ou no haver instncias da classe participando do relacionamento. Muitos. Indica que muitos objetos da classe esto envolvidos no relacionamento. No mnimo 1 e no mximo muitos. Indica que h pelo menos um objeto envolvido no relacionamento, podendo haver muitos objetos envolvidos. No mnimo 2 e no mximo 5. Indica que existem pelo menos 2 instncias envolvidas no relacionamento e que podem ser 3, 4 ou 5 as instncias envolvidas, mas no mais do que isso.
1..1 0..* * 1..* 2..5
As associaes que possuem multiplicidade do tipo muitos (*) em qualquer de suas extremidades, foram a transmisso do atributo-chave contido na classe da outra extremidade da associao, porm esse atributo-chave no aparece desenhado na classe.
CLASSE ASSOCIATIVA
Quando um relacionamento possui multiplicidade muitos (*) em suas duas extremidades necessrio criar uma classe associativa para guardar os objetos envolvidos nessa associao. Na classe associativa so definidos o conjunto de atributos que participam da associao e no s classes que participam do relacionamento. Neste caso, pelo menos os atributos-chave devem fazer parte da classe associativa, porm, a classe associativa tambm pode possuir atributos prprios. Uma classe associativa representada por uma reta tracejada partindo do meio da associao e atingindo uma classe. A figura abaixo apresenta um exemplo de classe associativa que
possui atributos prprios, alm dos atributos-chave das classes que participam da associao (s que nesse caso esses atributos-chave no so representados no diagrama).
Exemplo de classe associativa Neste exemplo, uma instncia da classe Curso pode se relacionar com muitas instncias da classe Disciplina, e uma instncia da classe Disciplina pode se relacionar com muitas instncias da classe Curso. Como existe a multiplicidade muitos nas extremidades de ambas as classes da associao, no h como reservar atributos para armazenar as informaes decorrentes da associao, pois no h como determinar um limite para a quantidade 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 informao, alm das informaes prprias da classe, que so a carga horria da disciplina no curso e tambm a qual srie essa disciplina estar vinculada naquele curso. Os atributos-chave das classes Curso e Disciplina so transmitidos de forma transparente pela associao, no sendo, portanto, necessrio escrevlos como atributos da classe associativa. Segundo Guedes (2007, p. 61), as classes associativas podem ser substitudas por classes normais, que, neste caso, so chamadas de classes intermedirias, mas que desempenham
121
exatamente a mesma funo das classes associativas. A figura abaixo mostra o mesmo exemplo da figura anterior, porm com a classe intermediria ao invs da classe associativa.
Exemplo de classe intermediria
ESTUDO DE CASO 1
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 Fbrica de Colches. No vou colocar o documento aqui, mas seria interessante que voc fizesse a leitura novamente do documento antes de analisar o diagrama de classes abaixo.
ESTUDO DE CASO 2
Neste estudo de caso, vou mostrar um novo documento de requisitos, agora de um Laboratrio de Anlises Clnicas. Com base nesse documento de requisitos, vamos elaborar o diagrama de casos de uso e tambm o diagrama de classes, mas dessa vez faremos isso passo a passo. Mas antes de comearmos a ler o documento de requisitos, gostaria que voc imaginasse que foi a um mdico, por exemplo, um clnico geral. Para te dar um diagnstico preciso e correto, esse mdico pediu que voc fizesse uma srie de exames, como, por exemplo: hemograma, glicemia, creatinina, triglicerdeos e urocultura. Ele anotou essa lista de exames em um Pedido de Exames e voc, de posse desse pedido, vai at um laboratrio de anlises clnicas para fazer os exames (nesse caso, voc vai at o Laboratrio So Joo). a que comea o nosso documento de requisitos. DOCUMENTO DE REQUISITOS Laboratrio de Anlises Clnicas O Laboratrio de Anlises Clnicas So Joo deseja informatizar suas atividades, pois hoje no h controle sobre o histrico 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 laboratrio funciona da seguinte forma: O paciente (voc) chega ao laboratrio com o pedido dos exames (preenchido pelo seu mdico aquele que o clnico geral que voc acabou de consultar, preencheu). Se for a primeira vez que o paciente vai fazer exames, preenchida uma ficha de cadastro com os seguintes dados: nome, endereo, cidade, UF, CEP, telefone, data de nascimento, RG e CPF. A recepcionista (a moa que te atendeu quando voc chegou ao laboratrio So Joo) preenche uma ficha com o nome do paciente, nome do convnio do paciente, os nomes dos exames que o paciente ir fazer e a data e horrio da realizao de cada exame. No final da ficha anotada a data em que os exames estaro prontos. A primeira via desta ficha entregue ao paciente (a voc).
123
O resultado do exame colocado no envelope para posterior retirada pelo paciente.
O Laboratrio deseja que o novo sistema possa fornecer informaes rpidas, precisas e seguras, para assim melhorar suas atividades administrativas e o atendimento a seus pacientes (e neste caso, voc vai demorar bem menos no laboratrio, pois os processos estaro automatizados). Para tanto, o novo sistema deve: Permitir o cadastro dos pacientes do laboratrio, com todos os dados preenchidos hoje na ficha de cadastro. Esse cadastro ser realizado pelas recepcionistas. Permitir o cadastro dos exames que o laboratrio pode realizar. Cada exame pertence a um Grupo de Exames. Por exemplo, o exame HEMOGRAMA, pertence ao grupo SANGUE. Para cada exame preciso saber o seu cdigo, descrio, valor e procedimentos para a realizao do mesmo. Por exemplo, hemograma: deve estar em jejum. Esse cadastro ser realizado pelos Bioqumicos. Permitir o cadastro dos pedidos de exames dos pacientes. necessrio saber qual o nome do paciente, o nome do mdico que est solicitando os exames, o nome do convnio que o paciente ir utilizar para este pedido, data e horrio dos exames (ateno: cada exame pode ser realizado em datas e horrios diferentes), os nomes dos exames a serem feitos, data e horrio em que cada exame ficar pronto (ateno: cada exame pode ficar pronto em uma data e horrio diferente) e o valor de cada um deles. Lembrando que o mdico pode solicitar mais de um exame em cada pedido (no seu caso, o mdico solicitou 5 exames. Est lembrado do comeo do nosso estudo de caso?). Esse cadastro ser realizado pelas recepcionistas. Emitir a ficha do paciente, contendo todos os dados cadastrados. Este relatrio ser solicitado e recebido tanto pelas recepcionistas quanto pelo departamento administrativo do laboratrio. Emitir relatrio com todos os exames que o laboratrio realiza com o cdigo, descrio, procedimentos e valor de cada exame, agrupados por grupo de exame, devendo ser impresso neste relatrio o cdigo e a descrio do grupo. Este relatrio ser solicitado e recebido pelas recepcionistas. Emitir o pedido do exame em 3 vias, com todos os dados do pedido do exame. O relatrio 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 cobrana dos exames dos convnios) e a 3 via para os bioqumicos (para a realizao dos exames). Emitir relatrio com os resultados dos exames por pedido de exame, contendo o nome do paciente, data e horrio do exame (da realizao do exame), nome do mdico que solicitou o exame, nome do convnio, o nome e o resultado de cada exame realizado, no caso de ter sido mais de um. Esse relatrio ser solicitado pela recepcionista e entregue ao paciente (no necessrio que a recepcionista fique com esse relatrio).
PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE CASOS DE USO

1. Leia novamente o Documento de Requisitos acima e verifique quais so os usurios do sistema. Essas pessoas sero os atores. Faa uma lista com os atores. a. Recepcionista a. Bioqumicos b. Departamento Administrativo c. Departamento de Faturamento d. Paciente 2. Agora faa uma lista com as funcionalidades do sistema. Algumas aparecem descritas claramente no documento de requisitos. Cada relatrio que mencionado no documento ser uma funcionalidade. Ento j sabemos que teremos as seguintes funcionalidades: a. Emitir ficha do paciente b. Emitir relatrio de exames c. Emitir pedido de exame d. Emitir resultados dos exames 3. Porm, importante observar que, alm dos relatrios, um sistema precisa ter os cadastros para que o usurio consiga inserir os dados no sistema, para da ser possvel emitir os relatrios. Ento, com base nos relatrios mencionados acima, teremos os
125
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. Ento, 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. Alm das funcionalidades j relacionadas, importante pensar que algumas informaes podem ser transformadas em classes, facilitando o uso e manuteno do sistema. Por exemplo: o sistema pode ter, alm dos cadastros relacionados acima, um cadastro de mdico, evitando que a recepcionista precisasse digitar o nome completo do mdico toda vez que um pedido de exame daquele mdico fosse lanado no sistema. Seguindo esse mesmo raciocnio alguns cadastros seriam importantes para o sistema: a. Cadastro de mdicos b. Cadastro de convnios c. Cadastro de cidades d. Cadastro de UFs e. Cadastro de grupos de exames (neste caso esse cadastro de suma importncia, pois o relatrio de exames deve ser agrupado por Grupo de Exames. Com a criao de um cadastro evita-se de o usurio cadastrar o mesmo grupo vrias 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 comea com um verbo.
PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE CLASSES

1. Como voc j fez o diagrama de casos de uso vai ficar mais fcil elaborar o diagrama de classes. Com base nos casos de uso que voc definiu, voc vai fazer uma lista das possveis classes do sistema. Lembre-se que os relatrios no sero classe por si s, mas para emitir cada relatrio 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 sero cadastrados nesse caso de uso. Seguindo esse raciocnio teramos as seguintes classes: a. Paciente b. Exame c. Pedido de Exame d. Resultado de Exame e. Mdicos f. Convnios
127
g. Cidades h. UFs i. Grupos de Exames 2. Agora, para cada uma das classes listadas, relacione os possveis atributos de cada uma delas. A maioria desses atributos j aparece descrita no documento de requisitos. Nunca se esquea de voltar ao documento de requisitos sempre que tiver dvidas. a. Paciente: cdigo, nome, endereo, CEP, cidade, UF, telefone, data de nascimento, RG e CPF. b. Exame: cdigo, descrio, valor, procedimentos, grup,o ao qual pertence o exame. c. Pedido de Exame: cdigo, nome do paciente, nome do mdico, nome do convnio, nomes dos exames que sero realizados, data e hora da realizao de cada exame, data e hora em que cada exame ficar pronto, valor de cada exame. d. Resultado de Exame: descrio do resultado (para cada exame do pedido de exame o resultado dever ser cadastrado). e. Mdicos: CRM, nome (como o documento de requisitos no menciona nada sobre os dados dos mdicos, coloquei somente os atributos que interessam para o pedido de exame). f. Convnios: cdigo, nome (como o documento de requisitos no menciona nada sobre os dados dos convnios, coloquei somente os atributos que interessam para o pedido de exame). g. Cidades: cdigo, nome, DDD (neste caso, mesmo o documento de requisitos no mencionando nada, esses atributos devem constar em qualquer classe de cidades). h. UFs: sigla, nome. i. Grupos de Exames: cdigo, descrio. 3. Desenhar as classes relacionadas acima, com seus respectivos atributos, no Diagrama de Classes. Faremos o desenho do diagrama tambm utilizando a ferramenta 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: associao (unria e binria), generalizao/especializao, agregao. Releia tambm a explicao sobre classes 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.
Seguem alguns esclarecimentos sobre o diagrama acima: 1. Um pedido de exame pode estar relacionado a somente um paciente, um mdico e um convnio (no diagrama no aparece a multiplicidade 1, por ser o valor default de
129
um relacionamento). 2. Um pedido de exame pode estar relacionado a um ou a vrios exames (no caso desse documento de requisitos, a 5 exames). 3. Note que os atributos: data_realizacao_exame, hora_realizao_exame, data_pronto, hora_pronto, resultado e valor esto armazenados na classe associativa que 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 diferentes. Por exemplo: se o atributo DATA_PRONTO tivesse sido armazenado na classe PEDIDO_EXAME, seria possvel cadastrar somente uma data em que os exames ficariam prontos. Mas, na realidade, no 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 no foi criada uma classe RESULTADO_EXAME, pois como somente uma descrio, decidiu-se armazen-la na classe associativa Exame-Pedido Exame. 5. Note tambm que na classe Pedido Exame no 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. No desenhamos o atributo-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 invs de termos utilizado o recurso da classe associativa, poderamos ter utilizado o relacionamento de agregao. Veja como ficaria (sero mostradas somente algumas classes, as demais no foram mostradas, pois ficariam iguais ao diagrama j mostrado anteriormente).
CONSIDERAES FINAIS
No decorrer desta unidade estudamos sobre a importncia 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 implantao de um bom software. necessrio 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, so representados por meio de diagramas, em que utilizada uma notao grfica, que, em nosso caso, foi a UML. A UML tem muitos tipos de diagramas, apoiando a criao de diferentes modelos de sistema, no entanto, conhecemos, nesta unidade, somente o Diagrama de Casos de Uso e o Diagrama de Classes, que so considerados por muitos autores, como os principais diagramas da UML. A UML no estabelece uma ordem pr-definida para a elaborao dos seus diversos diagramas,
131
porm, como o diagrama de casos de uso, um dos diagramas mais gerais e informais da UML, normalmente a modelagem do sistema inicia-se com a elaborao desse diagrama. O diagrama de casos de uso mostra as interaes entre um sistema e seu ambiente externo, determinando as funcionalidades e as caractersticas do sistema sob o ponto de vista do usurio. Conhecemos, nesta unidade, os conceitos necessrios para a elaborao desse diagrama: atores, casos de uso e os possveis relacionamentos entre estes elementos. Alm disso, foi apresentado um diagrama pronto, que foi elaborado a partir do documento de requisitos para uma fbrica de colches, mostrando como os conceitos acima podem ser aplicados em um diagrama. Depois que o diagrama de casos de uso elaborado fica bem mais fcil elaborar o diagrama de classes, que o mais importante e tambm o mais utilizado da UML, e que define a estrutura das classes identificadas para o sistema, mostrando os atributos e mtodos possudos por cada uma das classes, e tambm os seus relacionamentos. Com base no mesmo documento de requisitos, o da fbrica de colches, foi mostrado como fica o diagrama de classes referente ao mesmo. E, para auxiliar o entendimento desses dois diagramas, foi apresentado a elaborao 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. Ento mos a obra!
1. Sobre relacionamento entre Casos de Uso e Atores a. Explique o relacionamento de Associao (association). b. Explique o relacionamento de Generalizao entre casos de uso (generalization). c. Explique o relacionamento de Extenso (extend ). d. Explique o relacionamento de Incluso (include). 2. Explique qual a diferena entre os diagramas de classe abaixo:
Diagrama A
Gnero
1..*
Diagrama B
Filme
Gnero
0..*
Filme
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 Peas XYZ Ltda atua no ramo de compra e venda de peas para veculos automotores. Atualmente, a empresa no possui sistema automatizado, mas pretende informatizar-se totalmente, para isso est contratando os servios de um analista de sistemas. A empresa pretende comear pelo controle de estoque, pois o aumento do seu faturamento depende de um controle de estoque rgido. O sistema atualmente funciona da seguinte maneira: 1. Os produtos so separados e controlados por grupos de produtos. 2. A empresa compra peas de diversos fornecedores. preenchido um formulrio denominado pedido de compra, no qual constam os seguintes dados: nmero do pedido, data do pedido, nome do fornecedor, telefone do fornecedor, nome do produto, quantidade do produto e preo unitrio do produto. E, no final do pedido, uma totalizao (quantidade * preo). Em cada pedido de compra tem-se somente um fornecedor, podendo ter-se vrios produtos comprados. 3. Vende as peas vista ou a prazo para os clientes. Nas vendas vista so preenchidos os seguintes dados do cliente: nome, endereo completo, telefone e e-mail, para envio de correspondncias (jornais de propaganda, ofertas). Nas vendas a prazo, so preenchidos os seguintes dados: nome, endereo completo, telefone, e-mail, RG, CPF, renda mensal, local de trabalho. Para cada venda preenchida uma nota fiscal de venda, contendo os seguintes dados: nmero da nota fiscal, data da venda, nome do cliente, nome do vendedor, condio de pagamento, nome do produto, quantidade do produto e preo unitrio do produto. Sendo que, no final da nota fiscal, feito uma totalizao da mesma (quantidade * preo unitrio). Em cada nota fiscal de venda tem-se somente um cliente, podendo ter-se vrios produtos vendidos. 4. Os vendedores so comissionados. Cada vendedor pode ter um % diferente de comisso sobre as vendas efetuadas. No final de cada ms, as vendas so somadas e a comisso do vendedor calculada. A empresa deseja que o sistema: Efetue o cadastro dos pedidos de compra que so preenchidos no item 2, atualizando automaticamente o estoque dos produtos que esto sendo comprados (somando no estoque). Este cadastro ser realizado pelo Departamento de Compras.
133
Efetue o cadastro das notas fiscais de vendas que so preenchidas no item 3, atualizando automaticamente o estoque do produto que est sendo vendido (diminuindo do estoque). Este cadastro ser realizado pelo Departamento de Vendas. Calcule automaticamente as comisses dos vendedores de acordo com o % de cada um deles. Os demais cadastros sero efetuados pelo Departamento de Vendas.
O sistema deve emitir os seguintes relatrios: Lista de preo de produtos por grupo de produtos. Este relatrio ser solicitado e recebido pelo Departamento de Compras e pelo Departamento de Vendas.
Grupo: 99 - XXXXXXXXXXXXXXXXXXXX Cdigo Produto 999999 999999 Nome do Produto XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX Preo Unitrio 999.999,99 999.999,99
Quantidade disponvel em estoque por produto e grupo de produto. Este relatrio ser solicitado e recebido pelo Departamento de Compras e pelo Departamento de Vendas.
Grupo: 99 - XXXXXXXXXXXXXXXXXXXX Cdigo Produto 999999 999999 Nome do Produto XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX Estoque Atual
9.999,99 9.999,99
Compras dirias sinttico. Este relatrio ser solicitado e recebido pelo Departamento de Compras.
DATA: 99/99/9999 N PEDIDO 999999 999999 NOME FORNECEDOR XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX TOTAL COMPRADO
99.999.999,99
999.999.999,99
Vendas dirias por cliente sinttico. Este relatrio ser solicitado e recebido pelo Departamento de Vendas.
TOTAL VENDIDO
DATA: 99/99/9999 N NF 999999 999999 NOME CLIENTE XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX VENDEDOR XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX
99.999.999,99 99.999.999,99
Vendas por vendedor num determinado intervalo de data. Este relatrio ser solicitado e recebido pelo Departamento de Vendas.
PERODO: 99/99/9999 A 99/99/9999 VENDEDOR: XXXXXXXXXXXXXXXXXXXXXXXXXX DATA 99/99/9999 99/99/9999 99/99/9999 N NF 999999 999999 999999 NOME CLIENTE XXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXX TOTAL VENDIDO 9.999.999,99 9.999.999,99 9.999.999,99 VLR COMISSAO 999.999,99 999.999,99 999.999,99
135
UNIDADE V
PROJETO, TESTES E EVOLUO DE SOFTWARE

Professora Me. Mrcia Cristina Dadalto Pascutti Objetivos de Aprendizagem Expor a importncia do projeto de software, mostrando os artefatos que sero criados durante o projeto. Estudar os formatos de entradas e sadas de informaes atravs da interface do sistema. Entender o processo de validao de software, ou seja, quais os tipos de testes que devem ser realizados no sistema. Compreender a importncia da evoluo de software, para que o mesmo continue til aos seus usurios. Plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Projeto de Software Diagrama Geral do Sistema, Interfaces e Especificao de Casos de Uso Testes de Software Evoluo de Software
INTRODUO
Na quarta unidade estudamos sobre a modelagem do sistema e aprendemos sobre Diagrama de Casos de Uso e Diagrama de Classes. Agora, para a prxima etapa do processo de software, ou seja, a etapa do projeto de software, precisaremos desses dois diagramas e tambm do documento de requisitos, para definir uma srie de artefatos necessrios 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 ao da modelagem e preparando a cena para a construo (gerao de cdigo e validao) 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 mdulos e submdulos do sistema, assim como os itens que compem cada um deles. O principal objetivo do DGS mostrar como esses mdulos e seus itens esto relacionados. Cada item que aparece no diagrama deve aparecer como um caso de uso no Diagrama de Casos de Uso.
139
Depois que o DGS est definido, pode-se partir para a definio das interfaces com o usurio, tanto as de vdeo quanto as impressas. Para cada item que aparece no DGS, voc deve pensar em como o usurio 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 esto definidos no Diagrama de Classes. A interface do usurio um dos elementos mais importantes de um sistema, e quando essa interface mal projetada, a capacidade de o usurio aproveitar todo o potencial do sistema pode ser seriamente afetada, portanto, uma interface fraca pode fazer com que toda uma aplicao falhe (PRESSMAN, 2011, p. 313). Nesta unidade, na seo Formatos de Entradas/Sadas, so mostradas algumas diretrizes importantes que o ajudaro a definir uma interface humana que seja de mais fcil compreenso para o usurio. Depois que a interface foi definida e que o software foi implementado em alguma linguagem de programao, chegou a hora de executar a validao do software. A etapa de validao vai garantir que o software realmente executa as funcionalidades solicitadas pelos usurios. E, finalmente, depois que o software foi validado e colocado em funcionamento, vir a etapa de evoluo do software, pois, com certeza, os usurios tero requisitos que podero ser alterados, implicando em alteraes no software. Portanto, para que o software continue sendo til para o usurio necessrio que ele evolua, atendendo as necessidades desse usurio.
PROJETO DE SOFTWARE
De acordo com Sommerville (2007, p. 50), um projeto de software a descrio da estrutura de software a ser implementada, dos dados, das interfaces do sistema e, algumas vezes, dos
algoritmos utilizados (que, em nosso caso, ser realizada por meio da Especificao dos casos de Uso). Um projeto deve ser desenvolvido de forma iterativa, por meio de diferentes verses que devem ser mostradas ao usurio 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 Usurio (telas e relatrios) e iii) desenvolver um conjunto de especificaes de casos de uso, sendo que, essas especificaes devem conter detalhes suficientes para permitir a codificao. Geralmente, durante o projeto, o engenheiro de software ter que definir cada componente do sistema ao nvel de detalhamento que se fizer necessrio para a sua implementao em uma determinada linguagem de programao. Diagrama Geral do Sistema Tambm conhecido por Diagrama de Mdulos, apresenta os mdulos do sistema, as ligaes entre eles, os seus submdulos e/ou itens. O Diagrama Geral do Sistema deve ser condizente com o Diagrama de Caso de Uso, ou seja, as opes 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.
141
Exemplo 1 Diagrama Geral do Sistema para um sistema de Controle de Estoque
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 Condies de Pagamento, Cadastrar Fornecedores, Cadastrar Pedido
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 Relatrio de Clientes, Emitir Relatrio de Fornecedores, Emitir Relatrio de Vendedores, Emitir Lista de Preos de Produtos, Emitir Relatrio de Estoque Atual de Produtos, Emitir Relatrio de Produtos Mais Vendidos. Exemplo 2 Diagrama Geral do Sistema para um sistema de Controle de Biblioteca
Sistema Biblioteca
Cadastros
Movimentaes
Relatrios
Consultas
Categoria
Emprstimos
Leitores por Categoria
Leitor por Exemplar
Leitor
Comprovante Emprstimos
Emprstimos
Exemplares por Leitor
Assuntos
Devolues
Devolues
Editoras
Catlogo Livros
Autores
Geral
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
143
casos de uso: Cadastrar Categorias, Cadastrar Leitores, Cadastrar Assuntos, Cadastrar Editoras, Cadastrar Autores, Cadastrar Livros, Cadastrar Exemplares, Registrar Emprstimos, Emitir Comprovante de Emprstimos, Registrar Devolues, Emitir Relatrio de Leitores por Categoria, Emitir Relatrio de Emprstimos, Emitir Relatrio de Devolues, Emitir Catlogo Geral de Livros, Emitir Catlogo de Livros por Assunto, Emitir Relatrio de Livros em Atraso, Efetuar Consulta de Leitor por Exemplar, Efetuar Consulta de Exemplares por Leitor. Interfaces com o Usurio Sommerville (2007, p. 241) comenta que o projeto de interface com o usurio deve ser feito cautelosamente, pois uma parte fundamental de todo o processo de projeto de software. A interface com o usurio deve ser projetada para combinar as habilidades, experincias e expectativas dos usurios do sistema. A confiabilidade do sistema aumenta se um bom projeto de interface com o usurio for executado, se forem consideradas as capacidades dos usurios reais bem como o seu ambiente de trabalho. O engenheiro de software dever definir todas as interfaces de vdeo e as interfaces impressas do sistema que est sendo projetado. Interface de Vdeo Para cada funcionalidade do sistema (caso de uso), definir o layout da tela. O layout o desenho da tela e onde devem constar as informaes que o usurio dever fornecer ao sistema. Sugesto: criar uma padronizao para todas as telas do sistema, para facilitar a utilizao do mesmo pelo usurio. Seguem alguns exemplos de interfaces de vdeo. Tela de Cadastro de Pacientes: esta interface contm as informaes pessoais de um paciente. Note que as informaes encontram-se distribudas de maneira lgica e o espao foi otimizado para que em uma mesma tela vrias informaes pudessem ser colocadas.
Outro Exemplo de Tela de Cadastro de Pacientes: j nesta tela as informaes no esto distribudas de maneira lgica. Note que o nome do paciente somente solicitado depois da data de nascimento, RG e telefone.
Tela de Cadastro de Produtos: nesta tela, alm de cadastrar os dados do produto, tambm possvel cadastrar os fornecedores que fornecem o produto.
145
Este boto um BOTO DE ATALHO, que chamar o cadastro de marcas, caso a marca de determinado produto no esteja cadastrada. Desta forma, o usurio no ter que sair do cadastro de produto, chamar o cadastro de marcas e depois chamar novamente a tela de cadastro de produtos. Tela de Cadastro de Filmes: nesta tela o usurio poder informar os dados do filme, com seu gnero e categoria e todos os atores que fazem parte do elenco do filme. Note que os atores esto em uma grade, em que possvel cadastrar vrios atores.
Tela de Venda: nesta tela possvel lanar vrios produtos em uma mesma venda, pois medida que o lanamento do produto efetuado e o usurio 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.
147
Tela de Pedido de Exame: nesta tela possvel lanar vrios exames em um mesmo pedido de exame. Nesta mesma tela possvel, no caso do pedido de exame ser pago em parcelas, lanar o valor de cada parcela, o nmero do cheque deixado pelo paciente e a data de vencimento de cada parcela.
Tela de Compras: nesta tela sero lanados os dados da compra, ou seja, a data da compra, o fornecedor, a condio de pagamento e os vrios produtos que esto sendo comprados. Nesta tela tambm aparecem os botes de atalho. Note que o desenho do boto o mesmo, assim o sistema fica padronizado e o usurio, quando se depara com esse boto em qualquer lugar do sistema, saber que ao clic-lo o sistema o levar para o cadastro referente ao dado em que o boto estava se referindo.
Outro exemplo de Tela de Compras: nesta tela, alm de lanar os produtos comprados, possvel j efetuar o lanamento do Contas a Pagar, ou seja, como na Nota Fiscal de Compra, normalmente j vem as informaes da data de vencimento e do valor de cada parcela, quando uma compra parcelada, o usurio j pode efetuar o lanamento dessas informaes no momento em que est cadastrando as compras.
149
Tela de Filtro do Relatrio de Consultas Mdicas Efetuadas por Dia: a tela de filtro de relatrio tem por objetivo oferecer ao usurio mecanismos para a seleo dos dados que ele deseja imprimir no relatrio, pois, caso contrrio, seriam impressos todos os dados cadastrados na base de dados referentes quele relatrio. Na tela abaixo o usurio ir informar uma data e o relatrio emitir somente as consultas efetuadas na data informada.
Tela de Filtro do Relatrio de Pagamento de Consultas por Perodo: note que neste filtro de relatrio o usurio poder informar um intervalo de datas, dessa forma ele poder emitir o relatrio de um nico dia, de uma semana, de um ms, ou seja, do perodo que ele desejar. Este tipo de filtro torna o relatrio mais flexvel. No exemplo abaixo sero emitidos os pagamentos das consultas efetuadas a partir da data inicial at a data final informadas na tela de filtro.
Tela de Filtro do Relatrio de Pedido de Exame: na tela abaixo so oferecidos dois filtros: primeiro o usurio dever escolher se ele quer selecionar o nome do paciente ou o seu cdigo. Depois ele poder escolher de qual data ele quer emitir o pedido de exame. As opes que devero aparecer na tela de filtro dos relatrios devero ser discutidas com o usurio, pois o objetivo facilitar o andamento do seu trabalho quando o mesmo estiver utilizando o sistema.
151
Tela de Filtro do Relatrio de Contas a Pagar por Fornecedor: no exemplo abaixo o usurio poder escolher, alm do perodo, tambm o fornecedor que ele deseja emitir o relatrio de contas a pagar.
B) Interface Impressa Para cada relatrio do sistema (definidos no Diagrama de Caso de Uso), necessrio definir o seu layout. Sugesto: criar uma padronizao para todos os relatrios do sistema, para facilitar a utilizao dos mesmos pelo usurio. Seguem alguns exemplos de interfaces impressas. Note nos exemplos que eles possuem no cabealho o nome da empresa, o nmero da pgina do relatrio, a data (e em alguns o horrio) da emisso do relatrio, o ttulo do relatrio e, em alguns, o valor dos parmetros informados na tela de filtro do relatrio para que o usurio possa saber depois do relatrio impresso, quais foram os dados informados no filtro para a emisso do mesmo. Relatrio de Clientes por Cidade
NOME DA EMPRESA DATA: 99/99/9999 CDIGO 9999 9999 9999 9999 NOME XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX Relatrio de Clientes ENDERECO XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX CEP XXXXXXX XXXXXXX XXXXXXX XXXXXXX PAG.: 99 TELEFONE XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX
CIDADE: 9999 XXXXXXXXXXXXXXXXXXX
Relatrio de Consultas Efetuadas por Dia

NOME DA EMPRESA Relatrio de Consultas Efetuadas em 99/99/9999 PACIENTE XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXX MDICO XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX DATA:99/99/9999 PAG.: 99 CONVNIO XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX
Relatrio de Pagamento de Consultas por Perodo
NOME DA EMPRESA 99/99/9999 99:99 Relatrio de Pagamentos de Consultas de 99/99/9999 a 99/99/9999 PAG.: 99 VALOR DATA PAGAMENTO PACIENTE MDICO 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 99/99/9999 XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX 999.999,99 VALOR TOTAL 99.999.999,99 Especificao de Casos de Uso A especificao de casos de uso descreve, por meio de uma linguagem bastante simples, as restries que devero ser consideradas no momento da implementao do caso de uso. Essas especificaes devem conter detalhes suficientes para permitir a codificao em uma linguagem de programao qualquer. Seguem alguns exemplos de especificaes de casos de uso. Especificao de Caso de Uso Cadastrar Paciente Os dados digitados pelo usurio devero estar em caixa alta. O cdigo do paciente dever ser gerado automaticamente pelo sistema, mas o usu-
153
rio poder alterar. Nesse caso, no pode ser menor ou igual a zero. O nome do paciente no pode ser branco. Se CPF for digitado, aceitar somente CPF vlido. No permitir a excluso de um paciente que tenha pelo menos um horrio cadastrado na agenda. Especificao de Caso de Uso Cadastrar Agenda Os dados digitados pelo usurio devero estar em caixa alta. O cdigo do paciente no pode ser menor ou igual a zero. No permitir que seja marcada mais de uma consulta para o mesmo mdico na mesma data e no mesmo horrio. Quando for includo um novo horrio, 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 no pode ser menor que a data atual. Especificao de Caso de Uso Emitir Relatrio de Pagamentos de Consultas por Perodo Selecionar somente as instncias da classe AGENDAS que tenham o atributo DATA maior ou igual data inicial informada na tela de filtro do relatrio e menor ou igual data final e CONS_REALIZADA igual a S e VLR_CONSULTA diferente de zero. No permitir data final menor que data inicial. Validar datas. Caso no exista nenhuma instncia selecionada, mostrar mensagem de alerta NO H PAGAMENTO DE CONSULTAS NO PERODO INFORMADO e no mostrar relatrio em branco.
FORMATOS DE ENTRADAS/SADAS
Um dos problemas comuns de entrada/sada inclui a organizao fsica de elementos de dados de entrada em uma tela de vdeo, a natureza das mensagens de erro quando se comete em erro de entrada e a organizao fsica de elementos de dados de sada nas telas e em relatrios. Com o imenso conjunto atual de linguagens de quarta gerao e ferramentas de prototipao, interessante dar ao usurio diversas variaes de telas de entrada, imagens de sada e coisas desse tipo. Uma vez obtido o consentimento do usurio, deve ser vinculada uma cpia das imagens de tela e formatos de relatrios documentao do sistema. claro que em muitos casos o usurio no ter grandes sugestes para fazer porque no tem experincia anterior em trabalhar com um sistema informatizado. No caso dos sistemas de informaes computadorizadas, as seguintes diretrizes ajudaro a desenvolver uma interface humana amistosa ao usurio na maioria dos casos. 1. Seu sistema deve requisitar entradas e produzir sadas em uma forma consistente. Isso particularmente verdadeiro nos sistemas on-line em que o usurio pode introduzir uma entre diversas transaes diferentes e/ou receber uma de diversas imagens diferentes. Por exemplo, se o sistema solicitar a data ao usurio sempre que uma transao for introduzida, seria desastroso se um tipo de transao exigisse a data na forma 12/23/87, enquanto outra transao exigisse a data na forma 87/12/23. E tambm seria desastroso se uma parte do sistema exigisse que o usurio especificasse o estado como um cdigo 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 anloga, se uma parte do sistema exigir que o usurio fornea um cdigo de rea quando introduzir um nmero de telefone, todas as partes do sistema devem exigir um cdigo de rea quando for introduzido um nmero de telefone. 2. Pea informaes em uma sequncia lgica. Em muitos casos, isso depende da natureza da aplicao e exigir minuciosos entendimentos com o usurio. Por exemplo, se estiver sendo desenvolvido um sistema de controle de pedidos onde o usurio especifique o nome do cliente,
155
ser necessrio especificar a sequncia na qual os componentes de nome de cliente seriam introduzidos. Uma sequncia lgica seria solicitar ao usurio que introduzisse a informao na seguinte sequncia: ttulo (Sr./Sra. etc.) primeiro nome inicial do nome intermedirio ltimo nome Porm, o usurio pode achar isso muito desajeitado; suponha que o usurio tenha obtido o nome do cliente de alguma fonte externa como um catlogo de telefones. Nesse caso, seria muito mais prtico que o usurio introduzisse. ltimo nome inicial do nome intermedirio ttulo 3. Evidencie ao usurio o tipo de erro que cometeu e onde est. Em muitos sistemas, o usurio fornece uma quantidade substancial de informaes ao sistema para cada evento ou transao. Em um sistema de controle de pedidos, por exemplo, o usurio pode especificar o nome do cliente, endereo e nmero de telefone, bem como informaes sobre itens que esto sendo pedidos, desconto aplicvel, instrues de embarque e impostos de vendas. Todas essas informaes 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 usurio compreenda a espcie de erro que foi cometido e onde o erro est localizado; no aceitvel 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 nvel de sofisticao do usurio, pode ser tambm importante exibir uma
mensagem explicativa. 4. Oferea ao usurio um modo de (a) cancelar parte de uma transao e (b) cancelar toda uma transao. ingnuo pressupor que o usurio sempre terminar a introduo de uma transao inteira sem ter interrompido. O usurio pode ter introduzido um nome e endereo de cliente antes de descobrir que estava trabalhando com o cliente errado; ele desejar ser capaz de anular o que foi digitado e comear de novo. Ou o usurio pode haver terminado a introduo da maior parte das informaes do cliente e, ento, perceber que escreveu mal o primeiro nome do cliente; ele vai querer poder retornar quele elemento de dados e corrigi-lo sem perder todas as outras informaes j digitadas. 5. Providencie um mecanismo prtico de socorro. Nos sistemas on-line cada vez mais importante oferecer ao usurio um mecanismo prtico para a obteno de informaes sobre como usar o sistema. Em alguns casos, a facilidade do socorro simplesmente fornecer uma explicao se o usurio cometer um erro; em outros casos, o socorro poderia ser usado para explicar os detalhes de vrios comandos ou transaes disponveis ao usurio. Existem muitos meios de implementar essa facilidade, e o analista e os usurios devem examinar diversos exemplos tpicos antes de tomar uma deciso. 6. Se o seu sistema estiver empenhado em um processamento muito prolongado, exiba uma mensagem para que o usurio no pense que o sistema travou. Se o seu sistema tiver de executar clculos extensos ou se ele provavelmente apresentar demoras peridicas por causa de entradas volumosas, importante exibir uma adequada mensagem para o usurio; caso contrrio possvel 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 mnimo, emitir uma mensagem (por exemplo, SISTEMA OPERANDO - POR FAVOR, ESPERE) em intervalos regulares. Melhor ainda seria uma srie de mensagens informando o usurio quanto do trabalho j foi executado e aproximadamente quanto tempo falta para complet-lo, como acontece na maioria dos processos de instalao de aplicativos, como, por exemplo, Microsoft Word, Visio, Visual Studio.
157
7. Fornea defaults para entradas padronizadas. Em muitos casos, o sistema pode fazer uma boa suposio sobre o provvel valor de uma entrada fornecida pelo usurio; tornando-o um default, poder ser economizado um considervel tempo do usurio. Essa abordagem vlida para todos os tipos de sistemas. Um exemplo de valor default a data: em muitas aplicaes a data mais provvel que o usurio introduzir a data atual. Ou, suponha que voc esteja construindo um sistema de controle de pedidos, e o usurio diz que 95% dos clientes vivem nas redondezas; em seguida, quando for solicitado que o usurio informe o nmero do telefone do cliente, o sistema deve presumir que o cdigo de rea default o seu cdigo de rea local. 8. Beneficie-se das cores e do som, mas no exagere. Os efeitos de cores e som podem ser bastante teis para a enfatizao de tipos diferentes de entrada ou atrair a ateno do usurio 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 usurio, e vermelho para todas as mensagens de erro. Entretanto, o analista no deve exagerar: a maioria dos usurios poder no gostar se as telas ficarem parecendo rvores de Natal. Isso tambm vale para efeitos sonoros; uma ocasional campainha ou bip til, mas o usurio no deseja que o terminal produza todos os efeitos sonoros do filme Guerra nas Estrelas.
VALIDAO DE SOFTWARE
A validao de software tem como objetivo mostrar que um sistema est de acordo com as especificaes descritas no documento de requisitos e que ele atende s expectativas do cliente comprador do sistema. Esse processo envolve a verificao em cada estgio do processo de software, desde a definio dos requisitos dos usurios at o desenvolvimento de cada um dos programas que compem o sistema. Porm, a maior parte dos custos de validao observada depois da implementao, 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 prpria implementao. Por outro lado, caso um erro seja descoberto durante o desenvolvimento, o custo para sua correo ser muito menor do que se esse mesmo erro tivesse sido descoberto somente na fase de manuteno. 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 especificao, projeto e implementao. O que voc precisa saber sobre testes como analista de sistemas? Em muitos casos, o analista de sistemas trabalha em estreita associao com o usurio para desenvolver um conjunto completo e abrangente de casos de testes. Esse processo de desenvolvimento de casos de testes de aceitao pode ser executado em paralelo com as atividades de implementao de projeto e programao, de modo que, quando os programadores tiverem terminado seus programas e executado seus prprios testes locais, a equipe usurio/analista estar pronta para seus prprios casos de testes (YOURDON, 1990, p.539).
TIPOS DE TESTES
Para Yourdon (1990, p. 540), existem diferentes estratgias de testes, porm as duas mais conhecidas so os testes bottom-up e os top-down. A abordagem bottom-up comea por
159
testar os mdulos pequenos de forma individual; essa modalidade muitas vezes chamada de teste de unidade, teste de mdulo ou teste de programa. Em seguida, os mdulos individuais so agrupados com outros mdulos para serem testados em conjunto; isso costuma ser chamado de teste de subsistemas. Finalmente, todos os mdulos do sistema so combinados para um teste final, que conhecido como teste do sistema, e muitas vezes seguido pelo teste de aceitao, quando o usurio 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 estratgia de testes presume que os mdulos de execuo de alto nvel do sistema foram desenvolvidos, mas que os mdulos de baixo nvel existem apenas como simulaes, somente como prottipos. Como a maioria das funes detalhadas do sistema no foi desenvolvida, os testes iniciais se tornam limitados, sendo possvel 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. Alm desses conceitos bsicos, voc deve conhecer os seguintes tipos de testes: Testes funcionais. Neste tipo de teste o objetivo verificar se o sistema executa corretamente suas funes para os quais ele foi projetado. Portanto, os casos de testes sero desenvolvidos e lanados no sistema; as sadas (e os resultados da atualizao da base de dados) sero examinadas para testar sua correo (YOURDON, 1990, p. 540). Testes de desempenho. O objetivo deste tipo de teste verificar se o sistema pode manipular o volume de dados e transaes recebidas, bem como verificar se ele apresenta o tempo de resposta necessrio (YOURDON, 1990, p. 541). Isso pode exigir que a equipe de desenvolvimento execute uma srie de testes em que a carga do sistema aumentada at que o seu desempenho se torne inaceitvel (SOMMERVILLE, 2011, p. 153). Testes de Unidade. Tm por objetivo verificar um elemento que possa ser logicamente
tratado como uma unidade de implementao, por exemplo, uma sub-rotina ou um mdulo. Testes de Aceitao. Tm por objetivo validar o produto, ou seja, verificar se esse atende aos requisitos especificados. Eles so executados em ambiente o mais semelhante possvel ao ambiente real de execuo. Se os casos de teste forem desenvolvidos no final da etapa de projeto, com utilizao do diagrama de casos de uso, diagrama de classes e da especificao de casos de uso, no h meio de se saber como o programa funcionar quando o desenvolvedor escrever o cdigo fonte e, desse modo, pode-se, ento, 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 no verificam como ocorre o processamento, mas apenas os resultados produzidos. Pressman (2011, p. 439) coloca que o teste de caixa preta pode encontrar funes 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 inicializao e trmino. Quando a lgica e a estrutura interna do programa so conhecidas, isto , depois de o programador ter escrito o programa, pode-se fundamentar os casos de testes na lgica 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 mdulo foram exercidos pelo menos uma vez, exercitar todas as decises lgicas 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 transferncia do desenvolvedor para o seu cliente, ou seja, toda vez que um cliente usa o sistema, um teste est sendo realizado.
161
EVOLUO DE SOFTWARE
Aps a implantao de um sistema inevitvel que ocorram mudanas, sejam elas para pequenos ajustes ps-implantao, para melhorias substanciais, por fora da legislao, para atender novos requisitos dos usurios e finalmente, por estar gerando erros. De acordo com Sommerville (2011, p. 164), cerca de dois teros de custos de software esto relacionados evoluo do software, requerendo grande parte do oramento de Tecnologia da Informao para todas as empresas. Manuteno de Software O desafio da manuteno comea to logo o software colocado em funcionamento. Normalmente, depois que os usurios comeam a utilizar o software, eles percebem que outras funcionalidades (ainda inexistentes) podem ser acrescentadas ao mesmo, ou seja, acabam aparecendo requisitos que o usurio no 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 so consideradas como manuteno. Ou ento a manuteno se d para correo de erros no sistema, pois descobrir todos os erros enquanto o software est na etapa de validao bastante complexo, pois todos os caminhos possveis dentro dos programas teriam que ser testados e nem sempre isso possvel. O fato que a manuteno sempre vai existir e vai consumir bastante tempo da equipe de desenvolvimento. Pressman (2011, p. 663) coloca que de fato, no raro uma organizao de software despender de 60% a 70% de todos os recursos com manuteno de software. Uma das razes para o problema da manuteno de software a troca das pessoas que compem as equipes de desenvolvimento, podendo acontecer que a equipe que desenvolveu o software inicialmente, j no se encontra mais por perto. Ou ainda, que ningum que esteja
trabalhando atualmente na empresa, tenha participado da concepo 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 alterao se tornar mais fcil e pode-se dizer que o sistema apresenta alta manutenibilidade. De acordo com Pressman (2011, p. 664), um software manutenvel (de fcil manuteno) apresenta uma modularidade eficaz, utiliza padres de projeto que permitem entend-lo com facilidade, foi construdo utilizando padres e convenes de codificao bem definidos. Dessa forma, tanto o projeto quanto a implementao do software ajudaro a pessoa ou equipe que precisar realizar a alterao.
<http://www.youtube.com/watch?v=G6yk7fLK3JY&feature=relmfu>. Vdeo que mostra a importncia dos testes e da manuteno de um software.
CONSIDERAES FINAIS
Nesta ltima unidade, pudemos fechar todas as etapas do processo de software, ou seja, j tnhamos estudado a importncia 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, validao e evoluo de software. A etapa de projeto de software se caracteriza por ser a definio fsica do sistema, ou seja, onde podemos definir as interfaces do nosso sistema. No entrei em muitos detalhes de como elaborar essa interface, pois este no o nosso principal objetivo, mas se voc tiver interesse pode estudar mais sobre o assunto Interao Humano-Computador (IHC) que uma matria interdisciplinar que relaciona a cincia da computao, artes, design, ergonomia, semitica e outras reas afins (veja s como esse assunto abrangente!). Na etapa de projeto tambm importante especificar cada caso de uso definido no diagrama de casos de uso. Voc deve ter
163
notado que essa especificao vai ajudar, e muito, o programador a escrever o cdigo fonte de cada programa, pois esta especificao deve conter detalhes sobre as restries 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 programao escolhida. Tambm no falamos nada sobre esse assunto, pois com certeza, voc aprender (ou j aprendeu) as tcnicas de programao em outras disciplinas do seu curso, e saber que essa etapa bastante trabalhosa e deve ser muito bem realizada para que todo o esforo despendido at aqui no seja em vo. Depois que o software foi implementado, hora da sua validao, 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 esto desenvolvendo, mas isto s no basta. necessrio desenvolver vrios tipos de testes, como mostramos nesta unidade, para assegurar que o sistema funcionar corretamente. A real validao do software, normalmente, feita quando o mesmo est em uso, pois muito difcil testar todas as possibilidades de um sistema inteiro. Aps a implantao e efetiva utilizao do sistema pelo usurio, qualquer alterao que seja necessria ser considerada como uma evoluo do software. Essa evoluo necessria para que o software continue sendo til ao usurio, para que ele continue atendendo as suas necessidades. Se um software tiver uma vida longa, passar por manutenes durante esse perodo e, para que o mesmo continue manutenvel, vimos que necessrio manter a aplicao das tcnicas de engenharia de software, pois nem sempre quem desenvolve quem vai dar manuteno no software. Com isso, chegamos ao final das atividades bsicas 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).
1. Baseando-se no Documento de Requisitos Laboratrio de Anlises Clnicas, mostrado na unidade IV estudo de caso 2: a. Elabore o Diagrama Geral do Sistema.
b. Elabore as Interfaces de Vdeo dos seguintes casos de uso: Cadastrar exames, cadastrar mdicos e cadastrar resultados de exame. c. Elabore as telas de filtros dos relatrios de Ficha de Paciente e Relatrio de Exame. d. Elabore o layout dos relatrios de Ficha de Paciente e Exame. 2. Explique quatro diretrizes que devem ser levadas em considerao no desenvolvimento da interface do sistema. 3. Para que um sistema funcione corretamente necessrio que sejam efetuados vrios testes. Explique como o analista deve conduzir esta etapa de testes, para que, no final, o sistema possa ser considerado apto a ser implantado.
165
CONCLUSO
Neste livro procurei mostrar a voc a importncia 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 I, foram estudados os conceitos de software e de engenharia de software. Mostrei tambm que podemos ter vrias aplicaes para o software, desde o software embutido que pode estar na sua mquina de lavar roupas at o software que controla um foguete espacial. Porm, neste material procurei utilizar exemplos que fazem parte do nosso dia a dia, pensando em facilitar o entendimento para problema e da sua possvel soluo. Ainda na unidade I tratamos sobre ferramentas CASE, que so softwares que auxiliam o trabalho do desenvolvedor, automatizando tarefas que so realizadas durante o processo de software. Outro assunto que estudamos nesta unidade foram alguns conceitos de orientao a objetos e uma rpida introduo linguagem de modelagem UML. Na unidade II, trabalhamos especificamente com processos de software. Mostrei que podem existir diversos modelos de processos de software, mas que algumas atividades bsicas esto presentes em todos eles (s vezes com nomes diferentes, mas esto presentes). Voc est lembrado de quais so essas atividades? As atividades so: especificao de software, projeto e implementao de software, validao de software e, por ltimo, evoluo de software. A unidade III foi dedicada exclusivamente a explicar o que so requisitos de software. Mostrei qual a diferena entre os requisitos funcionais e no funcionais e a importncia 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 tambm um exemplo de diagrama, partindo do documento de requisitos, explicando passo a passo a elaborao de cada um deles. E para finalizar, vimos na unidade V, as etapas de projeto, validao e evoluo de software, permitindo que voc pudesse entender todas as etapas envolvidas nos modelos de processos de software. Espero ter alcanado o objetivo inicial, que era mostrar a importncia da Engenharia de Software.
Desejo que voc seja muito feliz profissionalmente utilizando os conceitos apresentados aqui e se puder ajudar de alguma forma, estou a sua disposio. Desejo muito sucesso e paz. Prof. Mrcia.
167
REFERNCIAS
BOOCH, Grady. UML: guia do usurio. 2. ed. So Paulo: Campus, 2005. GUEDES, Gilleanes T. A. UML 2: guia prtico. So Paulo: Novatec Editora, 2007. LIMA, Adilson da Silva. UML 2.0: do requisito soluo. So Paulo: rica, 2009. MELO, Ana Cristina. Desenvolvendo Aplicaes com UML 2.0: do conceitual implementao. 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 . Florianpolis: Visual Books, 2007. SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison-Wesley, 2007. SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Prentice Hall, 2011. YOURDON, Edward. Anlise Estruturada Moderna. Rio de Janeiro: Elsevier, 1990.

Eng Software

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Eng Software

Transféré par

Droits d'auteur :

Formats disponibles

ISBN 978-85-8084-508-2

Professora Me. Mrcia Cristina Dadalto Pascutti

gradUao AnaLise e desenVoLViMento de sisteMas e sisteMas Para a internet

NEAD - Ncleo de Educao a Distncia

Ficha catalogrfica elaborada pela Biblioteca Central - UniCesumar

CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

INTRODUO ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

TIPOS DE APLICAES DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

FERRAMENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING)

ENGENHARIA DE SOFTWARE | Educao a Distncia

CONCEITOS BSICOS DE ORIENTAO A OBJETOS

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

Exemplo de Classe com Atributos

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

UML UNIFIED MODELING LANGUAGE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

MODELOS DE PROCESSO DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

Fonte: Sommerville (2011, p.22)

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

Modelos de Processos de Engenharia de Software <http://xps-project.googlecode.com/svn-history/r43/trunk/outros/02_Artigo.pdf>.

ENGENHARIA DE SOFTWARE | Educao a Distncia

ATIVIDADES BSICAS DO PROCESSO DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

PROJETO E IMPLEMENTAO DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia