FACULDADE DE TECNOLOGIA DE AMERICANA

LEANDRO RODRIGUES DE CARVALHO

Anlise do modelo de desenvolvimento de software PRISM , na elaborao do projeto do sistema de software para pequenas e mdias empresas.

AMERICANA /SP 2012

FACULDADE DE TECNOLOGIA DE AMERICANA

LEANDRO RODRIGUES DE CARVALHO RA:0822922

Anlise do modelo de desenvolvimento de software PRISM , na elaborao do projeto de sistema de software para pequenas e mdias empresas.
Trabalho Monogrfico,

desenvolvido em cumprimento exigncia curricular do Curso

Superior de Tecnologia em Anlise de Sistemas da e Tecnologia da

Informao

Fatec-Americana,

sob orientao do Prof. Me. Alberto Martins Junior. rea: Anlise de sistemas.

AMERICANA /SP 2012

BANCA EXAMINADORA

________________________________________ Prof. Me. Alberto Martins Junior (Orientador)

________________________________________ Prof. Antonio Alfredo Lacerda (Convidado)

________________________________________ Prof. Me. CLERIVALDO JOS ROCCIA (Convidado)

AGRADECIMENTOS Primeiramente agradecer a Deus por ter me dado sade e motivao para encarar essa nova etapa na minha vida. Gostaria de agradecer a todos os professores e funcionrios da FATEC Americana por todos os ensinamentos, sempre prestativos e atenciosos. Em especial gostaria de agradecer ao professor Alberto Martins Junior pela orientao deste trabalho e por todos os incentivos. Agradeo tambm a todos os meus familiares pelo apoio em especial a minha noiva Cristiane pela pacincia durante os quatro anos de estudo.

DEDICATRIA Dedico esse trabalho em especial a Deus e aos meus pais, pois sem eles no estaria escrevendo essa dedicatria e a minha noiva Cristiane. No poderia deixar de dedicar tambm a todos os professores pelos conhecimentos compartilhados e pela pacincia, pois o ato de ensinar no simples. Dedico tambm a todos os amigos e colegas de turmas que tive a oportunidade de conhecer e conviver.

RESUMO

A UML (Unified Modeling Language) ou linguagem de modelagem unificada define atravs de diagramas que auxilia no desenvolvimento de sistemas orientado a objetos. Em diferentes livros que aborda o tema UML, sempre so apresentadas as definies dos diferentes tipos de diagramas e alguns exemplos isolados, pois a UML no est ligada diretamente a um processo de desenvolvimento especfico. Por est razo a escolha do tema desse trabalho est diretamente

relacionado ao modelo de desenvolvimento de software apresentado e desenvolvido no livro UML na Prtica , Do problema a soluo ,publicado em 2003 de Caque Cardoso chamado de PRISM. O PRISM um modelo de desenvolvimento de software que utiliza os diagramas UML de forma sistematizada e o modelo de desenvolvimento incremental para gerar todos os elementos necessrios para a criao de sistemas de softwares. Este trabalho faz um panorama sinttico sobre os diferentes paradigmas do desenvolvimento de sistemas de softwares , passando pelo

desenvolvimento tradicional at o desenvolvimento orientado a objetos. So abordados tambm tpicos sobre a UML, desde seu surgimento passando pelos principais diagramas e sua utilizao em programao baseada em modelo , atravs do MDA (Model Drive Architecture). Atravs de uma pesquisa bibliogrfica do PRISM e de outros elementos que compe o desenvolvimento de software orientado a objeto,tais como, anlise, desenvolvimento e teste de software o presente trabalho tem por objetivo analisar as vantagens e possveis desvantagens na utilizao do modelo de desenvolvimento de software proposto pelo PRISM.

Palavras Chave: Metodologia, UML, Software.

ABSTRACT

The UML (Unified Modeling Language) or unified modeling language defined by the diagrams assists in developing object-oriented systems. In different books that addresses the topic UML, always presents the definitions of different types of diagrams and a few isolated examples, since the UML is not connected directly to a specific development process. For reason is the choice of the theme of this work is directly related to software development model presented and developed in the book "UML in Practice, From problem to solution," published in 2003 Caique Cardoso called PRISM. The PRISM is a model of software development using UML diagrams in a systematic and incremental development model to generate all the necessary elements for creating software systems. This work is a synthetic overview of the different paradigms of development of software systems through development to the traditional objectoriented development. They are also covered topics on the UML, since its inception through the main diagrams and their use in model-based programming through the MDA (Model Drive Architecture). Through a literature search of the PRISM and other elements that make up the development of object-oriented software, such as analysis, software development and testing of the present work aims to analyze the advantages and potential disadvantages in using the software model development proposed by PRISM.

Keywords: Methodology, UML, Software.

Lista de Figuras e tabelas

Figura 1-Relao Cliente Fornecedor. ............................................ 16 Figura 2-Modelo em cascata. .............................................................. 23 Figura 3- Prototipao:........................................................................ 24 Figura 4- Modelo em Espiral : ............................................................. 25 Figura 5- Modelo Iterativo. .................................................................. 26 Figura 6 - modelo tradicional versus orientado a objeto ................. 27 Figura 7- Exemplo de Objeto .............................................................. 28 Figura 8- Herana entre Classes. ....................................................... 29 Figura 9- Polimorfismo. ....................................................................... 30 Figura 10 - Estrutura UML. .................................................................. 33 Figura 11- Diagrama USE CASE. ........................................................ 34 Figura 12-Classe de fronteira ............................................................. 35 Figura 13- Classe de entidade ............................................................ 35 Figura 14- Classe de controle ............................................................. 36 Figura 15- relacionamento entre classes de anlise ........................ 36 Figura 16- Diagrama de Classe ........................................................... 37 Figura 17- Diagrama de Pacotes ........................................................ 38 Figura 18- Diagrama de Sequncia .................................................... 39 Figura 19 - Diagrama de componentes .............................................. 40

Figura 20- Diagrama de atividade ....................................................... 41 Figura 21 - Diagrama de mquina de estado ..................................... 42 Figura 22- Relao de dependncia ................................................... 43 Figura 23- Associao ......................................................................... 43 Figura 24 - Associao por composio ........................................... 44 Figura 25- Associao por agregao ............................................... 44 Figura 26-Associao .......................................................................... 45 Figura 27- Generalizao .................................................................... 45 Figura 28 - Transformaes entre Modelos. ...................................... 47 Figura 29- Processo de Testes ........................................................... 49 Figura 30 - Fases de teste. .................................................................. 51 Figura 31- Processo PRISM. ............................................................... 53 Figura 32- Exemplo de interface grfica ............................................ 58 Figura 33 - exemplo de tabela de dados ............................................ 59 Figura 34 - Desenvolvimento em camadas ........................................ 60 Tabela 1-Documentao de requisitos .............................................. 56 Tabela 2- Documentao de cada USE CASE ................................... 57 Tabela 3- Requisitos relacionados com a interface .......................... 58 Tabela 4- Documento de classes de anlise. .................................... 61 Tabela 5 - modelo de documentao de teste ................................... 64

Lista de Siglas e Abreviaes

Adhoc o termo utilizado para designar ciclos completos de construo de softwares baseados em modelos informais . CIM - Computation Independent Model COM+ - Component Object Model DFD Diagrama de Fluxo de Dados. DMS - Document Management System . IDE - Integrated Development Environment. J2EE - Java 2 Enterprise Edition . MVC Model view controller . MDA- Model Driven Architecture. OMG - Object Management Group . GOT - Guia Operacional de Testes. PIM Plataform Independent Model. PRISM- Practical Software Development Model . PSM Plataform Specific Model. RUP - Processo Unificado da Rational. UML - Unified Modeling Language .

SUMRIO

Lista de Figuras e tabelas ..................................................................... 8 Lista de Siglas e Abreviaes ............................................................ 10 1. 2. 3. 4. 5. INTRODUO ............................................................................. 12 JUSTIFICATIVAS ......................................................................... 14 OBJETIVOS ................................................................................. 17 METODOLOGIA........................................................................... 18 REVISO LITERRIA ................................................................. 19
5.1 Desenvolvimento de Software .............................................................. 19 5.2 Modelo de desenvolvimento de Software .............................................. 22 5.3 Programao Orientada a Objetos ....................................................... 27 5.4 UML ...................................................................................................... 31 5.5 MDA ...................................................................................................... 46 5.6 Teste de Software................................................................................. 48

6. 7. 8. 9.

ESTUDO DETALHADO DO PRISM............................................ 52 CONCLUSO............................................................................... 65 REFERNCIAS ............................................................................ 66 APNDICE ................................................................................... 69

12

1. INTRODUO

As metodologias utilizadas para o desenvolvimento de sistemas de softwares orientado a objetos so recentes. Nas dcadas de 50 e 60 no havia metodologias de desenvolvimento padronizado, os computadores contavam com baixa capacidade de processamento, isso obrigava os desenvolvedores a construir sistemas pequenos e simples para aproveitar ao mximo os recursos disponveis. Acreditava-se que quando os algoritmos estivessem

