UNISUL UNIVERSIDADE DO SUL DE SANTA CATARINA PR-REITORIA ACADMICA CENTRO DE CINCIAS EXATAS, AGRRIAS E DAS ENGENHARIAS CURSO DE CINCIA

A DA COMPUTAO

PESQUISA E DESENVOLVIMENTO EM UML

ALEXANDRE DE ALMEIDA REGINALDO DAROLT

ARARANGU SC 2001

UNISUL UNIVERSIDADE DO SUL DE SANTA CATARINA PR-REITORIA ACADMICA CENTRO DE CINCIAS EXATAS, AGRRIAS E DAS ENGENHARIAS CURSO DE CINCIA DA COMPUTAO

PESQUISA E DESENVOLVIMENTO EM UML

ALEXANDRE DE ALMEIDA REGINALDO DAROLT

Projeto apresentado disciplina de Projetos em Cincia da Computao II, coordenado pelo Professor Luciano Savio e orientado pelo Professor

Alessandro Zanini.

ARARANGU SC 2001

ii UNISUL UNIVERSIDADE DO SUL DE SANTA CATARINA PR-REITORIA ACADMICA CENTRO DE CINCIAS EXATAS, AGRRIAS E DAS ENGENHARIAS CURSO DE CINCIA DA COMPUTAO

TERMO DE APROVAO PROJETO DE CONCLUSO DE CURSO

Aprovamos o Projeto PESQUISA E DESENVOLVIMENTO EM UML, elaborado pelos alunos ALEXANDRE DE ALMEIDA e REGINALDO DAROLT, apresentado com requisito parcial para a obteno de Grau em Bacharel em Cincia da Computao.

Prof. Carlos Fernando Buss Coord. do Curso de Cincias da Computao Banca de Avaliao

Prof. Luciano Savio Coordenador de PCC

Prof. Alessandro Zanini Orientador

Prof. Ana Cludia G. Barbosa Convidada

Prof. Juarez Bento Da Silva Convidado ARARANGU SC 2001

iii

Dedicamos este Trabalho a nossos pais, namoradas e familiares que sempre nos apoiaram e estiveram a nosso lado em todos os momentos.

iv

AGRADECIMENTOS

A Deus. A todos os colegas e professores, em especial Alessandro Zanini, Ana Claudia, Rafael vila Faraco, Luciano Savio e Carlos Fernando Buss, os quais nos incentivaram e deram apoio no desenvolvimento deste Projeto. As empresas Seara Alimentos S/A, Domnio Sistemas Ltda e Betha Sistemas Ltda, em especial ao colega Cristiano Tomasi(Betha Sistemas Ltda).

SUMRIO

LISTA DE FIGURAS ............................................................................................ xii RESUMO............................................................................................................. xiv ABSTRACT.......................................................................................................... xv Captulo 1 - INTRODUO ................................................................................... 1 1.1 Apresentao ............................................................................................ 1 1.2 Objetivos Geral e Especficos ................................................................... 2 1.3 Justificativa................................................................................................ 3 1.4 Abrangncia .............................................................................................. 4 1.5 Metodologia............................................................................................... 4 1.6 Estrutura ................................................................................................... 5 Captulo 2 - ANLISE E PROJETOS ORIENTADOS A OBJETOS ..................... 8 2.1 Conceito.................................................................................................... 8 2.2 Anlise Orientada a Objetos ..................................................................... 9 2.3 Projeto Orientado a Objetos.................................................................... 10 2.4 Classes ................................................................................................... 11 2.5 Objetos.................................................................................................... 11 2.6 Abstrao ................................................................................................ 12

vi 2.6.1 Abstrao de Procedimentos ........................................................... 12 2.6.2 Abstrao de dados.......................................................................... 12 2.7 Encapsulamento ..................................................................................... 13 2.8 Herana .................................................................................................. 13 2.9 Polimorfismo ........................................................................................... 14 Captulo 3 - UML ................................................................................................. 15 3.1 Introduo ............................................................................................... 15 3.2 Histrico .................................................................................................. 16 3.3 Aceitao ................................................................................................ 18 3.4 Padronizao OMG................................................................................. 19 3.5 Aplicao ................................................................................................ 19 Captulo 4 - ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML ....... 20 4.1 Anlise de Requisitos.............................................................................. 20 4.2 Anlise .................................................................................................... 21 4.3 Projeto..................................................................................................... 21 4.4 Programao........................................................................................... 22 4.5 Testes ..................................................................................................... 23 Captulo 5 - FERRAMENTAS CASE................................................................... 24 5.1 Conceito.................................................................................................. 24 5.2 Vantagens............................................................................................... 26 5.3 Aceitao no Mercado ............................................................................ 27 5.4 O Futuro .................................................................................................. 28 5.5 Rational Rose.......................................................................................... 28 Captulo 6 - VISES DE SISTEMAS................................................................... 30 6.1 Conceito.................................................................................................. 30

vii 6.2 Viso USE-CASE.................................................................................... 31 6.3 Viso Lgica............................................................................................ 31 6.4 Viso de Componentes........................................................................... 32 6.5 Viso de concorrncia............................................................................. 32 6.6 Viso de Organizao............................................................................. 33 Captulo 7 - MODELOS DE ELEMENTOS.......................................................... 34 7.1 Definio ................................................................................................. 34 7.2 Classes ................................................................................................... 35 7.2.1 Nomes .............................................................................................. 36 7.2.2 Atributos ........................................................................................... 37 7.2.3 Operaes ........................................................................................ 38 7.3 Objetos.................................................................................................... 39 7.4 Estados ................................................................................................... 40 7.5 Pacotes ................................................................................................... 42 7.6 Componentes.......................................................................................... 43 7.7 Relacionamentos .................................................................................... 43 7.7.1 Associaes ..................................................................................... 44 7.7.1.1 Associaes Normais .................................................................... 44 7.7.1.2 Associaes Recursivas ................................................................ 45 7.7.1.3 Associaes Qualificadas .............................................................. 46 7.7.1.4 Associaes Exclusivas ................................................................. 46 7.7.1.5 Associaes Ordenadas ................................................................ 47 7.7.1.6 Associaes de Classe .................................................................. 47 7.7.1.7 Associaes Ternrias................................................................... 48 7.7.1.8 Agregao...................................................................................... 49

viii 7.7.2 Generalizaes................................................................................. 50 7.7.2.1 Generalizao Normal ................................................................... 50 7.7.2.2 Generalizao Restrita .................................................................. 51 7.7.3 Dependncias e Refinamentos ........................................................ 52 7.8 Mecanismos Gerais ................................................................................ 53 Captulo 8 - DIAGRAMAS ................................................................................... 55 8.1 Conceito.................................................................................................. 55 8.2 Diagramas de Casos de Uso .................................................................. 56 8.3 Diagramas de Classes ............................................................................ 57 8.4 Diagramas de Objetos ............................................................................ 59 8.5 Diagramas de Estados............................................................................ 61 8.6 Diagramas de Seqncia........................................................................ 62 8.7 Diagramas de Colaborao .................................................................... 63 8.8 Diagramas de Atividade .......................................................................... 64 8.9 Diagramas de Componentes .................................................................. 65 8.10 Diagramas de Implantao ................................................................... 66 Captulo 9 - METODOLOGIA DESENVOLVIDA................................................. 68 9.1 Introduo ............................................................................................... 68 9.2 Documentao ........................................................................................ 69 9.2.1 Fonte ................................................................................................ 69 9.2.2 Gravao da Documentao ............................................................ 70 9.2.3 Extenso de Arquivos....................................................................... 71 9.2.4 Impresso......................................................................................... 71 9.2.5 Backup ............................................................................................. 72 9.2.6 Controle de Verses......................................................................... 72

ix 9.3 Eventos Iniciais ....................................................................................... 73 9.3.1 Contatos ........................................................................................... 74 9.3.2 Estudo dos Dados ............................................................................ 74 9.3.3 Definio dos Participantes .............................................................. 75 9.4 Anlise de requisitos ............................................................................... 76 9.4.1 Reunio/Entrevista ........................................................................... 76 9.4.2 Preenchimento da ata da reunio..................................................... 79 9.4.3 Definies de responsabilidades ...................................................... 79 9.4.4 Resumo do Projeto........................................................................... 79 9.4.5 Atores ............................................................................................... 80 9.4.6 Casos de Uso ................................................................................... 80 9.4.7 Escopo ............................................................................................. 81 9.4.8 Diagrama de caso de uso................................................................. 82 9.4.9 Anlise de riscos .............................................................................. 82 9.4.10 Cronograma ................................................................................... 83 9.4.11 Aprovao ...................................................................................... 84 9.5 Anlise .................................................................................................... 84 9.5.1 Diagrama de Classes ....................................................................... 84 9.5.2 Diagrama de Objetos........................................................................ 85 9.5.3 Diagramas de Interao ................................................................... 86 9.5.3.1 Diagrama de Seqncia ................................................................ 87 9.5.3.2 Diagrama de Colaborao ............................................................. 88 9.5.4 Diagrama de Estado......................................................................... 89 9.5.5 Diagrama de Atividade ..................................................................... 89 9.6 Projeto..................................................................................................... 90

x 9.6.1 Diagrama de implementao............................................................ 91 9.6.1.1 Diagrama de componente.............................................................. 91 9.6.1.2 Diagrama de implantao .............................................................. 93 9.7 Implementao........................................................................................ 95 9.7.1 Traduo .......................................................................................... 95 9.7.2 Escolha da Linguagem ..................................................................... 95 9.7.3 Documentao do Cdigo ................................................................ 97 9.8 Testes ..................................................................................................... 99 9.8.1 Planejamento de Testes................................................................... 99 9.8.2 Execuo de Testes ....................................................................... 100 9.8.2.1 Teste de Unidade......................................................................... 100 9.8.2.2 Teste de Integrao ..................................................................... 102 9.8.2.3 Teste de Validao ...................................................................... 103 9.8.2.4 Teste de Sistemas ....................................................................... 104 9.8.3 Avaliao dos Resultados .............................................................. 104 Captulo 10 - Validao da Metodologia ......................................................... 106 10.1 Introduo ........................................................................................... 106 10.2 Formulrio de Documentao ............................................................. 106 10.3 Contatos Iniciais.................................................................................. 107 10.4 Ata da Reunio ................................................................................... 108 10.5 Resumo do Projeto ............................................................................. 109 10.6 Escopo ................................................................................................ 110 10.7 Lista de Casos de Uso ........................................................................ 111 10.8 Diagrama de Caso de Uso .................................................................. 112 10.9 Diagrama de Classes.......................................................................... 113

xi 10.10 Escolha da Linguagem...................................................................... 114 Captulo 11 - RESULTADOS OBTIDOS ........................................................... 115 Captulo 12 - CONCLUSO .............................................................................. 119 12.1 Recomendaes ................................................................................. 120 Captulo 13 - BIBLIOGRAFIA ........................................................................... 121

xii

LISTA DE FIGURAS

Figura 2.1 : Anlise Orientada a Objeto............................................................ 10 Figura 2.2 : Projeto Orientado a Objetos .......................................................... 11 Figura 6.1 : Vises de Sistemas ........................................................................ 31 Figura 7.1 : Classes ............................................................................................ 36 Figura 7.2 : Nomes ............................................................................................. 37 Figura 7.3 : Atributos.......................................................................................... 38 Figura 7.4 : Operaes ....................................................................................... 39 Figura 7.5 : Objetos ............................................................................................ 40 Figura 7.6 : Estados............................................................................................ 41 Figura 7.7 : Pacotes............................................................................................ 42 Figura 7.8 : Componentes.................................................................................. 43 Figura 7.9 : Associaes Normais .................................................................... 45 Figura 7.10 : Associaes Recursiva................................................................ 46 Figura 7.11 : Associaes Qualificadas ........................................................... 46 Figura 7.12 : Associaes Exclusivas .............................................................. 47 Figura 7.13 Associaes de Classe .................................................................. 48 Figura 7.14 : Associaes Ternrias................................................................. 48

xiii Figura 7.15 : Agregao ..................................................................................... 49 Figura 7.16 : Agregao Compartilhada ........................................................... 49 Figura 7.17 : Agregao de Composio ......................................................... 49 Figura 7.18 : Generalizao Normal .................................................................. 50 Figura 7.19 : Generalizao de Sobreposio ................................................. 51 Figura 7.20 : Generalizao Completa .............................................................. 52 Figura 7.21 : Relao de Dependncia ............................................................. 52 Figura 7.22 : Refinamentos................................................................................ 53 Figura 7.23 : Ornamentos e Nota ...................................................................... 54 Figura 8.1 : Diagramas de Casos de Uso ......................................................... 57 Figura 8.2 : Diagramas de Classes ................................................................... 59 Figura 8.3 : Diagramas de Objeto...................................................................... 60 Figura 8.4 : Diagramas de Estados ................................................................... 62 Figura 8.5 : Diagramas de Seqncia ............................................................... 63 Figura 8.6 : Diagramas de Colaborao ........................................................... 64 Figura 8.7 : Diagramas de Atividade ................................................................. 65 Figura 8.8 : Diagramas de Componentes ......................................................... 66 Figura 8.9 : Diagramas de Implantao ............................................................ 67 Figura 10.1 Escopo do Sistema....................................................................... 111 Figura 10.2 Diagrama de Caso de Uso do Sistema de Contabilidade.......... 113 Figura 10.3 Diagrama de Classes do Sistema de Contabilidade.................. 114

xiv

RESUMO

Usar uma metodologia de desenvolvimento de sistema para captar desde os primeiros contatos, at a concluso das etapas de desenvolvimento de software, de extrema importncia. A UML(Unified Modeling Language) a juno das trs mais conceituadas linguagens de modelagem orientados a objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh), porm a UML no possui um mtodo de trabalho a ser seguido. Este trabalho estuda a UML para que se possa criar uma metodologia de desenvolvimento de sistemas que englobe todas as fases do processo, desde os eventos iniciais, passando pela Anlise de Requisitos, Anlise, Projeto, Programao e Testes. Para a validao da metodologia desenvolvida ser aplicada no desenvolvimento de um prottipo. Utilizaremos a ferramenta case Rational Rose, da Rational Software Corporation no apoio a modelagem do sistema. Ao final do desenvolvimento de cada fase sero feitas observaes que serviro de concluso e base para futuros melhoramentos.

xv

ABSTRACT

To use a metodology of system development to obtain since the first contacts until the final version is very important. The UML (Unified Modeling Language) is the junction of three most respected language of model oriented for objects (Booch of Grady, OOSE of Jacobson and OMT of Rumbaugh) [Booch,2001], but the UML doesnt have a work metod to be follwed. The paper studies the UML in order to create a metodology of system development that joints all the steps of the process, since the first events, passing through the Analysis of Requisites, Analysis, Project, Programming and Tests. For the validation of the developed metodology well aplicate on the development of a prototype, where it will be used the instrument Rational Rose, of Ratonal Software Corporation, to support the system model. By the end of the development of each phasis, will be made observations that will serve as conclusion and basis for future improvement.

Captulo 1 - INTRODUO

1.1 Apresentao

Um grande problema no desenvolvimento de novos sistemas utilizando a orientao a objetos o fato de no existir uma notao padronizada e realmente eficaz que possa abranger qualquer tipo de aplicao. Cada metodologia existente possui suas prprias notaes (smbolos usados para projetar modelos orientados a objetos), processos e ferramentas. Isso faz com que a escolha do mtodo a ser utilizado torne-se uma deciso extremamente importante e freqentemente leva a discusses e debates sobre qual o melhor mtodo, o mais avanado e adequado para ser utilizado em um projeto especfico. Com o lanamento da UML (Unified Modeling Language)

desenvolvedores da rea de orientao a objetos, ficaram entusiasmados com sua abrangncia. Pois a UML traz novos conceitos que normalmente no so usados. Um bom entendimento da UML no somente um conhecimento de

2 sua smbologia e significados, mas tambm um contexto geral de modelagem orientada a objetos. Com a juno das trs mais conceituadas metodologias(Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh) de modelagem orientado a objetos criou-se a UML aproveitando o que havia de melhor em cada uma delas adicionando conceitos e vises da linguagem. UML permite comunicar certos conceitos mais claramente que as linguagens alternativas [Fowler, 2000]. A UML uma padronizao de modelagem orientado a objetos de forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistncia, fcil de se comunicar com outras aplicaes, simples de ser atualizado e compreensvel. Com este projeto pretendemos justamente pesquisar sobre esta linguagem de modelagem, suas aplicaes, vantagens e desvantagens. Como conseqncia dessa pesquisa definiremos uma metodologia de

desenvolvimento de sistemas baseada em UML, a qual analisamos ser o mais eficaz s necessidades atuais de desenvolvimento.

1.2 Objetivos Geral e Especficos

Objetivamos com esta pesquisa o estudo aprofundado de uma metodologia unificada de desenvolvimento de sistemas orientado a objetos baseado em UML, com a perspectiva de desenvolver uma metodologia e aplic-la desenvolvendo um prottipo, comprovando sua eficincia e

funcionalidade.

