eng.software

Professora Me. Mrcia Cristina Dadalto Pascutti

ENGENHARIA DE SOFTWARE

GRADuAO

ANAlISE E DESENvOlvImENTO DE SISTEmAS E SISTEmAS pARA A INTERNET

mARING-pR

2012

ISBN 978-85-8084-508-2

Reitor: Wilson de Matos Silvavice-Reitor: Wilson de Matos Silva Filhopr-Reitor de Administrao: Wilson de Matos Silva Filhopr-Reitor de EAD: Willian Victor Kendrick de Matos Silvapresidente da mantenedora: Cludio Ferdinandi

NEAD - Ncleo de Educao a Distncia

Diretor Comercial, de Expanso e Novos Negcios: Marcos GoisDiretor de Operaes: Chrystiano MincoffCoordenao de Sistemas: Fabrcio Ricardo LazilhaCoordenao de polos: Reginaldo CarneiroCoordenao de ps-Graduao, Extenso e produo de materiais: Renato DutraCoordenao de Graduao: Ktia CoelhoCoordenao Administrativa/Servios Compartilhados: Evandro BolsoniCoordenao de Curso: Danillo Xavier SaesGerente de Inteligncia de mercado/Digital: Bruno JorgeGerente de marketing: Harrisson BraitSupervisora do Ncleo de produo de materiais: Nalva Aparecida da Rosa MouraCapa e Editorao: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, Jos Jhonny Coelho, Luiz Fernando Rokubuiti e Thayla Daiany Guimares CripaldiSuperviso 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 ISBN 978-85-8084-508-2 CIP - NBR 12899 - AACR/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.brNEAD - Ncleo de Educao a Distncia - bl. 4 sl. 1 e 2 - (44) 3027-6363 - [email protected] - www.ead.cesumar.br


Professora Me. Mrcia Cristina Dadalto Pascutti

5ENGENHARIA DE SOFTWARE | Educao a Distncia

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 do-cente; aquisio de competncias institucionais para o desenvolvimento de linhas de pesqui-sa; 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 SilvaReitor

6 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 SOFTWAREProfessora Me. Mrcia Cristina Dadalto Pascutti

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.

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 SOFTWAREProfessora Me. Mrcia Cristina Dadalto Pascutti

Objetivos de Aprendizagem

Entenderoqueengenhariadesoftwareequalasuaimportncia.

Estudarosconceitosbsicosdeorientaoaobjetosnecessriosparaoentendi-mento da UML.

AbordaraimportnciadautilizaodaUMLparaamodelagemdesistemas.

plano de Estudo

A seguir, apresentam-se os tpicos que voc estudar nesta unidade:

ConceitosbsicossobreSoftwareeEngenhariadeSoftware

TiposdeAplicaesdeSoftware

FerramentasCASE

ConceitosBsicosdeOrientaoaObjetos

IntroduoUML


INTRODuO

Fonte

:SHU

TTER

STOC

K.co

m

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,noerasuficiente.

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).


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


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 fabri-cado 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 concen-tram-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 dife-rente, 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 hardwa-re, 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


dos softwares continua a ser construda de forma personalizada (sob encomenda).

A reutilizao de componentes de hardware parte natural do seu processo de engenha-ria, 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 compo-nentes 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 con-fiveis 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 fos-sem 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.


AlgunsFundamentosdaEngenhariadeSoftware

Por Wilson de Pdua Paula FilhoOqueEngenhariadeSoftware?

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: . 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),:

Softwaredesistema so aqueles programas desenvolvidos para atender a ou-tros programas, como por exemplo, editores de texto, compiladores e sistemas ope-racionais.

Softwaredeaplicao so programas desenvolvidos para solucionar uma neces-


sidade especfica de negcio, processando dados comerciais ou tcnicos de forma que ajude nas operaes comerciais ou tomadas de deciso pelos administradores da empresa.

Softwarecientfico/deengenharia so aplicaes que vo da astronomia vul-canologia, 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.

Softwarede intelignciaartificial utiliza algoritmos no numricos para solu-cionar 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.MarvinMinsky,cofundadordolaboratriodeintelignciaartificialdoInstitutodeTecnologiadeMas-sachusetts.

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 in-formaes 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.


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 lingua-gem 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 caracters-ticas 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 Ferramen-ta tambm acompanham todo o ciclo de desenvolvimento, entretanto, possuem a propriedade de conjugar sua capacidade a outras ferramentas externas comple-mentares, que variam de acordo com as necessidades do 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 m-quina. So mais usadas para desenvolvimento corporativo, apresentando controle de acesso, verso, repositrios de dados entre outras caractersticas.


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 fun-cionalidade 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 ativi-dades como especificaes, modelagem e implementao.