amadurecidos, no seria necessrio alter-los ou realizar qualquer manuteno at que deixavam de serem utilizado (Lima , 2009). Com o aumento da capacidade de processamento dos computadores, por volta da dcada de 70, o desenvolvimento de sistemas foi modularizado, dando origem as funes ou trechos de cdigos reutilizveis. As metodologias de desenvolvimento dessa poca baseavam-se em fluxogramas, que com o aumento da complexidade, tornava a interpretao difcil para a equipe de desenvolvimento. Com surgimento de linguagens de programao Simula e Smalltalk, deu origem a uma nova forma de modelar sistemas computacionais, o foco mudou de procedimentos e funes para o desenvolvimento orientado a objetos. De acordo com Lima sistemas desenvolvidos orientados a objetos tendem a ser mais flexveis , mais fceis de manter e promove uma maior compreenso do domnio do problema. Porm a utilizao eficiente dos conceitos de programao orientado a objetos , devem estar alinhados a uma forma de representao e modelagem concisa e eficiente. Em se tratando de produtos ou servios relacionados a sistemas de informao orientados a objetos a UML (Unified Modeling Language - Linguagem de Modelagem Unificada) fornece uma variedade

mecanismos para elaborao das fases de um projeto. Desde a concepo , especificao , construo e entrega da soluo de um projeto de software, utilizando um conjunto de diagramas que suportam conceitos de alto nvel. A UML no fornece suporte semntico que substitua uma linguagem de programao, ou seja , ela no esta orientada a nenhum cdigo e no uma

13

linguagem de programao. E segundo a OMG (Grupo de gerenciamento de objeto) a UML uma linguagem para especificao, construo e documentao de artefatos de um sistema de software intensivo. A UML tambm no um metodologia ou processo, assim para utiliz-la de modo eficiente necessria a utilizao tanto de uma ferramenta quanto uma metodologia para a elaborao de um projeto. Por isso necessrio aliar os diagramas a uma metodologia de desenvolvimento de forma a conect-los e dar-lhes significado como um todo. Segundo o prprio autor do PRISM Caque Cardoso (2003) , o objetivo do PRISM auxiliar todas as etapas do desenvolvimento , ou seja , dos requisitos ao sistema. Assim foco desse trabalho ser analisar a utilizao dos procedimentos definidos pela metodologia do PRISM para elaborado um projeto de software de pequeno porte.

14

2. JUSTIFICATIVAS

Todo projeto concebido para fornecer uma orientao na construo de um produto ou realizao de um servio. Dessa forma, para entregar uma soluo , o projeto deve conter a melhores formas possveis para solucionar um problema, document-lo e disponibiliz-lo de forma clara para o cliente. Antes da codificao de um software em si, deve haver um direcionamento de todos os passos a ser seguido na elaborao de uma soluo baseada em software. Esses passos devem estar discriminados em um documento ou um projeto de software, aliando as necessidades atuais e futuras dos clientes com todos os passos para sua realizao. Softwares so extremamente caros, cuja principal funo aumentar a eficincia das empresas e assim reduzir custos e aumentar o faturamento. Segundo o instituto de pesquisas Gartner (2012), apenas no Brasil os oramentos destinados para TI esto estimados em mais de US$ 140 bilhes para 2012, cerca de 10% maior do que registrado em 2010. O mesmo instituto prev um crescimento anual no setor de TI brasileiro na ordem de 9,9% at 2014. De acordo com Engholm (2010), h uma srie de problemas que as empresas enfrentam quando investem no desenvolvimento de sistemas sem a utilizao de processos ou metodologias bem definidas, dentre elas vale destacar: Sistemas difceis de manter, tanto em relao a manuteno corretiva quanto evolutiva. Mal aproveitamento de cdigos, podendo propagar erros ou repeties de cdigos que realizam as mesmas funes. Falta de confiana nos dados gerados pelo sistema, como consequncia , o cliente deixa de us-lo. Muitas empresas preferem o desenvolvimento de sistemas ad hoc conforme Engholm (2010), sob a alegao de reduo de custos e tempo de execuo do projeto de software. Engholm frisa ainda que toda a economia promovida pela utilizao do desenvolvimento ad hoc consumida vrias

15

vezes mais nos processos de manuteno e correo de erros. Mesmo que o sistema funcione perfeitamente a evoluo do mesmo se torna muito cara e demorada, devido principalmente a de documentao apropriada. De acordo com Lima (2009), os custos relativos ao desenvolvimento e a manuteno de sistemas de softwares esto cada vez maiores, em contra partida os custos de equipamentos (hardware) tem diminudo com o passar do tempo. Boa parte deste problema est relacionada a adoo de mtodos inapropriados para a elaborao de projetos de softwares que atenda demanda. Guedes (2009) destaca que por mais simples que um projeto de software seja, deve ser modelado antes de program-lo, pois os sistemas de informao tm a propriedade de crescer em tamanho, complexidade e abrangncia. Ainda segundo Guedes um sistema de informao necessita de uma documentao precisa e detalhada alm de estar atualizada, dessa forma o sistema de informao possa ser mantido com maior facilidade e que no surjam novos erros ao corrigir os antigos. Modelar um sistema de software tem por objetivo captar uma viso do sistema fsico , descrevendo-o de acordo com os aspectos relevantes ao propsito do modelo (Guedes , 2009). De acordo com Engholm (2010) , a implantao de um processo para o desenvolvimento de sistema de software pode ocorrer de duas formas, ou com a utilizao de propostas existentes e reconhecidas no mercado ou a criao interna, que neste caso pode no ser eficiente. Independente da metodologia a ser utilizada, ressalta Engholm, deve ser considerados os pontos relativos a cultura da empresa, tamanho da organizao, formalidade, equipe , complexidade do sistema e prioridades relativas a facilidades e prazo de entrega, dentre outras.

16

A charge abaixo , ilustra a difcil relao entre os clientes com os desenvolvedores de sistemas.

Figura 1-Relao Cliente Fornecedor. Disponvel em http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/intro/ processo.htm , 24/04/2012.

Cardoso prope, atravs da metodologia de desenvolvimento de software definida pelo PRISM, uma forma de desenvolvimento relativa ao ponto de vista do desenvolvedor de sistemas, apresentando a sequncia das etapas do trabalho a ser realizado, desde o levantamento dos requisitos a entrega da soluo do sistema. Segundo Cardoso (2003) o modelo de desenvolvimento PRISM est focado em trs eixos, anlise, projeto e arquitetura, est metodologia no aborda aspectos de gerenciamento no processo de desenvolvimento do sistema.

17

3. OBJETIVOS

O presente trabalho tem como objetivo geral analisar o modelo de desenvolvimento de software PRISM , desenvolvido por Caque Cardoso , que define uma forma para desenvolver aplicaes de softwares.

Os objetivos especficos so:

Analisar como o modelo PRISM desenvolve as fases de desenvolvimento de um projeto de software. Como ocorre a documentao do projeto de software. Identificar como se d a utilizao dos diferentes tipos de diagramas UML no processo de desenvolvimento do projeto de software.

18

4. METODOLOGIA

A presente pesquisa foi realizada predominantemente

utilizando a

metodologia de pesquisa bibliogrfica , mas tem tambm um carter de pesquisa exploratria (Spigolon , 2010) . Segundo Severino (2007) o mtodo de pesquisa bibliogrfica se baseia em documentos impressos, tais como livros , revistas, etc. Atravs da abordagem qualitativa das informaes e a utilizao do mtodo analtico para as concluses obtidas. Conforme Schlittler (2008) o mtodo no precisa ser entendido como um paradigma sobre o qual no h margem de erro.

19

5. REVISO LITERRIA

5.1 Desenvolvimento de Software Software pode ser minimamente definido como uma sequncia de instrues a ser seguido para se alcanar um objetivo. De acordo com Pressman o software que controla uma mquina automatizada , aceita dados distintos com estrutura limitada e produz comandos em rpida sucesso. No contexto da informtica o termo software pode ser utilizado como referncia a qualquer sistema cujo objetivo levar o computador a executar uma ou mais tarefas especficas. Segundo Melo (2009), desde os primeiros sistemas desenvolvidos na dcada de 40 at meados da dcada de 70, as aplicaes de um modo geral no atingiam grandes propores, devido a limitaes das mquinas existentes. A anlise era feita sem muito formalismo, adhoc, praticamente a nica forma de modelagem era feita utilizando fluxogramas. Assim houve a necessidade de mudar a metodologia daquela poca, conhecida como prtica primitiva de desenvolvimento, atravs de