3 Especificamente, os objetivos apresentados so: Obter amplos conhecimentos sobre UML; Mostrar a sociedade a importncia do uso de uma metodologia no desenvolvimento de sistemas; Estudar como se desenvolve uma metodologia de desenvolvimento de sistemas; Desenvolver uma metodologia de trabalho baseado em UML; Estudo de uma ferramenta CASE, para modelagem do sistema. Desenvolvimento de um prottipo usando a metodologia; Apresentao do prottipo desenvolvido.

1.3 Justificativa

Com as constantes inovaes que surgem em ferramentas de desenvolvimento de sistemas orientados a objetos e a necessidade de desenvolvimento de sistemas mais complexos e precisos, faz com que um estudo sobre uma metodologia unificada de desenvolvimento torne-se um grande atrativo a ser pesquisado. Com este interesse, desenvolveremos o presente projeto com o intuito de apresentar a analistas uma metodologia de desenvolvimento e salientar a importncia de sua aplicao, a qual poder resolver muitos problemas encontrados no decorrer de todo o desenvolvimento de um sistema. Para isto ser desenvolvido um prottipo utilizando-se desta metodologia.

1.4 Abrangncia

A UML tende a ser uma linguagem de desenvolvimento de sistemas orientado a objetos dominante, comum entre os melhores analistas e desenvolvedores. Por conseqncia este projeto pretende comprovar a eficcia do uso desta metodologia, com base no desenvolvimento de um prottipo. Destacamos os principais tpicos : A modelagem de sistemas (no apenas de software) usando os conceitos da orientao a objetos; Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm executveis; Estabelecer um mtodo de comunicao entre toda a equipe envolvida (cliente, analista, desenvolvedor, etc); Mostrar a sociedade a qualidade de um sistema desenvolvido com o uso da UML.

1.5 Metodologia

Para o desenvolvimento do Trabalho de Concluso de Curso (TCC), sero definidas as seguintes etapas: Estudo da metodologia UML; Conceitos sobre esta metodologia; Aprimoramento da metodologia usada, visando sua melhor performance;

5 Estudo e definio de uma ferramenta CASE que melhor atenda a essa metodologia; Estudo e definio de ferramentas para desenvolvimento do sistema; Escolha de um sistema para aplicao da metodologia estudada comprovando sua eficcia; Desenvolvimento de um prottipo do sistema; Concluso sobre a metodologia estudada e sua aplicao.

1.6 Estrutura

Este captulo apresentar a voc leitor, uma breve descrio de cada captulo que constitui este trabalho.

No captulo 2 descreveremos um breve conceito da anlise e projetos orientado a objetos bem como sua necessidade, surgimento, etc. Faremos uma descrio da base da anlise e projetos orientado a objetos descrevendo seus pontos principais como classes, objetos, abstraes, etc. Este captulo importante para o entendimento da anlise orientada a objetos.

O captulo 3 faz uma introduo UML(Linguagem Unificada de Modelagem) dizendo o que ela nos disponibiliza, sua aceitao, padronizao e aplicaes. Para um melhor entendimento do processo de criao da UML apresentaremos um histrico completo, desde o incio das pesquisas at a concluso da ltima verso.

O captulo 4 descreve as etapas tcnicas da UML, baseada nos conceitos tradicionais das atividades de desenvolvimento. Estas etapas vo desde os primeiros passos(Anlise de Requisitos) at a fase de testes.

O captulo 5 faz uma descrio sobre ferramenta CASE, apresenta algumas vantagens da aplicao desta ferramenta e tambm descreve sua aceitao no mercado. Ao final deste captulo ainda apresentamos uma viso do futuro desta ferramenta.

No captulo 6 apresentado um conceito sobre vises em UML e qual a importncia destas vises para o entendimento do sistema. Descreve-se ainda em detalhes as 5(cinco) vises utilizadas e o uso de cada uma destas vises.

O captulo 7 traz uma definio de modelos de elementos e descreve detalhadamente todos os modelos de elementos utilizados pela UML, tais como Classes, Objetos, Estados, Pacotes, Componentes e

Relacionamentos.

O captulo 8 apresenta um conceito genrico sobre diagramas em UML, descreve detalhadamente os 9(nove) tipos de diagramas utilizados pela UML, exemplificando graficamente e indicando o uso de alguns tipos de diagramas.

7 No captulo 9 apresentaremos a metodologia desenvolvida.

O captulo 10 mostra um prottipo desenvolvido aplicando a metodologia do captulo anterior.

No captulo 11 mostraremos os resultados obtidos durante a validao de cada fase da metodologia.

No captulo 12 faremos nossas concluses sobre todo o TCC.

captulo

13

apresenta

toda

bibliografia

utilizada

no

desenvolvimento do TCC.

Captulo 2 - ANLISE E PROJETOS ORIENTADOS A OBJETOS

2.1 Conceito

Com os enormes computadores da dcada de 1950 e 1960, e a pouca capacidade de processamento, desenvolvedores de programas tinham que aproveitar ao mximo todo bit que o hardware disponibilizava. J na dcada de 1960 computadores transistorizados foram surgindo, o que na poca j era um grande avano, substituindo os enormes computadores de vlvulas. Desenvolvedores mais radicais afirmavam que os algoritmos para os sistemas que esses computadores rodavam tinham que ser monolticos. Ou

seja, se j se chegou na melhor fase do algoritmo no necessrio mais alteraes ou manutenes, ficando do mesmo jeito at deixar de ser usado. Desenvolvedores menos radicais e com uma viso um pouco diferente, afirmavam que os sistemas tinham que ser modularizados para que

9 fossem de mais fcil manuteno e compreenso. Este conceito foi mais aceito a medida que os computadores foram aumentando sua capacidade. Precursores da analise orientada a objeto, defendiam que devamos estruturar programas de computador de acordo com o problema a ser resolvido. O termo Orientao a Objetos sugere abstraes do mundo real e trechos de programas de computador, ou objeto. Um grande fator da orientao a objetos a reusabilidade. Estamos reutilizando cdigos de programas desde o incio da computao. As tcnicas de orientao a objetos nos permitem muito mais que a reutilizao de cdigos, podemos reutilizar requisitos, anlise, projeto, planejamento de testes, interfaces de usurio e arquiteturas, ou seja todos os componentes de engenharia de software podem ser encapsulados como reutilizveis.

2.2 Anlise Orientada a Objetos

Anlise o estudo de um problema, antes de qualquer ao [De Marco, 1978] Anlise o estudo do domnio de um problema que leva a uma especificao de comportamentos observveis externamente. uma

declarao completa, consistente e possvel do que necessrio, um conjunto de caractersticas operacionais quantificadas e funcionais. Analisar obter as necessidades de um sistema e o que este precisa ser desenvolvido para satisfazer as necessidades do usurio. Analisar no definir como o sistema ser desenvolvido, mas sim investigar o problema conforme mostra a Figura 2.1.

10 A AOO tem dois propsitos. Primeiramente formalizar uma viso do mundo real dentro do qual o sistema ser desenvolvido, estabelecendo os objetos que serviro como principais estruturas organizacionais do sistema de software e tambm as que o mundo real impe. Em segundo lugar, a AOO formaliza a colaborao de um dado conjunto de objetos na execuo do trabalho do sistema de software que est sendo especificado. Esta formalizao representa como cada objeto se comunica com os demais.

Figura 2.1 : Anlise Orientada a Objeto

2.3 Projeto Orientado a Objetos

O Projeto Orientado a Objetos (PjOO) visto como o processo de especificao das partes da construo, ou seja, instrues, guias,

recomendaes, estipulaes, qualificaes, regras, etc..

Utilizamos estes

processos para implementar um sistema em um ambiente especfico, em busca da soluo do problema conforme mostra a Figura 2.2.

11 Durante a PjOO dado nfase na elaborao dos elementos lgicos do software [Larman, 2000]. Sendo implementados em uma linguagem de programao orientada a objetos, os quais possuem atributos e mtodos.

Figura 2.2 : Projeto Orientado a Objetos

2.4 Classes

Uma Classe em linguagens Orientadas a Objetos a possibilidade de combinar num nico registro, campos de dados e campos que so funes para operar os campos de dados do registro [Furlan, 1998].

2.5 Objetos

Um objeto simplesmente alguma coisa que faz sentido no contexto de uma aplicao [Rumbaugh, 1994]. Objeto uma entidade independente, assncrona e concorrente, armazena dados, encapsula servios, troca

12 mensagens com outros objetos, e modelado para executar as funes finais do sistema.

2.6 Abstrao

Abstrao o princpio de ignorar os aspectos de um assunto no relevante para o propsito em questo, tornando possvel uma concentrao maior nos assuntos principais [Cood, 1991]. Consiste na seleo que o analista faz de alguns aspectos, ignorando outros. Existem duas formas de abstrao, de Procedimentos e de Dados.

2.6.1 Abstrao de Proc edimentos

Princpio de que qualquer operao com um efeito bem definido pode ser tratada por seus usurios como uma entidade nica, mesmo que a operao seja realmente conseguida operaes de nvel mais baixo. atravs de alguma seqncia de

2.6.2 Abstrao de dado s

Consiste em definir um tipo de dado conforme as operaes aplicveis aos objetos deste tipo. Porm, estes objetos s podem ser modificados e observados atravs destas operaes.

13

2.7 Encapsulamento

Encapsular omitir informaes pelo princpio de que uma determinada entidade esconde informaes as quais so necessrias apenas mesma. fundamental que o objeto proteja seus dados, no permitindo que o usurio do objeto os acesse diretamente. Mas sim atravs de mtodos se houver necessidade[Furlan, 1998].

2.8 Herana

Esta provavelmente a caracterstica mais discutida da abordagem orientada a objetos [Mazzola, 1999]. a principal caracterstica do processo de

Generalizao/Especializao. Atravs da herana uma determinada subclasse herda todos os atributos e mtodos da superclasse. Permite a um analista especificar servios e atributos comuns uma s vez, assim como especializar e estender estes atributos e servios em casos especficos.

14

2.9 Polimorfismo

o conceito usado em linguagens de programao orientada a objetos para denotar a caracterstica de que a linguagem suporta a utilizao do mesmo identificador (o mesmo nome) para mtodos de classes diferentes. Um conceito em teoria de tipo no qual um nome (como uma

declarao de varivel) pode denotar objetos de muitas subclasses diferentes que so relacionadas por alguma superclasse comum, assim, qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operaes de modos diferentes [Booch, 2000].

Captulo 3 - UML

3.1 Introduo

A UML a linguagem padro para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e atravs de diferentes tecnologias de implementao [Furlan, 1998]. A UML disponibiliza uma forma padro de modelagem de projetos de Sistemas, incluindo seus aspectos conceituais tais como processos de negcios e funes do sistema, alm de itens concretos como as classes escritas em determinada linguagem de programao, processos de banco de dados e componentes de software reutilizveis.

16

3.2 Histrico

As linguagens de modelagem orientadas a objetos surgiram entre a metade da dcada de 1970 e o final da dcada de 1980, medida que o pessoal envolvido com metodologia, diante de um novo gnero de linguagens de programao orientadas a objeto e de aplicaes cada vez mais

complexas, comeou a experimentar mtodos alternativos de anlise e projeto. A quantidade de mtodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o perodo de 1989 a 1994. Muitos usurios desses mtodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender inteiramente s suas necessidades. Destacaram-se algumas linguagens como o Booch, o OOSE (Object-Oriented Software Engineering) de Jacobson, e o OMT (Object Modeling Technique) de Rumbaugh. Podemos citar outros mtodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon. Todos eram mtodos completos, alguns se destacavam em algum ponto, porm tinham suas limitaes. O mtodo Booch destacava-se durante as fases de projeto e construo de sistemas, o OOSE fornecia excelente suporte para captura de requisitos, a anlise e o projeto em alto nvel; o OMT-2 era mais til com a anlise e sistemas de informaes com uso de dados[Booch, 2000]. Na metade da dcada de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de mtodos orientados a objetos, comearam a pegar as melhores idias e partiram para a criao de uma linguagem unificada de modelagem. Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com os quais os desenvolvedores de ferramentas pudessem criar uma

17 ferramenta mais utilizvel. Usando tcnicas orientadas a objeto criariam uma linguagem que iria desde o conceito at o sistema executvel, no somente a sistemas complexos mas tambm a sistemas menores e tambm a outros problemas que no fossem sistemas de informao, podendo ser utilizado por seres humanos e mquinas[Furlan, 1998]. A criao da UML iniciou oficialmente em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificao dos mtodos Booch e OMT[Furlan, 1998]. O esboo da verso 0.8 do Mtodo Unificado foi lanado em outubro de 1995. Mais ou menos na mesma poca Jacobson se associou Rational com a finalidade de incorporar o OOSE no escopo inicial da verso 0.8, resultando o lanamento da verso 0.9 da UML em junho de 1996[Booch, 2000]. Foi ento aprovada pela comunidade de engenharia de software em geral. Muitas empresas ficaram interessadas, foi ento criada um consrcio com vrias empresas interessadas em dedicar recursos com o propsito de trabalhar uma definio mais forte e completa da UML. Empresas que contriburam para a definio da UML 1.0, Digital Equipment Corporationm Hewlett-Packard, I-Logix, Intel-licorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments e Unisys. Resultando uma linguagem de modelagem bem definida , expressiva, poderosa, e que poderia ser aplicada a uma grande variedade de tipos de problemas[Booch, 2000]. A UML foi oferecida para a OMG (Object Management Group) em janeiro de 1997, em resposta solicitao do prprio OMG de propostas para uma linguagem padro de modelagem[Furlan, 1998].