CONCEITOSBSICOSDEORIENTAOAOBJETOS

Fonte

:SHU

TTER

STOC

K.co

m

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.


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.


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


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.


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 subclas-ses (conceito apresentado a seguir) podem acess-lo.

O smbolo de menos (-) indica que a visibilidade privada, ou seja, somente os obje-tos 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


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


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, diferenciando-se 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.


ExemplodePolimorfismo

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


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).

.Vdeo que mostra uma introduo aos conceitos de orientao a objetos.

uml UNIFIED MODELING LANGUAGE

Fonte:


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).


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


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 . 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.

FERRAMENTASCASEBASEADASNALINGUAGEMUML

Nesta unidade,jvimosqueumaferramentasCASE(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


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 .

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 , 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: .

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 .

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


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.


ATIvIDADE DE AuTOESTuDO1. Uma classe um conjunto de objetos que compartilham os mesmos atributos, mto-

dos 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.

uNIDADE II

pROCESSOS DE SOFTWAREProfessora Me. Mrcia Cristina Dadalto Pascutti

Objetivos de Aprendizagem

Compreender os conceitos de processode software emodelos deprocessodesoftware.

Mostrarasatividadesbsicasdoprocessodesoftware.

Mostrartrsmodelosdeprocessodesoftware.

plano de Estudo

A seguir, apresentam-se os tpicos que voc estudar nesta unidade:

ProcessosdeSoftware

ModelosdeProcessodeSoftware

AtividadesBsicasdoProcessodeSoftware


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.

Fonte

:SHU

TTER

STOC

K.co

m

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


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.Especificaodesoftware. necessrio que o cliente defina as funcionalidades do software que ser desenvolvido, bem como defina todas as suas restries operacionais.

2.Projetoeimplementaodesoftware. O software deve ser confeccionado seguindo as especificaes definidas anteriormente.

3.Validaodesoftware. 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.Evoluodesoftware. As funcionalidades definidas pelo cliente durante o desen-volvimento do software podem mudar e o software precisa evoluir para atender a essas mudanas.


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.

OprocessodedesenvolvimentodesoftwareeautilizaodeferramentasCASE

Por Maria Clara dos Santos Pinto SilveiraA presente dissertao situa-se na rea das ferramentas CASE. apresentado um estudo dos concei-tos 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 desen-volvimento de software. Registra ainda as caractersticas, vantagens e desvantagens das ferramentas


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 organiza-o, 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: . 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.


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, desen-volvimento, validao e evoluo, que so fundamentais ao processo, e as representa como fases separadas, como a especificao de requisitos, o projeto de software, a im-plementao, os testes e assim por diante (SOMMERVILLE, 2011).

2. Desenvolvimento Incremental. Esse modelo intercala as atividades de especifica-o, 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.EngenhariadeSoftwareOrientadaaReuso. Esse modelo parte do princpio de que existem muitos componentes que podem ser reutilizveis. O processo de desenvolvimen-to 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

Fonte

:SHU

TTER

STOC

K.co

m


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.Anliseedefinioderequisitos As funes, as restries e os objetivos do sis-tema so estabelecidos por meio da consulta aos usurios do sistema. Em seguida, so definidos em detalhes e servem como uma especificao do sistema.

2.Projetodesistemasedesoftware 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.Implementaoetestedeunidades 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.Integraoetestedesistemas 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.Operaoemanuteno Normalmente (embora no necessariamente), esta a fase mais longa do ciclo de vida. O sistema instalado e colocado em operao. A ma-nuteno 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


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 pro-posto 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 ne-cessidades 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.

.VdeodedemonstraodomodelodedesenvolvimentocascatasimuladopelojogoSERPG.

Desenvolvimento incremental

O desenvolvimento incremental, segundo Sommerville (2011, p. 21) tem como base a ideia


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.

Especificao

Desenvolvimento

Validao

Descrio do esboo

Verso inicial

Verses intermedirias

Verso final

Atividades concorrentes

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


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 regu-lar, para que possam medir o progresso. Se os sistemas so desenvolvidos rapidamente, no vivel produzir documentos que reflitam cada verso do sistema.

2.Ossistemasfrequentementesomalestruturadosa mudana constante tende a corromper a estrutura do software. Incorporar modificaes no software torna-se cada vez mais difcil e oneroso.

3.Podemserexigidas ferramentase tcnicasespeciais 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.

Engenhariadesoftwareorientadaareuso

Na maioria dos projetos de software, ocorre algum reuso de software, pois, normalmente,


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.


Conforme Sommerville (2011, p.23), essas etapas so:

1.Anlisedecomponentes 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.Modificaoderequisitosnodecorrerdessaetapa,osrequisitossoanalisados,levando-se em considerao as informaes sobre os componentes que foram encontra-dos 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 pro-curar outras solues.

3.Projetodosistemacomreuso durante essa etapa, o framework do sistema proje-tado ou ento alguma infraestrutura existente reutilizada. Os projetistas levam em con-siderao 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.Desenvolvimentoeintegrao nessa etapa, o software que no puder ser compra-do 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.


PGDS - Processo de gerenciamento e desenvolvimento de sistemas DATASUSEm busca de direcionamento e padronizao dos seus processos e da melhoria contnua da quali-dade 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 re-alizados. Em 2010, com a implantao da Unidade de Apoio a Programas e Projetos (UAPP), o PDS eaEGPforamunificadosemumametodologia,agoradenominadaProcessodeGerenciamentoeDesenvolvimento de Sistemas - PGDS.Ela foi criada para auxiliar o DATASUS na elaborao, planejamento, execuo, controle, monitora-mento e encerramento de seus projetos, por meio das melhores prticas de gerenciamento dispon-veis no mercado e as j adotadas pelo DATASUS.

Fases do PGDSO 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)-Umpapeldefineocomportamentoeresponsabilidadesdeumprofissionalougrupode profissionais que participamdo desenvolvimento do projeto.O comportamento representadoatravs 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 ati-vidades 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.