especificaes de anlise e projeto durante a vida til de um software e durante a manuteno de um software existente. Iniciando o conceito de engenharia de software em resposta crise de software. De acordo com Silva (2007), a realidade da Engenharia de Software a busca da capacidade de desenvolver softwares continuamente mais complexos e em menor tempo e esforo. Ainda de acordo com Melo (2009), surgiram obras importantes que desenvolveram o paradigma estruturado, surgindo diversos diagramas, tais como , DFD (Diagrama de Fluxo de Dados), DER (Diagramas de Entidade e Relacionamento), ainda hoje h timos softwares em funcionamento que foram desenvolvidos completamente dentro dessa abordagem. Porm essa abordagem apresenta uma grande dificuldade em garantir compatibilidade entre as fases de anlise e projeto afirma Melo (2009), isso tende a se agravar durante a fase de evoluo ou manuteno do sistema de software.

20

A partir da dcada de 70 mtodos orientados a objetos comearam a surgir, dando origem a uma nova fase na abordagem metodolgica. O paradigma de anlise orientada a objetos unificou a perspectiva funcional e de dados do sistema at ento negligenciada pelo antigo paradigma. Sistemas desenvolvidos pelo modelo orientado a objetos so mais flexveis , permitem manuteno mais fcil e melhor administrao do domnio do problema. A primeira linguagem orientada a objetos geralmente reconhecida como sendo o Simula 67 , desenvolvida por Dahl e Nygaard, na Noruega em 1967. A Simula 67 inspirou a linguagem Smalltalk nos anos 80 e posteriormente as linguagens Object C, C++ e Java. Segundo Cardoso (2003) , o inicio da dcada de noventa , houve uma espcie de guerra dos mtodos para produo de softwares, cada um dizendo que seu mtodo era o melhor. Porm na realidade as coisas no eram to simples e em meados da dcada decidiu-se que era mais prudente reunir oque houvesse de melhor em cada proposta e criar um nico modelo. Foi assim que Jacobson, Booch e Rumbaugh criaram a UML, onde se pretendia apresentar um modelo universal que servisse de sustentao ao desenvolvimento dos projetos de softwares. Assim a UML tem origem na compilao das melhores prticas de engenharia que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT(Rumbaugh) e OOSE (Jacobson) fundindo-os numa nica linguagem de modelagem comum e

largamente utilizada. Os objetivos da UML so: especificao, documentao, estruturao para sub-visualizao e maior visualizao lgica do

desenvolvimento completo de um sistema de informao. A UML um modo de padronizar as formas de modelagem. Com o passar do tempo, houve vrias tentativas de se estabelecer uma notao visual de projeto de software, mas nenhuma foi to bem sucedida quanto a UML conforme Braude (2005). A UML ampla para descrever os blocos de construo das aplicaes, desde funcionalidades at a maneira como elas reagem aos eventos que nelas ocorrem.

21

Segundo Booch, Rumbaugh, Jacobson (2005) a UML (Unified Modeling Language), ou linguagem de modelagem unificada, uma linguagem padro para a elaborao da estrutura de projetos de softwares. adequada para a modelagem de sistemas, empregada na visualizao do projeto, na especificao, na construo e na documentao de artefatos que faam uso de sistemas complexos de software.

22

5.2 Modelo de desenvolvimento de Software O modelo de desenvolvimento de software uma abstrao referente ao processo de desenvolvimento de software que especifica as etapas que ocorrem durante o ciclo de vida no desenvolvimento de software. De acordo com Miles e Pilone (2008) , um processo apenas uma sequncia de etapas que seguimos para fazer algo e que o processo de desenvolvimento de software correto para uma equipe ou empresa ser o que ajuda a desenvolver e distribuir softwares de qualidade, dentro de prazos e oramentos .A seguir descreverei alguns modelos de desenvolvimento de software.

Ciclo de vida Clssico

O desenvolvimento baseado no ciclo de vida Clssico , tambm conhecido como modelo de desenvolvimento em cascata, se baseia no desenvolvimento em fases sequenciais (exemplo de fases , Anlise de requisitos , Projeto , Codificao , Testes e Manuteno). Segundo Silva (2007), historicamente esse modelo de desenvolvimento corresponde a primeira viso de como deveria ocorrer o desenvolvimento de um software, onde a fase seguinte comeava somente aps a concluso da fase anterior. De acordo com Ahmed e Umrysh (2002), esse modelo de desenvolvimento funciona bem para projetos pequenos , onde as exigncias so estveis e se conhece bem o domnio do problema. A figura na pgina seguinte ilustra as fases de desenvolvimento baseado no modelo clssico:

23

Figura 2-Modelo em cascata. Disponvel em : http://inf.unisul.br/~vera/egs/aula01.htm, 23/04/2012.

Prototipao

uma forma de desenvolvimento onde inicialmente criada uma verso (prottipo) do sistema a fim de realizar verificaes e implementaes. Tem carter preliminar de modo a reduzir os riscos na construo final do sistema. Segundo Sommerville (2003) essa forma de desenvolvimento evolucionria e visa melhor compreenso dos requisitos do cliente. A principal desvantagem desse modelo de desenvolvimento o fato de o cliente achar que o prottipo j representa o produto final exigindo assim seu pleno funcionamento. Outro ponto negativo a iluso de desperdcio de tempo ao se construir o sistema final baseado no prottipo.

24

Figura 3- Prototipao: Disponvel em :http://centraldaengenharia.wordpress.com/2011/02/09/ paradigmas-prototipacao/, 24/04/2012. Modelo em espiral

O modelo de desenvolvimento em espiral foi inicialmente proposto por Boehm em 1988 e consiste em realizar o processo de construo do software como uma sequncia de atividades com retorno entre as fases do processo. Essa forma de desenvolvimento trabalha diretamente com a prototipao. O ciclo da espiral comea com a definio dos objetivos e em seguida define formas de se atingir esses objetivos analisando as restries e riscos em cada um deles. A cada loop da espiral ocorre definio dos requisitos do sistema e nos loops mais internos ocorre tambm a viabilidade em se seguir com o projeto . Segundo Sommerville (2006) a principal diferena entre o modelo em espiral e os outros modelos a anlise de risco que ocorre em cada fase do processo.

25

Figura 4- Modelo em Espiral :

Disponvel em : http://voat.com.br/rdal/?tag=espiral , 10/04/2012. Processo Iterativo

O modelo iterativo ou incremental foi criado para diminuir as fraquezas do modelo de desenvolvimento em cascata . De acordo com Fowler a diferena entre esse modelo de desenvolvimento com o modelo de desenvolvimento em cascata est na forma da subdiviso do projeto de acordo com as funcionalidades. Independente das etapas envolvidas em um processo, a iterao uma prtica recomendvel, segundo Miles e Pilone (2008) independente do tamanho da equipe, ou do prazo do projeto, a iterao sempre ponto

determinante na construo de softwares de qualidade.Cada iterao um mini projeto, com seus prprios requisitos, design, codificao, teste , etc, ou seja, a cada iterao o projeto passa por todas as fases de desenvolvimento. Neste modelo de desenvolvimento h a participao do cliente em cada

iterao, avaliando ou modificando o sistema.De acordo com Miles e Pilone

26

(2008), com a iterao possvel avaliar se o projeto est indo na direo correta e evitar assim a descoberta de erros aps o fim do projeto. Fowler (2005) ainda destaca que o modelo de desenvolvimento iterativo aparece com muitos nomes , tais como , incremental , espiral , evolutivo , etc, e que todos , de um modo ou de outro, utilizam os conceitos do modelo em cascata e do modelo de iterao. Os dois padres mais conhecidos de sistemas iterativos de desenvolvimento so o RUP (Processo Unificado da Rational) e o Desenvolvimento gil de software.

Figura 5- Modelo Iterativo. Disponvel em : http://voat.com.br/rdal/?tag=espiral, 10/04/2012.

27

5.3 Programao Orientada a Objetos A programao orientada a objeto est muito prxima da forma como o ser humano aprende e pensa. De acordo com Guedes desde sua infncia o ser humano constri seu conhecimento por meio de abstraes e classificaes. O termo Objeto um conceito que existe no mundo real, segundo Lima os objetos possuem caractersticas e comportamentos que permitem que separemos em colees chamadas de classes. Por exemplo, reconhecemos um objeto fogo porque apresenta as caractersticas como cor, dimenses , peso, nmero de queimadores e as aes de esquentar , cozinhar e assar os alimentos. Os diferentes tipos de objetos foges so representados por uma classe denominada fogo que pode conter subdivises, tais como , fogo bsico, fogo industrial , fogo de luxo e etc. De acordo com Furlan (1998), o foco da modelagem tradicional se baseia na construo de sistemas de informao como um conjunto de programas, que executam processos sobre dados. O enfoque na modelagem de sistemas baseados em objetos , apresentam uma coletnea de objetos que se relacionam entre si de acordo com caractersticas prprias, que so representadas pelos seus atributos e mtodos.

Figura 6 - modelo tradicional versus orientado a objeto

28