18 Entre janeiro a julho de 1997, o grupo original se expandiu, passando a incluir virtualmente todos os participantes e colaboradores da resposta inicial ao OMG, entre os quais se encontravam Andersen Consulting, Ericson, Object Time Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software e Taskon. Um grupo foi formado, liberado por Cris Kobryn da MCI Systemhouse e administrado por Ed Eykholt da Rational, com o propsito de formalizar a especificao da UML e de integrar a linguagem a outros esforos de padronizao. A verso 1.1 foi entregue a OMG em julho de 1997. Em setembro do mesmo ano, essa verso foi aceita pela ADTF (Analysis and Design Task Force) e pelo Architecture Board do OMG e, posteriormente submetida a votao de todos os membros da OMG. A verso 1.1 foi adotada pela OMG em 14 de novembro de 1997[Booch, 2000]. A manuteno da UML foi ento assumida pela RTF (Revision Task Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lanou uma reviso editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF lanou a UML 1.3[Furlan, 1998].

3.3 Aceitao

Os criadores da UML procuraram desenvolver uma linguagem unificada padro que pudesse ser de fcil entendimento a todos. Preocuparamse em deix-la aberta aos desenvolvedores, onde os mesmos pudessem criar seu prprio mtodo de trabalho. Empresas desenvolvedoras de ferramentas esto livres para criarem uma ferramenta aqueda ao uso da UML. Devido a necessidade de criao da

19 UML empresas e profissionais liberais da rea esto desenvolvendo estudos para melhor aplic-la.

3.4 Padronizao OM G

Quando se iniciaram os trabalhos para criao da UML, os criadores tinham como inteno fazer sua aceitao com a distribuio da linguagem a vrios desenvolvedores. A OMG (Object Management Group) fez um requerimento por uma linguagem de modelagem padro. Ento houve interesse dos criadores da UML em padroniz-la, para isso foi preciso que os mesmos aprimorassem a qualidade da linguagem para tal. Pois para serem realmente utilizadas por empresas era necessrio sua padronizao.

3.5 Aplicao

A UML pode ser usada para modelar vrias fases de um sistema, desde os primeiros contatos at a gerao do cdigo. aplicada em qualquer tipo de sistemas em termos de diagramas de orientao a objeto. Geralmente mais usada na modelagem de Softwares usando o conceito de orientao a objetos, mas tambm pode ser aplicada em sistemas mecnicos, de engenharia em geral, pode tambm ajudar na organizao de processos de uma organizao.

Captulo 4 - ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML

4.1 Anlise de Requis itos

Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes chamadas "use-cases" [Barros, 2001]. a descrio das necessidades ou desejos de um determinado sistema. O princpio bsico da anlise de requisitos identificar e documentar o que realmente necessrio, desta forma comunicando a todos os envolvidos no projeto da forma mais clara possvel, de maneira no-ambgua de modo que os riscos sejam identificados sem correr riscos de imprevistos. Atravs do desenvolvimento de casos de uso(em UML chamamos de use-cases), as entidades externas ao sistema (em UML chamamos de "atores externos") que interagem e possuem interesse no sistema so modelados entre as funes que eles requerem, funes estas chamadas de "use-cases". Os atores externos e os "use-cases" so modelados com

21 relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Descrevemos um use-case atravs de um texto especificando os requisitos do ator externo que utilizar este use-case. Um use-case tanto pode depender de um ou mais use-case como pode ter seus dependentes. Atravs do diagrama de use-cases mostraremos aos atores externos(futuros usurios) o que estes podem esperar do sistema. A anlise de requisitos tambm pode ser desenvolvida baseada em sistemas de negcios, e no apenas para sistemas de software

4.2 Anlise

A fase de anlise preocupa-se com as primeiras abstraes(classes e objetos) e mecanismos presentes no contexto do problema[Larman, 2000]. Descrevemos as classes nos Diagramas de Classes e tambm para ajudar na descrio dos use-cases, podendo estas estar ligados uma nas outras atravs de relacionamentos. Nesta fase modelamos somente as classes que pertencem ao domnio principal do problema, ou seja, classes tcnicas mais detalhadas no estaro neste diagrama.

4.3 Projeto

Projeto cria uma representao do domnio de problema do mundo real e leva-a a um domnio de soluo que o software [Pressman, 1995].

22 Nesta fase partimos para as solues tcnicas, atravs dos resultados obtidos na fase da anlise. Sero adicionadas novas classes para oferecer uma infra-estrutura tcnica tais como: interface do usurio e perifricos, banco de dados, interao com outros sistemas, e outras mais. feita uma juno das classes da fase da anlise com as classes tcnicas da nova infra-estrutura, podendo assim alterar tanto o domnio principal do problema quanto a infra-estrutura. Com a elaborao do projeto obtemos detalhadamente as especificaes para dar inicio a fase de programao.

4.4 Programao

Para que uma fase de programao possa ter um bom desempenho, necessitamos de um projeto bem elaborado, consequentemente converteremos as classes da fase do projeto para o cdigo da linguagem orientada a objetos escolhida. Se o desenho foi elaborado corretamente e com detalhes suficientes, a tarefa de codificao facilitada [Furlan, 1998].A complexidade dessa converso vai depender da capacidade da linguagem escolhida, no entanto esta pode tornar-se fcil ou difcil de se realizar. Em UML durante a elaborao dos modelos de anlise e projeto, devemos evitar traduzi-los em cdigos. Cabendo esta tarefa fase de programao.

23

4.5 Testes

Na fase de teste executamos um programa com a inteno de descobrir um erro[Pressman, 1995]. Testamos cada rotina ou processo detalhadamente, bem como a integrao de todos os processos e a aceitao. As rotinas devem ser testadas de duas formas, uma pelos programadores, pois estes tem um conhecimento das classes e grupo de classes que envolvem esta rotina, sabendo desta forma onde esto os pontos mais crticos que podem causar falhas. A outra forma de testes de uma rotina feita por outro usurio, pois este ir fazer um teste do seu modo, tendo a viso da rotina como um todo. Os testes de integrao so feitos usando as classes e seus componentes de integrao para verificar se estas classes esto realmente colaborando uma com as outras conforme especificado nos modelos. Nos

testes de aceitao verificado se o sistema est de acordo com o especificado no diagramas de use-cases. Por fim, o sistema ser testado pelo usurio final e este verificar se os resultados apresentados esto realmente de acordo com suas intenes expressas no incio do projeto.

Captulo 5 - FERRAMENTAS CASE

5.1 Conceito

O termo CASE(Computer-Aided Software Engineering) significa Engenharia de Software Auxiliada por Computador. Antigamente, os analistas desenvolviam software para outras reas (como Engenharia, Arquitetura, Medicina, etc) mas no se utilizavam de software para fazer seu trabalho. Tinham necessidade de visualizar o projeto como um todo, ao invs de analislo em partes. difcil de acreditar que ferramentas de software to simples estejam ficando cada vez mais importantes nos dias de hoje [Cood, 1991]. Com a crescente demanda pela qualidade e integrao de softwares, e tambm pela unificao de planejamentos administrativos com a anlise, projeto e gerao de sistemas, surgiu ento as denominadas Ferramentas Case.

25 Uma Ferramenta Case um software que auxilia no ciclo de desenvolvimento de um sistema desde a fase de anlise at a fase de testes, auxiliando tambm na manuteno do sistema. Apoiam na utilizao de metodologias e mtodos, armazenam informaes em sua base de dados, tanto em forma de textos como em forma grfica, possibilitando a comunicao com o usurio, a aprovao das definies de processos, fluxos de informaes e atributos de entidades, no esquecendo de nenhum passo da metodologia usada, proporcionando alto nvel de documentao. As ferramentas CASE se dividem em 3 tipos: Integrated System CASE (I-CASE) , que visam desde a anlise/projeto at a gerao do cdigo. Tentam abranger tudo, porm "superlota" uma etapa com vrios tipos de sub-ferramentas com a inteno de abranger vrias metodologias. Case's de automao de uma fase(ou mais) de desenvolvimento, so ferramentas que se prendem a uma etapa do desenvolvimento tal como ferramentas de modelagem de dados(modelo de dados) e ferramentas de testes (testes do sistema). Ferramentas que seguem uma metodologia especifica, tal como antigo Composer By IEF que seguia a engenharia da informao. O prprio Rational Rose, segue como linha base a Orientao a Objetos.

26

5.2 Vantagens

Citamos algumas vantagens com a utilizao de Ferramentas CASE Maior qualidade dos produtos finais: as ferramentas CASE diminuem a probabilidade de erros, uma vez que podem ajudar no controle de consistncia dos dados em um ambiente de desenvolvimento, tambm proporcionam maior eficcia dos produtos, ao auxiliarem as fases de Anlise e Teste do produto pelo usurio; Produtividade: ao ajudar na realizao de tarefas e at mesmo ao realizar algumas automaticamente, as ferramentas contribuem para uma maior agilidade no desenvolvimento de software, isto , mais produtos em menos tempo; Eliminao de trabalho que muitas vezes no agregam valor ao produto final: as ferramentas CASE podem realizar algumas tarefas cansativas para os desenvolvedores, tais como procurar informaes e desenhar smbolos de um diagrama, as quais so mais sucetveis ao erro; Mais tempo para a tomada de deciso: em conseqncia de as ferramentas realizarem certas atividades pelas pessoas, estas ficam liberadas para outras tarefas, geralmente mais nobres, que exigem tomada de deciso e criatividade, ao invs de tarefas repetitivas; Flexibilidade para mudanas: as ferramentas permitem que sejam mudados dados e diagramas de maneira mais rpida e fcil, o que ajuda o desenvolvedor no trabalho de tentar satisfazer o usurio; Menos programao: as ferramentas eliminam muito tempo do trabalho de programao, deixando mais tempo para que a equipe tcnica se preocupe

27 com a Anlise do Sistema, que onde se define como solucionar o problema do usurio; Melhor documentao: por armazenarem dados e diagramas, as

ferramentas tambm contribuem para uma melhor documentao do sistema, agilizando relatrios, busca de informaes e alteraes; Manuteno mais fcil e gil: por conseqncia do item anterior, possvel ter mais informaes sobre o software na hora de realizar sua manuteno (correo, atualizao ou expanso). As Ferramentas Case nos auxiliam em todas as fases do projeto, portanto seu uso de extrema importncia, considerando suas vantagens no vemos outra sada para um projeto bem desenvolvido e documentado.

5.3 Aceitao no Mer cado

A aceitao de ferramentas CASE ocorreu com diagramas como o DFD e o E-R, que s foram amplamente utilizados quando surgiram as primeiras ferramentas para auxiliar na tarefa de diagramao. Hoje em dia, h tambm a difuso do termo I-CASE, que usado para caracterizar um grupo de ferramentas CASE integradas, isto , que se relacionam entre si (entradas e sadas) e que permitem controlar a consistncia dos dados quando seguimos uma metodologia.

28

5.4 O Futuro

Podemos dizer que as ferramentas CASE, evoluiro no de uma forma fechada, mas de uma forma aberta de maneira que as mesmas cada vez mais se integraro com outras ferramentas de fabricantes distintos. A palavra de ordem dos CASE's de amanh diversidade e especializao. O conceito de CASE's apenas se transformou. O conceito de CASE de amanh nasceu hoje. Ou melhor, sofreu uma mutao mercadolgica dado o poder dos fabricantes. Entender o conceito importante, mas entender a evoluo do mesmo tambm importante.

5.5 Rational Rose

Rational Rose uma ferramenta CASE para desenvolvimento de sistemas orientados a objetos, sendo tambm, um repositrio para os produtos gerados por processos de anlise e projetos orientados a objetos. Ela acelera esse desenvolvimento de anlise e projetos utilizando metodologias de desenvolvimento muito difundidas no meio da informtica, principalmente o padro Unified Modeling Language (UML). O padro UML o mais utilizado hoje em dia, pois com ele h uma documentao interativa e automtica dos processos de modelagem, sendo tambm possvel a gerao, pela ferramenta, de cdigos a partir da mesma modelagem. As verses mais novas ferramenta contemplam at a interao com ambientes de desenvolvimento das mais variadas linguagens existentes no mercado [DBSERVER, 2001].

29 Por quatro anos consecutivos o IDC nomeou a Rational Rose como a ferramenta principal de projeto e de construo baseada em anlise orientada a objetos [DBSERVER, 2001]. Segundo RATIONAL, a ferramenta Rational Rose uma soluo completa para [2001]: Empresas e Analistas de Sistemas : Permite analistas visualizar e modelar processos de empresas e requisitos de sistemas. Projetos : Permite projetar modelos de sistemas baseados em UML mantendo o sincronismo entre o cdigo e o projeto. Modelagem de Banco de Dados e Anlise : Oferece em uma nica ferramenta linguagem e notao para toda a equipe. Desenvolvedores Web : Fornece suporte a XML, Java, EJB. Permite visualizar a arquitetura da Web de forma compreensiva, at mesmo sites mais complexos. Desenvolvedores UNIX : Suporta a interoperabilidade completa entre UNIX e Windows, oferece aos usurios UNIX a mesma interface do usurio Windows e suporta os mesmos formatos de compartilhar modelos e projetos de desenvolvimento. Para todos : O modelo integrado permite melhor o desempenho da equipe de desenvolvimento. Conhecendo mais profundamente seus algoritmos, ir gerar um bom resultado ao final do projeto. arquivo, permitindo

Captulo 6 - VISES DE SISTEMAS

6.1 Conceito

O desenvolvimento de um sistema complexo no uma tarefa fcil. O ideal seria que o sistema inteiro pudesse ser descrito em um nico grfico e que este representasse por completo as reais intenes do sistema sem ambigidades, sendo facilmente interpretvel [Barros, 2001]. Um sistema composto por diversos aspectos: funcional (que sua estrutura esttica e suas interaes dinmicas), no funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo, etc.). Descrevemos um sistema em vrias vises, cada viso mostra alguma particularidade do sistema e esto em alguns de diagramas. Algumas vises esto interligadas atravs de diagramas, podendo uma viso fazer parte de uma ou mais vises. Os diagramas que compem as

31 vises contm os modelos de elementos do sistema. A Figura 6.1 apresenta as cinco vises de sistemas.

Figura 6.1 : Vises de Sistemas

6.2 Viso USE-CASE

Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usurios). A viso use-case central, j que seu contedo base do desenvolvimento das outras vises do sistema. Essa viso montada sobre os diagramas de use-case e eventualmente diagramas de atividade.

6.3 Viso Lgica

Descreve como a funcionalidade do sistema ser implementada. feita principalmente pelos analistas e desenvolvedores. Em contraste com a viso use-case, a viso lgica observa e estuda o sistema internamente. Ela

32 descreve e especifica a estrutura esttica do sistema (classes, objetos, e relacionamentos) e as colaboraes dinmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funes do sistema. Propriedades como persistncia e concorrncia so definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura esttica descrita pelos diagramas de classes e objetos. O modelamento dinmico descrito pelos diagramas de estado, seqncia, colaborao e atividade.

6.4 Viso de Compon entes

uma descrio da implementao dos mdulos e suas dependncias. principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas.

6.5 Viso de concorr ncia

Trata a diviso do sistema em processos e processadores. Este aspecto, que uma propriedade no funcional do sistema, permite uma melhor utilizao do ambiente onde o sistema se encontrar, se o mesmo possui execues paralelas, e se existe dentro do sistema um gerenciamento de eventos assncronos. Uma vez dividido o sistema em linhas de execuo de processos concorrentes (threads), esta viso de concorrncia dever mostrar como se d a comunicao e a concorrncia destas threads. A viso de concorrncia suportada pelos diagramas dinmicos, que so os diagramas

33 de estado, seqncia, colaborao e atividade, e pelos diagramas de implementao, que so os diagramas de componente e execuo.

6.6 Viso de Organiza o

Finalmente, a viso de organizao mostra a organizao fsica do sistema, os computadores, os perifricos e como eles se conectam entre si. Esta viso ser executada pelos desenvolvedores, integradores e testadores, e ser representada pelo diagrama de execuo.

Captulo 7 - MODELOS DE ELEMENTOS

7.1 Definio

Os conceitos usados nos diagramas so chamados de modelos de elementos [Barros, 2001]. Um modelo de elemento definido com a semntica, a definio formal do elemento com o exato significado do que ele representa sem definies duvidosas ou ambguas e tambm define sua representao grfica que mostrada nos diagramas da UML. Um elemento pode existir em diversos tipos de diagramas, mas existem regras que definem quais elementos podem ser mostrados em que tipos de diagramas. Alguns exemplos de modelos de elementos so as classes, objetos, estados, pacotes e componentes. Os relacionamentos tambm so modelos de elementos, e so usados para conectar outros modelos de elementos entre si.

35

7.2 Classes

As classes so os blocos de construo mais importantes de qualquer sistema orientado a objetos [Booch, 2000]. Uma classe uma descrio de um conjunto de objetos que compartilham os mesmo atributos, operaes, relacionamentos e semntica. Podem ser implementadas em uma ou mais interfaces. Todos os objetos so instncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que possuir a relao de atributos que a classe possui em sua estrutura interna, e o compartimento de operaes, que sero os mtodos de manipulao de dados e de comunicao de uma classe com outras do sistema(ver Figura 7.1). A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem de programao, embora pode ser usadas outras sintaxes como a do C++, Java, e etc.

36

Figura 7.1 : Classes

7.2.1 Nomes
Todas as classes devem ter um nome que as diferencie das demais. Usamos uma seqncia de caracteres para identific-las. Uma classe pode ter um nome simples, ou com caminho como mostra a Figura 7.2. O caminho identifica o pacote ao qual a classe pertence.

37

Figura 7.2 : Nomes

7.2.2 Atributos
Um atributo uma propriedade de uma classe, que descreve um intervalo de valores que as instncias da propriedade podem apresentar. Uma classe pode ter qualquer nmero de atributos ou nenhum. Um atributo representa o tipo de dados ou estados que cada item de uma classe pode assumir, so representados logo aps o nome da classe (veja Figura 7.3).

38

Figura 7.3 : Atributos

7.2.3 Operaes
Operaes so os processos que a classe pode realizar. Operaes correspondem claramente a mtodos em uma classe. No nvel de especificao, as operaes correspondem a mtodos pblicos. Normalmente, voc no mostra as operaes que simplesmente manipulam atributos, porque elas podem ser freqentemente inferidas. Entretanto, voc poder ter que identificar seu um dado atributo somente para leitura(isto , o seu valor nunca muda). No modelo de implementao, voc tambm pode querer mostrar operaes privativas(private) e protegidas(protected). Uma classe pode ter vrias operaes ou at mesmo nenhuma, so representadas logo aps os atributos (veja Figura 7.4).

39

Figura 7.4 : Operaes

7.3 Objetos

Os objetos so elementos que podemos manipular, acompanhar seu comportamento, criar, interagir com ele, ou at destrui-lo. Um objeto pode existir no mundo real ou pode ser uma derivao de estudos da estrutura e comportamento de outros objetos do mundo real. Corresponde a qualquer coisa que tenha algum significado para uma dada aplicao [Mazzola, 1999].Por exemplo, uma mquina, uma organizao, ou negcio. Em UML um objeto mostrado como uma classe s que seu nome sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da classe, conforme mostra a Figura 7.5.

40

Figura 7.5 : Objetos

7.4 Estados

Um estado uma condio ou situao na vida de um objeto durante a qual o objeto satisfaz alguma condio, realiza alguma atividade ou aguarda um evento [Booch, 2000]. Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, normalmente este estado determinado pelos valores dos atributos e ligaes com outros objetos. Um objeto muda de estado quando acontece algo, o fato do objeto alterar o seu estado chamamos de evento. Analisando as mudanas de estado que um objeto pode sofrer, podemos prever todos os possveis comportamento de um objeto de acordo com os eventos que o mesmo possa sofrer. Um estado pode ter trs compartimentos (veja Figura 7.6): Nome do Evento, Atributos e Atividades.

41 Nome do Evento - mostra o nome do evento, geralmente este nome descreve o que este estado realiza; Atributos mostra as variveis de estado, onde os atributos do objeto em questo pode ser listados e atualizados; Atividades o compartimento de atividades onde podemos listar os eventos e aes. Est dividido em trs eventos padres : Entrar, Sair e Fazer. Entrar : usado para definir atividades no momento em que o objeto entra naquele estado; Sair : usado para definir atividades que o objeto executa antes de passar para o prximo estado; Fazer : usado para definir atividades que o objeto executa enquanto se encontra naquele estado.