Artefatos(oqu) - Em sentido amplo, o termo artefato representa um produto concreto produzido, modificadoouutilizadopelasatividadesdeumprocesso.OPGDSnoinclui todososartefatosdeum 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 profissional,quedesempenhaopapel responsvelporaquelaatividade,deveexecutarparageraralgumresultado.Asatividadesenvolvemaproduoemodificaodeartefatosdoprojeto.

Fases (quando) - As fases do PGDS apresentam a seqncia e a dependncia entre as atividades do projetoaolongodotempo.Asatividadesnofluxosodivididasemfasesdociclodevidadoprojetoenos papis responsveis pela execuo de cada uma.Disponvel em: . 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 . Ou ento acesse o endereo para ler mais sobre o DATASUS como um todo. uma leitura bastante esclarecedora.

Disponvel em: . Acesso em 05 jun. 2012.

ModelosdeProcessosdeEngenhariadeSoftware

.


ATIVIDADESBSICASDOPROCESSODESOFTWARE

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.

Fonte

:SHU

TTER

STOC

K.co

m


ESTuDO DO CIClO DE vIDA DO SOFTWARE Em umA EmpRESA DE DESENvOlvImENTO DE SISTEmASPor Fabrcio Luis Marinheiro Loureno e Mrcio Alan Benine Um estudo do ciclo de vida do software desenvolvido em uma empresa de desenvolvimento de siste-mas importante, pois construir um software com qualidade demanda a 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-seesseprocedimento,realizou-seumestudoutilizando-seumapesquisabibliogrfica,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, proporumcenriodesoluoadequadorealidadedaempresa.Comoresultadofinaldesteestudo,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 enge-nharia de software e que tenha aspectos de qualidade importantes. Concluiu-se que, cada vez mais, empresas de desenvolvimento de sistemas necessitam adotar processos de software adequados. A definiodociclodevidadeumsoftwareimportanteparaseteravisocompletadodesenvolvimen-todosoftware.Comisto,foipossveldefiniretapasqueabrangemdesdeaanlisedosrequisitosata entrega do software para o cliente.Fonte: . 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


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 tec-nologias 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 es-tudo 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.Levantamentoeanlisederequisitos: nesta fase necessrio levantar os requisi-tos 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.Especificaoderequisitos: a atividade de traduzir as informaes coletadas du-rante 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 do-cumento. De acordo com Sommerville (2011, p.24), os requisitos dos usurios so decla-raes 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 funcio-nalidades a serem fornecidas. Na prxima unidade trataremos com mais detalhes sobre requisitos.

4. validao de requisitos: Essa atividade verifica os requisitos quanto a sua perti-nncia, consistncia e integralidade. Durante o processo de validao, os requisitos que


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.

PROJETOEIMPLEMENTAODESOFTWARE

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,


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, pa

eng.software

Documents