Lima (2009) destaca que uma Classe a representao dos atributos e comportamentos de um conjunto de objetos . Os atributos por sua vez possuem caractersticas importantes como visibilidade , nome , tipo e valor inicial. A visibilidade de um atributo pode ser pblica, privada , protegida e de pacote, a visibilidade pblica significa que o atributo pode ser visto por

qualquer outra classe, quando um atributo caracterizado como privado somente a prpria classe consegue acess-lo diretamente. A visibilidade protegida indica que o atributo acessvel pela prpria classe e suas subclasses e por ltimo um atributo que tenha a visibilidade de pacote acessvel pelas classes que esto contidas no mesmo pacote. O tipo de

atributo e seu valor inicial podem variar um pouco de acordo com a linguagem de programao , mas que de modo geral contm textos ,data , nmeros , lgico , inclusive outras classes. As operaes definem o comportamento de um objeto, tambm chamadas de mtodos, as operaes se assemelham as funes das linguagens estruturadas. As operaes ou mtodos tambm possuem as visibilidades semelhantes ao dos atributos podendo conter ou no valores de retorno.

Figura 7- Exemplo de Objeto Disponvel em : http://www.usandoaccess.com.br/tutoriais/tuto16.asp , 14/05/2012.

29

De acordo com Guedes (2009) uma das caractersticas mais importantes da programao orientada a objetos o conceito de herana que representa o relacionamento entre classes. A herana permite que uma subclasse herde os atributos e mtodos de uma classe, diminuindo o nmero de linhas de cdigo e visa facilitar futuras manutenes.

Figura 8- Herana entre Classes. Disponvel em : http://www.devmedia.com.br/programacao-orientada-aobjeto-parte-i/16521, 14/05/2012. Outro conceito importante em orientao a objeto o do polimorfismo que est associado herana , segundo Lima (2009) polimorfismo o principio em que as subclasses podem utilizar operaes que tenhas a mesma assinatura das operaes herdadas mas com comportamentos diferentes. No exemplo seguinte podemos ilustrar o conceito de polimorfismo, imagine a classe Animal com o mtodo comunicar, todas as classes filhas herdaro e implementaro o mtodo comunicar de forma diferente.

30

Figura 9- Polimorfismo. Disponvel em: http://techblog.desenvolvedores.net/2011/02/12/ polimorfismo-poo/ , 14/05/2012.

31