Figura 7.6 : Estados

42

7.5 Pacotes

Pacote um mecanismo de propsito geral para organizar elementos de modelo em grupos, podendo, inclusive, estar aninhando dentro de outros pacotes(pacotes subordinados) [Furlan, 1998] (ver Figura 7.7). Todos os modelos de elementos que so ligados ou referenciados por um pacote so chamados de "Contedo do pacote". Um pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em outros pacotes.

Figura 7.7 : Pacotes

Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de elemento importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes no possuam semnticas definidas para suas instncias. Os relacionamentos permitidos entre pacotes so de dependncia, refinamento e generalizao (herana).

43 O pacote tem uma grande similaridade com a agregao. O fato de um pacote ser composto de modelos de elementos cria uma agregao de composio. Se este for destrudo, todo o seu contedo tambm ser.

7.6 Componentes

Um componente pode ser tanto um cdigo em linguagem de programao como um cdigo executvel j compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java ou .class um componente do sistema, e ser mostrado no diagrama de componentes que os utiliza. Veja na Figura 7.8 a representao de componentes.

Figura 7.8 : Componentes

7.7 Relacionamentos

Os relacionamentos ligam classes/objetos entre si criando relaes lgicas entre estas entidades [Barros, 2001]. Possumos trs tipos de relacionamentos: associao, generalizao e Dependncia/Refinamentos.

44 Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados. Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido. Dependncia e Refinamentos: Dependncia um relacionamento entre elementos, um independente e outro dependente. Uma modificao um elemento independente afetar diretamente elementos dependentes do anterior. Refinamento um relacionamento entre duas descries de uma mesma entidade, mas em nveis diferentes de abstrao.

7.7.1 Associaes
Associao uma relao que descreve um conjunto de vnculos entre elementos de modelo [Furlan, 1998].Representa a ligao entre classes ou objetos de classes, podendo ambas conhecer-se. Uma associao definida em UML como relacionamento.

7.7.1.1 Associaes Norm ais

O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao

45 possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos. Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um nome para cada sentido da associao (ver Figura 7.9). Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos esto relacionados na ligao. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrito nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).

Figura 7.9 : Associaes Normais

7.7.1.2 Associaes Recu rsivas

Podemos conectar uma classe a ela mesma, usando uma associao recursiva, e ainda podemos representar a conexo entre dois objetos, sendo os mesmos da mesma classe, conforme mostra a Figura 7.10.

46

Figura 7.10 : Associaes Recursiva

7.7.1.3 Associaes Quali ficadas

Associaes qualificadas so usadas com associaes de um para vrios (1..*) ou vrios para vrios (*). O "qualificador" (identificador da associao qualificada) especifica como um determinado objeto no final da associao "n" identificado, e pode ser visto como um tipo de chave para separar todos os objetos na associao. O identificador desenhado como uma pequena caixa no final da associao junto classe de onde a navegao deve ser feita (ver Figura 7.11).

Figura 7.11 : Associaes Qualificadas

7.7.1.4 Associaes Exclu sivas

Podemos encontrar em alguns modelos combinaes no vlidas. Uma associao exclusiva uma restrio em duas ou mais associaes. Ela especifica que objetos de uma classe podem participar de no mximo uma das associaes em um dado momento. Uma associao exclusiva representada

47 por uma linha tracejada entre as associaes que so parte da associao exclusiva, com a especificao "{ou}" sobre a linha tracejada.

Figura 7.12 : Associaes Exclusivas

Conforme figura 7.12 um contrato no pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento exclusivo a somente uma das duas classes.

7.7.1.5 Associaes Orden adas

As associaes entre objetos podem ter uma ordem implcita. O padro para uma associao desordenada ou seja no possui uma ordem especfica. Podemos resolver este problemas usando a associao ordenada, ajudando pois existem casos que a ordem precisa estar concisa para o entendimento da associao. Podemos escrever est associao apenas como {ordenada} junto a linha da associao.

7.7.1.6 Associaes de Cl asse

Uma classe pode ser associada a uma outra associao. Este tipo de associao no conectada a nenhuma das extremidades da associao j existente, mas na prpria linha da associao. Esta associao serve para se adicionar informaes extra a associao j existente (ver Figura 7.13).

48

Figura 7.13 Associaes de Classe

A associao da classe Fila com a associao das classes Cliente e Processo pode ser estendida com operaes de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho. Se operaes ou atributos so adicionados associao, ela deve ser mostrada como uma classe.

7.7.1.7 Associaes Tern rias

A associao ternria e a associao entre trs classes. Ela mostrada como um grade losango (diamante) e ainda suporta uma associao de classe ligada a ela, traaria-se, ento, uma linha tracejada a partir do losango para a classe onde seria feita a associao ternria.

Figura 7.14 : Associaes Ternrias

Conforme mostra a Figura 7.14 a associao ternria especifica que um cliente poder possuir 1 ou mais contratos e cada contrato ser composto de 1 ou vrias regras contratuais.

49

7.7.1.8 Agregao
A agregao uma caso particular da associao, indica que uma das classes do relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para identificar uma agregao so: "consiste em", "contm", " parte de" (ver Figura 7.15).

Figura 7.15 : Agregao

Existem tipos especiais de agregao que so as agregaes compartilhadas e as compostas. Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou est contida na outra, mas esta parte pode estar contida na outra vrias vezes em um mesmo momento (ver Figura 7.16).

Figura 7.16 : Agregao Compartilhada

Agregao de Composio: uma agregao onde uma classe que est contida na outra "vive" e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de composio sero destrudas juntamente j que as mesmas fazem parte da outra (ver Figura 7.17).

Figura 7.17 : Agregao de Composio

50

7.7.2 Generalizaes
Um relacionamento de taxinomia entre um elemento mais geral e um elemento mais especfico que completamente consistente com o primeiro elemento somando-o informao adicional especializado [Furlan, 1998]. Um objeto mais especfico pode ser usado como uma instncia do elemento mais geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados em outros. Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta.

7.7.2.1 Generalizao Nor mal

Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse (ver Figura 7.18). Os atributos, operaes e todas as associaes so herdadas.

Figura 7.18 : Generalizao Normal

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes. A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que coloca-se uma seta no lado da linha onde encontra-se a superclasse indicando a generalizao.

51

7.7.2.2 Generalizao Res trita

Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem as generalizaes restritas com mais de uma subclasse: Generalizaes de Sobreposio e Disjuntiva: Generalizao de

sobreposio significa que quando subclasses herdam de uma superclasse por sobreposio, novas subclasses destas podem herdar de mais de uma subclasse (ver Figura 7.19). A generalizao disjuntiva exatamente o contrrio da sobreposio e a generalizao utilizada como padro.

Figura 7.19 : Generalizao de Sobreposio

Generalizaes Completa e Incompleta: Uma restrio simbolizando que uma generalizao completa significa que todas as subclasses j foram especificadas, e no existe mais possibilidade de outra generalizao a partir daquele ponto (ver Figura 7.20). A generalizao incompleta exatamente o contrrio da completa e assumida como padro da linguagem.

52

Figura 7.20 : Generalizao Completa

7.7.3 Dependncias e Re finamentos

Uma dependncia indica a ocorrncia de um relacionamento semntico entre dois ou mais elementos do modelo onde uma classe cliente dependente de alguns servios da classe fornecedora, mas no tem uma dependncia estrutural interna com esse fornecedor [Furlan, 1998]. Uma mudana no elemento independente ir afetar o modelo dependente. Como no caso anterior com generalizaes, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante. Quando uma classe recebe um objeto de outra classe como parmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependncia entre estas duas classes, apesar de no ser explcita. Uma relao de dependncia simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de dependncia que existe entre as duas classes. Conforme mostra a figura 7.21, as classes "Amigas" provenientes do C++ so um exemplo de um relacionamento de dependncia.

Figura 7.21 : Relao de Dependncia

53 Os refinamentos so um tipo de relacionamento entre duas descries de uma mesma coisa, mas em nveis de abstrao diferentes e podem ser usados para modelar diferentes implementaes de uma mesma coisa (uma implementao simples e outra mais complexa, mas tambm mais eficiente). Os refinamentos so simbolizados por uma linha tracejada com um tringulo no final de um dos lados do relacionamento e so usados em modelos de coordenao (ver Figura 7.22). Em grandes projetos, todos os modelos que so feitos devem ser coordenados. Coordenao de modelos pode ser usada para mostrar modelos em diferentes nveis de abstrao que se relacionam e mostram tambm como modelos em diferentes fases de desenvolvimento se relacionam.

Figura 7.22 : Refinamentos

7.8 Mecanismos Gera is

A UML utiliza alguns mecanismos em seus diagramas para tratar informaes adicionais. Ornamentos: ornamentos grficos so anexados aos modelos de elementos em diagramas e adicionam semnticas ao elemento. Um exemplo de um ornamento o da tcnica de separar um tipo de uma instncia. Quando um elemento representa um tipo, seu nome mostrado em negrito. Quando o mesmo elemento representa a instncia de um tipo,

54 seu nome escrito sublinhado e pode significar tanto o nome da instncia quanto o nome do tipo. Outros ornamentos so os de especificao de multiplicidade de relacionamentos, onde a multiplicidade um nmero ou um intervalo que indica quantas instncias de um tipo conectado pode estar envolvido na relao. Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem importar o quanto extensa ela seja. Para permitir adicionar informaes a um modelo no poderia ser representado de outra forma, UML prov a capacidade de adicionar Notas. Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informao (ver Figura 7.23).

Figura 7.23 : Ornamentos e Nota

Captulo 8 - DIAGRAMAS

8.1 Conceito

Quando voc faz modelagem, voc simplifica a realidade para um melhor entendimento do sistema em desenvolvimento. Em UML voc desenvolve seus modelos a partir de blocos distintos tais como : classes, interfaces, colaboraes, componentes, dependncias, generalizaes,

associaes, etc. Os diagramas so meios utilizados para visualizao de blocos de construo [Booch, 2000]. Os diagramas utilizados pela UML so compostos de nove tipos: diagramas de casos de uso, classes, objetos, estados, sequncia, colaborao, atividade, componentes e execuo. A seguir trataremos cada um destes tipos de diagramas. Os exemplos utilizados para apresentar os diagramas foram retirados de livros utilizados neste projeto e de material encontrado na internet.

56

8.2 Diagramas de Cas os de Uso

Um diagrama de caso de uso ilustra um conjunto de casos de uso para um sistema, os atores e a relao entre os atores e os casos de uso [Larman, 2000]. Os casos de uso so usados para modelar como um sistema ou empresa funciona, ou como os usurios desejam que ele funcione. Os casos de uso geralmente so o ponto de partida da anlise orientada a objetos utilizando a UML. O modelo de caso de uso consiste de atores e casos de uso. Os atores representam usurios e outros sistemas que interagem com sistema modelado. Eles so representados graficamente por um homem palito. Os casos de uso mostram o comportamento do sistema, cenrios que o sistema percorre em resposta ao estmulo de um ator. Eles so desenhados como elipses conforme mostra a Figura 8.1. No modelo de caso de uso o relacionamento entre um ator e um caso de uso representa a participao deste ator no caso de uso. Alm deste relacionamento, existe dois outros tipos de relacionamentos entre casos de uso: o relacionamento estender: representado graficamente por uma seta com o esteretipo <<extends>>, mostrando que o caso de uso destino pode incluir o comportamento especificado pelo caso de uso origem; o relacionamento usar: representado por uma seta com o esteretipo <<uses>>, mostrando que o caso de uso origem inclui o comportamento especificado pelo caso de uso destino.

57 A figura 8.1 mostra um diagrama de casos de uso.

Figura 8.1 : Diagramas de Casos de Uso

8.3 Diagramas de Cla sses

uma estrutura lgica esttica em uma superfcie de duas dimenses mostrando uma coleo de elementos declarativos de modelo,

como classes, tipos e seus respectivos contedos e relaes [Furlan, 1998] (ver Figura 8.2).

58 Uma classe em UML representada por uma caixa retangular com trs compartimentos: um com o nome da classe, o outro com a lista de atributos da classe e o ltimo com a lista de operaes da classe. As associaes representam relacionamentos estruturados entre objetos de diferentes classes, e so representados graficamente atravs de uma linha conectando as classes. Uma associao pode ter um nome. E as extremidades da linha que representa uma associao pode ter nome de papis mostrando como a classe vista pelas outras classes na associao. A multiplicidade de uma associao especifica quantas instncias de uma classe relacionam-se a uma nica instncia de uma classe associada. Uma multiplicidade representada por um intervalo de valores possveis, no seguinte formato: limite_inferior..limite_superior, onde esses limites so valores inteiros ( o caracter * pode ser usado como limite_superior para indicar falta de limite). A agregao uma forma especial de associao que representa o relacionamento todo-parte entre objetos. Ela representada incluindo-se um losango na extremidade do objeto todo do relacionamento todo-parte. A generalizao uma ferramenta poderosa para a abstrao. A generalizao um relacionamento existente entre uma classe mais geral(superclasse) e uma classe mais especfica(subclasse), onde a classe mais especfica consistente com a mais geral e adiciona informaes a ela. Uma generalizao representada por uma linha com um tringulo, que liga a classe mais especfica a mais genrica. Veja figura 8.2.

59

Figura 8.2 : Diagramas de Classes

8.4 Diagramas de Ob jetos

Os diagramas de objetos fazem a modelagem de instncias de itens contidos em diagramas de classes. Um diagrama de objetos mostra um conjunto de objetos e seus relacionamentos em determinado ponto no tempo. Estes diagramas no so importantes apenas para a visualizao,

especificao e documentao de modelos estruturais, mas tambm para a construo de aspectos estticos de sistemas por meio de engenharia de produo e engenharia reversa [Booch, 2000] (ver Figura 8.3). A UML permite a utilizao de diagramas de classes para uma visualizao dos aspectos estticos dos blocos de construo do sistema. Voc usa os diagramas de interao para visualizar os aspectos dinmicos de seu

60 sistema, formados por instncias desses blocos de construo e mensagens enviadas entre eles. Os diagramas de objetos cobrem um conjunto de instncias dos itens encontrados nos diagramas de classes. O diagramas de objetos, portanto, expressa a parte esttica de uma interao, composta pelos objetos que colaboram entre si, mas sem qualquer uma das mensagens passadas entre eles. Nos dois casos, o diagrama de objetos congela um momento no tempo. Os diagramas de objetos so usados para fazer a modelagem da viso de projeto esttica ou da viso de processo esttica de um sistema, da mesma forma como faz com os diagramas de classes, mas a partir da perspectiva de instncias reais ou prototpicas. Isso envolver a modelagem de um retrato do sistema em determinado momento e a representao de um conjunto de objetos, seus estados e relacionamentos. Essa viso atende principalmente aos requisitos funcionais do sistema ou seja, os servios que o sistema dever proporcionar aos seus usurios finais. Os diagramas de objetos permitem que voc faa a modelagem de estruturas de dados estticos.

Figura 8.3 : Diagramas de Objeto

61

8.5 Diagramas de Est ados

Os

diagramas

de

estados

so

usados

para

modelar

comportamento dinmico de um sistema. Mostram o ciclo de vida de um objeto em nveis de detalhe arbitrariamente simples ou complexos [Larman, 2000]. Visualizam a seqncia de estados que um objeto ou uma interao percorre durante sua vida em resposta a estmulos recebidos, junto com suas prprias aes e respostas conforme mostra a Figura 8.4. Por exemplo, o comportamento de um objeto modelado em funo de qual estado ele est inicialmente, e para qual estado ele vai passar quando um determinado evento ocorrer. Os estados representam as condies dos objetos em um determinado momento. Os eventos representam incidentes que causam a mudana de um estado para outro. As linhas de transio descrevem o movimento de um estado para o outro. Cada linha de transio rotulada com o evento que causou a transio.

62

Figura 8.4 : Diagramas de Estados

8.6 Diagramas de Seq ncia

Os diagramas de seqncias so usados para modelar a interao entre objetos em um sistema. Tipicamente, um diagrama de seqncia captura o comportamento de um nico caso de uso. O diagrama apresenta os objetos e as mensagens que so passadas entre estes objetos dentro do caso de uso, conforme mostra a Figura 8.5. Os objetos so representados por linhas tracejadas verticais, e a passagem de mensagens entre dois objetos so representados por vetores horizontais. As mensagens so desenhadas cronologicamente do topo base do diagrama.

63

Figura 8.5 : Diagramas de Seqncia

8.7 Diagramas de Col aborao

Os diagramas de colaborao uma outra alternativa para a modelagem de interaes entre objetos de um sistema. Diferentemente do diagrama de seqncia que focaliza na seqncia cronolgica do cenrio que est sendo modelado, o diagrama de colaborao focaliza no relacionamento entre os objetos e na compreenso dos efeitos sobre um objeto durante um cenrio. Os objetos so conectados atravs de associaes e cada associao representa uma instncia de associao entre as respectivas classes envolvidas. As associaes mostram as mensagens enviadas entre os objetos, e a seqncia destas mensagens determinada usando-se nmeros seqenciais (ver Figura 8.6). Uma Colaborao uma viso de um conjunto de elementos de modelagem relacionados para um propsito particular em apoio a interaes [Furlan, 1998].

64

Figura 8.6 : Diagramas de Colaborao

8.8 Diagramas de Ativ idade

Um diagrama de atividade essencialmente um grfico de fluxo, mostrando o fluxo de controle de uma atividade para outra [Booch, 2000] (ver Figura 8.7). Os diagramas de atividades so um caso especial de diagramas de estado, onde todos os estados tm uma ao interna e nenhuma transio tem um evento de entrada. O propsito de um diagrama de atividades focar nos fluxos dirigidos pelo processamento interno e descrever o comportamento de processamentos paralelos. Os diagramas de atividades so usados para detalhar classes, implementao de operaes e casos de uso, enquanto os diagramas de estado so usados para especificar o comportamento global de um tipo. Os diagramas de atividades representam o que acontece, mas no representam quem faz o que. Isso significa que o diagrama no diz qual classe responsvel por cada atividade. Os divisores contornam esse problema atravs da organizao das responsabilidades da atividades dentro de uma classe. Atravs dos divisores podemos separar as atividades de acordo com as classes responsveis por essas atividades. Os divisores so representados por linhas verticais tracejadas.

65

Figura 8.7 : Diagramas de Atividade

8.9 Diagramas de Com ponentes

Mostram dependncias entre componentes de software [Furlan, 1998]. Os diagramas de componentes representam, de forma esttica, aspectos fsicos do sistema sendo modelado. So importantes tanto para visualizar, especificar e documentar sistemas baseados em componentes quanto para construir sistemas atravs de engenharia reversa (reverse) e direta (forward). Eles mostram um conjunto de componentes e seus relacionamentos conforme mostra a Figura 8.8. So tipicamente usados para: Modelar a organizao do cdigo fonte; Modelar lanamento de executveis (verses); Modelar fisicamente um banco de dados; Modelar sistemas adaptativos; Engenharia de produo e engenharia reversa;

66

Figura 8.8 : Diagramas de Componentes

8.10 Diagramas de Imp lantao

Os diagramas de implantao so diagramas que mostram a configurao de ns de processamento em tempo de execuo e os componentes que neles existem (ver Figura 8.9). Os diagramas de implantao no so importantes somente para visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribudos, mas tambm para o gerenciamento de sistemas por engenharia de produo e engenharia reversa. Os diagramas de implantao so empregados para modelagem da viso esttica de implantao de um sistema. Essa viso direciona primariamente a distribuio, entrega e instalao das partes que formam o sistema fsico. Na maior parte, isso envolve a modelagem da topologia do hardware em que o sistema executado. Os diagramas de implantao so essencialmente diagramas de classes que focalizam os ns do sistema.

67

Figura 8.9 : Diagramas de Implantao

Captulo 9 - METODOLOGIA DESENVOLVIDA

9.1 Introduo

A UML uma linguagem para especificao, visualizao, documentao e construo que tornam possvel expressar modelos orientados a objetos. Porm no prescreve como o trabalho deve ser feito. A utilizao da UML em grandes projetos pode ajud-lo a tornar-se mais eficiente, mas para tal devemos adotar um mtodo de desenvolvimento. O mtodo de desenvolvimento adotado deve descrever um nmero de atividades a ser seguidas em uma determinada ordem. Para alcanar com xito nossos objetivos devemos ter bem definido a expectativa do projeto. Um mtodo tradicional de desenvolvimento orientado a objetos dividido em anlise de requisitos, anlise, projeto, implementao e teste [Barros, 2001], que uma viso tcnica do desenvolvimento. O RUP(Rational Unfied Process) um outro mtodo, desenvolvido pela Rational Inc. que

69 dividido em concepo, elaborao, construo e transio, que mostra uma viso mais gerencial do desenvolvimento [Booch,2000]. Ferramentas desenvolvimento de modernas sistemas devem da suportar linguagem um de mtodo modelagem de e

alm

programao. Um exemplo o Rational Rose da Rational Inc. que suporta bem tanto a linguagem quanto o mtodo de desenvolvimento. A partir deste ponto descreveremos nossa metodologia,

apresentando cada fase da metodologia detalhadamente. Tomaremos como base para desenvolvimento de nossa metodologia a viso tcnica da UML que divide-se em 5(cinco) etapas: Anlise de Requisitos, anlise, projeto, programao e testes. Ao final do desenvolvimento de cada fase sero feitas observaes que serviro de concluso e de base para futuros melhoramentos.

9.2 Documentao

Estabelecemos alguns procedimentos inicias, a fim de manter a documentao organizada. Esses procedimentos podem interagir com outras documentaes em outros projetos usando a mesma metodologia em plataformas diferentes.

9.2.1 Fonte
Na documentao ser exigido a confeco de alguns documentos, cujo os quais deve-se redigi-los corretamente para um bom entendimento. Para

70 uma melhor visualizao determina-se antes do incio do projeto o tipo e o tamanho da fonte, para que todos os documentos escritos tenham o mesmo aspecto. O tipo da fonte usada na documentao tem que ser bem definida, partindo do princpio que nem todos tero as mesmas ferramentas e que existem editores que no possuem determinadas fontes. Devemos nos preocupar em estabelecer uma fonte que toda a equipe envolvida e at mesmo pessoas no envolvidas naquele projeto possuam. Numa apresentao do projeto criado os documentos tem que ser facilmente visualizados. Quanto ao tamanho, fontes pequenas demais tornam a

documentao um pouco cansativa para ser lida, fontes grandes gerariam muitas folhas e tambm traria um aspecto desfigurado. O tamanho da fonte dever estar relacionada com o seu tipo, normalmente usamos o tamanho de 10 a 14.

9.2.2 Gravao da Docu mentao

Para que todos os envolvidos no projeto possam ter acesso documentao do projeto, e para uma melhor organizao e entendimento, devemos gravar todos os processos envolvidos com o projeto numa mesma pasta. Estas pastas devem estar identadas sempre abaixo de uma que englobe o projeto como um todo, ou at mesmo o nome do projeto. Cria-se uma pasta me com o nome do projeto e abaixo dela conforme a necessidade cria-se outras pastas filhas. Todas as pastas criadas devem sempre fazer relao com os arquivos que estaro armazenados na mesma.

71 Na confeco de um novo projeto pode-se copiar estas pastas para um outro local e renome-las. Faz-se necessrio uma reviso de todas as pastas para adequao com o novo projeto.

9.2.3 Extenso de Arqui vos

Na preocupao que nosso projeto possa se comunicar com outros ou at mesmo a juno dos mesmos, devemos estabelecer extenses de arquivos que possam ser abertas em qualquer plataforma, sistema operacional, editor, etc. Muito importante para uma boa definio deste item, saber quais sero os possveis editores usados, sistemas operacionais que os envolvidos no projeto possuem. Arquivos do tipo .txt seriam de bastante abrangncia, exceto no caso de criao de arquivos um pouco mais complexos, necessitando ferramentas com um pouco mais de recursos, pois arquivos com este tipo de extenso podem ser abertas em muitas plataformas. Se houver realmente a necessidade de criao de arquivos com recursos um pouco mais complexos que os .txt (modo caracter), procurar usar extenses de arquivos que abram na grande maioria dos editores.

9.2.4 Impresso
Para que todos os documentos, diagramas, etc., que vierem a ser gerados e impresso no projeto possam ser bem visualizados e arquivados, devemos definir anteriormente um tamanho de papel padro. As margens podem ser configuradas de acordo com a necessidade, pois dentro do projeto haver diagramas que necessitaro de margens um

72 pouco menores ou maiores devido a sua complexidade. Sendo que para sua melhor visualizao s vezes necessrio o uso do papel at sua extremidade.

9.2.5 Backup
Deve-se criar um sistema de backup, sugerindo um responsvel pela execuo do mesmo, para que no haja surpresas no decorrer do projeto, como perdas de dados. Ocasionando atraso na concluso do projeto, alterando as datas as quais a equipe se submeteu a cumprir. A periodicidade dos backups depende do envolvimento da equipe e das informaes armazenadas diariamente, se houver necessidade pode-se realizar os backups diariamente, semanalmente ou mensalmente. Criaremos um formulrio sugesto que envolve todos os

procedimentos da documentao, conforme anexo 01.

9.2.6 Controle de Verse s

Desejamos com o controle de verses que os desenvolvedores possam manter o sistema atualizado de acordo com sua documentao. Serve tambm para diferenciar um software dele mesmo, porm qualquer tipo de alterao feita ser registrada uma nova verso do software. Uma verso dever ser representada de modo a controlar desde pequenas alteraes at novas funcionalidades e/ou grandes alteraes que mudem a funcionalidade do sistema. Sugerimos a representao da verso em seqncias de trs blocos de caracteres (N.NX-NN) onde : N um caracter numrico no intervalo de 1 a 9;

73 NX : N um caracter numrico no intervalo de 1 a 9; X um caracter alfanumrico no intervalo de A-Z; NN so caracteres numricos no intervalo de 01 a 99; Os dois primeiros caracteres (N.N) representam a verso principal. Somente so alterados quando se tratar de grandes modificaes e/ou inovaes, como por exemplo : troca de linguagem, incluso de novo mdulo no sistema, troca ou incluso de nova plataforma. O terceiro caracter (X) destinado a alteraes de mdio porte e/ou incluso de novas rotinas, como por exemplo : cadastros, relatrios, lanamentos, consultas. Nos dois ltimos caracteres (NN) registramos pequenas alteraes e correes em rotinas j existentes no sistema, como por exemplo : alteraes de relatrios, consultas, cadastros, etc.

9.3 Eventos Iniciais

Aps concludo o item documentao, trataremos alguns eventos que ocorrem antes da anlise de requisitos. Trata-se de eventos iniciais de extrema importncia para um bom desenvolvimento da anlise de requisitos, onde so feitos os primeiros contatos, um estudo dos dados e definio de possveis envolvidos no projeto.

74

9.3.1 Contatos
Um determinado usurio faz um contato solicitando o

desenvolvimento de um software. Este contato pode ser de forma mais varivel possvel: Fone, Fax, email, pessoal, etc. A empresa ou pessoa que recebeu o contato, solicita ao usurio, ou acompanha o mesmo no preenchimento de um formulrio padro. Trata-se de um formulrio que servir para registrar a solicitao do usurio e tambm para a convocao de algumas pessoas para uma possvel reunio a qual ser marcada. Como trata-se de algo bem genrico, atravs deste formulrio ainda no se sabe com certeza quem ser envolvido no sistema. Define-se tanto os participantes por parte do usurio quanto da empresa de desenvolvimento de software. Este formulrio dever ser preenchido em meio

magntico(aconselhvel) ou papel, este ltimo depois de preenchido ser transformado em meio magntico. Criaremos um formulrio sugesto que contm todos os itens necessrios para registrar um contato, conforme anexo 02.

9.3.2 Estudo dos Dados

Tratando-se de um desenvolvimento de um novo software ser analisado: Aps uma anlise da rea de negcio, concluindo-se que a empresa no pode atender a solicitao, ser retornado ao mesmo que trata-se de uma rea de negcio a qual a empresa no oferece solues. Esta resposta

75 tambm poder ser dada no momento do preenchimento do formulrio padro, dependendo de quem e da capacidade do atendente. A rea de negcio da solicitao abrangida pela empresa, ento ser feita uma avaliao sobre a descrio e com base nesta avaliao e na rea de negcio, sero convocados para uma reunio os possveis envolvidos no projeto, tanto por parte do solicitante, quanto por parte da empresa desenvolvedora.

9.3.3 Definio dos Part icipantes

A definio dos participantes deve sempre girar em torno da rea de negcio e da descrio, pois ali que contm alguns conceitos bsicos que podem ajudar os responsveis a convocar as pessoas certas para definir os possveis participantes. Nesta definio procura-se envolver todos que de alguma forma podero contribuir para o projeto de ambas as partes. Logicamente de acordo com o andamento do projeto sero filtrados, ficando apenas aqueles que podem contribuir para o bom desenvolvimento do projeto. Aps definir todos os participantes da reunio, ser marcada a data da mesma e os envolvidos sero convocados. At este ponto trata-se de um evento que antecede as fases da metodologia de desenvolvimento de sistemas.

76

9.4 Anlise de requis itos

Esta fase a base do projeto, dever ser bem elaborada para um bom desenvolvimento das demais fases. Sero abordados itens necessrios para a concepo do projeto, definio de equipe envolvida e tambm alguns itens tcnicos como: atores, casos de uso, diagrama de casos de uso e anlise de riscos.

9.4.1 Reunio/Entrevista
Nas reunies, das quais as pessoas convocadas a participar, no existe nenhuma hierarquia. Todos os participantes, sejam eles analistas, gerentes, diretores ou escriturrios, devem se posicionar livremente, pois se foram convidados a participar porque tm alguma contribuio a dar com o seu conhecimento especfico no assunto objeto da reunio. Em uma situao normal, a hierarquia funciona como um agente inibidor e a opinio da pessoa de nvel mais alto prevaleceria sobre as demais, sem nenhuma garantia de que fosse a mais indicada. Para dar incio a comunicao entre os participantes, Gause e Weinberg sugerem que o analista comece fazendo perguntas de livre contexto, concentrando-se no cliente, nas metas globais e nos benefcios. Por exemplo, o analista poderia perguntar : Quem est por trs do pedido deste trabalho? Quem usar a soluo? Qual o benefcio econmico de uma soluo bem-sucedida? H outra fonte para a soluo exigida?

77 Em seguida, o analista pode fazer perguntas que o ajudaro na compreenso do problema e ter uma idia da soluo: Como voc caracteriza um "bom" resultado(sada) que seria gerado por uma soluo bem-sucedida? Qual o(s) problema(s) essa soluo resolver? Voc poderia mostrar-me(ou descrever-me) o ambiente que a soluo ser utilizada? Existem questes de desempenho ou restries especiais que afetaro a maneira pela qual a soluo abordada? Por fim, o analista far perguntas decisivas, que concentram-se na efetividade da reunio: Voc a pessoa certa para responder a essas perguntas? Suas respostas so "oficiais"? Minhas perguntas so pertinentes ao problema que voc tem? Estou fazendo perguntas demais? H mais algum que possa fornecer informaes adicionais? Existe algo mais que eu possa perguntar-lhe? Uma abordagem coleta de exigncias orientadas a equipes aplicada durante as primeiras etapas de anlise e especificao a FAST(Facilitaded Application Specification Techniques). Essa abordagem estimula a criao de uma equipe conjunta de clientes e desenvolvedores que trabalhem juntos para identificar o problema, propor elementos de soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos de soluo. Hoje, a FAST usada predominantemente pela

78 comunidade de sistemas de informao, mas a tcnica oferece potencial para uma melhor comunicao em aplicaes de todos os tipos. Outra abordagem especializada de entrevista que pode ser usada o JAD(Joint Application Development). Consiste numa rpida entrevista e um processo acelerado de coleta de dados em que todos os principais usurios e o pessoal da anlise de sistemas agrupam-se em uma nica e intensiva reunio(que pode prolongar-se de um dia a uma semana) para documentar os requisitos do usurio. A reunio costuma ser supervisionada por um especialista treinado que atua como mediador para encorajar melhores comunicaes entre os analistas de sistemas e os usurios. Esses mtodos citados possuem suas diferenas, mas todos tem alguns princpios bsicos : Um encontro levado a efeito num local neutro e participam

desenvolvedores e clientes; Usam-se regras para preparao e participao; Uma agenda formal para captar os pontos importantes, agindo de forma livre o suficiente para encorajar o fluxo de idias e sugestes; Um moderador (Cliente, Desenvolvedor ou algum de fora) para controlar a reunio; Utilizao de um mecanismo de definio que pode ser uma planilha, um cavalete, adesivos de parede ou cartazes; Identificao do problema, propor elementos de soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos de soluo num clima que facilite a realizao da atividade.

79

9.4.2 Preenchimento da ata da reunio

Nesta primeira reunio aparecero muitas idias sobre como se deve comportar o sistema ou o que ele deve atingir. Todas as idias devem ser includas na ata pois sero a partir delas que ser dado o start no projeto. A ata da reunio dever ser compostas de alguns elementos essenciais . Criaremos um formulrio sugesto que contm todos os elementos essenciais, conforme anexo 03.

9.4.3 Definies de resp onsabilidades

Aqui definiremos a responsabilidade de cada um dos envolvidos no projeto. Coordenador da equipe: Responsvel pelo andamento do Projeto.

9.4.4 Resumo do Projeto

Um texto geral sobre o sistema que ser desenvolvido. Neste texto ser descrito as principais caractersticas e funcionalidades do sistemas. Tambm ser descrita a abrangncia de todo o Projeto, com quem interage e por quem interagido(isto pode ser representado por diagramas de casos de uso) . Discriminar alguns requisitos mnimos para um bom funcionamento do projeto tambm faz parte deste resumo, tais como equipamentos, fontes de dados, ambiente de trabalho, etc. Cria-se um arquivo com o nome do sistema cujo o resumo faz referncia.