5.4 UML A UML nasceu da fuso dos mtodos Booch, OOSE(Object Oriented Software Engineering) e OMT (Object Modeling dos respectivos autores Grandy Booch , Ivar Jacobson e James Rumbaugh na dcada de 90. Separadamente cada mtodo era excelente em um aspecto e no muito em outros, mas com a unificao a UML ganhou o melhor de cada mtodo. A UML 1.0 foi oferecida para padronizao ao OMG (Object Management Group) em janeiro de 1997, mas somente a UML 1.1 foi adotada pela a OMG em 14 de novembro de 1997 .A OMG assumiu a manuteno da UML das verses 1.3, 1.4 e 1.5, de 2000 a 2003, aps reviso de um ano , coordenada por Branselic (IBM) a UML verso 2 foi adotada em 2005 pela OMG. Um modelo uma simplificao da realidade e segundo Booch,

Rumbaugh, Jacobson (2005) modelagem uma tcnica de engenharia aprovada e bem sucedida. Um bom modelo inclui aqueles componentes que tm ampla repercusso e omite os componentes menores que no so relevantes em determinado nvel de abstrao. A modelagem permite a compreenso de um problema, nenhum modelo inteiramente suficiente para compreenso de um determinado problema. Sempre sero necessrios vrios modelos conectados entre si para tornar possvel entender os aspectos do sistema. Assim como no caso de um projeto de um prdio, no existe um nico conjunto de esboos capazes de revelar todos os detalhes da construo, no mnimo sero necessrias as plantas baixas, eltricas ,de circulao, gua , esgoto , etc. Porm todos os esboos se inter relacionam para atingir o objetivo comum que a construo do edifcio. O mesmo verdadeiro em relao aos sistemas de softwares, principalmente os projetos de softwares orientados a objetos. Para compreender a arquitetura desses sistemas, necessrio recorrer a vrias vises complementares e inter-relacionadas. Nesse sentido a UML fornece vrias vises divididas nos seguintes grupos:

32

Casos de uso: expondo os requisitos do sistema.

Viso de projeto : captando o vocabulrio do espao do problema e do espao da soluo.

Viso de processo : modelando a distribuio dos processos do sistema.

Viso de implementao: direcionando a realizao fsica do sistema, ou codificando o sistema em determinada linguagem de programao.

Viso de implantao: com o foco voltado para questes de engenharia de sistemas.

Cada uma dessas vises poder conter aspectos estruturais como tambm aspectos comportamentais, que representam a base do projeto de software, o diagrama a seguir mostra a estrutura da UML.

33

Figura 10 - Estrutura UML. Disponvel em: http://www.marcosmoraisdesousa.blogspot.com.br/, 14/04/2012.

A seguir ser feito um resumo dos principais diagramas e elementos da UML utilizados no PRISM e alguns so construdos a partir da ferramenta gratuita Astah Community disponvel em http://astah.net/editions/community.

34

Digrama de USE CASE (Caso de Uso)

Figura 11- Diagrama USE CASE. Disponvel em : http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/ Graduacao/SI-II/Uml/diagramas/usecases/usecases.htm , 23/04/2012. Um caso de uso descreve o comportamento do sistema sob diversas condies conforme o sistema responde a uma requisio, o ator primrio inicia uma interao com o sistema para atingir algum objetivo

(Cockburn,2005). Segundo Lima (2009) a viso de caso de uso ocupa posio central no desenvolvimento do sistema, pois a base para os demais elementos UML. representado por atores (Paciente , Doutor ,

Balconista,qualquer elemento que interage com o sistema) que se conectam as funcionalidades (elipses) do sistema. Possui tambm as tags <<include>> e <<extend>>, que podemos associar a deve fazer e pode ser feito respectivamente.

35

Classe de fronteira

Figura 12-Classe de fronteira De acordo com Cardoso, as classes de fronteira so responsveis pela interao dos usurios com o sistema ou entre as USE CASEs e atores .As classes de fronteiras sempre esto associadas a FORMs , janelas , interfaces de impressoras, terminais e outros sensores. Classe de entidade

Figura 13- Classe de entidade

As classes de entidade so utilizadas para modelar todas as informaes persistentes do sistema, podendo ser associadas a representao de banco de dados , arquivos etc. Normalmente pode ser determinadas de 1 a 3 classes de entidade por USER CASE (Cardoso,2003).

36

Classe de controle

Figura 14- Classe de controle As classes de controle so utilizadas para representar as regras de negcio da aplicao, encapsulando as aes complexas do

sistema.Geralmente as classes de controle fazem a mediao entre as classes de fronteira e as classes de entidade.Segundo Cardoso, em primeira anlise se define uma classe de controle para cada USER CASE. Diagrama de relacionamento entre classes de anlise

Figura 15- relacionamento entre classes de anlise Neste diagrama mostra o relacionamento entre as classes de anlise de uma determinada USER CASE.

37

Diagrama de classes

Figura 16- Diagrama de Classe Segundo Guedes (2009), o diagrama de classe o diagrama mais utilizado e um dos mais importantes da UML. Alm de servir de base para outros diagramas , define os atributos e mtodos de uma classe e seu relacionamento com as demais classes do sistema.

38

Diagrama de pacotes

Figura 17- Diagrama de Pacotes O diagrama de pacotes tem por objetivo representar os diferentes subsistema ou mdulos de uma aplicao. Segundo Fowler (2005) um pacote uma construo de agrupamentos de classes de acordo com o princpio da reutilizao comum, ou seja , as classes devem ser utilizadas juntas . Esse diagrama tambm pode ser utilizado para demonstrar a arquitetura de uma linguagem.

39

Diagramas de sequncia

Figura 18- Diagrama de Sequncia Disponvel em : http://techblog.desenvolvedores.net/2011/06/06/ diagrama-de-sequencia-uml/ , 14/05/2012.

No diagrama de sequncia o objetivo determinar o comportamento do sistema em ordem temporal em que ocorrem as trocas de mensagens entre os objetos em um determinado processo. De acordo com Guedes (2009) um diagrama de sequncia identifica o ator responsvel pelo evento, quais os objetos e mtodos a ser disparados e as mensagens enviadas entre os objetos.

40

Diagrama de componentes

Figura 19 - Diagrama de componentes

De acordo com Guedes (2009) os diagramas de componentes esto associados s linguagens de programao. O diagrama de componentes determina como tais componentes estaro estruturados e como iro interagir com os demais componentes do sistema. Fowler (2005) destaca que um ponto importante de que os componentes representam peas que podem ser adquiridas, atualizadas ou mesmo substitudas de forma independente.

41

Diagrama de Atividade

Figura 20- Diagrama de atividade Disponvel em : http://www.devmedia.com.br/uml-unified-modelinglanguage-parte-03/9505 , 14/05/2012.

Os diagramas de atividades so uma forma de descrever processos de negcio e fluxo de trabalho. Segundo Fowler eles so semelhantes aos DFDs , diagramas de fluxos de dado, ou mesmos aos fluxogramas. De forma simples, os diagramas de atividades definem a ordem e os possveis caminhos a ser seguido em um determinado processo, que podem ocorrer at mesmo em paralelo, desde o inicio at o final do processo.

42

Diagrama de Mquina de estados

Figura 21 - Diagrama de mquina de estado

De acordo com Guedes (2009) o diagrama de mquina de estados demonstra o comportamento de um elemento em um conjunto de estados finitos. Muito utilizado para representar uma parte do sistema, geralmente usado para modelar um caso de uso especfico. Segundo Lima (2009) um estado simplesmente representa uma ao executada, uma condio satisfeita ou uma situao esttica de espera de um objeto no processo de execuo do sistema.

43

Relacionamento ou associaes entre classes

As classes geralmente se relacionam com outras classes que permitem que elas compartilhem informaes entre si e colaborem para a execuo dos processos de um sistema (Guedes , 2011). As associaes so representadas por linhas que ligam as classes envolvidas, alm de especificar o tipo de vnculo existente , especifica tambm a multiplicidade dos elementos envolvidos. Os relacionamentos entre as classes so definidos a partir de trs formas bsicas, dependncia , agregao e generalizao. A dependncia se caracteriza por uma relao simples entre dois objetos, no se caracteriza uma relao estrutural. De acordo com Cardoso, nesse tipo de relao sempre haver a figura do fornecedor e do cliente , um oferecer um determinado servio a ser consumido pelo outro.Um

relacionamento de dependncia pode ser implementado como uma varivel local , um parmetro por referncia ou uma classe utilitria. A figura a seguir demonstra a representao desse tipo de relao.

Figura 22- Relao de dependncia J a relacionamento por associao se caracteriza por ser mais duradouro e normalmente o cliente necessita constantemente de servios do fornecedor. Associaes so relaes estruturais e podem ser dividido em composio e agregao.

Figura 23- Associao

44

A composio um tipo de associao muito forte e representa a coexistncia entre os objetos envolvidos. Lima destaca que este tipo de associao pode ser expresso pela frase a parte no vive sem o todo. Na figura a seguir demonstra um exemplo entre uma rvore e seu galho, onde um galho no vive sem uma rvore.

Figura 24 - Associao por composio Uma associao por agregao um tipo de associao de fora mdia, onde os elementos envolvidos no necessitam existir mutuamente e os objetos podem existir independentemente um do outro. Na figura abaixo, demonstra a representao deste tipo de associao tendo como exemplo uma floresta e um pssaro, supe-se que pssaros podem existir sem floresta e que os

pssaros so agregados floresta. Furlan (1998) destaca que os objetos agregados no podem ser destrudos por qualquer objeto diferente do objeto que o criou, ou seja , do objeto de agregao.

Figura 25- Associao por agregao Outro detalhe importante a representao da navegabilidade (para onde a seta aponta), indica que a classe de origem tem visibilidade da classe destino, se no houver navegabilidade, ambas as classes podem ser

visualizadas (Fowler , 2005).No exemplo a seguir mostra uma associao simples.

45

Figura 26-Associao Outro relacionamento importante entre as classes a generalizao que consiste em compartilhar elementos de uma classe , como atributos e mtodos. As classes abstratas so muito utilizadas para representar comportamentos e atributos genricos, pode ser identificada utilizando a verificao um tipo de ou um entre os elementos (Cardoso , 2003).

Figura 27- Generalizao

46

5.5 MDA

Com a evoluo da UML , a modelagem poder chegar to perto do cdigo , ou mesmo ser o prprio, atravs de modelos que executam diretamente (Magela , 2006). No ano 2000, o OMG publicou e lanou um artigo denominado Model Driven Architecture (MDA , Arquitetura Baseado em Modelo) , no qual apresentava uma forma de desenvolvimento de software baseada em modelos e suas transformaes. O objetivo do desenvolvimento baseado em modelo elevar o nvel de abstrao dos projetos, de modo a transform-lo diretamente no cdigo fonte alvo (qualquer linguagem de programao) sem a necessidade de

complement-los, ou pelo menos realizar pequenos ajustes. Atualmente diferentes ferramentas de construes UML, do suporte a transformao dos diagramas UML em cdigos de diferentes linguagem , porm so gerados somente o esqueleto do cdigo, ficando a cargo do desenvolvedor completar as especificidades do sistema (regras de negcio). Oque se prope com o MDA a automatizao do processo de anlise a codificao, onde os modelos criados podero ser convertidos em cdigos e vice-versa de maneira completa. Dessa forma o analista s se preocupar com o desenvolvimento do modelo do sistema , pois qualquer alterao ou acrscimo no modelo se refletir no cdigo do sistema. A programao baseada em modelo torna a manuteno e evoluo dos sistemas de software muito mais fceis do que em relao ao cdigo do sistema. Segundo Mellor et al. (2005) , modelos consistem em um conjunto de elementos que descrevem alguma realidade fsica , abstrata ou hipottica. Modelos so mais baratos de se construir e servem como meio de comunicao entre equipes, alm de poderem ser construdos em diferentes nveis de abstrao, tudo de acordo com o contexto. Para a MDA , o importante criar diferentes modelos em diferentes nveis de abstrao , para ligao posterior, formando assim uma implementao. Neste processo a UML tem papel fundamental para a MDA , por ser uma linguagem bem definida , grfica e extremamente adaptvel (expansvel) , principalmente atravs dos

47

esteretipos , reduz a probabilidade de m interpretao dos modelos (MELLOR et al., 2005). Contudo, Mellor et al. (2005) frisa que a MDA deve suportar o desenvolvimento iterativo incremental, expressando cada aspecto do sistema em um nvel apropriado de abstrao. A arquitetura da MDA consiste basicamente em Modelos e Viewpoints( princpio interno de separao de aspectos e princpios de abstrao) e conforme Magela (2006) seus conceitos mais conhecidos so o CIM (Computation Independent Model) , PIM (Plataform Independent Model) e PSM (Plataform Specific Model) . O CIM um modelo de contexto do negcio ou do domnio do negcio que no possui detalhes da estrutura ou do comportamento do software. Confirme Magela (2006) , um bom CIM preenche o espao entre o conhecimento especializado do analista de negcio e o conhecimento especializado do desenvolvedor de software.De acordo com Mellor et al. (2005) o PIM uma viso do modelo de software com especializaes e comportamentos gerais, que no possuam qualquer ligao ou caractersticas de uma plataforma especfica (ex. J2EE , .NET). J o PSM uma viso do modelo de software a partir de uma plataforma especfica , de acordo com Magela (2006) o PIM transformado em PSM , que por sua vez pode ser transformado em cdigo ou em outros PSM.

Figura 28 - Transformaes entre Modelos. Disponvel em : http://www.linhadecodigo.com.br/artigo/1953/model-drivenarchitecture---conceitos-fundamentais.aspx , 24/05/2012.

48

5.6 Teste de Software Em um mercado cada vez mais dependente de softwares, devido ao apoio nos negcios das organizaes e em alguns casos so partes intrnsecas do prprio negcio. H uma grande demanda por produtos e servios de qualidades e livres de defeitos. De acordo com Rios e Moreira (2006) cerca de 90% dos sistemas so entregues com algum tipo de defeito grave, softwares com defeitos correspondem a um custo de quase 1% do PIB(Produto interno Bruto) Americano. Uma das causas identificadas para esse custo exorbitante a falta de tecnologias padronizadas de testes de softwares. Outro fator importante apontado por Rios e Moreira o fato das empresas desenvolvedoras de sistemas no considerarem os testes como um verdadeiro processo que na maioria das vezes so realizados pelos prprios desenvolvedores de forma informal. A realizao dos testes de softwares com qualidade implica em identificar e corrigir os defeitos o quanto antes, de forma a evitar o retrabalho mais adiante no projeto, defeitos esses que podem encarecer ainda mais o custo do produto alm da quebra de confiana do cliente. Segundo Cardoso (2003), existe um consenso que todo software tem algum tipo de defeito que pode as vezes nunca ser descoberto, porm , a funo principal dos testes permitir que o sistema seja o mais confivel e consistente possvel. Com o aumento do tamanho e complexidades dos softwares que passaram de milhares de linhas de cdigos para milhes, alm da necessidade de equipes cada vez maiores para sua construo, se torna fundamental a execuo de um processo de teste de software eficiente e de qualidade.

49

Processo de testes

processo

de

testes deve

estar integrado

ao processo

de

desenvolvimento normal do sistema, alm de possuir pessoal qualificado com ferramentas e ambientes apropriados. De acordo com Rios e Moreira(2006) os procedimentos iniciais na realizao de qualquer processo de testes , consiste na elaborao de um documento GOT ( Guia Operacional de Testes). Este documento visa estabelecer um acordo entre todos os envolvidos no projeto de testes , usurios , desenvolvedores, teste e produo. No processo de teste deve haver tambm as fases de planejamento, preparao , especificao , execuo e entrega do sistema ou parte dele, para o ambiente de produo.

Figura 29- Processo de Testes Disponvel em : http://testesw.wordpress.com/processo-de-testes/ , 14/05/2012.

50

Tipos de testes

Os testes de softwares podem ser classificados de duas formas gerais , o teste de caixa preta e teste de caixa branca(DELAMARO; MALDONARO; JINO ,2007). No teste de caixa preta verificado as funcionalidades do sistema, sob a ptica do usurio , seguindo certos requisitos pr definidos e sem qualquer conhecimento do cdigo do componente a ser testado, somente se conhece a interface do componente. J no teste de caixa branca, tambm chamado de caixa de vidro, o objetivo avaliar o sistema com base no cdigo e na lgica interna do componente avaliado. O processo de teste se subdivide em vrios estgios ou nveis de testes que dependem diretamente do tipo de produto a ser testado, dentre eles podemos destacar: Teste unitrio. Teste de integrao. Teste de sistema. Teste de regresso. Teste de carga ou stress. Teste de usabilidade. Etc.

A uma grande variedade de nveis de testes que exigiria muito tempo e trabalho para citar e explicar cada um deles fugindo do escopo deste trabalho. De acordo com Rios e Moreira (2006) a qualidade dos testes est ligada diretamente aos riscos de falhas aps o lanamento do produto, alm de ser diretamente proporcional aos custos e prazos envolvidos no projeto. Tem que se tomar cuidado em analisar o custo na elaborao de um processo de software de qualidade, pois quanto mais completos e melhores forem os testes menor o custo total do sistema durante seu ciclo de vida. A figura a seguir resume as principais fases de um processo de teste de software.

51

Figura 30 - Fases de teste. Disponvel em : http://testesw.wordpress.com/processo-de-testes/, 14/05/2012.

52

6. ESTUDO DETALHADO DO PRISM

O PRISM um modelo de desenvolvimento de software criado por Caque Cardoso que tem por objetivo facilitar o trabalho de arquitetura e engenharia de software. Utilizando os diagramas UML de forma sistemtica como ferramenta de trabalho, alm da documentao de projeto, o PRISM resultado da experincia do autor em projetos prticos que alia conceitos tericos consistentes com o dia a dia de uma equipe de desenvolvimento de software. A utilizao do modelo de desenvolvimento PRISM no especifica o modo de gerenciamento do projeto e nem a ferramenta CASE utilizada na elaborao dos diagramas UML. De acordo com Cardoso (2003) o PRISM no define o tamanho do projeto, apesar do intuito inicial ser de criar um modelo prtico para projetos e equipes de pequeno porte, mas nada impede a sua utilizao em projetos maiores e mais complexos. Cardoso (2003) tambm disponibilizou um DMS (Document Management System ) , ou documento de gerenciamento de sistemas, para servir de modelo de documentao do sistema de software e ser utilizado durante todo desenvolvimento de software atravs do PRISM. A ideia bsica do PRISM fornecer uma forma de desenvolvimento de um sistema de maneira clara e objetiva fornecendo a sequncia do trabalho a ser desenvolvido. O modelo PRISM utiliza o processo de desenvolvimento Iterativo ou incremental, onde cada etapa inicia-se com a aquisio ou refinamento dos requisitos do sistema junto ao cliente, passando pelas demais etapas do desenvolvimento do sistema. Ao final de cada iterao gera-se parte do cdigo , e depois da fase dos testes e aprovao do cliente, inicia-se novamente uma nova iterao. O diagrama de atividades a seguir resume todas as fases utilizadas no modelo de desenvolvimento PRISM a cada iterao at a concluso do projeto. As definies de cada fase assim como a forma de utilizao sero realizadas posteriormente.

53

Figura 31- Processo PRISM.

54

Analisaremos cada etapa do processo PRISM, verificando como realizlos, document-los e de que forma uma etapa fornece elementos para as etapas e iteraes seguintes. Em anexo se encontra um modelo de documentao para o projeto de software para ser utilizado com o processo de desenvolvimento PRISM.

Levantamento de requisitos

O primeiro passo o levantamento de requisitos do sistema junto ao cliente. De acordo com Cardoso (2003) o responsvel pelo levantamento dos requisitos tem que estar preparado para mergulhar , o mais profundo, nos problemas do cliente.Todos os requisitos devem ser registrados, por mais que parea difcil de implement-lo no momento, essa avaliao deve ser realizada em momento posterior. No mtodo PRISM os requisitos so divididos nos seguintes tipos: Requisito funcional (F); Requisito de dado (D); Requisito de interface (I); Requisito no funcional (N).

Os requisitos funcionais especifica as aes que devero ser realizadas pelo sistema independente das restries fsicas , os requisitos de dados por sua vez se caracteriza pelas informaes que sero persistidas, ou seja, em uma base de dados, representando a parte esttica do sistema Requisitos de interfaces refere-se a comunicao com o usurio , hardware ou mesmo outro sistema. Os requisitos de suporte, tais como sistema operacional ou qualquer requisito que no faz parte da lgica do negcio so classificados como requisitos no funcionais (Cardoso , 2003).

55

Cada requisto identificado e documentado de acordo com a seguinte definio: ER [ f | a] [F | D | I | N ] [XXXX].N , segue-se o significado de cada elemento: ER Especificao de Requisito; [ f | a] requisito futuro (f) ou atual (a); [F | D | I | N ] tipo do requisito; XXXX numero ou sigla do projeto que o requisito est associado; N nmero sequencial de requisito do projeto.

necessrio definir riscos e prioridades associados aos requisitos , Cardoso (2003) resalta que em geral o cliente tem a tendncia de afirmar que todos os requisitos so de altssima prioridade, algo nem sempre verdadeiro. As prioridades determinaro a ordem e qual atividade dever ser realizada., dessa forma o PRISM divide as prioridades em :

Altssima Alta Mdia Baixa Baixssima

A classificao dos requisitos de acordo com Prioridade/Risco(P/R) determinar o desenvolvimento do projeto, deve-se ter como objetivo a reduo do risco associados aos requisitos de maior prioridade que pode ser feito atravs de prottipos. Cardoso (2003) afirma que o sucesso do projeto se baseia em levantar e especificar os requisitos com extrema preciso, alm de um excelente gerenciador de requisitos, pois conforme o projeto vai tomando forma se torna mais claro, inclusive para o cliente.

56

Cardoso (2003) salienta que no necessrio obter e especificar todos os requisitos do sistema, pois o PRISM baseado no desenvolvimento iterativo e incremental. A forma de documentar os requisitos , de acordo com o modelo PRISM: Tabela 1-Documentao de requisitos ER [ f | a] [F | D | I | N ] [XXXX].N Descrio Nome da especificao de requisito Faa aqui a descrio detalhada do requisito, exemplificando sempre que possvel. Risco Prioridade Qualificador Altssima/Alta /Mdia/Baixa /Baixssima

Descrio do risco

Faa aqui a descrio do risco associada ao Qualificador requisito, colocando o mximo de informaes Altssima/Alta possveis para a mitigao. /Mdia/Baixa /Baixssima

Modelagem de USER CASE

O processo de modelagem de USE CASE comea pela identificao os atores (quem utilizar o sistema), deve se dar nome e fazer uma breve descrio dos papis de cada ator no sistema. Cada USE CASE est baseada nos requisitos do sistema e para identific-las o PRISM prope o seguir os passos seguintes: 1. Analisar e agrupar todos os funcionalidades. 2. Aps agrupados, determinar quais atores interagem com este ciclo de uso. 3. Descreva o fluxo timo para este ciclo (entrada do ator que levar ao resultado final sem erros). 4. Descreva os fluxos alternativos (em que algo possa dar errado). 5. Caso o fluxo seja complexo, gere um diagrama de atividades para demonstrar graficamente o fluxo. 6. Divida as USE CASE em partes para no ocorrer repeties, exemplo login do usurio. requisitos do ponto de vista das

57

Cardoso (2003) prope que ao final de cada USE CASE faa uma reunio com o cliente no sentido de discutir se o que foi analisado est de acordo com as necessidades. Ressalta ainda que no se deve tentar detalhar todas as USE CASE ao mesmo tempo, pois como se trata de um processo incremental, sempre haver a oportunidade de se corrigir e aprofundar o detalhamento das USE CASE. A forma de documentar os requisitos , de acordo com o modelo PRISM: Tabela 2- Documentao de cada USE CASE Nome da USE CASE Descrio Coloque um nome adequado para USE CASE Descreva detalhadamente o propsito da USE CASE. Requisitos associados Liste os requisitos que esto sendo atendidos por esta USE CASE. Pr-condio Se existir uma ou mais pr-condies, descreva aqui. Ps-condio Se existir uma ou mais ps-condies, descreva aqui. Atores Liste os atores que relacionam com esta USE CASE. Fluxo Principal Aes recebidas Aes realizadas 1. O ator X inicia o fluxo principal 2. O processo recebe a entrada, (ou fluxo timo). avalia e envia ao controle. 3. O controle trata a informao. 4. Aps tratar a informao os dados so apresentados ao ator. Fluxo alternativo N Aes recebidas Aes realizadas 1. O ator X inicia o fluxo alternativo 2. O processo recebe a entrada, N (ou fluxo de erro, ou fluxo avalia e envia ao controle. opcional etc.) 3. O controle trata a informao. 4. Aps tratar a informao os dados so apresentados ao ator.

58

Modelagem de interface

Conforme Cardoso (2003) , cada interface uma descrio lgica e conceitual de como uma ou mais USE CASE interage com o usurio. As

interfaces representa uma forma de entender os requisitos do cliente (usurio). importante que se faa o desenhos das interfaces grficas , descrevendo cada campo relacionado. A forma de documentar as interfaces , de acordo com o modelo PRISM:

Interface N Tabela 3- Requisitos relacionados com a interface Requisitos relacionados com a interface

Cadastro de Usurios
Dados do usurio Nome do usurio: Campo 1 Campo 2 Campo 3 Campo 4

Email:

Senha:

Confirmar Senha:

Cadastrar

Cancelar

Figura 32- Exemplo de interface grfica Campo1 - Campo de entrada e visualizao do nome do usurio. Campo2 campo de entrada e visualizao de email do usurio. Campo3 campo de entrada de senha do usurio. Campo4 campo de confirmao da senha do usurio. Boto Cadastrar efetua o cadastro do usurio na base de dados. Boto Cancelar realiza o cancelamento da operao.

59

Persistncia de Dados

Nesta etapa deve ser descritos os dados do sistema que devem ser persistidos. Utilizando a organizao dos dados em tabelas, vises , ndices e procedimentos usados para manter a persistncia do sistema(Cardoso, 2003).
Usuario PK id nome email senha

Figura 33 - exemplo de tabela de dados

Diagramas de camadas e componentes

Segundo Cardoso(2003), no incio os sistemas eram desenvolvidos em uma nica camada, que era responsvel pelos dados e pela interface com o cliente. Com o aumento da complexidade dos sistema houve a necessidade de dividir o sistema em camadas. Um modelo de diviso da aplicao em camadas o padro Model-view-controller (MVC) , atualmente considerado uma "arquitetura padro" . O modelo MVC isola a lgica da aplicao da interface do usurio , permitindo o desenvolvimento e testes separadamente . De acordo com Magela (2006) os crditos do modelo MVC dado para Trygve Reenskaug em seus escritos de 1979. As camadas so agrupadas em pacotes que tem por objetivo organizar as classes do sistema a fim de melhorar a compreenso e manuteno do software como um todo. Conforme Cardoso (2003) as prprias classes de anlise podero fazer partes de pacotes correspondentes e vo naturalmente influenciar na distribuio da atividade de desenvolvimento em paralelo. Uma camada ou pacote pode ser composto de componentes, que em sistema complexos , como os sistemas baseados na WEB ,so responsveis em grande parte pelos requisitos no funcionais da aplicao. E necessrio a

60

construo de diagramas de componentes para facilitar a visualizao da distribuio dos componentes e a forma de instalao (Cardoso, 2003). O uso de padres de componentes depender do tamanho do projeto e da escolha da tecnologia a ser utilizada.E so utilizados em sistemas corporativos de trs ou mais camadas como por exemplo COM+ (Microsoft) e J2EE da Oracle (antiga Sun). A figura abaixo mostra o desenvolvimento em trs camadas:

Figura 34 - Desenvolvimento em camadas Uma camada Wiew, onde feita a comunicao ou interface de dados entre o usurio e o sistema. Uma camada Controller , responsvel pelo tratamento dos dados que so enviados ou recebidos do usurio do sistema.

61

Uma camada Model, responsvel pela comunicao e interao com o repositrio de dados.

Modelagem de classe de anlise

As classes de anlise representam uma abstrao de uma ou mais classe de projeto e so construdas de acordo com cada USE CASE. Segundo Cardoso (2003) as caractersticas das classes de anlise evolui de acordo com a introduo de mais informaes na anlise do projeto at que cada classe de anlise se torne uma ou mais classes de projeto. Nesta etapa so modelados os trs tipos de classes de anlise: classe de fronteira , classe de controle e classe de entidade, ambas definidas no capitulo sobre UML deste trabalho, a tabela a seguir resume a forma de documentao para as classes de anlise definida pelo PRISM. Tabela 4- Documento de classes de anlise. Classes de anlise
(N significa o nmero da classe caso haja mais de uma)

Nome da USE CASE Classe de fronteira N Nome da classe Descrio

Classe de entidade N

Nome da classe

Descrio

Classe de controle N

Nome da classe

Descrio

Diagrama de relacionamento entre classes de anlise Coloque o diagrama de relacionamento entre as classes de anlise para esta USE CASE.

62

Modelagem dinmica com o diagrama de sequncia

De acordo com Cardoso (2003), as classes de anlise sero fundidas ou subdivididas durante a anlise dos objetos. A modelagem dinmica, principalmente no diagrama de sequncia, gerar a maioria das classes de projeto, facilitando a identificao dos atributos e mtodos (operaes) das classes de projeto e tambm facilitar a reutilizao do cdigo j desenvolvido. Como no existe uma linha divisria na construo das classes de projeto, dependendo das necessidades do desenvolvimento dever trabalhar em outros diagramas para complet-las. Neste momento importante a definio dos subsistemas que fazem parte do projeto oque permite o desenvolvimento em paralelo.

Modelagem de classes do projeto

Depois de modelado o diagrama de sequncia, inicia-se a montagem das classes de projeto que representam a ltima etapa antes da gerao do cdigo do sistema. Cardoso (2003) ressalta que o aprofundamento do trabalho no diagrama de sequncia vai depender da complexidade e conhecimento tcnico do analista. Para identificao das classes de projeto Cardoso (2003) prope seguir as seguintes orientaes: Desenvolver as classes de projeto iniciais que so retiradas diretamente do diagrama de sequncia; Definir as operaes de relacionamento; Definir atributos e outras operaes; Definir dependncias , associaes e generalizaes; Verificar a consistncia da classe quanto aos requisitos no funcionais; Criar , se necessrio , novas classes de projeto.

Outro detalhe importante na modelagem de classe de projeto que cada classe deve possuir um propsito bem definido. Dessa forma aumentam as

63

chances das classes serem reutilizadas e torna mais fceis a tarefa de implementao e manuteno.

Cdigo executvel

Nesta etapa so implementadas as classe do projeto gerado na iterao do processo de desenvolvimento. A gerao de cdigo representa o incio e o fim do incremento no PRISM. Um novo cdigo gerado ao final de cada ciclo do processo. O modelo de desenvolvimento PRISM no define qual ferramenta ou IDE (Integrated Development Environment ou ambiente integrado de desenvolvimento de software) utilizada para a implementao das classes de projeto. Ficando a cargo da equipe de desenvolvimento a escolha das ferramentas a serem utilizadas.

64

Testes

A etapa de testes comea logo aps a gerao dos primeiros cdigos executveis. De acordo com Cardoso (2003) a etapa de teste representa o final do ciclo (ou final do incremento) logo aps a gerao do cdigo executvel. Deve se documentar todos os testes realizados, seja teste de Classe , teste de Stress ou teste de funcionalidade de acordo com a tabela proposta pelo PRISM.

Tabela 5 - modelo de documentao de teste Responsvel Data:

Inclua o nome da pessoa responsvel Inclua a data e horrio da execuo pela execuo do teste. Recursos necessrios: Inclua a especificao de hardware e sofware da(s) mquinas envolvida(s) no teste. Hardware Configurao Software do teste.

Procedimentos: Descreva os procedimentos para a execuo do teste. Resultados: Descreva os resultados obtidos ao final do teste

Os trs tipos de testes ocorrem em momentos diferentes de acordo com o andamento do projeto. O teste de classe visa verificar se a classe atende s responsabilidades atribudas . J o teste de stress utilizado para verificar o comportamento do sistema quando submetido a um grande volume de dados. O teste de funcionalidade est relacionado diretamente com os objetivos das USE CASE , verificando se os fluxos esto de acordo com os previstos.

65

7. CONCLUSO

O modelo de desenvolvimento de software PRISM de fcil entendimento e no oferece dificuldades de implementao , pois no exige nenhum tipo de software especfico para sua utilizao. Podendo utilizar diferentes tipos de ferramentas que fornecem suporte a UML , inclusive gratuitas, para elaborao dos diagramas e documentao do projeto do sistema de software . um modelo flexvel que se adapta as necessidades da equipe de desenvolvimento. Somente um ponto talvez que poderia ser considerado uma desvantagem o fato do modelo de desenvolvimento PRISM no propor uma forma de gerenciamento, na elaborao do projeto de software, dependendo muito da experincia da equipe de desenvolvimento. Para uma anlise mais completa, seria necessrio o acompanhamento de alguns projeto que utilizariam o modelo de desenvolvimento PRISM , de acordo com o tamanho do projeto , nmeros de indivduos em cada projeto e a experincia das equipes de desenvolvimento.

66

8. REFERNCIAS

AHAMED, Khawar Zaman e UMRYSH, Cary E..Desenvolvendo Aplicaes Comerciais em Java com J2EE e UML. Rio de Janeiro: Cincia Moderna Ltda , 2002.

BRAUDE , Eric . Projeto de Software : Da programao arquitetura : uma abordagem baseada em Java. Trad; Edson Furmankiewicz. Porto Alegre : Bookman , 2005.

BOOCH , Grady ; RUMBAUGH ,James ; JACOBERSON , Ivar . UML : Guia do Usurio . 2.ed. Rio de Janeiro: Campus , 2005.

CARDOSO, Caque . UML na prtica : do problema ao sistema. So Paulo : Cincia Moderna Ldta, 2003. COCKBURN, Alistair. Escrevendo casos de uso eficazes. Porto Alegre: Bookman, 2005.

DELAMARO,

Mrcio

Eduardo;

MALDONADO,

Jos

Carlos;

JINO,

Mario.Introduo ao Teste de Software. Rio de Janeiro: Campus, 2007.

ENGHOLM JNIOR, Hlio. Engenharia de software na prtica. So Paulo : Novatec Editora , 2010. FI : http://aosfi.blogspot.com.br/ , acesso em 20/04/2012. FOWLER, Martin. UML essencial : um breve guia para a linguagem-padro de modelagem de objetos / Martin Fowler; trad. Joo Tortello. 3.ed.Porto Alegre : Bookman ,2005.

67

FURLAN, Jos Davi. Modelagem de Objetos atravs da UML:ANLISE E DESENHO ORIENTADOS A OBJETO. So Paulo: Makron Books, 1998. Gartner instituto: http://computerworld.uol.com.br/tecnologia/2011/10/25/gastoscom-ti-no-brasil-chegarao-a-us-144-bilhoes-em-2012/> acesso em 19/04/2012. GUEDES , Gilleanes T.A. UML 2: Uma abordagem prtica. So Paulo : Novatec Editora , 2009.

JUNIOR, Joaquim Martins: Como escrever trabalhos de concluso de curso. Petrpolis , RJ: Vozes , 2011. LIMA, Adilson da Silva. UML 2.0 : Do Requisito Soluo .4.ed.So Paulo : rica, 2009.

MELO , Ana Cristina . Desenvolvendo Aplicaes com UML 2.0 : Do conceitual implementao. 2.ed . Rio de janeiro : BRASPORT , 2004.

MAGELA , Rogrio: ENGENHARIA DE SOFTWARE APLICADA : PRINCPIOS. Rio de Janeiro : Editora Alta Books Ltda, 2006. MELLOR, Stephen J. et al. MDA Destilada: Principios de Arquitetura Orientada por Modelos. Rio de Janeiro: Editora Moderna Ltda, 2005.

NOGUEIRA, Marcelo . Engenharia de software: Um framework para a gesto de riscos em projetos de softwares. Rio de Janeiro: Editora Cincia Moderna Ltda, 2009. PILONE, Dan; MILES, Russ. Use a Cabea: Desenvolvimento de Software. Rio de Janeiro: Alta Books, 2008. Traduo. PRESSMAN, R. S. Engenharia de Software. 5a edio, Editora McGraw-Hill, 2002. RIOS, Emerson; MOREIRA, Trayah. Teste de Software. 2. ed. Rio de Janeiro: Alta Books, 2006.

68

SEVERINO , Antnio Joaquim: Metodologia do Trabalho Cientfico. So Paulo : Cortez , 2007. SILVA, Ricardo Pereira . UML 2.2 em Modelagem Orientada a Objeto. Florianpolis : Visual Books, 2007. SOMMERVILLE, IAN. Engenharia de Software. 6a. edio, Addison-Wesley, 2003. SCHILITTLER, Jos M. Martins: Como fazer monografias. Campinas ,SP: Servanda Editora, 2008.

SPIGOLON, Ana Lucia: Manual para elaborao e apresentao de dissertaes monografias , TCCs para a faculdade de Tecnologia de Americana. Americana , 2010.

69

9. APNDICE

70

DMS - DOCUMENTO DE MODELAGEM DE SISTEMA

VERSO:
[NOME DO SISTEMA] [AUTORES]

71

TABELA DE REVISES

Verso

Principais Autores

Descrio da Verso

Data de Trmino

V[x.x]

[nome]

[descrio da verso]

[dd/mm/aaaa]

V[x.x]

[nome]

[descrio da verso]

[dd/mm/aaaa]

72

PREFCIO

73

NDICE

74

10.

Lista de Figuras

75

11.

Lista de Tabelas

76

12.

Introduo

Finalidade Este documento apresenta a modelagem do sistema <nome>, utilizando como referncia o livro UML na Prtica Do Problema ao Sistema. O pblico alvo deste documento inclui pessoas envolvidas com o desenvolvimento

(analistas de sistemas e programadores), testes do sistema e avaliadores do projeto. Escopo O Documento de Modelagem de Sistema prov uma viso completa dos modelos do sistema <nome>. Ele produzido e utilizado pelos

desenvolvedores da equipe para documentar os requisitos, modelos e arquitetura do sistema. Definies, Acrnimos e Abreviaturas

Referncias

Detalhes do Sistema

77

13.

Especificao de Requisitos

Especificao dos Requisitos

ER[f|a][F|D|I|N].N

ER[f|a][F|D|I|N].N Descrio Descrio do risco Risco Prioridade

O porqu da no implementao do requisito

Tabela 6 Tabela de Especificao do Requisito ER[f|a][F|D|I|N].N

78

14.

Descrio das Use Cases e Atores

Use Cases Descrio dos Atores

[Nome do Ator N]

Diagrama Geral de Use Cases

Detalhamento das Use Cases

Use Case [Nome da Use Case N]

Nome da Use Case Descrio Requisitos Associados Pr Condies Ps Condies Atores Fluxo Principal Aes Recebidas 1. Aes Recebidas 1. 2. Fluxo Alternativo N Aes Realizadas Aes Realizadas

Tabela 7 - Fluxo de Eventos da Use Case [nome da UC]

79

15.

Interfaces

Interface N Requisitos relacionadas com a interface

Tabela 8 Requisitos relacionadas com a interface

80

16.

Persistncia de Dados

Dados da Tabela N Requisitos relacionadas com os dados

Tabela 9 Requisitos relacionadas com a tabela

81

17.

Classes de Anlise

Classes de Anlise da [Nome da Use Case N]

Classe de Fronteira N [Nome da Classe] Classe de Entidade N [Nome da Classe] Classe de Controle N [Nome da Classe] Diagrama de Classes de Anlise

82

18.

Camadas e Pacotes

Diagrama de Camadas (ou Pacotes) Camada (ou Pacote ) [Nome da Camada (ou do Pacote)]

83

19.

Comportamento Dinmico

Diagramas de Sequncia da Use Case [Nome da Use Case]

[Nome do Diagrama de Sequncia N]

84

20.

Subsistemas e Componentes

85

21.

Comportamento Esttico

Diagramas de Classe Projeto [Nome do Diagrama]

86

22.

Testes

Teste de Classe

Classe - [nome da classe]

Responsvel: Data:

Nome do mtodo: Procedimentos: Resultados:

Tabela 10 - Teste de classe [nome da classe]

Teste de Stress

Responsvel:

Incio:

Final:

Recursos necessrios: Hardware Configurao Software

Procedimentos: Resultados:

87

Teste de Funcionalidade

Teste de funcionalidade do Fluxo de Evento Principal

Responsvel: Data:

Recursos necessrios: Hardware Configurao Software

Procedimentos:

Resultados:

Tabela 11 - Teste de funcionalidade do Fluxo de Evento Principal

Teste de funcionalidade do Fluxo de Evento Alternativo [N]

Responsvel: Data:

Recursos necessrios: Hardware Configurao Software

Procedimentos:

Resultados:

Tabela 12 - Teste de funcionalidade do Fluxo de Evento Alternativo [N]

88

Teste de funcionalidade do Fluxo de Evento de Exceo [N]

Responsvel: Data:

Recursos necessrios: Hardware Configurao Software

Procedimentos:

Resultados:

Tabela 13 - Teste de funcionalidade do Fluxo de Evento Exceo [N]