80

9.4.5 Atores
Atores so usurios e/ou outros meios externos que desenvolvem algum papel em relao ao sistema. Os meios externos so hardwares e/ou softwares que, assim como os usurios, geram informaes para o sistema ou necessitam de informaes geradas a partir do sistema. Existem atores que podem desempenhar mais de um papel no sistema, quando se pensar em atores sempre bom pensar neles como papis em vez de pensar como pessoas, cargos, mquinas. No sistema podem ter usurios com diferentes permisses, para isto necessrio criar um ator para cada diferente tipo de permisses. Os atores so quem desempenham os casos de uso, um mesmo ator pode estar em um ou mais casos de uso. Cada ator deve possuir um nome cujo ter relao direta com a sua funo, possuir uma descrio que definir o que ele faz e com quem ele interage. Criaremos um formulrio sugesto para listar os atores do sistema, conforme anexo 04.

9.4.6 Casos de Uso

Antes da definio de casos de uso, devemos ter definidos os atores e ter a idia da funcionalidade do sistema, a partir disto, comearemos a definir os casos de uso. Casos de uso especificam o comportamento do sistema ou parte(s) dele e descrevem a funcionalidade do sistema desempenhada pelos atores. Voc pode imaginar um caso de uso como um conjunto de cenrios, onde cada

81 cenrio uma seqncia de passos a qual descreve uma interao entre um usurio e o sistema. Os casos de uso so representados em forma de elipse. No deve-se detalhar muito um determinado caso de uso, o seu detalhamento vai depender do risco que o mesmo corre, quanto maior o risco, mais detalhes ter o caso de uso. Ao definir os casos de uso a serem desenvolvidos, trate apenas dos casos de usos mais crticos para o sistema, os casos de uso que so tarefas rotineiras no precisam ser desenvolvidos. Dessa forma sua documentao no se tornar montona. Numericamente falando, em modo geral trate apenas de 10 20(%) dos casos de uso mais crticos de seu sistema, estes nmeros citados claro que podem variar dependendo do sistema a ser desenvolvido. Os nomes dos casos de usos devemos sempre usar verbos, pois assim facilitar no entendimento dos mesmos. Devemos possuir uma lista com todos os nomes dos casos de usos para facilitar na identificao dos mesmos. Preencher todos os requisitos de um caso de uso de extrema importncia. Criaremos um formulrio sugesto para listar os casos de uso, conforme anexo 05. Tambm criaremos outro formulrio sugesto contendo todos os requisitos de uma caso de uso, conforme anexo 06.

9.4.7 Escopo
Uma viso grfica do sistema, mostrando a idia geral do sistema como ele ir interagir com o mundo externo. Esta viso transformao de funcionalidades, interao e abrangncia descritos no resumo do projeto para uma representao grfica. Deve-se usar os atores e casos de uso.

82

9.4.8 Diagrama de caso de uso

O diagrama de caso de uso um ponto importante de comunicao entre a equipe de desenvolvimento e o usurio, portanto dever ser de fcil entendimento. Sua definio deve deixar bem transparente a idia do sistema. Nos diagramas de casos de uso ilustramos conjuntos dos casos de uso do sistema, os atores e a relao entre os atores e os casos de uso. Devemos definir o nome do diagrama de caso de uso sempre relacionado-o com o seu propsito. Ento relacionamos os casos de uso de uma determinada parte ou de todo o sistema e os relacionamos com seus respectivos atores. Deve-se documentar cada diagrama desenvolvido

observando alguns itens importantes como: nome do diagrama, descrio, atores e casos de uso relacionados. Criaremos um formulrio sugesto que contm todos os itens de diagrama de caso de uso, conforme anexo 07.

9.4.9 Anlise de riscos

Em todo projeto surgem vrias incertezas, devemos considerar algumas mais crticas, estas devero ser tratadas com mais importncia, pois podero comprometer todo o desenvolvimento do sistema. Dentre elas podemos citar as mais crticas e que geralmente ocorrem na maioria dos projetos: Est realmente claro a importncia deste projeto? Baseado nos casos de uso, tem-se condies de implementar as funes dentro prazo previsto? Analisar os problemas tcnicos que podero ocorrer ao longo do projeto.

83 Caso encontre problemas, estes sero resolvidos de forma que no altere o cronograma do projeto? Os requisitos foram bem definidos de modo que se ocorrerem eventuais mudanas, estas no geraro alteraes considerveis no tempo e nem nos custos de desenvolvimento? Empenho dos envolvidos no projeto, todos que se comprometeram realmente iro participar? A anlise de riscos uma tarefa de grande importncia no gerenciamento de um projeto de software, embora, em muitos casos, esta atividade nem seja considerada. O seu objetivo determinar um conjunto de passos a serem seguidos para determinar os riscos envolvidos no projeto: identificao, avaliao, classificao, definio de estratgias para administrar os riscos, resoluo dos riscos, etc...

9.4.10 Cronograma
Os cronogramas so metas que devem ser atingidas, definindo prazos nos quais os envolvidos devero empenhar-se na execuo de suas atividades para o cumprimento dos mesmos. Dever ser criada uma representao (grfico ou tabela) que exprima o tempo dedicado a cada tarefa, determinando assim o prazo final do projeto. Criaremos um formulrio sugesto que contm todos os itens para um correto preenchimento de um cronograma, conforme anexo 08.

84

9.4.11 Aprovao
Cria-se um formulrio onde responsveis devero aprovar a fase. Criaremos um formulrio modelo conforme anexo 09.

9.5 Anlise

Esta fase preocupa-se com as primeiras abstraes e mecanismos que estaro presentes no domnio do problema. Traremos dos diagramas de classes em conjunto com diagramas de objetos, os diagramas de interao os dividiremos em seqncia e colaborao, trataremos tambm dos diagramas de estado e atividade.

9.5.1 Diagrama de Class es

Nos diagramas de classes modelamos a viso esttica do sistema, o conjunto de classes, interfaces, colaboraes e seus relacionamentos. Nestes relacionamentos dar-se- mais ateno aos quatro principais tipos que so: Generalizao/especificao, Agregao, Associao e Dependncia. Em sistema de grande complexidade podemos dividir o diagrama de classes em diagramas menores, logicamente observando sempre a integrao de todas as partes. Deve-se considerar alguns procedimentos no desenvolvimento de diagramas de classes: Praticamente, ter em mos todas as informaes sobre um modelo de objetos pouco provvel. Deve-se ter conhecimento dos comportamentos

85 iniciais destes objetos, defini-los, classific-los e identificar os

relacionamentos entre eles. Devemos nos direcionar mais as abstraes comportamentais, reduzindo o nmero de objetos. No devemos nos preocupar muito em usar toda a teoria envolvida nos diagramas de classes, mas sim as mais simples: classes, associaes, atributos e generalizao usando logicamente outras abstraes quando forem necessrias. Ter conhecimento e compreenso da idia do projeto fundamental. Cria-se modelos apenas das reas chaves do sistema. Atribuir-lhe um nome que indique sua finalidade. Na definio das classes podemos usar para definir os nomes substantivos, para os mtodos usamos verbos e para os atributos usamos propriedades da classe. A ateno em todos os detalhes desenvolvidos neste diagrama ser de grande influncia na construo de um bom sistema.

9.5.2 Diagrama de Objet os

Os diagramas de objetos so utilizados para visualizar, especificar, construir e documentar a estrutura de um conjunto de objetos, onde cada um est num estado especfico e em um determinado relacionamento com demais objetos. Os diagramas de objetos ajudam principalmente na modelagem de estruturas complexas. Quando construmos diagramas de classes, de componentes ou de implementao o que captamos realmente um conjunto de abstraes que nos interessa como um conjunto e, deste ponto de vista,

86 mostra-se sua semntica e seus relacionamentos com outras abstraes existentes neste conjunto. Se imaginarmos um determinado momento num sistema modelado, encontraremos um conjunto de objetos, cada um em um estado especfico e em um determinado relacionamento com os demais objetos. Um diagrama de objetos mostra um nico conjunto de objetos relacionados uns com os outros em um momento especfico. Segundo Booch, citamos algumas consideraes para

desenvolvimento de diagramas de objetos [1995]: Identifique alguma funo ou comportamento de parte do sistema cuja modelagem voc est fazendo e que resultante da interao de uma sociedade de classes, interfaces e outros itens. Para cada funo ou comportamento, identifique as classes, interfaces e outros elementos e seus relacionamentos entre si que participem nessa colaborao. Considere apenas um nico cenrio capaz de percorrer tudo isto, congele o cenrio em determinado momento e represente cada objeto participante. Exponha o estado e os valores dos atributos de cada um desses objetos, conforme seja necessrio, para compreenso do cenrio. De forma semelhante, exponha os vnculos existentes entre esses objetos, representando instncias de associaes entre eles.

9.5.3 Diagramas de Inter ao

O diagrama de interao enfatiza a interao de objetos, uma especificao comportamental que inclui uma seqncia de trocas de

87 mensagens entre objetos dentro de um contexto a fim de realizar um determinado propsito. Devemos utilizar diagramas de interao quando necessitamos ver o comportamento de vrios objetos dentro de um nico caso de uso, a partir de mensagens que so trocadas entre eles. Estes diagramas modelam os aspectos dinmicos do sistema. Os diagramas de interao podem ser apresentados de duas formas: Diagrama de Seqncia e Diagrama de Colaborao.

9.5.3.1 Diagrama de Seq ncia

O diagrama de seqncia expe o aspecto do modelo que enfatiza o comportamento dos objetos em um sistema, incluindo suas operaes, interaes, colaboraes e histrias de estado em seqncia temporal de mensagem e representao explcita de ativao de operaes [Furlan, 1998]. Em um diagrama de seqncia, um objeto representado por um retngulo no topo de uma linha vertical tracejada projetada para baixo. Esta linha representa o ciclo de vida de um objeto durante uma interao. As mensagens so representadas por linhas horizontais entre as linhas verticais de dois objetos, e a ordem de como as mensagens acontecem tambm mostrada de cima para baixo. O diagrama de seqncia mostra uma seqncia explcita de mensagens e devemos us-lo para especificaes de tempo real e para cenrios complexos.

88

9.5.3.2 Diagrama de Colab orao

Um diagrama de colaborao um contexto, um grfico de objetos e vnculos com fluxos de mensagens anexados [Furlan, 1998]. Num diagrama de colaborao, os objetos so desenhados como cones, e as setas indicam as mensagens enviadas entre objetos para realizar um caso de uso. O diagrama de colaborao auxilia no entendimento de um comportamento de um conjunto de objetos que trocam mensagens entre si para realizar um propsito em uma interao global, atravs deste diagrama podemos ver somente os objetos e as mensagens envolvidas. Uma colaborao anexada a um tipo, uma operao ou um caso de uso para descrever seus efeitos externos. Em diagramas complexos devemos separ-los em diagramas menores para facilitar seu entendimento. Utilizamos a descrio do caso de uso como ponto de partida para a confeco do diagrama. Como podemos observar os diagramas de seqncia e colaborao expressam informaes semelhantes, porm de forma diferente. Quando tivermos que decidir entre qual diagrama devemos adotar para estudar uma interao, podemos escolher primeiramente o diagrama de colaborao quando o objeto e seus vnculos facilitam a compreenso da interao, e somente escolher o diagrama de seqncia se a seqncia precisar ser evidenciada.

89

9.5.4 Diagrama de Estad o

O diagrama de estado exibe os eventos e os estados interessantes de um objeto e o comportamento de um objeto em resposta a um evento. O diagrama de estado implica na importncia da ordem de execuo dos eventos. Este diagrama faz a modelagem dos aspectos dinmicos de sistemas. Para melhor definir estes diagramas, deve-se desenvolver de forma individualizada um diagrama para cada classe existente, desta forma detalhando todos os estados da classe. Um estado representado por um retngulo com cantos arredondados e pode ter de um trs compartimentos que so: compartimento do nome do estado, compartimento de variveis e compartimento de atividade interna. Deve-se considerar alguns procedimentos no desenvolvimento de diagramas de estados: Atribuir-lhe um nome capaz de comunicar seu propsito Comece modelando os estados estveis do objeto e, em seguida faa a modelagem das transies legais de um estado para outro. No grfico deste diagrama, procure organizar seus componentes de forma que reduza o cruzamento de ligaes de componentes.

9.5.5 Diagrama de Ativid ade

Podemos fazer uma analogia com um grfico de fluxo(fluxograma), pois os diagramas de atividades controlam o fluxo de controle de uma atividade para outra. Focalizando as atividades que ocorrem entre objetos, modelando aspectos dinmicos do sistema.

90 Nos Diagramas de Atividades modelamos a ordem pela qual as coisas devem ser feitas, em processos seqncias ou paralelos, o que os diferencia de um fluxograma que so limitados a processos seqnciais. Usamos os Diagrama de Atividades para diferentes propsitos como: Anlise de Caso de Uso e compreenso do fluxo de trabalho entre vrios casos de uso; Capturar o funcionamento interno de um objeto; Entender as aes quando executamos uma operao; Mostrar o funcionamento de um processo de negcio em termos de atores, fluxos de trabalho, organizaes e objetos; Mostrar como uma instncia de caso de uso pode ser realizada em termos de ao e mudanas de estado de objetos; Mostrar como um conjunto de aes relacionadas pode ser executado e como afetar objetos ao seu redor.

9.6 Projeto

Baseado na anlise, trataremos nesta fase de solues tcnicas. Para essas solues sero usados os diagramas de implementao, os quais esto divididos em diagramas de componentes e implantao.

91

9.6.1 Diagrama de imple mentao

Os diagramas de implementao modelam os aspectos fsicos. Apresentam aspectos de implementao, inclusive da estrutura de cdigo fonte e de implementao de runtime. Esto divididos em diagramas de Componentes e diagramas de implantao.

9.6.1.1 Diagrama de comp onente

O diagrama de implantao mostra a configurao dos ns de processamento em tempo de execuo e os componentes que nele existem. Os diagramas de componentes mostram a organizao e as dependncias existentes entre um conjunto de componentes, transformam seu projeto lgico em bits. Modelam os itens fsicos que residem em um n como executveis, bibliotecas, tabelas, arquivos e documentos. Devemos atribuir-lhe um nome que demonstre seu propsito, seu contedo costuma conter: componentes, interfaces, relacionamentos de dependncia, generalizao, associao e realizao. Podem conter notas e restries. So usados para a modelagem da viso esttica de implementao de um sistema. A reunio das partes modeladas ajudaro na formao do sistema executvel. Usamos os Diagramas de Componentes nas seguintes formas: Para modelagem de cdigo-fonte: Identificar um conjunto de arquivos de cdigo-fonte de interesse e transform-lo em componentes;

92 Em sistemas grandes, devemos usar pacotes para mostrar grupos de arquivos de cdigo-fonte; No diagrama de componentes a exposio da verso do arquivo de cdigo-fonte ajuda no entendimento das dependncias de compilao; Para modelagem de verses executveis: Identificar o conjunto de componentes, isso envolver alguns ou todos que vivem em um nico n ou a distribuio desse conjunto de componentes por todos os ns existentes no sistema; Considere o esteretipo de cada componente desse conjunto; Para cada componente existente no conjunto, faa seus

relacionamentos. Para modelagem de bancos de dados fsicos: Identificar as classes existentes no modelo que representam o esquema de seu banco de dados lgico; Faa o mapeamento de suas classes em tabelas; Esteretipe suas tabelas para um diagrama de componentes; Transforme seu projeto lgico em fsico

Para modelagem de sistemas adaptveis: Identificar a distribuio fsica dos componentes que podero mover de um n para outro. Especifique a localizao de uma instncia do componente, atribua a ela o valor location. Para modelagem das causas de mudanas de um componente use um diagrama de interao para auxili-lo. Para uma melhor compreenso dos diagramas de componentes

podemos usar notas e cores como indicaes visuais com a finalidade de

93 chamar a ateno a pontos importantes do diagrama. E tambm devemos usar elementos estereotipados com cuidado, escolhendo um conjunto pequeno de cones e utilizando-o de maneira consistente.

9.6.1.2 Diagrama de impla ntao

Diagrama de Implantao usada para mostrar a organizao do hardware e a ligao do software aos dispositivos fsicos. Este diagrama denota vrios dispositivos de hardware e interfaces fsicas determinadas por seus esteretipos, como processador, impressora, memria, disco; suficientes para que o engenheiro de software especifique a plataforma em que o sistema executado. O diagrama de implantao modela a viso esttica da implantao de um sistema entre seus ns fsicos e seus relacionamentos e para especificar seus detalhes referente a construo. Usamos os Diagramas de Implantao em uma das trs formas : Para modelar Sistemas Embutidos : Identificar os dispositivos e os ns que so nicos para o sistema; Crie indicaes visuais para dispositivos de hardware e outros tipos dispositivos; Modele os relacionamentos entre os dispositivos; Se necessrio crie diagramas de implantao mais detalhado em dispositivos inteligentes. Para modelar sistema Cliente/Servidor : Identificar os ns que representem os processadores do cliente e do servidor do sistema;

94 Junte os dispositivos importantes para o comportamento do sistema. Crie indicaes visuais para processadores e dispositivos usando esteretipos Modele a topologia dos ns, especificando seus relacionamentos.

Para modelar sistema totalmente distribudo : Identificar os dispositivos e processadores para sistemas cliente/servidor mais simples; Caso precise analisar o desempenho da rede do sistema ou modificaes na rede, modele esses dispositivos em um nvel de detalhe que previna essas avaliaes; Analise os agrupamentos lgicos de ns, especificando-os em pacotes; Identifique a topologia do seu sistema; Se for preciso focalizar a dinmica do sistema, introduza diagramas de casos de uso para especificar o comportamento em foco e crie diagrama de interao para expandir esses casos de uso. Os diagramas de implantao no so muito utilizados em sistema

que residem em uma mquina e que interagem somente com dispositivos padro(teclado, monitor, mouse, modem pessoal) dessa mquina, que j so gerenciados pelo S.O. host. Em contrapartida se estiver desenvolvendo software que interaja com dispositivos que o sistema operacional host tipicamente no gerencia, ou por processadores distribudos fisicamente no mesmo host, o diagrama de implantao ajudar a analisar o mapeamento de software para hardware de seu sistema. Para uma melhor compreenso dos diagramas de implantao devemos atribuir-lhe um nome que identifique seu propsito, podemos usar

95 notas e cores como indicaes visuais com a finalidade de chamar a ateno a pontos importantes do diagrama. E tambm devemos usar elementos estereotipados com cuidado, escolhendo um conjunto pequeno de cones e utilizando-o de maneira consistente.

9.7 Implementao

A fase da implementao , na prtica, a construo fsica do sistema proposto [Silva,1998]. onde todos os modelos desenvolvidos no projeto so traduzidos para cdigo que a mquina possa reconhecer. muito importante que as fases anteriores j estejam concludas, pois a codificao uma conseqncia natural do projeto.

9.7.1 Traduo
O processo de traduo acontece quando a compilador aceita o cdigo-fonte como entrada e gera um cdigo-objeto como sada. Para que o cdigo-fonte no seja gerado de maneira diferente do projeto, deve-se ter todos os detalhes do projeto bem elaborados e estudados.

9.7.2 Escolha da Lingua gem

Linguagem de codificao complexa ou pouco conhecida pode levar a cdigos mal elaborado e de difcil legibilidade. Devemos nos concentrar em escolher linguagens de codificao que tenha suporte ao projeto.

96 A escolha de uma linguagem de programao para um projeto especfico deve-se considerar as suas facilidades e aonde ela ir ajudar o melhor desenvolvimento do projeto. PRESSMAN sugere alguns critrios a serem avaliados durante a escolha de uma linguagem de programao [1995]: A rea de aplicao geral; A complexidade computacional e algortmica; O ambiente em que o software ser executado; Consideraes de desempenho; A complexidade da estrutura de dados; O conhecimento da equipe de desenvolvimento do software; A disponibilidade de um bom compilador. Geralmente considera-se a rea de aplicao geral como um dos itens mais estudados na escolha da linguagem. O lanamento de novas linguagens ou verses muito constante, portanto muitas vezes necessitamos escolher linguagens do conhecimento da equipe, que geralmente no so os ltimos lanamentos. Porm novas linguagens devem ser cuidadosamente estudadas e a mudana da linguagem atual para nova tem que ocorrer. Na escolha de uma linguagem orientada a objetos deve-se considerar suporte para definies de classes, herana, encapsulao e transmisso de mensagens ou ainda caractersticas adicionais como herana mltipla e polimorfismo. As novas geraes de ferramentas CASE possuem uma variedade de linguagens, com isto elas podem gerar cdigos-fonte baseadas no modelo

97 desenvolvido. Porm devem ser bastante estudadas pois uma falha no modelo pode comprometer todo o produto final.

9.7.3 Documentao do Cdigo

Um cdigo-fonte bem estruturado e documentado ser de grande importncia para futuras manutenes no sistema. A estruturao e documentao comea com a escolha de nomes identificadores(variveis e rtulos), prosseguindo com a colocao e

composio do comentrio e por fim com a organizao visual do cdigo. Na escolha de nomes de identificadores devemos considerar alguns itens a fim de facilitar a interpretao : Expressar diretamente o seu propsito. Identificao do tipo e de sua abrangncia(global, local) no sistema. Podem ser feitas algumas definies de nomes antes do incio da programao. No usar nomes muito extensos, mas que expresse o seu propsito. Neste caso dever prevalecer o bom censo e experincia por parte do programador. Na colocao e composio de comentrios, tomaremos alguns cuidados para que estes realmente ajudem outros leitores de cdigo na compreenso do cdigo e at mesmo para que o desenvolvedor possa localizar-se com mais facilidade e rapidez em futuras manutenes. Isto de extrema importncia no desenvolvimento de sistemas e/ou funes complexas. Segundo PRESSMAN, comentrios em forma de prlogo so bastante usados, eles aparecem no incio de cada mdulo, e seguem o formato abaixo [1995]:

98 Uma declarao de propsitos que indique a funo do mdulo. Uma descrio da interface("seqncia de chamada", descrio de todos os argumentos e uma lista de todos os mdulos subordinados). Uma discusso de dados pertinente, tais como variveis importantes e suas restries e limitaes de uso. Um histrico de desenvolvimento(autor do mdulo, auditor e data, datas e descrio das modificaes). Para uma melhor documentao em mdulos e/ou funes muito complexas devemos utilizar tambm comentrios descritivos embutidos no decorrer do cdigo-fonte. Este tipo de comentrio ser de grande utilidade para documentarmos linhas ou conjunto de linhas especficas em determinado local dentro de um mdulo e/ou funo. Este comentrio dever sempre anteceder o bloco de comandos que se deseja documentar, faa apenas a identificao da funcionalidade de tal linha ou conjunto de linhas, no necessrio documentar outros dados como datas, autores, etc. Ao escrevermos cdigo-fontes e tambm seus comentrios devemos sempre nos preocupar com sua esttica, procuramos sempre elaborar cdigos identados e seus comentrios devem sempre ter uma boa visualizao. Algumas dicas de PRESSMAN para simplificar a codificao [1995]: Evitar o uso de testes condicionais complicados; Evitar os testes em condies negativas; Evitar um intenso alinhamento de laos ou condies; Usar parnteses para esclarecer expresses lgicas ou aritmticas; Usar smbolos de espaamento e/ou legibilidade para esclarecer o contedo da instruo;

99 Usar somente caractersticas com padro ANSI; Auto questionar-se: Ser que entenderia este cdigo se no fosse eu o autor deste?

9.8 Testes

A atividade de teste visa executar um programa ou parte dele com a inteno de encontrar erros. Um teste bem executado aquele que encontra um maior nmero de erros com o menor nmero de tentativas, em um tempo e esforo mnimo. Certamente que os projetistas codificam o software para que no haja erros. Uma estratgia de teste de software deve estar dividida nas seguintes fases : planejamento de teste, projeto de casos de teste, execuo de teste e a resultante coleta e avaliao de dados [Pressman, 1995]. Para tornar esta estratgia mais flexvel e customizada sem perder sua validade e regidez, objetivando a reduo de custos e tempo adotamos a seguinte estratgia : planejamento, execuo e avaliao dos resultados.

9.8.1 Planejamento de T estes

Antes do incio dos teste devemos definir a equipe responsvel pelos testes. Devemos formar um grupo de testes independentes (GTI), envolvendo tambm os desenvolvedores principalmente na etapa de teste de unidade da fase de execuo que ser abordado a seguir.

100 Devemos tomar como base para testes os casos de usos desenvolvido na fase de anlise de requisitos, verificando se seu propsito est contemplado, observando seu fluxo normal e quando este fluxo no seguido se os fluxos alternativos esto atendendo tal situao.

9.8.2 Execuo de Teste s

Nesta etapa so realizados os testes na integra, abordaremos os testes de Unidade, Integrao, Validao e Sistema. Durante a execuo dos testes, deve-se fazer um relatrio de acompanhamento para registro de todos as ocorrncias encontradas.

9.8.2.1 Teste de Unidade

Nestes testes cada unidade de software(classe, procedimento, funo, arquivo, etc) testado individualmente garantindo que ele funcione adequadamente. Aqui a participao dos desenvolvedores tambm

recomendada, pois estes tem um melhor conhecimento interno de cada unidade. Alguns aspectos a serem testados: so a interface, as estruturas de dados, as condies limite, os caminhos independentes e os caminhos de tratamento de erros. A interface, em busca de erros de passagem de dados para dentro e para fora do mdulo. Deve ser realizada em primeiro lugar, durante a realizao deste teste os seguintes aspectos devem ser observados : 1. Consistncia entre o nmero e o tipo de parmetros de entrada com o nmero e tipo de argumentos;

101 2. Consistncia entre o nmero e o tipo de argumentos transmitidos aos mdulos chamados com os parmetros; 3. Consistncia de variveis globais ao longo dos mdulos; 4. Existncia de referncias a parmetros no associados ao ponto de entrada atual; 5. Modificao de argumentos de entrada/sada. As estruturas de dados locais, para se prover a garantia de que todos os dados armazenados localmente mantm sua integridade ao longo da execuo do mdulo. Neste teste devemos nos preocupar em : 1. Digitao inconsistente ou imprpria; 2. Iniciao ou valores default errneos; 3. Tipos de dados errados; 4. Underflow e Overflow. As condies limite, que permitem verificar que o mdulo executa respeitando os valores mximos e mnimos estabelecidos para seu processamento. Os caminhos independentes (ou caminhos bsicos) da estrutura de controle so analisados para ter garantia de que todas as instrues do mdulo foram executadas pelo menos uma vez. Os erros mais comuns so : 1. Precedncia aritmtica incorreta; 2. Operaes em modo misto; 3. Inicializao incorreta; 4. Erros de preciso; 5. Representao simblica de uma expresso incorreta; 6. Laos mal definidos;

102 7. Comparao de diferentes tipos de dados; 8. Operadores lgicos utilizados incorretamente. Os caminhos de tratamento de erros (se existirem), sero testados para observar a robustez do mdulo. Devemos observar os seguintes itens : 1. Descrio incompreensvel do erro; 2. O erro exibido no o erro encontrado; 3. Interveno da condio de erro no sistema antes do seu tratamento; 4. O processamento das condies de excees incorreto; 5. A descrio do erro no ajuda na localizao da causa do erro.

9.8.2.2 Teste de Integra o

O teste de integrao uma tcnica sistemtica para a construo da estrutura de programa, realizando-se em paralelo, testes com o objetivo de descobrir erros associados a interfaces. Seu objetivo montar, a partir dos mdulos testados ao nvel de unidade construir a estrutura de programa que foi determinado pelo projeto. Este teste est divido em incremental e no incremental. Incremental aborda o teste de integrao top-down o programa construdo e testado em pequenos seguimentos, onde os erros so mais fceis de ser isolados e corrigidos. O teste no incremental aborda o teste de integrao bottom-up o programa testado como um todo, um conjunto de erros encontrado e sua correo difcil porque o isolamento das causas complicado pela vasta amplitude do programa inteiro [Pressman,1995]. 1. Integrao top-down : Os mdulos so integrados movimentando-se de cima para baixo atravs da hierarquia de controle, iniciado-se do

103 mdulo principal. Os mdulos subordinados ao mdulo principal de uma maneira depth-first(pela profundidade) ou breadth-first(pela largura). 2. Integrao bottom-up : Inicia-se a construo e testes com mdulos localizados nos nveis mais baixos da estrutura do programa dirigindo-se ao mdulo principal.

9.8.2.3 Teste de Validao

Ao final do teste de integrao, o software finalmente estruturado na forma de um pacote ou sistema. O teste de validao a validao e verificao de que o software como um todo cumpre os requisitos do sistema. Na fase de anlise de requisitos so definidos critrios que serviro de validao para aprovao ou no do software. O teste de validao aborda as seguintes estratgias : reviso de configurao e teste alfa e beta. 1. Reviso de configurao: onde so verificados os elementos de configurao do software se esto adequadamente desenvolvidos e detalhados para futuras manutenes. 2. Teste alfa: feito por um cliente nas instalaes do desenvolvedor. O software usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros" do usurio e registrando erros e problemas de uso. 3. Teste beta: feito nas instalaes do cliente pelo usurio final do sistema. O desenvolvedor no est presente. O cliente registra os problemas(reais ou imaginveis) que so encontrados e relata-os ao desenvolvedor em intervalos regulares.

104

9.8.2.4 Teste de Sistemas

O software apenas um elemento de um sistema baseado em computador mais amplo. Este teste envolve um grande nmero de diferentes testes, cujo propsito pr completamente prova o sistema baseado em computador. Entre os tipos de testes de sistemas destacamos: De recuperao, de segurana, de estresse e de desempenho. O teste de recuperao um teste de sistema que fora o software a falhar de diversas maneiras e verifica se a recuperao executada. O teste de segurana verifica se todos os mecanismos de proteo embutidos no sistema o protegero. O teste de estresse fora o sistema a usar recursos em quantidade, freqncia ou volumes anormais. O teste de desempenho feito para testar o desempenho do software em tempo real.

9.8.3 Avaliao dos Res ultados

Completadas a fase de execuo dos testes, passaremos para a avaliao dos mesmos. Isto ser feito analisando os relatrios elaborados durante a fase anterior. Esta fase de grande valia para vrios aspectos do sistema. Nesta poderemos ter uma idia por completo de todo o desenvolvimento do projeto. Podemos apontar falhas em determinadas fases do projeto baseando-se nesta avaliao, bem como certificar-se da qualidade e/ou bom desempenho do projeto.

105 Ocorrendo pequenos erros ou observaes que no interfiram no objetivo do projeto, estes devero ser tratados diretamente com o responsvel pela fase onde ocorreu o problema. Quando na avaliao ocorrem problemas do tipo que tenha que ser refeito alguma unidade por completo, isto geralmente estar comprometendo os objetivos do projeto e, consequentemente dever ser de conhecimento de toda a equipe envolvida no projeto. Aps feitas as correes dos problemas encontrados, estando de acordo com as especificaes definidas na anlise de requisitos e aceitas pelo cliente, o software estar pronto para uso.

Captulo 10 - Validao da Metodologia

10.1 Introduo

Neste captulo documentaremos o prottipo desenvolvido baseado na metodologia, mostrando a idia principal do sistema. Sero abordados os seguintes itens : Formulrio de Documentao, Contatos Iniciais, Ata da Reunio, Resumo do Projeto, Escopo, Lista de Caso de Uso, Diagrama de Caso de Uso, Diagrama de Classes e Escolha da Linguagem.

10.2 Formulrio de Do cumentao

Fonte Tipo : Times New Roman Gravao Tamanho : 12

107 Pasta Me : Contabilidade Descrio : Esta pasta contm toda a documentao do projeto do sistema de contabilidade. Extenso de Arquivos : .rtf Impresso Tamanho do papel: A4(210 X 297mm) Backup Responsvel: Reginaldo Darolt / Alexandre de Almeida Periodicidade: Semanal. Verso: 1.0A-01

10.3 Contatos Iniciais

Data: 14/03/2001 Razo Social: Escritrio Criciumense de Contabilidade Solicitante: Joo da Silva Departamento: Gerencial Fone: 048-4371159 Fax : 048-4376020 Ramal: 203 Email: joaocri@terra.com.br Descrio: Sistema de Contabilidade com capacidade de emitir os relatrios legais como: dirio, razo, balancete aps os lanamentos nas contas contbeis do plano de contas da empresa. Ir receber tambm

108 lanamentos dos sistemas de livros fiscais, folha de pagamento e controle patrimonial. Ir gerar informaes gerenciais para o administrativo. Tipo do pedido: (X ) Novo ( ) Alterao

rea de negcio do problema: Contbil Prioridade: (X) Normal ( ) Alta ( ) Urgente

Data pretendida para soluo: 12 meses

10.4 Ata da Reunio

Data : 21/03/2001

Hora Incio : 19:00 Hora Final: 22:30

Participantes: Alexandre de Almeida, Reginaldo Darolt e Joo da Silva Objetivos: 1.Definir a abrangncia do sistema. 2.Definir as possveis entradas de dados. 3.Definir os procedimentos padres do sistema. 4.Definir as sadas/relatrios que o usurio necessita. 5.Definir os possveis tipos de usurio do sistema. Observaes: Utilizamos o mtodo questionrio para alcanar os objetivos da reunio. Definies da reunio: 1.O sistema ir abranger somente o mdulo de contabilidade 2.As possveis entradas de dados no sistema sero:

Manual(atravs de digitao) e tambm automticas por outros sistemas. Quando geradas por outros sistemas, estes devero estar conectados no

109 mesmo banco de dados e sem o auxlio de nenhuma rotina do mdulo de contabilidade para execuo de tal tarefa. 3.Procedimentos: Cadastro de Usurios. Cadastro de Contas Contbeis e Histricos Padres. Lanamentos. Emisso de relatrios. Definio de parmetros do sistema como perodo de

lanamento e mscara contbil. 4.Relatrios: Cadastrais: Contas e Histricos. Acompanhamento de lanamentos. Legais: Dirios, Razo, DRE, Balano e Livro Caixa. Tempo gasto no sistema por usurio.

5.Usurios: Contador Digitador Usurios de outros sistemas que somente faro lanamentos no sistema quando conectados no mesmo banco de dados.

10.5 Resumo do Proje to

Um sistema de Contabilidade com cadastros de contas, histricos e lanamentos. Recebe lanamentos do sistema de Livros Fiscais nos

110 lanamentos de notas, apurao e pagamento de impostos. Do Controle Patrimonial recebe lanamentos na atualizao dos bens e no fechamento de perodo. Na Folha de Pagamento recebe lanamentos no momento do clculo mensal. Este sistema gera informaes sobre tempo gasto do usurio para o sistema administrativo. Emite relatrios cadastrais, de acompanhamentos e tambm os relatrios legais tais como: Dirio, Razo, DRE, Balano e Livro Caixa. Para um bom desempenho do sistema ser necessrio o uso de mquinas com configurao igual ou superior a PII 233 Mhz com 32 Mb. Ambiente Windows95 ou Windows98, e para uma boa apresentao dos relatrios faz-se necessrio impressora Jato de Tinta ou Laser. No caso de mais de uma estao de trabalho, estas devero estar conectadas atravs de uma rede que suporte as estaes no ambiente citado.

10.6 Escopo

Na figura 10.1 apresentamos o escopo do sistema:

111

Figura 10.1 Escopo do Sistema

10.7 Lista de Casos de Uso

UC001 - EFETUAR LANAMENTO UC002 - MANTER CONTA CONTBIL UC003 - MANTER PARMETROS UC004 - MANTER PERMISSES

112 UC005 - EFETUAR LANAMENTOS LIVROS FISCAIS UC006 - APURAR IMPOSTOS LIVROS FISCAIS UC007 - PAGAR IMPOSTOS LIVROS FISCAIS UC008 - FECHAR PERODO CONTROLE PATRIMONIAL UC009 - MANTER BENS CONTROLE PATRIMONIAL UC010 - NAVEGAR EM REGISTROS UC011 - CALCULAR FOLHA DE PAGAMENTO

10.8 Diagrama de Caso de Uso

A figura 10.2 mostra o diagrama de casos de uso do Sistema de Contabilidade.

113

Figura 10.2 Diagrama de Caso de Uso do Sistema de Contabilidade

10.9 Diagrama de Clas ses

Na figura 10.3 mostramos o diagrama de classes do Sistema de Contabilidade.

114

Figura 10.3 Diagrama de Classes do Sistema de Contabilidade

10.10 Escolha da Lingu agem

Para desenvolvimento do Sistema de Contabilidade, escolhemos a linguagem PowerBuilder verso 5.0.02 da Powersoft com o banco de dados Sybase SQL Anywhere verso 5.0.03.

Captulo 11 - RESULTADOS OBTIDOS

Aps a validao da metodologia desenvolvida, obtemos alguns resultados os quais julgamos ser necessrios destacar. Neste captulo discriminaremos os pontos fortes e pontos fracos de cada fase da metodologia desenvolvida. Documentao Pontos Fortes: A extenso de arquivos utilizada nos auxiliou na comunicao entre a equipe envolvida no projeto, devido ao fato de poder ser manipulado nos diversos ambientes encontrados. O backup nos salvou de refazer boa parte do projeto, pois tivemos problemas com vrus na mquina principal onde estava o projeto e a mesma teve de ser formatada. Pontos Fracos: Necessidade de um arquivo leia-me.rtf contendo todos os arquivos utilizados no desenvolvimento do projeto e uma pequena descrio de cada arquivo. Estabelecimento de uma padronizao para nome de arquivos.

116 Eventos Iniciais Pontos Fortes: De um modo geral atendeu as necessidades, pois desde o primeiro contato do cliente com a empresa, tudo foi registrado, facilitando as prximas etapas. Com o estudo da rea de

negcio ficou definido que a empresa atenderia a solicitao do cliente. Anlise de Requisitos Pontos Fortes: Com os tpicos abordados na reunio, obteve-se os objetivos gerais e especficos pretendidos com o sistema. Ao final ficou registrado na ata da reunio. Os casos de uso foram bem detalhados, de modo que qualquer membro do projeto entendeu o seu funcionamento. Facilitou no desenvolvimento durante a fase de implementao. O diagrama de caso de uso auxiliou na comunicao entre o cliente e os desenvolvedores. Pontos Fracos: Na lista de Atores deveria ter tambm a data da criao do ator e o autor que o criou, desta forma facilitaria no esclarecimento de possveis dvidas sobre o ator. Anlise Pontos Fortes: Seguindo as definies da metodologia, o diagrama de classes foi facilmente desenvolvido e compreendido por toda a equipe.

117 Os diagramas de interao mostraram o fluxo de funcionamento do sistema, como as informaes trafegam no mesmo. Auxiliando desta forma na compreenso comportamental do sistema. O diagrama de estado mostrou de forma clara os eventos da principal rotina do sistema que a rotina de lanamentos. O diagrama de atividade mostrou de forma clara a ordem de funcionamento do caso de uso manter contas. Pontos Fracos: O diagrama de objetos deveria ser detalhado na metodologia para facilitar seu desenvolvimento. Projeto Pontos Fortes: O diagrama de componentes nos auxiliaram na estruturao do cdigo fonte, separando seus objetos de acordo com sua finalidade. O diagrama de implantao mostrou a toda a equipe a estrutura fsica do cliente, bem como informaes essenciais para o software como por exemplo o servidor de banco de dados. Implementao Pontos Fortes: Conforme sugerido na metodologia, escolhemos uma linguagem conhecida pelos desenvolvedores e que atendesse os requisitos do projeto.

118 A documentao do cdigo foi de grande importncia durante o desenvolvimento do sistema, pois todos os programadores poderiam facilmente compreender as rotinas independentes do autor da mesma. Esta documentao ainda ser muito utilizada em futuras manutenes do sistema. Testes Na estratgia de testes no adotamos a fase de projetos porque seus mtodos torna essa tarefa cansativa e tambm eleva os custos. uma fase que pode ser eliminada sem comprometer a fase de testes do projeto. Nas fases de teste demos nfase ao teste de unidade, cujo no nosso ponto de vista o mais importante, os demais so apenas citados para que sejam explorados caso algum tenha esta necessidade.

119

Captulo 12 - CONCLUSO

Em virtude das constantes inovaes que surgem em ferramentas de desenvolvimento de sistemas orientadas a objetos, podemos afirmar a importncia do uso de uma metodologia que englobe todas as fases do processo, desde os eventos iniciais, passando pela anlise de requisitos, anlise, projeto, implementao e testes. Durante a realizao do trabalho constatamos o interesse por parte de desenvolvedores de software, de uma metodologia deste nvel. Com o desenvolvimento de sistemas mais complexos, necessrio o uso de uma metodologia unificada, tanto para a comunicao entre toda a equipe envolvida (cliente, analista, programador, etc), quanto para a documentao(requisitos e cdigo-fonte). Neste contexto, foi proposta uma metodologia de desenvolvimento de sistemas orientados a objetos baseada em UML(Unified Modeling Language), a partir da qual o desenvolvedor poder seguir suas etapas para o fluxo correto do desenvolvimento de um projeto. Aps o estudo da ferramenta CASE Rational Rose da Rational Software Corporation, utilizamos a mesma no apoio a validao da

120 metodologia. Esta ferramenta mostrou-se bastante complexa e eficaz, pois ela possui uma documentao interativa e automtica dos processos de modelagem, permitindo at mesmo gerar cdigo-fonte a partir do modelo. Na implementao do sistema utilizamos a ferramenta de desenvolvimento chamada Power Builder pela facilidade da programao orientada a objetos, bem como pelo conhecimento que todos envolvidos tinham da mesma. Com o desenvolvimento do prottipo utilizando a metodologia, podemos afirmar que os resultados esperados foram alcanados, tendo em vista que esta atendeu todas as fases de desenvolvimento do prottipo. Desta forma podemos dizer que a metodologia se torna necessria para um bom desenvolvimento de sistema orientados a objetos.

12.1 Recomendaes

Este trabalho est aberto a futuros melhoramentos, e como recomendaes futuras podemos ressaltar: Aplicao da metodologia em um sistema complexo. Estudo de novas ferramentas CASE. Desenvolver encontrados. Desenvolvimento de uma ferramenta CASE baseado-se na metodologia desenvolvida. Utilizao da metodologia no apoio s aulas de engenharia de software. novas pesquisas visando corrigir os pontos-fracos

Captulo 13 - BIBLIOGRAFIA

1. BOOCH Grady et al. UML : Guia do Usurio, O mais avanado tutorial sobre Unified Modeling Language. Rio de Janeioro. Campus, 2000. 2. SCHNEIDER, Geri et al. Applying Use Cases : A Pratical Guide. Massachusetts. Addison-Wesley, 1998. 3. Technologies, ADD. Histrico da UML. http://www.addtech.com.br.

Consultada em 24/03/2001. 4. CABRAL, Adelino Manuel de Oliveira et al. UML : Unified Modeling Language. http://www.tutprog.cjb.net. Consultada em 24/03/2001. 5. SILVA, Leonardo de Arajo et al. UML : Diagrama de Atividade. http://www.dcc.ufmg.br/~marcosfg/. Consultada em 24/03/2001. 6. UML - Diagramas de Implementao : importantes quando trata de questes como reutilizao e desempenho. Consultada em

http://www.dcc.ufmg.br/~gorgulho/tbd/seminario.html. 24/03/2001.

7. UML Introduo : ao modelar alguma coisa, estamos criando uma simplificao da realidade para um melhor entendimento do sistema. http://www.dcc.ufmg.br/~lucanaan/tbd/texto.htm. Consultada 24/03/2001.

122 8. ARAJO, Bethnia Lagoeiro. Uma Contribuio para o Problema de Compatibilizao de Modelos . na Consultada UML. em

http://www.dcc.ufmg.br/pos/html/spg98/node3.html 24/03/2001.

9. CNPQ, UFSC. UML : Unified Modeling Language. Abrange sua histria, definies, arquivos e sites relacionados. http://www.eps.ufsc.br/~wolff . Consultada em 24/03/2001. 10. BARROS, Pablo. UML : Linguagem de Modelagem Unificada em Portugus. http://cc.usu.edu/~slqz9/uml . Consultada em 24/03/2001 . 11. TECHMARK, Engenharia de Software. Tutoriais.

http://www.techmark.com.br/download.html . Consultada em 24/03/2001. 12. LARMAN, Craig. UTILIZANDO UML E PADRES : Uma introduo anlise e ao projeto orientados a objetos. Porto Alegre 2000. 13. FOWLER, Martin, Kendal Scott. UML ESSENCIAL : Um breve guia para a linguagem padro de modelagem de objetos. Porto Alegre - Bookman, 2000. 14. PRESSMAN, Roger S. . ENGENHARIA DE SOFTWARE. So Paulo Makron Books ,1995. 15. RUMBAUGH, James, Michael Blaha, William Premerlani, Frederick Eddy, Willian Lorensen. MODELAGEM E PROJETOS BASEADOS EM Bookman,

OBJETOS. Rio de Janeiro - Campus, 1994. 16. FURLAN, Jos Davi. MODELAGEM DE OBJETOS ATRAVS DA UML : The Unified Modeling Languagem. So Paulo - Makron Books, 1998.

123 17. MAZZOLA, Vitrio Bruno. CONCEITOS BSICOS DA ORIENTAO A OBJETOS : Captulo 1, 1999. 18. COOD, Peter, Edward Yourdon. ANLISE BASEADA EM OBJETOS. Rio de Janeiro - Campus, 1991. 19. YOURDON, Edward, Carl Argila. ANLISE E PROJETO ORINTADOS A OBJETOS : Estudos de Casos. So Paulo - Makron Books, 1999. 20. SILVA, Nelson Peres da. PROJETO E DESENVOLVIMENTO DE SISTEMAS. So Paulo - rica, 1998. 21. MIZRAHI, Victorine Viviane. TREINAMENTO EM C++. So Paulo - Makron Books. 22. RATIONAL, Software Corporation. Rational Rose. www.rational.com. Consultada em 05/04/2001. 23. DBSERVER, Ferramentas Case. Parceria Rational. www.dbserver.com.br. Consultada em 30/10/2001.

124

1. Anexo 01 - Formulrio de documentao.

Fonte Tipo : <nome da fonte> Gravao Pasta Me : <Nome do Sistema> Descrio : <Abaixo desta pasta me esto todos os arquivos necessrios referentes a documentao do software>. Extenso de Arquivos : <tipo da extenso> Tamanho : <tamanho da fonte>

Impresso Tamanho do papel: <medidas do formulrio>

Backup Responsvel: <Nome do responsvel pelo Backup> Periodicidade: Verso: <N.NX-NN>

125

2. Anexo 02 - Formulrio de contato.

Data: <dd/mm/aaaa> Data do contato do cliente Razo Social: <Nome da Empresa solicitante do software> Solicitante: <Nome para contato na empresa> Departamento: <Departamento do solicitante> Fone: Fax : Ramal: Email: Descrio: <Neste item deve-se tentar passar o mximo de informaes possveis sobre a solicitao> Tipo do pedido: ( ) Novo ( ) Alterao <Informar neste item se

trata-se de software e/ou rotina novos ou alterao> rea de negcio do problema: < De acordo com o pedido deve-se definir a rea de negcio, para que os envolvidos possam verificar se podem atender ou no> Prioridade: prioridade do pedido> Data pretendida para soluo: <O preenchimento se faz necessrio, pois ser estudada pela equipe onde ser discutido a possibilidade ou no de ser efetuada> ( ) Normal ( ) Alta ( ) Urgente <Definir aqui a

126

3. Anexo 03 - Formulrio da ata de reunio

Data : <dd/mm/aaaa> Hora Incio : <hh:mm>Hora Final: <hh:mm> Participantes: <Nome1>, <Nome2>,.... Objetivos: <Deve definir o que se pretende alcanar com o sistema, os setores atendidos> Observaes: <Definio dos itens que ajudaro no

desenvolvimento do sistema> Definies da reunio: <A definio engloba tudo o que foi definido na reunio>

127

4. Anexo 04 - Formulrio lista de atores

Nome <Nome do ator> o que o ator faz e com o que ele interage> Descrio <Descrever em poucas palavras

128

5. Anexo 05 - Formulrio lista de casos de uso.

arquivo <nome do arquivo > caso de uso <Nome do caso de uso que est no arquivo>

129

6. Anexo 06 - Formulrio de requisitos de caso de uso.

NOME : <Nome do caso de uso> DESCRIO: <Descrever a funcionalidade do caso de uso> ATORES: <Listar os atores que interagem no caso de uso> DATA <data> ALTERAO <Descrio da alterao> AUTOR <Listar os autores>

SITUAO INICIAL DO PROCESSO : <O que precisa para existir o caso de uso> FLUXO NORMAL: <Seqncia de passos que ocorre naturalmente com maior freqncia. Esta seqncia dever ser ordenada e cada passo corresponde a uma ao do usurio e uma resposta do sistema ou vice-versa> FLUXOS ALTERNATIVOS: <Usa-se quando o fluxo normal no for seguido. Neste caso, tambm sero feitas seqncias de passos alternativos ordenados e identados conforme o fluxo normal que o gerou> REQUISITOS MNIMOS: <Os dados que tem que existir ou eventos que tem que ocorrer para que o caso de uso seja vlido> PONTOS DE EXTENSO: <So casos de uso que usam outro caso de uso> VARIAES DE DADOS E TECNOLGICAS: <Mudanas que podem ocorrem que iro afetar no funcionamento do sistema>

130

7. Anexo 07 - Formulrio Diagrama de caso uso

NOME : <Nome do diagrama> DESCRIO: <Descrever em poucas palavras o propsito do diagrama> ATORES RELACIONADOS: <Listar todos os atores relacionados no diagrama> CASOS DE USO RELACIONADOS: <Listar todos os casos de uso relacionados no diagrama> DATA <data da criao/alterao> ALTERAO <descrio da alterao> AUTOR <nome do responsvel da criao/alterao>

131

8. Anexo 08 - Formulrio de Cronograma

Fase: <Fase do projeto> Responsveis: Nome do Responsvel Assinatura

<Nome(s) do(s) responsvel(is) pela fase> <Assinatura de cada responsvel>

Data Prevista: <Data prevista para concluso da fase>

132

9. Anexo 09 - Formulrio de Aprovao

Fase: <Fase do projeto> Declaramos que a presente fase est de acordo com o propsito do sistema. Aprovado por Nome Assinatura

<Nome(s) do(s) responsvel(is) pela fase> <Assinatura de cada responsvel> Data da Aprovao: <Data que fase foi aprovada>