UNISUL – UNIVERSIDADE DO SUL DE SANTA CATARINA PRÓ-REITORIA ACADÊMICA CENTRO DE CIÊNCIAS EXATAS, AGRÁRIAS E DAS ENGENHARIAS CURSO

DE CIÊNCIA DA COMPUTAÇÃO

PESQUISA E DESENVOLVIMENTO EM UML

ALEXANDRE DE ALMEIDA REGINALDO DAROLT

ARARANGUÁ – SC 2001

UNISUL – UNIVERSIDADE DO SUL DE SANTA CATARINA PRÓ-REITORIA ACADÊMICA CENTRO DE CIÊNCIAS EXATAS, AGRÁRIAS E DAS ENGENHARIAS CURSO DE CIÊNCIA DA COMPUTAÇÃO

PESQUISA E DESENVOLVIMENTO EM UML

ALEXANDRE DE ALMEIDA REGINALDO DAROLT

Projeto apresentado à disciplina de Projetos em Ciência da Computação 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 ACADÊMICA CENTRO DE CIÊNCIAS EXATAS, AGRÁRIAS E DAS ENGENHARIAS CURSO DE CIÊNCIA DA COMPUTAÇÃO

TERMO DE APROVAÇÃO PROJETO DE CONCLUSÃO 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 obtenção de Grau em Bacharel em Ciência da Computação.

Prof. Carlos Fernando Buss Coord. do Curso de Ciências da Computação Banca de Avaliação

Prof. Luciano Savio Coordenador de PCC

Prof. Alessandro Zanini Orientador

Prof. Ana Cláudia G. Barbosa Convidada

Prof. Juarez Bento Da Silva Convidado ARARANGUÁ – SC 2001

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

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

......................................1 Conceito......3 Justificativa.................................................... xii RESUMO............................................... 4 1........................................................5 Metodologia.... 2 1...... 8 2..............................ANÁLISE E PROJETOS ORIENTADOS A OBJETOS ............. 11 2....................................6 Estrutura ................................................................................................... 11 2.........................................................3 Projeto Orientado a Objetos..................... xiv ABSTRACT..........1 Apresentação ...................................................................................................................................................... 5 Capítulo 2 ............................................................................................... 8 2....... 10 2......... 1 1..........2 Objetivos Geral e Específicos .....................5 Objetos......4 Classes .............................4 Abrangência .....................v SUMÁRIO LISTA DE FIGURAS .......................................................................................................................... 4 1................................................................................................ xv Capítulo 1 ............................................................................................INTRODUÇÃO .................................6 Abstração ........................................................................................................................... 12 ...................................2 Análise Orientada a Objetos ................ 1 1............................................................................................ 3 1............................................................. 9 2........

20 4..... 21 4....FERRAMENTAS CASE.... 18 3........ 14 Capítulo 3 ................................................................................. 15 3..UML ........4 Programação.. 30 6............................... 12 2.... 21 4.....................................................................................................................................................................................................................................................1 Introdução ....................................................................... 30 ..1 Análise de Requisitos.......................................................6...................................................................................................................................................................................2 Histórico .............................................................................8 Herança ................................... 26 5.................5 Rational Rose........ 20 4.................. 19 Capítulo 4 ................................................ 28 Capítulo 6 .............vi 2........................................................................ 13 2........................3 Aceitação .................................................3 Aceitação no Mercado ...............4 O Futuro ...6.................................................. 19 3..............................................................................................1 Conceito........................................................ 28 5......................5 Testes ....... 13 2.............VISÕES DE SISTEMAS........................................7 Encapsulamento .........................................2 Vantagens................................... 24 5.................................................................................2 Análise .......... 24 5......................................................................2 Abstração de dados..........................................................................................................3 Projeto.....................................1 Abstração de Procedimentos .......... 22 4.................1 Conceito.................................... 15 3.........9 Polimorfismo .......................4 Padronização OMG.........5 Aplicação ......................................................................... 16 3.................................................. 23 Capítulo 5 ............................................................................... 27 5....... 12 2...............................................................................................ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML ...............

...............................................................2 Classes ..........................1..........................................3 Operações ......................... 38 7........1............1...............5 Visão de concorrência............................................................................................................................................. 42 7.......................... 40 7............................1.................1 Associações ..............................1.........2 Visão USE-CASE............. 44 7........................... 36 7............7 Relacionamentos ...........7 Associações Ternárias............ 37 7.................. 43 7...............................7.................. 43 7.......2 Atributos .4 Estados ................................. 31 6................7....... 35 7................................................................................................1.................................. 32 6..........................................................2 Associações Recursivas .3 Objetos....................7........................................... 46 7.........5 Pacotes ............................... 31 6............vii 6.................. 47 7...........................................6 Componentes......................................................................................................4 Associações Exclusivas ................................................7........................ 48 7................ 32 6..... 34 7.............6 Visão de Organização............. 34 7..........6 Associações de Classe ............. 47 7............. 44 7........1 Nomes ..................... 49 ..............................................................................4 Visão de Componentes.............................................................2..................................................................................8 Agregação.................................................................MODELOS DE ELEMENTOS......................................................................1.......3 Associações Qualificadas .......1 Definição ...........................................2......................................7........................................1.......5 Associações Ordenadas ..... 33 Capítulo 7 ..................... 45 7..2.............................................................................3 Visão Lógica....7.......................7...........1 Associações Normais .........7.................................................... 46 7............................................ 39 7..7..............................

................................................. 69 9.......... 52 7................... 53 Capítulo 8 ................................................4 Diagramas de Objetos ................ 71 9.. 55 8............... 65 8..................................... 63 8.................................................................................................... 50 7...............6 Diagramas de Seqüência..............................7 Diagramas de Colaboração ........................................... 66 Capítulo 9 .........1 Fonte ........................3 Diagramas de Classes ....................... 62 8..............................................................................2 Documentação ... 68 9.....2....................DIAGRAMAS ..............................................7........6 Controle de Versões....................... 70 9.viii 7...............................................1 Conceito...................................................................................................................METODOLOGIA DESENVOLVIDA................................... 51 7...................... 50 7.......................................................................1 Introdução ........4 Impressão.1 Generalização Normal .... 69 9.................... 55 8............................................................................................2.......................................................2.................................................... 64 8...........................................................................2........... 72 ......................................................2.....7..2....................................................................2 Generalizações...........................10 Diagramas de Implantação ..2.................3 Dependências e Refinamentos ........................7...............................7..................2 Generalização Restrita ...8 Diagramas de Atividade ..................................... 59 8.......................................2.............. 57 8.... 71 9.................................................................................................2 Gravação da Documentação ..................................................................8 Mecanismos Gerais ..................................... 72 9......................5 Backup .......................................................2 Diagramas de Casos de Uso ..... 61 8.... 68 9......................9 Diagramas de Componentes .................5 Diagramas de Estados....... 56 8.....3 Extensão de Arquivos..........

........3 Eventos Iniciais .......... 89 9................................. 80 9....4 Resumo do Projeto................................. 83 9..........................4......3 Diagramas de Interação .......................5 Análise ............ 82 9................................................................4.............................................3 Definição dos Participantes ...................................................4................................4 Diagrama de Estado...................5 Diagrama de Atividade ......................................................................... 89 9........... 75 9..........4.1 Reunião/Entrevista .................3.................................4.................2 Diagrama de Colaboração ..........2 Estudo dos Dados ............5...............1 Diagrama de Seqüência ...........................5 Atores ......................4.............................................9 Análise de riscos ...................11 Aprovação ............... 79 9........... 79 9...............1 Diagrama de Classes ... 82 9.............................5.......................................................................................5........ix 9...4.................................. 86 9..................................... 81 9..3 Definições de responsabilidades ............................................................................ 85 9.....10 Cronograma .................... 87 9...8 Diagrama de caso de uso..........................................6 Projeto.....................................5................4.......6 Casos de Uso .............2 Diagrama de Objetos........................................4...................................... 90 .....................3...................................... 76 9......................................................................................................................................................5.........................1 Contatos ...................2 Preenchimento da ata da reunião.......... 84 9..........4..........................................................3...................... 74 9.................................3...................................4..............................................................................................................7 Escopo .4 Análise de requisitos .................................3................ 84 9... 84 9.............................. 73 9..... 76 9.................... 74 9.....................5..... 80 9..........5...................... 79 9................. 88 9.............................

......................2 Execução de Testes ............4 Teste de Sistemas ............8............... 99 9.2............ 113 .........................................2.................................................................. 93 9...................8......6............................................2... 110 10..... 108 10.................................................................4 Ata da Reunião . 97 9.......... 100 9......................9 Diagrama de Classes......8....................................7....... 106 10.........................3 Contatos Iniciais............................................................................8................................................. 91 9..................................... 102 9................................ 95 9.............................. 107 10........... 91 9.................1................2 Teste de Integração ............ 104 Capítulo 10 ........................................................1 Tradução .......................1 Introdução .......................................................................................2 Escolha da Linguagem ..........................................6.....8..................................................................1 Diagrama de componente......................................1 Teste de Unidade.................................................5 Resumo do Projeto ....................................................................................2 Formulário de Documentação ....... 95 9......... 111 10........................ 100 9....... 95 9...1 Diagrama de implementação....................3 Avaliação dos Resultados .........1...6 Escopo ........... 103 9......................... 106 10..7.......................6.............7 Implementação............x 9.........................2............................................................................7 Lista de Casos de Uso .............................................................................8....... 109 10...8 Testes ................................................... 104 9....... 99 9............................................................................7........ 106 10...1 Planejamento de Testes..............8....................................................................................3 Teste de Validação .........Validação da Metodologia ..............3 Documentação do Código ...............................2 Diagrama de implantação ............................................ 112 10...............8 Diagrama de Caso de Uso ...........

.............................................. 115 Capítulo 12 .......................... 120 Capítulo 13 ...................RESULTADOS OBTIDOS ........................................ 114 Capítulo 11 .........................1 Recomendações ....................xi 10........... 119 12......................BIBLIOGRAFIA ......................................................................................10 Escolha da Linguagem...... 121 ......................................CONCLUSÃO ..............................

....................................................................1 : Visões de Sistemas ............................................................................................................................8 : Componentes..........................3 : Atributos.. 43 Figura 7......................... 46 Figura 7............................................ 45 Figura 7.......................................................................5 : Objetos ............................................... 48 ..................... 11 Figura 6....... 38 Figura 7...............14 : Associações Ternárias...........................10 : Associações Recursiva...............................................................11 : Associações Qualificadas ........................................................................................ 37 Figura 7........... 39 Figura 7....xii LISTA DE FIGURAS Figura 2....................... 48 Figura 7................. 40 Figura 7............................1 : Análise Orientada a Objeto.....7 : Pacotes.................................2 : Projeto Orientado a Objetos ...............................................13 Associações de Classe ... 41 Figura 7..........12 : Associações Exclusivas .......................9 : Associações Normais ............................................................................ 36 Figura 7........................2 : Nomes ............................... 47 Figura 7........................ 10 Figura 2.......................6 : Estados..................................................................................................................................1 : Classes ........ 46 Figura 7. 42 Figura 7.................4 : Operações ................................. 31 Figura 7.................................................................................................................

.............................................................4 : Diagramas de Estados ............ 50 Figura 7........................................................16 : Agregação Compartilhada ...... 111 Figura 10.............................. 49 Figura 7..................17 : Agregação de Composição .....18 : Generalização Normal ..................................... 49 Figura 7....................................3 Diagrama de Classes do Sistema de Contabilidade....... 52 Figura 7................................................ 65 Figura 8.......6 : Diagramas de Colaboração .......................................................19 : Generalização de Sobreposição ............... 113 Figura 10........................21 : Relação de Dependência ...8 : Diagramas de Componentes ........................1 : Diagramas de Casos de Uso ................1 Escopo do Sistema.................... 49 Figura 7...... 52 Figura 7....... 60 Figura 8........................................................ 62 Figura 8............22 : Refinamentos......... 51 Figura 7............... 63 Figura 8....7 : Diagramas de Atividade ..............2 Diagrama de Caso de Uso do Sistema de Contabilidade................................ 67 Figura 10................................................... 64 Figura 8.......................... 53 Figura 7.......................................................................................................................................... 114 .................. 54 Figura 8.......3 : Diagramas de Objeto........................................9 : Diagramas de Implantação ........... 66 Figura 8........ 57 Figura 8....................................................23 : Ornamentos e Nota ...............................15 : Agregação .............................. 59 Figura 8.....................20 : Generalização Completa ...........................................................................................2 : Diagramas de Classes ......xiii Figura 7.........................................................................................5 : Diagramas de Seqüência .....................

Programação e Testes. desde os eventos iniciais. Este trabalho estuda a UML para que se possa criar uma metodologia de desenvolvimento de sistemas que englobe todas as fases do processo. Ao final do desenvolvimento de cada fase serão feitas observações que servirão de conclusão e base para futuros melhoramentos. OOSE de Jacobson e o OMT de Rumbaugh). é de extrema importância. da Rational Software Corporation no apoio a modelagem do sistema. até a conclusão das etapas de desenvolvimento de software. .xiv RESUMO Usar uma metodologia de desenvolvimento de sistema para captar desde os primeiros contatos. porém a UML não possui um método de trabalho a ser seguido. Projeto. Utilizaremos a ferramenta case Rational Rose. Para a validação da metodologia desenvolvida será aplicada no desenvolvimento de um protótipo. Análise. passando pela Análise de Requisitos. A UML(Unified Modeling Language) é a junção das três mais conceituadas linguagens de modelagem orientados a objetos (Booch de Grady.

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

Um bom entendimento da UML não é somente um conhecimento de . Com o lançamento da UML (Unified Modeling Language) desenvolvedores da área de orientação a objetos.INTRODUÇÃO 1. ficaram entusiasmados com sua abrangência. o mais avançado e adequado para ser utilizado em um projeto específico. Cada metodologia existente possui suas próprias notações (símbolos usados para projetar modelos orientados a objetos). processos e ferramentas. Isso faz com que a escolha do método a ser utilizado torne-se uma decisão extremamente importante e freqüentemente leva a discussões e debates sobre qual o melhor método.Capítulo 1 .1 Apresentação Um grande problema no desenvolvimento de novos sistemas utilizando a orientação a objetos é o fato de não existir uma notação padronizada e realmente eficaz que possa abranger qualquer tipo de aplicação. Pois a UML traz novos conceitos que normalmente não são usados.

a qual analisamos ser o mais eficaz às necessidades atuais de desenvolvimento. mas também um contexto geral de modelagem orientada a objetos. fácil de se comunicar com outras aplicações. possa ser modelado corretamente. Como conseqüência dessa pesquisa definiremos uma metodologia de desenvolvimento de sistemas baseada em UML. A UML é uma padronização de modelagem orientado a objetos de forma que qualquer sistema. . 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 visões da linguagem. com consistência. seja qual for o tipo. UML permite comunicar certos conceitos mais claramente que as linguagens alternativas [Fowler. suas aplicações. 2000]. simples de ser atualizado e compreensível. Com a junção das três mais conceituadas metodologias(Booch de Grady.2 sua símbologia e significados. Com este projeto pretendemos justamente pesquisar sobre esta linguagem de modelagem. com a perspectiva de desenvolver uma metodologia e aplicá-la desenvolvendo um protótipo. comprovando sua eficiência e funcionalidade.2 Objetivos Geral e Específicos Objetivamos com esta pesquisa o estudo aprofundado de uma metodologia unificada de desenvolvimento de sistemas orientado a objetos baseado em UML. 1. vantagens e desvantagens.

3 Especificamente.3 Justificativa Com as constantes inovações que surgem em ferramentas de desenvolvimento de sistemas orientados a objetos e a necessidade de desenvolvimento de sistemas mais complexos e precisos. Apresentação do protótipo desenvolvido. Mostrar a sociedade a importância do uso de uma metodologia no desenvolvimento de sistemas. • • • • Desenvolver uma metodologia de trabalho baseado em UML. Desenvolvimento de um protótipo usando a metodologia. os objetivos apresentados são: • • Obter amplos conhecimentos sobre UML. faz com que um estudo sobre uma metodologia unificada de desenvolvimento torne-se um grande atrativo a ser pesquisado. 1. . desenvolveremos o presente projeto com o intuito de apresentar a analistas uma metodologia de desenvolvimento e salientar a importância de sua aplicação. para modelagem do sistema. Para isto será desenvolvido um protótipo utilizando-se desta metodologia. • Estudar como se desenvolve uma metodologia de desenvolvimento de sistemas. a qual poderá resolver muitos problemas encontrados no decorrer de todo o desenvolvimento de um sistema. Estudo de uma ferramenta CASE. Com este interesse.

desenvolvedor. 1. Destacamos os principais tópicos : A modelagem de sistemas (não apenas de software) usando os conceitos da orientação a objetos. Conceitos sobre esta metodologia.5 Metodologia Para o desenvolvimento do Trabalho de Conclusão de Curso (TCC).4 1. Estabelecer um método de comunicação entre toda a equipe envolvida (cliente. visando sua melhor performance. analista. Estabelecer uma união fazendo com que métodos conceituais sejam também executáveis.4 Abrangência A UML tende a ser uma linguagem de desenvolvimento de sistemas orientado a objetos dominante. Por conseqüência este projeto pretende comprovar a eficácia do uso desta metodologia. . etc). serão definidas as seguintes etapas: • • • Estudo da metodologia UML. com base no desenvolvimento de um protótipo. comum entre os melhores analistas e desenvolvedores. Mostrar a sociedade a qualidade de um sistema desenvolvido com o uso da UML. Aprimoramento da metodologia usada.

etc. • • Desenvolvimento de um protótipo do sistema. sua aceitação.6 Estrutura Este capítulo apresentará a você leitor. Faremos uma descrição da base da análise e projetos orientado a objetos descrevendo seus pontos principais como classes. uma breve descrição de cada capítulo que constitui este trabalho. O capítulo 3 faz uma introdução à UML(Linguagem Unificada de Modelagem) dizendo o que ela nos disponibiliza. abstrações. objetos. 1. etc. Este capítulo é importante para o entendimento da análise orientada a objetos. No capítulo 2 descreveremos um breve conceito da análise e projetos orientado a objetos bem como sua necessidade. .5 • Estudo e definição de uma ferramenta CASE que melhor atenda a essa metodologia. Para um melhor entendimento do processo de criação da UML apresentaremos um histórico completo. Conclusão sobre a metodologia estudada e sua aplicação. surgimento. padronização e aplicações. Escolha de um sistema para aplicação da metodologia estudada comprovando sua eficácia. desde o início das pesquisas até a conclusão da última versão. • • Estudo e definição de ferramentas para desenvolvimento do sistema.

Pacotes. Componentes e Relacionamentos. descreve detalhadamente os 9(nove) tipos de diagramas utilizados pela UML. Descreve-se ainda em detalhes as 5(cinco) visões utilizadas e o uso de cada uma destas visões.6 O capítulo 4 descreve as etapas técnicas da UML. O capítulo 5 faz uma descrição sobre ferramenta CASE. Estas etapas vão desde os primeiros passos(Análise de Requisitos) até a fase de testes. exemplificando graficamente e indicando o uso de alguns tipos de diagramas. baseada nos conceitos tradicionais das atividades de desenvolvimento. No capítulo 6 é apresentado um conceito sobre visões em UML e qual a importância destas visões para o entendimento do sistema. O capítulo 8 apresenta um conceito genérico sobre diagramas em UML. apresenta algumas vantagens da aplicação desta ferramenta e também descreve sua aceitação no mercado. Ao final deste capítulo ainda apresentamos uma visão do futuro desta ferramenta. Estados. Objetos. tais como Classes. O capítulo 7 traz uma definição de modelos de elementos e descreve detalhadamente todos os modelos de elementos utilizados pela UML. .

7 No capítulo 9 apresentaremos a metodologia desenvolvida.

O capítulo 10 mostra um protótipo desenvolvido aplicando a metodologia do capítulo anterior.

No capítulo 11 mostraremos os resultados obtidos durante a validação de cada fase da metodologia.

No capítulo 12 faremos nossas conclusões sobre todo o TCC.

O

capítulo

13

apresenta

toda

a

bibliografia

utilizada

no

desenvolvimento do TCC.

Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A OBJETOS

2.1 Conceito

Com os enormes computadores da década de 1950 e 1960, e a pouca capacidade de processamento, desenvolvedores de programas tinham que aproveitar ao máximo todo bit que o hardware disponibilizava. Já na década de 1960 computadores transistorizados foram surgindo, o que na época já era um grande avanço, substituindo os enormes computadores de válvulas. Desenvolvedores mais radicais afirmavam que os algoritmos para os sistemas que esses computadores rodavam tinham que ser monolíticos. Ou

seja, se já se chegou na melhor fase do algoritmo não é necessário mais alterações ou manutenções, ficando do mesmo jeito até deixar de ser usado. Desenvolvedores menos radicais e com uma visão um pouco diferente, afirmavam que os sistemas tinham que ser modularizados para que

9 fossem de mais fácil manutenção e compreensão. Este conceito foi mais aceito a medida que os computadores foram aumentando sua capacidade. Precursores da analise orientada a objeto, defendiam que devíamos estruturar programas de computador de acordo com o problema a ser resolvido. O termo Orientação a Objetos sugere abstrações do mundo real e trechos de programas de computador, ou objeto. Um grande fator da orientação a objetos é a reusabilidade. Estamos reutilizando códigos de programas desde o início da computação. As técnicas de orientação a objetos nos permitem muito mais que a reutilização de códigos, podemos reutilizar requisitos, análise, projeto, planejamento de testes, interfaces de usuário e arquiteturas, ou seja todos os componentes de engenharia de software podem ser encapsulados como reutilizáveis.

2.2 Análise Orientada a Objetos

Análise é o estudo de um problema, antes de qualquer ação [De Marco, 1978] Análise é o estudo do domínio de um problema que leva a uma especificação de comportamentos observáveis externamente. É uma

declaração completa, consistente e possível do que é necessário, um conjunto de características operacionais quantificadas e funcionais. Analisar é obter as necessidades de um sistema e o que este precisa ser desenvolvido para satisfazer as necessidades do usuário. Analisar não é definir como o sistema será desenvolvido, mas sim investigar o problema conforme mostra a Figura 2.1.

etc. recomendações. . ou seja.10 A AOO tem dois propósitos. Figura 2. em busca da solução do problema conforme mostra a Figura 2. instruções.3 Projeto Orientado a Objetos O Projeto Orientado a Objetos (PjOO) é visto como o processo de especificação das partes da construção.2. estipulações. regras. Primeiramente formalizar uma “visão” do mundo real dentro do qual o sistema será desenvolvido. Utilizamos estes processos para implementar um sistema em um ambiente específico. estabelecendo os objetos que servirão como principais estruturas organizacionais do sistema de software e também as que o mundo real impõe.1 : Análise Orientada a Objeto 2. a AOO formaliza a colaboração de um dado conjunto de objetos na execução do trabalho do sistema de software que está sendo especificado. Esta formalização representa como cada objeto se comunica com os demais. qualificações. Em segundo lugar.. guias.

campos de dados e campos que são funções para operar os campos de dados do registro [Furlan.2 : Projeto Orientado a Objetos 2.11 Durante a PjOO é dado ênfase na elaboração dos elementos lógicos do software [Larman. troca . os quais possuem atributos e métodos. 1994]. 2000]. Objeto é uma entidade independente. 2.5 Objetos Um objeto é simplesmente alguma coisa que faz sentido no contexto de uma aplicação [Rumbaugh. Sendo implementados em uma linguagem de programação orientada a objetos. encapsula serviços. Figura 2. 1998]. assíncrona e concorrente.4 Classes Uma Classe em linguagens Orientadas a Objetos é a possibilidade de combinar num único registro. armazena dados.

2 Abstração de dado s Consiste em definir um tipo de dado conforme as operações aplicáveis aos objetos deste tipo. estes objetos só podem ser modificados e observados através destas operações.6 Abstração Abstração é o princípio de ignorar os aspectos de um assunto não relevante para o propósito em questão. mesmo que a operação seja realmente conseguida operações de nível mais baixo. ignorando outros.6. Porém. Existem duas formas de abstração. 2. e é modelado para executar as funções finais do sistema. de Procedimentos e de Dados. 2.12 mensagens com outros objetos. 1991]. através de alguma seqüência de 2.6.1 Abstração de Proc edimentos Princípio de que qualquer operação com um efeito bem definido pode ser tratada por seus usuários como uma entidade única. tornando possível uma concentração maior nos assuntos principais [Cood. Consiste na seleção que o analista faz de alguns aspectos. .

não permitindo que o usuário do objeto os acesse diretamente.7 Encapsulamento Encapsular é omitir informações pelo princípio de que uma determinada entidade esconde informações as quais são necessárias apenas à mesma. Mas sim através de métodos se houver necessidade[Furlan. . 2. 1998].8 Herança Esta é provavelmente a característica mais discutida da abordagem orientada a objetos [Mazzola. É fundamental que o objeto proteja seus dados. assim como especializar e estender estes atributos e serviços em casos específicos.13 2. Através da herança uma determinada subclasse herda todos os atributos e métodos da superclasse. É a principal característica do processo de Generalização/Especialização. 1999]. Permite a um analista especificar serviços e atributos comuns uma só vez.

.9 Polimorfismo È o conceito usado em linguagens de programação orientada a objetos para denotar a característica de que a linguagem suporta a utilização do mesmo identificador (o mesmo nome) para métodos de classes diferentes.14 2. 2000]. Um conceito em teoria de tipo no qual um nome (como uma declaração de variável) pode denotar objetos de muitas subclasses diferentes que são relacionadas por alguma superclasse comum. qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes [Booch. assim.

documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação [Furlan. . incluindo seus aspectos conceituais tais como processos de negócios e funções do sistema. visualizar. 1998].1 Introdução A UML é a linguagem padrão para especificar. além de itens concretos como as classes escritas em determinada linguagem de programação. processos de banco de dados e componentes de software reutilizáveis. A UML disponibiliza uma forma padrão de modelagem de projetos de Sistemas.Capítulo 3 .UML 3.

A quantidade de métodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o período de 1989 a 1994. O método Booch destacava-se durante as fases de projeto e construção de sistemas. Grady Booch (Rational Software Corporation). começaram a pegar as melhores idéias e partiram para a criação de uma linguagem unificada de modelagem. Na metade da década de 1990. Todos eram métodos completos. a análise e o projeto em alto nível. e o OMT (Object Modeling Technique) de Rumbaugh. Destacaram-se algumas linguagens como o Booch. diante de um novo gênero de linguagens de programação orientadas a objeto e de aplicações cada vez mais complexas.2 Histórico As linguagens de modelagem orientadas a objetos surgiram entre a metade da década de 1970 e o final da década de 1980. Podemos citar outros métodos importantes como Fusion. Muitos usuários desses métodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender inteiramente às suas necessidades. o OOSE fornecia excelente suporte para captura de requisitos. à medida que o pessoal envolvido com metodologia. Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com os quais os desenvolvedores de ferramentas pudessem criar uma . porém tinham suas limitações.16 3. 2000]. Shlaer-Mellor e Coad-Yourdon. alguns se destacavam em algum ponto. o OMT-2 era mais útil com a análise e sistemas de informações com uso de dados[Booch. o OOSE (Object-Oriented Software Engineering) de Jacobson. Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de métodos orientados a objetos. começou a experimentar métodos alternativos de análise e projeto.

expressiva. foi então criada um consórcio com várias empresas interessadas em dedicar recursos com o propósito de trabalhar uma definição mais forte e completa da UML. O esboço da versão 0. Muitas empresas ficaram interessadas.8 do Método Unificado foi lançado em outubro de 1995. 1998]. em resposta à solicitação do próprio OMG de propostas para uma linguagem padrão de modelagem[Furlan. Resultando uma linguagem de modelagem bem definida . A UML foi oferecida para a OMG (Object Management Group) em janeiro de 1997. IBM. Rational.9 da UML em junho de 1996[Booch. podendo ser utilizado por seres humanos e máquinas[Furlan. Foi então aprovada pela comunidade de engenharia de software em geral. Intel-licorp. não somente a sistemas complexos mas também a sistemas menores e também a outros problemas que não fossem sistemas de informação. 2000]. 1998]. poderosa. Usando técnicas orientadas a objeto criariam uma linguagem que iria desde o conceito até o sistema executável. e que poderia ser aplicada a uma grande variedade de tipos de problemas[Booch. Microsoft. Digital Equipment Corporationm Hewlett-Packard. ICON Computing. 1998]. Texas Instruments e Unisys. resultando o lançamento da versão 0. A criação da UML iniciou oficialmente em outubro de 1994.8. Empresas que contribuíram para a definição da UML 1. 2000]. .0. O foco inicial do projeto era a unificação dos métodos Booch e OMT[Furlan. Oracle.17 ferramenta mais utilizável. quando Rumbaugh se juntou a Booch na Rational. Mais ou menos na mesma época Jacobson se associou à Rational com a finalidade de incorporar o OOSE no escopo inicial da versão 0. I-Logix. MCI Systemhouse.

passando a incluir virtualmente todos os participantes e colaboradores da resposta inicial ao OMG. a UML 1. Empresas desenvolvedoras de ferramentas estão livres para criarem uma ferramenta aqueda ao uso da UML. Reich Technologies. Ericson. sob a responsabilidade de Cris Kobryn. 3. Object Time Limited. 2000]. Platinum Technology. em junho de 1998. Ptech. onde os mesmos pudessem criar seu próprio método de trabalho. 1998]. com o propósito de formalizar a especificação da UML e de integrar a linguagem a outros esforços de padronização. A versão 1. Softeam. Devido a necessidade de criação da . Em setembro do mesmo ano. essa versão foi aceita pela ADTF (Analysis and Design Task Force) e pelo Architecture Board do OMG e.3[Furlan. No final do mesmo ano. Sterling Software e Taskon.. entre os quais se encontravam Andersen Consulting. A versão 1.18 Entre janeiro a julho de 1997.2. a RTF lançou a UML 1.1 foi adotada pela OMG em 14 de novembro de 1997[Booch. Preocuparamse em deixá-la aberta aos desenvolvedores.3 Aceitação Os criadores da UML procuraram desenvolver uma linguagem unificada padrão que pudesse ser de fácil entendimento a todos. A manutenção da UML foi então assumida pela RTF (Revision Task Force) do OMG. liberado por Cris Kobryn da MCI Systemhouse e administrado por Ed Eykholt da Rational. A RTF lançou uma revisão editorial.1 foi entregue a OMG em julho de 1997. posteriormente submetida a votação de todos os membros da OMG. Um grupo foi formado. o grupo original se expandiu.

Pois para serem realmente utilizadas por empresas era necessário sua padronização. mas também pode ser aplicada em sistemas mecânicos. Então houve interesse dos criadores da UML em padronizá-la. de engenharia em geral. os criadores tinham como intenção fazer sua aceitação com a distribuição da linguagem a vários desenvolvedores. A OMG (Object Management Group) fez um requerimento por uma linguagem de modelagem padrão. É aplicada em qualquer tipo de sistemas em termos de diagramas de orientação a objeto.5 Aplicação A UML pode ser usada para modelar várias fases de um sistema. desde os primeiros contatos até a geração do código. pode também ajudar na organização de processos de uma organização. 3. . para isso foi preciso que os mesmos aprimorassem a qualidade da linguagem para tal. Geralmente é mais usada na modelagem de Softwares usando o conceito de orientação a objetos.4 Padronização OM G Quando se iniciaram os trabalhos para criação da UML.19 UML empresas e profissionais liberais da área estão desenvolvendo estudos para melhor aplicá-la. 3.

desta forma comunicando a todos os envolvidos no projeto da forma mais clara possível.Capítulo 4 . 2001].1 Análise de Requis itos Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases" [Barros. Através do desenvolvimento de casos de uso(em UML chamamos de “use-cases”). Os atores externos e os "use-cases" são modelados com . É a descrição das necessidades ou desejos de um determinado sistema. de maneira não-ambígua de modo que os riscos sejam identificados sem correr riscos de imprevistos. as entidades externas ao sistema (em UML chamamos de "atores externos") que interagem e possuem interesse no sistema são modelados entre as funções que eles requerem. O princípio básico da análise de requisitos é identificar e documentar o que é realmente necessário. funções estas chamadas de "use-cases".ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML 4.

Um “use-case” tanto pode depender de um ou mais “use-case” como pode ter seus dependentes. Descrevemos um “use-case” através de um texto especificando os requisitos do ator externo que utilizará este “use-case”.3 Projeto Projeto cria uma representação do domínio de problema do mundo real e leva-a a um domínio de solução que é o software [Pressman. 2000]. Nesta fase modelamos somente as classes que pertencem ao domínio principal do problema. Através do diagrama de “use-cases” mostraremos aos atores externos(futuros usuários) o que estes podem esperar do sistema. e não apenas para sistemas de software 4. 1995]. podendo estas estar ligados uma nas outras através de relacionamentos.2 Análise A fase de análise preocupa-se com as primeiras abstrações(classes e objetos) e mecanismos presentes no contexto do problema[Larman. A análise de requisitos também pode ser desenvolvida baseada em sistemas de negócios. ou seja. 4. classes técnicas mais detalhadas não estarão neste diagrama. .21 relacionamentos que possuem comunicação associativa entre eles ou são desmembrados em hierarquia. Descrevemos as classes nos Diagramas de Classes e também para ajudar na descrição dos “use-cases”.

a tarefa de codificação é facilitada [Furlan. Cabendo esta tarefa à fase de programação. consequentemente converteremos as classes da fase do projeto para o código da linguagem orientada a objetos escolhida. podendo assim alterar tanto o domínio principal do problema quanto a infra-estrutura. É feita uma junção das classes da fase da análise com as classes técnicas da nova infra-estrutura.4 Programação Para que uma fase de programação possa ter um bom desempenho. através dos resultados obtidos na fase da análise. Se o desenho foi elaborado corretamente e com detalhes suficientes. . 4. 1998]. devemos evitar traduzi-los em códigos. banco de dados. e outras mais. interação com outros sistemas.A complexidade dessa conversão vai depender da capacidade da linguagem escolhida. no entanto esta pode tornar-se fácil ou difícil de se realizar. Serão adicionadas novas classes para oferecer uma infra-estrutura técnica tais como: interface do usuário e periféricos. necessitamos de um projeto bem elaborado.22 Nesta fase partimos para as soluções técnicas. Com a elaboração do projeto obtemos detalhadamente as especificações para dar inicio a fase de programação. Em UML durante a elaboração dos modelos de análise e projeto.

uma pelos programadores. sabendo desta forma onde estão os pontos mais críticos que podem causar falhas. . 1995]. Nos testes de aceitação é verificado se o sistema está de acordo com o especificado no diagramas de “use-cases”. tendo a visão da rotina como um todo.23 4. A outra forma de testes de uma rotina é feita por outro usuário.5 Testes Na fase de teste executamos um programa com a intenção de descobrir um erro[Pressman. Os testes de integração são feitos usando as classes e seus componentes de integração para verificar se estas classes estão realmente colaborando uma com as outras conforme especificado nos modelos. Testamos cada rotina ou processo detalhadamente. bem como a integração de todos os processos e a aceitação. As rotinas devem ser testadas de duas formas. pois estes tem um conhecimento das classes e grupo de classes que envolvem esta rotina. o sistema será testado pelo usuário final e este verificará se os resultados apresentados estão realmente de acordo com suas intenções expressas no início do projeto. pois este irá fazer um teste do seu modo. Por fim.

etc) mas não se utilizavam de software para fazer seu trabalho. e também pela unificação de planejamentos administrativos com a análise. Medicina. Com a crescente demanda pela qualidade e integração de softwares.1 Conceito O termo CASE(Computer-Aided Software Engineering) significa Engenharia de Software Auxiliada por Computador. Tinham necessidade de visualizar o projeto como um todo. 1991]. projeto e geração de sistemas.Capítulo 5 . . surgiu então as denominadas Ferramentas Case. Antigamente. os analistas desenvolviam software para outras áreas (como Engenharia. ao invés de analisálo em partes. Arquitetura.FERRAMENTAS CASE 5. É difícil de acreditar que ferramentas de software tão simples estejam ficando cada vez mais importantes nos dias de hoje [Cood.

. auxiliando também na manutenção do sistema. que visam desde a análise/projeto até a geração do código. proporcionando alto nível de documentação. a aprovação das definições de processos. • Case's de automação de uma fase(ou mais) de desenvolvimento. segue como linha base a Orientação a Objetos. possibilitando a comunicação com o usuário. tanto em forma de textos como em forma gráfica. As ferramentas CASE se dividem em 3 tipos: • Integrated System CASE (I-CASE) . não esquecendo de nenhum passo da metodologia usada. • Ferramentas que seguem uma metodologia especifica. O próprio Rational Rose.25 Uma Ferramenta Case é um software que auxilia no ciclo de desenvolvimento de um sistema desde a fase de análise até a fase de testes. fluxos de informações e atributos de entidades. tal como antigo Composer By IEF que seguia a engenharia da informação. Tentam abranger tudo. são 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). Apoiam na utilização de metodologias e métodos. armazenam informações em sua base de dados. porém "superlota" uma etapa com vários tipos de sub-ferramentas com a intenção de abranger várias metodologias.

as quais são mais sucetíveis ao erro. mais produtos em menos tempo. as ferramentas contribuem para uma maior agilidade no desenvolvimento de software. • Produtividade: ao ajudar na realização de tarefas e até mesmo ao realizar algumas automaticamente. que exigem tomada de decisão e criatividade. • Eliminação de trabalho que muitas vezes não agregam valor ao produto final: as ferramentas CASE podem realizar algumas tarefas cansativas para os desenvolvedores.26 5. ao invés de tarefas repetitivas. deixando mais tempo para que a equipe técnica se preocupe . tais como procurar informações e desenhar símbolos de um diagrama.2 Vantagens Citamos algumas vantagens com a utilização de Ferramentas CASE • Maior qualidade dos produtos finais: as ferramentas CASE diminuem a probabilidade de erros. • Menos programação: as ferramentas eliminam muito tempo do trabalho de programação. estas ficam liberadas para outras tarefas. • Mais tempo para a tomada de decisão: em conseqüência de as ferramentas realizarem certas atividades pelas pessoas. ao auxiliarem as fases de Análise e Teste do produto pelo usuário. • Flexibilidade para mudanças: as ferramentas permitem que sejam mudados dados e diagramas de maneira mais rápida e fácil. uma vez que podem ajudar no controle de consistência dos dados em um ambiente de desenvolvimento. isto é. geralmente mais nobres. o que ajuda o desenvolvedor no trabalho de tentar satisfazer o usuário. também proporcionam maior eficácia dos produtos.

. agilizando relatórios. considerando suas vantagens não vemos outra saída para um projeto bem desenvolvido e documentado. há também a difusão do termo I-CASE. • Melhor documentação: por armazenarem dados e diagramas. portanto seu uso é de extrema importância. • Manutenção mais fácil e ágil: por conseqüência do item anterior. isto é. Hoje em dia. busca de informações e alterações. que é onde se define como solucionar o problema do usuário. atualização ou expansão). As Ferramentas Case nos auxiliam em todas as fases do projeto. que é usado para caracterizar um grupo de ferramentas CASE integradas. que se relacionam entre si (entradas e saídas) e que permitem controlar a consistência dos dados quando seguimos uma metodologia. é possível ter mais informações sobre o software na hora de realizar sua manutenção (correção. as ferramentas também contribuem para uma melhor documentação do sistema.3 Aceitação no Mer cado A aceitação de ferramentas CASE ocorreu com diagramas como o DFD e o E-R.27 com a Análise do Sistema. que só foram amplamente utilizados quando surgiram as primeiras ferramentas para auxiliar na tarefa de diagramação. 5.

de códigos a partir da mesma modelagem. Ou melhor. O conceito de CASE's apenas se transformou. 5. evoluirão não de uma forma fechada. sendo também possível a geração. um repositório para os produtos gerados por processos de análise e projetos orientados a objetos. Entender o conceito é importante. As versões mais novas ferramenta contemplam até a interação com ambientes de desenvolvimento das mais variadas linguagens existentes no mercado [DBSERVER. A palavra de ordem dos CASE's de amanhã é diversidade e especialização. mas de uma forma aberta de maneira que as mesmas cada vez mais se integrarão com outras ferramentas de fabricantes distintos. O padrão UML é o mais utilizado hoje em dia. sendo também. O conceito de CASE de amanhã nasceu hoje. sofreu uma mutação mercadológica dado o poder dos fabricantes. 2001].5 Rational Rose Rational Rose é uma ferramenta CASE para desenvolvimento de sistemas orientados a objetos. pois com ele há uma documentação interativa e automática dos processos de modelagem. Ela acelera esse desenvolvimento de análise e projetos utilizando metodologias de desenvolvimento muito difundidas no meio da informática. pela ferramenta.28 5. principalmente o padrão Unified Modeling Language (UML). .4 O Futuro Podemos dizer que as ferramentas CASE. mas entender a evolução do mesmo é também importante.

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

Capítulo 6 . cada visão mostra alguma particularidade do sistema e estão em alguns de diagramas.1 Conceito O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por completo as reais intenções do sistema sem ambigüidades.VISÕES DE SISTEMAS 6.) e aspectos organizacionais (organização do trabalho. etc. podendo uma visão fazer parte de uma ou mais visões. 2001]. não funcional (requisitos de tempo.). Algumas visões estão interligadas através de diagramas. confiabilidade. Um sistema é composto por diversos aspectos: funcional (que é sua estrutura estática e suas interações dinâmicas). sendo facilmente interpretável [Barros. desenvolvimento. Os diagramas que compõem as . mapeamento dos módulos de código. Descrevemos um sistema em várias visões. etc.

31 visões contém os modelos de elementos do sistema. Em contraste com a visão use-case. É feita principalmente pelos analistas e desenvolvedores.1 apresenta as cinco visões de sistemas. Figura 6.2 Visão USE-CASE Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usuários).1 : Visões de Sistemas 6. Ela . A visão use-case é central.3 Visão Lógica Descreve como a funcionalidade do sistema será implementada. a visão lógica observa e estuda o sistema internamente. 6. já que seu conteúdo é base do desenvolvimento das outras visões do sistema. A Figura 6. Essa visão é montada sobre os diagramas de use-case e eventualmente diagramas de atividade.

que são os diagramas . 6. A visão de concorrência é suportada pelos diagramas dinâmicos. A estrutura estática é descrita pelos diagramas de classes e objetos. bem como as interfaces e as estruturas de classes. colaboração e atividade. e relacionamentos) e as colaborações dinâmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funções do sistema. se o mesmo possui execuções paralelas. É principalmente executado por desenvolvedores. Uma vez dividido o sistema em linhas de execução de processos concorrentes (threads). que é uma propriedade não funcional do sistema. e consiste nos componentes dos diagramas. O modelamento dinâmico é descrito pelos diagramas de estado. 6. e se existe dentro do sistema um gerenciamento de eventos assíncronos. seqüência. permite uma melhor utilização do ambiente onde o sistema se encontrará.4 Visão de Compon entes É uma descrição da implementação dos módulos e suas dependências. Este aspecto.32 descreve e especifica a estrutura estática do sistema (classes. objetos. Propriedades como persistência e concorrência são definidas nesta fase. esta visão de concorrência deverá mostrar como se dá a comunicação e a concorrência destas threads.5 Visão de concorrê ncia Trata a divisão do sistema em processos e processadores.

integradores e testadores. . a visão de organização mostra a organização física do sistema. e será representada pelo diagrama de execução. seqüência. e pelos diagramas de implementação. que são os diagramas de componente e execução.33 de estado. Esta visão será executada pelos desenvolvedores.6 Visão de Organiza ção Finalmente. os computadores. os periféricos e como eles se conectam entre si. 6. colaboração e atividade.

mas existem regras que definem quais elementos podem ser mostrados em que tipos de diagramas. Os relacionamentos também são modelos de elementos.Capítulo 7 . a definição formal do elemento com o exato significado do que ele representa sem definições duvidosas ou ambíguas e também define sua representação gráfica que é mostrada nos diagramas da UML. Um modelo de elemento é definido com a semântica. e são usados para conectar outros modelos de elementos entre si. pacotes e componentes. Um elemento pode existir em diversos tipos de diagramas.1 Definição Os conceitos usados nos diagramas são chamados de modelos de elementos [Barros. estados. objetos. 2001]. .MODELOS DE ELEMENTOS 7. Alguns exemplos de modelos de elementos são as classes.

1). onde a classe descreve as propriedades e comportamentos daquele objeto.35 7. que conterá apenas o nome da classe modelada.2 Classes As classes são os blocos de construção mais importantes de qualquer sistema orientado a objetos [Booch. embora pode ser usadas outras sintaxes como a do C++. e o compartimento de operações. 2000]. operações. e etc. Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmo atributos. Todos os objetos são instâncias de classes. . A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem de programação. o de atributos. Podem ser implementadas em uma ou mais interfaces. Em UML as classes são representadas por um retângulo dividido em três compartimentos: o compartimento de nome. que possuirá a relação de atributos que a classe possui em sua estrutura interna. Java. relacionamentos e semântica. que serão os métodos de manipulação de dados e de comunicação de uma classe com outras do sistema(ver Figura 7.

ou com caminho como mostra a Figura 7.1 : Classes 7. Uma classe pode ter um nome simples. . Usamos uma seqüência de caracteres para identificá-las.2. O caminho identifica o pacote ao qual a classe pertence.36 Figura 7.1 Nomes Todas as classes devem ter um nome que as diferencie das demais.2.

Uma classe pode ter qualquer número de atributos ou nenhum.2 Atributos Um atributo é uma propriedade de uma classe. Um atributo representa o tipo de dados ou estados que cada item de uma classe pode assumir. .3).2 : Nomes 7.37 Figura 7. são representados logo após o nome da classe (veja Figura 7. que descreve um intervalo de valores que as instâncias da propriedade podem apresentar.2.

você não mostra as operações que simplesmente manipulam atributos. as operações correspondem a métodos públicos. o seu valor nunca muda).2. você poderá ter que identificar seu um dado atributo é somente para leitura(isto é.3 : Atributos 7. Operações correspondem claramente a métodos em uma classe. Entretanto. No modelo de implementação.38 Figura 7.3 Operações Operações são os processos que a classe pode realizar. você também pode querer mostrar operações privativas(private) e protegidas(protected). No nível de especificação. porque elas podem ser freqüentemente inferidas. Uma classe pode ter várias operações ou até mesmo nenhuma. são representadas logo após os atributos (veja Figura 7.4). Normalmente. .

39 Figura 7. .5.3 Objetos Os objetos são elementos que podemos manipular. e o nome do objeto pode ser mostrado opcionalmente precedido do nome da classe. ou até destrui-lo.4 : Operações 7. ou negócio. uma organização.Por exemplo. interagir com ele. Corresponde a qualquer coisa que tenha algum significado para uma dada aplicação [Mazzola. Em UML um objeto é mostrado como uma classe só que seu nome é sublinhado. Um objeto pode existir no mundo real ou pode ser uma derivação de estudos da estrutura e comportamento de outros objetos do mundo real. uma máquina. criar. acompanhar seu comportamento. 1999]. conforme mostra a Figura 7.

Analisando as mudanças de estado que um objeto pode sofrer. Atributos e Atividades. o fato do objeto alterar o seu estado chamamos de evento. realiza alguma atividade ou aguarda um evento [Booch. Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto. Um objeto muda de estado quando acontece algo.6): Nome do Evento. normalmente este estado é determinado pelos valores dos atributos e ligações com outros objetos. 2000]. Um estado pode ter três compartimentos (veja Figura 7. .5 : Objetos 7.40 Figura 7. podemos prever todos os possíveis comportamento de um objeto de acordo com os eventos que o mesmo possa sofrer.4 Estados Um estado é uma condição ou situação na vida de um objeto durante a qual o objeto satisfaz alguma condição.

Sair : usado para definir atividades que o objeto executa antes de passar para o próximo estado.41 • Nome do Evento . Está dividido em três eventos padrões : Entrar. Fazer : usado para definir atividades que o objeto executa enquanto se encontra naquele estado. • Atributos – mostra as variáveis de estado. onde os atributos do objeto em questão pode ser listados e atualizados. Figura 7. • Atividades – o compartimento de atividades é onde podemos listar os eventos e ações.mostra o nome do evento. Sair e Fazer.6 : Estados . geralmente este nome descreve o que este estado realiza. Entrar : usado para definir atividades no momento em que o objeto entra naquele estado.

podendo. Um pacote possui vários modelos de elementos. refinamento e generalização (herança).7 : Pacotes Pacotes podem importar modelos de elementos de outros pacotes.5 Pacotes Pacote é um mecanismo de propósito geral para organizar elementos de modelo em grupos. . os pacotes possuem relacionamentos com outros pacotes. inclusive. Figura 7. Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de "Conteúdo do pacote".42 7. Os relacionamentos permitidos entre pacotes são de dependência. Embora estes não possuam semânticas definidas para suas instâncias. refere-se apenas ao pacote que possui o elemento. Quando um modelo de elemento é importado. e isto significa que estes não podem ser incluídos em outros pacotes. estar aninhando dentro de outros pacotes(pacotes subordinados) [Furlan. Na grande maioria dos casos.7). 1998] (ver Figura 7.

class é um componente do sistema.8 : Componentes 7. Se este for destruído. 7.6 Componentes Um componente pode ser tanto um código em linguagem de programação como um código executável já compilado. Possuímos três tipos de relacionamentos: associação.43 O pacote tem uma grande similaridade com a agregação. todo o seu conteúdo também será. . 2001]. cada arquivo .java ou . e será mostrado no diagrama de componentes que os utiliza. Por exemplo.8 a representação de componentes.7 Relacionamentos Os relacionamentos ligam classes/objetos entre si criando relações lógicas entre estas entidades [Barros. Figura 7. Veja na Figura 7. generalização e Dependência/Refinamentos. em um sistema desenvolvido em Java. O fato de um pacote ser composto de modelos de elementos cria uma agregação de composição.

1 Associações Norm ais O tipo mais comum de associação é apenas uma conexão entre classes. O elemento mais específico pode conter apenas informações adicionais.1. Uma modificação é um elemento independente afetará diretamente elementos dependentes do anterior. Em UML. 7. A associação . Refinamento é um relacionamento entre duas descrições de uma mesma entidade.44 • Associação: É uma conexão entre classes.Representa a ligação entre classes ou objetos de classes. 7. • Dependência e Refinamentos: Dependência é um relacionamento entre elementos.7. Uma associação é definida em UML como relacionamento. uma associação é definida com um relacionamento que descreve uma série de ligações. mas em níveis diferentes de abstração. um independente e outro dependente. • Generalização: É um relacionamento de um elemento mais geral e outro mais específico. Uma instância (um objeto é uma instância de uma classe) do elemento mais específico pode ser usada onde o elemento mais geral seja permitido. podendo ambas conhecer-se. e também significa que é uma conexão entre objetos daquelas classes.1 Associações Associação é uma relação que descreve um conjunto de vínculos entre elementos de modelo [Furlan.7. É representada por uma linha sólida entre duas classes. 1998]. onde a ligação é definida como a semântica entre as duplas de objetos ligados.

e ainda podemos representar a conexão entre dois objetos. 4. normalmente um verbo. zero para vários (0. . significando um nome para cada sentido da associação (ver Figura 7.1). O intervalo pode ser de zero para um (0. Para expressar a multiplicidade entre os relacionamentos. dois (2).1.12). mas substantivos também são permitidos.45 possui um nome (junto à linha que representa a associação).. um intervalo indica quantos objetos estão relacionados na ligação.2 Associações Recu rsivas Podemos conectar uma classe a ela mesma.* ou apenas *).7.9). 6.. usando uma associação recursiva.. cinco para 11 (5. sendo os mesmos da mesma classe. Figura 7.9 : Associações Normais 7..*). Pode-se também colocar uma seta no final da associação indicando que esta só pode ser usada para o lado onde a seta aponta.1 ou apenas 1).10. conforme mostra a Figura 7... Se não for descrito nenhuma multiplicidade. um para vários (1. É também possível expressar uma série de números como (1.11) e assim por diante. Mas associações também podem possuir dois nomes. então é considerado o padrão de um para um (1.

.7.11). O identificador é desenhado como uma pequena caixa no final da associação junto à classe de onde a navegação deve ser feita (ver Figura 7. Ela especifica que objetos de uma classe podem participar de no máximo uma das associações em um dado momento.10 : Associações Recursiva 7. e pode ser visto como um tipo de chave para separar todos os objetos na associação.*) ou vários para vários (*). Figura 7.46 Figura 7.11 : Associações Qualificadas 7.3 Associações Quali ficadas Associações qualificadas são usadas com associações de um para vários (1.1. Uma associação exclusiva é representada .1. O "qualificador" (identificador da associação qualificada) especifica como um determinado objeto no final da associação "n" é identificado.4 Associações Exclu sivas Podemos encontrar em alguns modelos combinações não válidas.7. Uma associação exclusiva é uma restrição em duas ou mais associações.

1. mas na própria linha da associação. com a especificação "{ou}" sobre a linha tracejada. Este tipo de associação não é conectada a nenhuma das extremidades da associação já existente. Podemos resolver este problemas usando a associação ordenada.1.6 Associações de Cl asse Uma classe pode ser associada a uma outra associação. 7. ajudando pois existem casos que a ordem precisa estar concisa para o entendimento da associação.12 : Associações Exclusivas Conforme figura 7.47 por uma linha tracejada entre as associações que são parte da associação exclusiva. significando que o relacionamento é exclusivo a somente uma das duas classes. Esta associação serve para se adicionar informações extra a associação já existente (ver Figura 7.13). O padrão para uma associação é desordenada ou seja não possui uma ordem específica.12 um contrato não pode se referir a uma pessoa e a uma empresa ao mesmo tempo. Podemos escrever está associação apenas como {ordenada} junto a linha da associação.5 Associações Orden adas As associações entre objetos podem ter uma ordem implícita. Figura 7.7. 7.7. .

Se operações ou atributos são adicionados à associação. traçaria-se. 7. para ler e remover da fila e de ler o seu tamanho. . Figura 7.7.14 a associação ternária especifica que um cliente poderá possuir 1 ou mais contratos e cada contrato será composto de 1 ou várias regras contratuais.7 Associações Terná rias A associação ternária e a associação entre três classes. ela deve ser mostrada como uma classe. uma linha tracejada a partir do losango para a classe onde seria feita a associação ternária.1.48 Figura 7.13 Associações de Classe A associação da classe Fila com a associação das classes Cliente e Processo pode ser estendida com operações de adicionar processos na fila.14 : Associações Ternárias Conforme mostra a Figura 7. então. Ela é mostrada como um grade losango (diamante) e ainda suporta uma associação de classe ligada a ela.

Figura 7.1. "contém".7. Se o objeto da classe que contém for destruído.15 : Agregação Existem tipos especiais de agregação que são as agregações compartilhadas e as compostas. as classes da agregação de composição serão destruídas juntamente já que as mesmas fazem parte da outra (ver Figura 7. As palavras chaves usadas para identificar uma agregação são: "consiste em".17).15). indica que uma das classes do relacionamento é uma parte.17 : Agregação de Composição .16).16 : Agregação Compartilhada • Agregação de Composição: É uma agregação onde uma classe que está contida na outra "vive" e constitui a outra. Figura 7. ou está contida na outra. "é parte de" (ver Figura 7. mas esta parte pode estar contida na outra várias vezes em um mesmo momento (ver Figura 7. Figura 7.49 7. ou está contida em outra classe. • Agregação Compartilhada: É dita compartilhada quando uma das classes é uma parte.8 Agregação A agregação é uma caso particular da associação.

A generalização. operações e todas as associações são herdadas. chamada de superclasse (ver Figura 7. São elas: generalização normal e restrita. chamada de subclasse.7.50 7.2. . herda tudo da classe mais geral. também chamada de herança. 7.2 Generalizações Um relacionamento de taxinomia entre um elemento mais geral e um elemento mais específico que é completamente consistente com o primeiro elemento somando-o informação adicional especializado [Furlan. permite a criação de elementos especializados em outros. disjuntiva.7. Existem alguns tipos de generalizações que variam em sua utilização a partir da situação.18). se ela estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações. As generalizações restritas se dividem em generalização de sobreposição. A generalização normal é representada por uma linha entre as duas classes que fazem o relacionamento. Os atributos. Figura 7.18 : Generalização Normal Uma classe pode ser tanto uma subclasse quanto uma superclasse. 1998]. Um objeto mais específico pode ser usado como uma instância do elemento mais geral. completa e incompleta. sendo que coloca-se uma seta no lado da linha onde encontra-se a superclasse indicando a generalização.1 Generalização Nor mal Na generalização normal a classe mais específica.

51 7. As restrições a seguir definem as generalizações restritas com mais de uma subclasse: • Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição significa que quando subclasses herdam de uma superclasse por sobreposição. novas subclasses destas podem herdar de mais de uma subclasse (ver Figura 7.2. .19). A generalização disjuntiva é exatamente o contrário da sobreposição e a generalização é utilizada como padrão.20).2 Generalização Res trita Uma restrição aplicada a uma generalização especifica informações mais precisas sobre como a generalização deve ser usada e estendida no futuro.7.19 : Generalização de Sobreposição • Generalizações Completa e Incompleta: Uma restrição simbolizando que uma generalização é completa significa que todas as subclasses já foram especificadas. A generalização incompleta é exatamente o contrário da completa e é assumida como padrão da linguagem. Figura 7. e não existe mais possibilidade de outra generalização a partir daquele ponto (ver Figura 7.

3 Dependências e Re finamentos Uma dependência indica a ocorrência de um relacionamento semântico entre dois ou mais elementos do modelo onde uma classe cliente é dependente de alguns serviços da classe fornecedora. um use-case e assim por diante. E sobre essa linha o tipo de dependência que existe entre as duas classes. mas não tem uma dependência estrutural interna com esse fornecedor [Furlan.21 : Relação de Dependência .21. Uma relação de dependência é simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento. 1998]. Figura 7. um pacote.52 Figura 7. Nesse caso existe uma dependência entre estas duas classes. Como no caso anterior com generalizações.20 : Generalização Completa 7.7. Quando uma classe recebe um objeto de outra classe como parâmetro. Uma mudança no elemento independente irá afetar o modelo dependente. Conforme mostra a figura 7. uma classe acessa o objeto global da outra. apesar de não ser explícita. as classes "Amigas" provenientes do C++ são um exemplo de um relacionamento de dependência. os modelos de elementos podem ser uma classe.

Em grandes projetos. Quando um elemento representa um tipo. Os refinamentos são simbolizados por uma linha tracejada com um triângulo no final de um dos lados do relacionamento e são usados em modelos de coordenação (ver Figura 7. Coordenação de modelos pode ser usada para mostrar modelos em diferentes níveis de abstração que se relacionam e mostram também como modelos em diferentes fases de desenvolvimento se relacionam.8 Mecanismos Gera is A UML utiliza alguns mecanismos em seus diagramas para tratar informações adicionais. Quando o mesmo elemento representa a instância de um tipo.53 Os refinamentos são um tipo de relacionamento entre duas descrições de uma mesma coisa. . • Ornamentos: ornamentos gráficos são anexados aos modelos de elementos em diagramas e adicionam semânticas ao elemento. mas em níveis de abstração diferentes e podem ser usados para modelar diferentes implementações de uma mesma coisa (uma implementação simples e outra mais complexa.22). seu nome é mostrado em negrito. Figura 7. todos os modelos que são feitos devem ser coordenados.22 : Refinamentos 7. Um exemplo de um ornamento é o da técnica de separar um tipo de uma instância. mas também mais eficiente).

• Notas: Nem tudo pode ser definido em uma linguagem de modelagem. UML provê a capacidade de adicionar Notas.23). sem importar o quanto extensa ela seja. Outros ornamentos são os de especificação de multiplicidade de relacionamentos. onde a multiplicidade é um número ou um intervalo que indica quantas instâncias de um tipo conectado pode estar envolvido na relação.54 seu nome é escrito sublinhado e pode significar tanto o nome da instância quanto o nome do tipo. Figura 7. e pode conter qualquer tipo de informação (ver Figura 7.23 : Ornamentos e Nota . Para permitir adicionar informações a um modelo não poderia ser representado de outra forma. Uma Nota pode ser colocada em qualquer lugar em um diagrama.

DIAGRAMAS 8. atividade.Capítulo 8 . dependências. Os diagramas utilizados pela UML são compostos de nove tipos: diagramas de casos de uso. associações. 2000]. interfaces. classes. colaborações. Em UML você desenvolve seus modelos a partir de blocos distintos tais como : classes. generalizações. colaboração. etc. sequência. você simplifica a realidade para um melhor entendimento do sistema em desenvolvimento. componentes. componentes e execução. A seguir trataremos cada um destes tipos de diagramas. objetos. Os diagramas são meios utilizados para visualização de blocos de construção [Booch.1 Conceito Quando você faz modelagem. . Os exemplos utilizados para apresentar os diagramas foram retirados de livros utilizados neste projeto e de material encontrado na internet. estados.

2000]. • o relacionamento usar: é representado por uma seta com o estereótipo <<uses>>. No modelo de caso de uso o relacionamento entre um ator e um caso de uso representa a participação deste ator no caso de uso. ou como os usuários desejam que ele funcione. cenários que o sistema percorre em resposta ao estímulo de um ator. . Os atores representam usuários e outros sistemas que interagem com sistema modelado. O modelo de caso de uso consiste de atores e casos de uso. Os casos de uso mostram o comportamento do sistema. Além deste relacionamento. Eles são desenhados como elipses conforme mostra a Figura 8.56 8. Os casos de uso são usados para modelar como um sistema ou empresa funciona. mostrando que o caso de uso destino pode incluir o comportamento especificado pelo caso de uso origem. Os casos de uso geralmente são o ponto de partida da análise orientada a objetos utilizando a UML.2 Diagramas de Cas os de Uso Um diagrama de caso de uso ilustra um conjunto de casos de uso para um sistema. mostrando que o caso de uso origem inclui o comportamento especificado pelo caso de uso destino. existe dois outros tipos de relacionamentos entre casos de uso: • o relacionamento estender: é representado graficamente por uma seta com o estereótipo <<extends>>. os atores e a relação entre os atores e os casos de uso [Larman. Eles são representados graficamente por um homem palito.1.

como classes. tipos e seus respectivos conteúdos e relações [Furlan.57 A figura 8.1 mostra um diagrama de casos de uso. 1998] (ver Figura 8.3 Diagramas de Cla sses É uma estrutura lógica estática em uma superfície de duas dimensões mostrando uma coleção de elementos declarativos de modelo.1 : Diagramas de Casos de Uso 8. Figura 8. .2).

Veja figura 8. Ela é representada incluindo-se um losango na extremidade do objeto todo do relacionamento todo-parte. A agregação é uma forma especial de associação que representa o relacionamento todo-parte entre objetos. onde esses limites são valores inteiros ( o caracter * pode ser usado como limite_superior para indicar falta de limite).limite_superior. Uma associação pode ter um nome. A generalização é um relacionamento existente entre uma classe mais geral(superclasse) e uma classe mais específica(subclasse). . A multiplicidade de uma associação especifica quantas instâncias de uma classe relacionam-se a uma única instância de uma classe associada. As associações representam relacionamentos estruturados entre objetos de diferentes classes.58 Uma classe em UML é representada por uma caixa retangular com três compartimentos: um com o nome da classe.. A generalização é uma ferramenta poderosa para a abstração. o outro com a lista de atributos da classe e o último com a lista de operações da classe. no seguinte formato: limite_inferior. Uma generalização é representada por uma linha com um triângulo. que liga a classe mais específica a mais genérica. e são representados graficamente através de uma linha conectando as classes.2. Uma multiplicidade é representada por um intervalo de valores possíveis. E as extremidades da linha que representa uma associação pode ter nome de papéis mostrando como a classe é vista pelas outras classes na associação. onde a classe mais específica é consistente com a mais geral e adiciona informações a ela.

59 Figura 8. Estes diagramas não são importantes apenas para a visualização. Você usa os diagramas de interação para visualizar os aspectos dinâmicos de seu .3). especificação e documentação de modelos estruturais. Um diagrama de objetos mostra um conjunto de objetos e seus relacionamentos em determinado ponto no tempo. A UML permite a utilização de diagramas de classes para uma visualização dos aspectos estáticos dos blocos de construção do sistema. mas também para a construção de aspectos estáticos de sistemas por meio de engenharia de produção e engenharia reversa [Booch. 2000] (ver Figura 8.4 Diagramas de Ob jetos Os diagramas de objetos fazem a modelagem de instâncias de itens contidos em diagramas de classes.2 : Diagramas de Classes 8.

expressa a parte estática de uma interação. o diagrama de objetos congela um momento no tempo. formados por instâncias desses blocos de construção e mensagens enviadas entre eles.3 : Diagramas de Objeto . seus estados e relacionamentos. portanto. Os diagramas de objetos são usados para fazer a modelagem da visão de projeto estática ou da visão de processo estática de um sistema. O diagramas de objetos. Nos dois casos. mas a partir da perspectiva de instâncias reais ou prototípicas. composta pelos objetos que colaboram entre si. da mesma forma como faz com os diagramas de classes. Essa visão atende principalmente aos requisitos funcionais do sistema – ou seja. os serviços que o sistema deverá proporcionar aos seus usuários finais. Os diagramas de objetos cobrem um conjunto de instâncias dos itens encontrados nos diagramas de classes. Figura 8. Isso envolverá a modelagem de um retrato do sistema em determinado momento e a representação de um conjunto de objetos. Os diagramas de objetos permitem que você faça a modelagem de estruturas de dados estáticos.60 sistema. mas sem qualquer uma das mensagens passadas entre eles.

As linhas de transição descrevem o movimento de um estado para o outro. o comportamento de um objeto é modelado em função de qual estado ele está inicialmente. e para qual estado ele vai passar quando um determinado evento ocorrer. Por exemplo. 2000]. Mostram o ciclo de vida de um objeto em níveis de detalhe arbitrariamente simples ou complexos [Larman. Cada linha de transição é rotulada com o evento que causou a transição.61 8.4. Os eventos representam incidentes que causam a mudança de um estado para outro. . junto com suas próprias ações e respostas conforme mostra a Figura 8. Os estados representam as condições dos objetos em um determinado momento. Visualizam a seqüência de estados que um objeto ou uma interação percorre durante sua vida em resposta a estímulos recebidos.5 Diagramas de Est ados Os diagramas de estados são usados para modelar o comportamento dinâmico de um sistema.

As mensagens são desenhadas cronologicamente do topo à base do diagrama.6 Diagramas de Seq üência Os diagramas de seqüências são usados para modelar a interação entre objetos em um sistema.5. conforme mostra a Figura 8. O diagrama apresenta os objetos e as mensagens que são passadas entre estes objetos dentro do caso de uso.62 Figura 8. Os objetos são representados por linhas tracejadas verticais. um diagrama de seqüência captura o comportamento de um único caso de uso.4 : Diagramas de Estados 8. . e a passagem de mensagens entre dois objetos são representados por vetores horizontais. Tipicamente.

7 Diagramas de Col aboração Os diagramas de colaboração é uma outra alternativa para a modelagem de interações entre objetos de um sistema. As associações mostram as mensagens enviadas entre os objetos. e a seqüência destas mensagens é determinada usando-se números seqüenciais (ver Figura 8. o diagrama de colaboração focaliza no relacionamento entre os objetos e na compreensão dos efeitos sobre um objeto durante um cenário. Uma Colaboração é uma visão de um conjunto de elementos de modelagem relacionados para um propósito particular em apoio a interações [Furlan. 1998]. Diferentemente do diagrama de seqüência que focaliza na seqüência cronológica do cenário que está sendo modelado. .5 : Diagramas de Seqüência 8.63 Figura 8. Os objetos são conectados através de associações e cada associação representa uma instância de associação entre as respectivas classes envolvidas.6).

7). . mas não representam quem faz o que. Os divisores são representados por linhas verticais tracejadas.64 Figura 8. 2000] (ver Figura 8. Os diagramas de atividades são um caso especial de diagramas de estado.6 : Diagramas de Colaboração 8. onde todos os estados têm uma ação interna e nenhuma transição tem um evento de entrada. mostrando o fluxo de controle de uma atividade para outra [Booch. Os diagramas de atividades representam o que acontece. Os divisores contornam esse problema através da organização das responsabilidades da atividades dentro de uma classe. enquanto os diagramas de estado são usados para especificar o comportamento global de um tipo. Através dos divisores podemos separar as atividades de acordo com as classes responsáveis por essas atividades.8 Diagramas de Ativ idade Um diagrama de atividade é essencialmente um gráfico de fluxo. Os diagramas de atividades são usados para detalhar classes. implementação de operações e casos de uso. Isso significa que o diagrama não diz qual classe é responsável por cada atividade. O propósito de um diagrama de atividades é focar nos fluxos dirigidos pelo processamento interno e descrever o comportamento de processamentos paralelos.

8. São importantes tanto para visualizar. Modelar sistemas adaptativos. 1998]. Os diagramas de componentes representam. Modelar lançamento de executáveis (versões). Modelar fisicamente um banco de dados.7 : Diagramas de Atividade 8.65 Figura 8. São tipicamente usados para: Modelar a organização do código fonte. especificar e documentar sistemas baseados em componentes quanto para construir sistemas através de engenharia reversa (reverse) e direta (forward). Eles mostram um conjunto de componentes e seus relacionamentos conforme mostra a Figura 8. aspectos físicos do sistema sendo modelado. Engenharia de produção e engenharia reversa. . de forma estática.9 Diagramas de Com ponentes Mostram dependências entre componentes de software [Furlan.

9).66 Figura 8.8 : Diagramas de Componentes 8.10 Diagramas de Imp lantação Os diagramas de implantação são diagramas que mostram a configuração de nós de processamento em tempo de execução e os componentes que neles existem (ver Figura 8. entrega e instalação das partes que formam o sistema físico. isso envolve a modelagem da topologia do hardware em que o sistema é executado. mas também para o gerenciamento de sistemas por engenharia de produção e engenharia reversa. . Os diagramas de implantação são essencialmente diagramas de classes que focalizam os nós do sistema. Na maior parte. Os diagramas de implantação não são importantes somente para visualizar. cliente/servidor e distribuídos. Os diagramas de implantação são empregados para modelagem da visão estática de implantação de um sistema. Essa visão direciona primariamente a distribuição. especificar e documentar sistemas embutidos.

67 Figura 8.9 : Diagramas de Implantação .

2001]. Um método tradicional de desenvolvimento orientado a objetos é dividido em análise de requisitos.Capítulo 9 .METODOLOGIA DESENVOLVIDA 9.1 Introdução A UML é uma linguagem para especificação. Porém não prescreve como o trabalho deve ser feito. Para alcançar com êxito nossos objetivos devemos ter bem definido a expectativa do projeto. O método de desenvolvimento adotado deve descrever um número de atividades a ser seguidas em uma determinada ordem. implementação e teste [Barros. A utilização da UML em grandes projetos pode ajudá-lo a tornar-se mais eficiente. projeto. mas para tal devemos adotar um método de desenvolvimento. O RUP(Rational Unfied Process) é um outro método. análise. que é . que é uma visão técnica do desenvolvimento. desenvolvido pela Rational Inc. visualização. documentação e construção que tornam possível expressar modelos orientados a objetos.

A partir deste ponto descreveremos nossa metodologia.69 dividido em concepção. programação e testes. a fim de manter a documentação organizada. Ao final do desenvolvimento de cada fase serão feitas observações que servirão de conclusão e de base para futuros melhoramentos. apresentando cada fase da metodologia detalhadamente.2 Documentação Estabelecemos alguns procedimentos inicias. Para .1 Fonte Na documentação será exigido a confecção de alguns documentos. cujo os quais deve-se redigi-los corretamente para um bom entendimento. que mostra uma visão mais gerencial do desenvolvimento [Booch. Ferramentas desenvolvimento de modernas sistemas devem da suportar linguagem um de método modelagem de e além programação. Tomaremos como base para desenvolvimento de nossa metodologia a visão técnica da UML que divide-se em 5(cinco) etapas: Análise de Requisitos. elaboração.2. construção e transição. 9. projeto. 9. que suporta bem tanto a linguagem quanto o método de desenvolvimento.2000]. Esses procedimentos podem interagir com outras documentações em outros projetos usando a mesma metodologia em plataformas diferentes. Um exemplo é o Rational Rose da Rational Inc. análise.

devemos gravar todos os processos envolvidos com o projeto numa mesma pasta. Numa apresentação do projeto criado os documentos tem que ser facilmente visualizados. . Quanto ao tamanho. O tipo da fonte usada na documentação tem que ser bem definida. para que todos os documentos escritos tenham o mesmo aspecto. partindo do princípio que nem todos terão as mesmas ferramentas e que existem editores que não possuem determinadas fontes. Devemos nos preocupar em estabelecer uma fonte que toda a equipe envolvida e até mesmo pessoas não envolvidas naquele projeto possuam. e para uma melhor organização e entendimento. Todas as pastas criadas devem sempre fazer relação com os arquivos que estarão armazenados na mesma. fontes grandes gerariam muitas folhas e também traria um aspecto desfigurado.70 uma melhor visualização determina-se antes do início do projeto o tipo e o tamanho da fonte. O tamanho da fonte deverá estar relacionada com o seu tipo. normalmente usamos o tamanho de 10 a 14. ou até mesmo o nome do projeto.2 Gravação da Docu mentação Para que todos os envolvidos no projeto possam ter acesso à documentação do projeto. Cria-se uma pasta mãe com o nome do projeto e abaixo dela conforme a necessidade cria-se outras pastas filhas. 9. fontes pequenas demais tornam a documentação um pouco cansativa para ser lida.2. Estas pastas devem estar identadas sempre abaixo de uma que englobe o projeto como um todo.

71 Na confecção de um novo projeto pode-se copiar estas pastas para um outro local e renomeá-las. Faz-se necessário uma revisão de todas as pastas para adequação com o novo projeto.

9.2.3 Extensão de Arqui vos
Na preocupação que nosso projeto possa se comunicar com outros ou até mesmo a junção dos mesmos, devemos estabelecer extensões de arquivos que possam ser abertas em qualquer plataforma, sistema operacional, editor, etc. Muito importante para uma boa definição deste item, é saber quais serão os possíveis editores usados, sistemas operacionais que os envolvidos no projeto possuem. Arquivos do tipo .txt seriam de bastante abrangência, exceto no caso de criação de arquivos um pouco mais complexos, necessitando ferramentas com um pouco mais de recursos, pois arquivos com este tipo de extensão podem ser abertas em muitas plataformas. Se houver realmente a necessidade de criação de arquivos com recursos um pouco mais complexos que os .txt (modo caracter), procurar usar extensões de arquivos que abram na grande maioria dos editores.

9.2.4 Impressão
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 padrão. As margens podem ser configuradas de acordo com a necessidade, pois dentro do projeto haverá diagramas que necessitarão de margens um

72 pouco menores ou maiores devido a sua complexidade. Sendo que para sua melhor visualização às vezes é necessário o uso do papel até sua extremidade.

9.2.5 Backup
Deve-se criar um sistema de backup, sugerindo um responsável pela execução do mesmo, para que não haja surpresas no decorrer do projeto, como perdas de dados. Ocasionando atraso na conclusão do projeto, alterando as datas as quais a equipe se submeteu a cumprir. A periodicidade dos backup´s depende do envolvimento da equipe e das informações armazenadas diariamente, se houver necessidade pode-se realizar os backup´s diariamente, semanalmente ou mensalmente. Criaremos um formulário sugestão que envolve todos os

procedimentos da documentação, conforme anexo 01.

9.2.6 Controle de Versõe s
Desejamos com o controle de versões que os desenvolvedores possam manter o sistema atualizado de acordo com sua documentação. Serve também para diferenciar um software dele mesmo, porém qualquer tipo de alteração feita será registrada uma nova versão do software. Uma versão deverá ser representada de modo a controlar desde pequenas alterações até novas funcionalidades e/ou grandes alterações que mudem a funcionalidade do sistema. Sugerimos a representação da versão em seqüências de três blocos de caracteres (N.NX-NN) onde : • N é um caracter numérico no intervalo de 1 a 9;

73 • NX : N é um caracter numérico no intervalo de 1 a 9; X é um caracter alfanumérico no intervalo de A-Z; • NN são caracteres numéricos no intervalo de 01 a 99; Os dois primeiros caracteres (N.N) representam a versão principal. Somente são alterados quando se tratar de grandes modificações e/ou inovações, como por exemplo : troca de linguagem, inclusão de novo módulo no sistema, troca ou inclusão de nova plataforma. O terceiro caracter (X) é destinado a alterações de médio porte e/ou inclusão de novas rotinas, como por exemplo : cadastros, relatórios, lançamentos, consultas. Nos dois últimos caracteres (NN) registramos pequenas alterações e correções em rotinas já existentes no sistema, como por exemplo : alterações de relatórios, consultas, cadastros, etc.

9.3 Eventos Iniciais

Após concluído o item documentação, trataremos alguns eventos que ocorrem antes da análise de requisitos. Trata-se de eventos iniciais de extrema importância para um bom desenvolvimento da análise de requisitos, onde são feitos os primeiros contatos, um estudo dos dados e definição de possíveis envolvidos no projeto.

Este contato pode ser de forma mais variável possível: Fone.74 9.3. etc. pessoal. concluindo-se que a empresa não pode atender a solicitação. email. conforme anexo 02. A empresa ou pessoa que recebeu o contato. Define-se tanto os participantes por parte do usuário quanto da empresa de desenvolvimento de software.2 Estudo dos Dados Tratando-se de um desenvolvimento de um novo software será analisado: • Após uma análise da área de negócio. Esta resposta .3. Trata-se de um formulário que servirá para registrar a solicitação do usuário e também para a convocação de algumas pessoas para uma possível reunião a qual será marcada. este último depois de preenchido será transformado em meio magnético. Fax. solicita ao usuário. 9. ou acompanha o mesmo no preenchimento de um formulário padrão. Criaremos um formulário sugestão que contém todos os itens necessários para registrar um contato. será retornado ao mesmo que trata-se de uma área de negócio a qual a empresa não oferece soluções. Como trata-se de algo bem genérico. através deste formulário ainda não se sabe com certeza quem será envolvido no sistema.1 Contatos Um determinado usuário faz um contato solicitando o desenvolvimento de um software. Este formulário deverá ser preenchido em meio magnético(aconselhável) ou papel.

então será feita uma avaliação sobre a descrição e com base nesta avaliação e na área de negócio. Logicamente de acordo com o andamento do projeto serão filtrados.75 também poderá ser dada no momento do preenchimento do formulário padrão. tanto por parte do solicitante. pois é ali que contém alguns conceitos básicos que podem ajudar os responsáveis a convocar as pessoas certas para definir os possíveis participantes. • A área de negócio da solicitação é abrangida pela empresa. Após definir todos os participantes da reunião.3. . 9. quanto por parte da empresa desenvolvedora. dependendo de quem e da capacidade do atendente. ficando apenas aqueles que podem contribuir para o bom desenvolvimento do projeto. Nesta definição procura-se envolver todos que de alguma forma poderão contribuir para o projeto de ambas as partes.3 Definição dos Part icipantes A definição dos participantes deve sempre girar em torno da área de negócio e da descrição. serão convocados para uma reunião os possíveis envolvidos no projeto. será marcada a data da mesma e os envolvidos serão convocados. Até este ponto trata-se de um evento que antecede as fases da metodologia de desenvolvimento de sistemas.

nas metas globais e nos benefícios. concentrando-se no cliente. diagrama de casos de uso e análise de riscos.4. o analista poderia perguntar : • • • • Quem está por trás do pedido deste trabalho? Quem usará a solução? Qual o benefício econômico de uma solução bem-sucedida? Há outra fonte para a solução exigida? . diretores ou escriturários. casos de uso. Por exemplo. Para dar início a comunicação entre os participantes.76 9. definição de equipe envolvida e também alguns itens técnicos como: atores. Serão abordados itens necessários para a concepção do projeto. a hierarquia funciona como um agente inibidor e a opinião da pessoa de nível mais alto prevaleceria sobre as demais. Em uma situação normal. 9.1 Reunião/Entrevista Nas reuniões. deverá ser bem elaborada para um bom desenvolvimento das demais fases. Gause e Weinberg sugerem que o analista comece fazendo perguntas de livre contexto. devem se posicionar livremente. sem nenhuma garantia de que fosse a mais indicada. gerentes. pois se foram convidados a participar é porque têm alguma contribuição a dar com o seu conhecimento específico no assunto objeto da reunião. não existe nenhuma hierarquia. Todos os participantes. das quais as pessoas convocadas a participar.4 Análise de requis itos Esta fase é a base do projeto. sejam eles analistas.

Hoje. o analista pode fazer perguntas que o ajudarão na compreensão do problema e ter uma idéia da solução: • Como você caracteriza um "bom" resultado(saída) que seria gerado por uma solução bem-sucedida? • • Qual o(s) problema(s) essa solução resolverá? Você poderia mostrar-me(ou descrever-me) o ambiente que a solução será utilizada? • Existem questões de desempenho ou restrições especiais que afetarão a maneira pela qual a solução é abordada? Por fim. a FAST é usada predominantemente pela . que concentram-se na efetividade da reunião: • Você é a pessoa certa para responder a essas perguntas? Suas respostas são "oficiais"? • • • • Minhas perguntas são pertinentes ao problema que você tem? Estou fazendo perguntas demais? Há mais alguém que possa fornecer informações adicionais? Existe algo mais que eu possa perguntar-lhe? Uma abordagem à coleta de exigências orientadas a equipes aplicada durante as primeiras etapas de análise e especificação é a FAST(Facilitaded Application Specification Techniques). negociar diferentes abordagens e especificar um conjunto preliminar de requisitos de solução. Essa abordagem estimula a criação de uma equipe conjunta de clientes e desenvolvedores que trabalhem juntos para identificar o problema.77 Em seguida. o analista fará perguntas decisivas. propor elementos de solução.

mas todos tem alguns princípios básicos : • Um encontro é levado a efeito num local neutro e participam desenvolvedores e clientes. . adesivos de parede ou cartazes. • • Usam-se regras para preparação e participação. Esses métodos citados possuem suas diferenças. propor elementos de solução. • Identificação do problema. negociar diferentes abordagens e especificar um conjunto preliminar de requisitos de solução num clima que facilite a realização da atividade. mas a técnica oferece potencial para uma melhor comunicação em aplicações de todos os tipos. Consiste numa rápida entrevista e um processo acelerado de coleta de dados em que todos os principais usuários e o pessoal da análise de sistemas agrupam-se em uma única e intensiva reunião(que pode prolongar-se de um dia a uma semana) para documentar os requisitos do usuário. um cavalete. • Um moderador (Cliente. Desenvolvedor ou alguém de fora) para controlar a reunião. Outra abordagem especializada de entrevista que pode ser usada é o JAD(Joint Application Development).78 comunidade de sistemas de informação. agindo de forma livre o suficiente para encorajar o fluxo de idéias e sugestões. Uma agenda formal para captar os pontos importantes. • Utilização de um mecanismo de definição que pode ser uma planilha. A reunião costuma ser supervisionada por um especialista treinado que atua como mediador para encorajar melhores comunicações entre os analistas de sistemas e os usuários.

tais como equipamentos.3 Definições de resp onsabilidades Aqui definiremos a responsabilidade de cada um dos envolvidos no projeto. ambiente de trabalho.4. Também será descrita a abrangência de todo o Projeto.2 Preenchimento da ata da reunião Nesta primeira reunião aparecerão muitas idéias sobre como se deve comportar o sistema ou o que ele deve atingir. Neste texto será descrito as principais características e funcionalidades do sistemas.4. com quem interage e por quem é interagido(isto pode ser representado por diagramas de casos de uso) . etc. Cria-se um arquivo com o nome do sistema cujo o resumo faz referência.4.4 Resumo do Projeto Um texto geral sobre o sistema que será desenvolvido. 9.79 9. fontes de dados. A ata da reunião deverá ser compostas de alguns elementos essenciais . 9. conforme anexo 03. Discriminar alguns requisitos mínimos para um bom funcionamento do projeto também faz parte deste resumo. Todas as idéias devem ser incluídas na ata pois serão a partir delas que será dado o start no projeto. . Criaremos um formulário sugestão que contém todos os elementos essenciais. Coordenador da equipe: Responsável pelo andamento do Projeto.

No sistema podem ter usuários com diferentes permissões. Cada ator deve possuir um nome cujo terá relação direta com a sua função. quando se pensar em atores é sempre bom pensar neles como papéis em vez de pensar como pessoas. Criaremos um formulário sugestão para listar os atores do sistema.4. assim como os usuários. onde cada .6 Casos de Uso Antes da definição de casos de uso. Os meios externos são hardwares e/ou softwares que. Existem atores que podem desempenhar mais de um papel no sistema. para isto é necessário criar um ator para cada diferente tipo de permissões.5 Atores Atores são usuários e/ou outros meios externos que desenvolvem algum papel em relação ao sistema. possuirá uma descrição que definirá o que ele faz e com quem ele interage. conforme anexo 04. um mesmo ator pode estar em um ou mais casos de uso. 9. a partir disto. Os atores são quem desempenham os casos de uso. geram informações para o sistema ou necessitam de informações geradas a partir do sistema.80 9. cargos.4. devemos ter definidos os atores e ter a idéia da funcionalidade do sistema. começaremos a definir os casos de uso. Você pode imaginar um caso de uso como um conjunto de cenários. máquinas. Casos de uso especificam o comportamento do sistema ou parte(s) dele e descrevem a funcionalidade do sistema desempenhada pelos atores.

mostrando a idéia geral do sistema como ele irá interagir com o mundo externo. Os casos de uso são representados em forma de elipse.4. estes números citados é claro que podem variar dependendo do sistema a ser desenvolvido. em modo geral trate apenas de 10 à 20(%) dos casos de uso mais críticos de seu sistema.81 cenário é uma seqüência de passos a qual descreve uma interação entre um usuário e o sistema. Também criaremos outro formulário sugestão contendo todos os requisitos de uma caso de uso. mais detalhes terá o caso de uso. trate apenas dos casos de usos mais críticos para o sistema. quanto maior o risco. Dessa forma sua documentação não se tornará monótona. o seu detalhamento vai depender do risco que o mesmo corre. Criaremos um formulário sugestão para listar os casos de uso.7 Escopo Uma visão gráfica do sistema. Deve-se usar os atores e casos de uso. 9. Ao definir os casos de uso a serem desenvolvidos. Preencher todos os requisitos de um caso de uso é de extrema importância. interação e abrangência descritos no resumo do projeto para uma representação gráfica. conforme anexo 05. Esta visão é transformação de funcionalidades. Os nomes dos casos de usos devemos sempre usar verbos. Numericamente falando. Devemos possuir uma lista com todos os nomes dos casos de usos para facilitar na identificação dos mesmos. . os casos de uso que são tarefas rotineiras não precisam ser desenvolvidos. Não deve-se detalhar muito um determinado caso de uso. pois assim facilitará no entendimento dos mesmos. conforme anexo 06.

atores e casos de uso relacionados. Criaremos um formulário sugestão que contém todos os itens de diagrama de caso de uso. pois poderão comprometer todo o desenvolvimento do sistema. . Então relacionamos os casos de uso de uma determinada parte ou de todo o sistema e os relacionamos com seus respectivos atores. 9. tem-se condições de implementar as funções dentro prazo previsto? • Analisar os problemas técnicos que poderão ocorrer ao longo do projeto. conforme anexo 07. Devemos definir o nome do diagrama de caso de uso sempre relacionado-o com o seu propósito.82 9.8 Diagrama de caso de uso O diagrama de caso de uso é um ponto importante de comunicação entre a equipe de desenvolvimento e o usuário. estas deverão ser tratadas com mais importância. Dentre elas podemos citar as mais críticas e que geralmente ocorrem na maioria dos projetos: • • Está realmente claro a importância deste projeto? Baseado nos casos de uso. Nos diagramas de casos de uso ilustramos conjuntos dos casos de uso do sistema.4. devemos considerar algumas mais críticas. portanto deverá ser de fácil entendimento.9 Análise de riscos Em todo projeto surgem várias incertezas. os atores e a relação entre os atores e os casos de uso. Deve-se documentar cada diagrama desenvolvido observando alguns itens importantes como: nome do diagrama.4. Sua definição deve deixar bem transparente a idéia do sistema. descrição.

estes serão resolvidos de forma que não altere o cronograma do projeto? • Os requisitos foram bem definidos de modo que se ocorrerem eventuais mudanças. conforme anexo 08.. embora. avaliação. todos que se comprometeram realmente irão participar? A análise de riscos é uma tarefa de grande importância no gerenciamento de um projeto de software. definindo prazos nos quais os envolvidos deverão empenhar-se na execução de suas atividades para o cumprimento dos mesmos. .83 • Caso encontre problemas. O seu objetivo é determinar um conjunto de passos a serem seguidos para determinar os riscos envolvidos no projeto: identificação. determinando assim o prazo final do projeto. 9. classificação. estas não gerarão alterações consideráveis no tempo e nem nos custos de desenvolvimento? • Empenho dos envolvidos no projeto. esta atividade nem seja considerada.. Deverá ser criada uma representação (gráfico ou tabela) que exprima o tempo dedicado a cada tarefa. Criaremos um formulário sugestão que contém todos os itens para um correto preenchimento de um cronograma. em muitos casos. definição de estratégias para administrar os riscos.4.10 Cronograma Os cronogramas são metas que devem ser atingidas. resolução dos riscos. etc.

4. os diagramas de interação os dividiremos em seqüência e colaboração.11 Aprovação Cria-se um formulário onde responsáveis deverão aprovar a fase. Agregação. logicamente observando sempre a integração de todas as partes. Traremos dos diagramas de classes em conjunto com diagramas de objetos.5. Criaremos um formulário modelo conforme anexo 09.5 Análise Esta fase preocupa-se com as primeiras abstrações e mecanismos que estarão presentes no domínio do problema. Deve-se considerar alguns procedimentos no desenvolvimento de diagramas de classes: • Praticamente. colaborações e seus relacionamentos. interfaces. Nestes relacionamentos dar-se-á mais atenção aos quatro principais tipos que são: Generalização/especificação.84 9. o conjunto de classes. Deve-se ter conhecimento dos comportamentos . Em sistema de grande complexidade podemos dividir o diagrama de classes em diagramas menores.1 Diagrama de Class es Nos diagramas de classes modelamos a visão estática do sistema. 9. ter em mãos todas as informações sobre um modelo de objetos é pouco provável. trataremos também dos diagramas de estado e atividade. 9. Associação e Dependência.

para os métodos usamos verbos e para os atributos usamos propriedades da classe. de componentes ou de implementação o que captamos realmente é um conjunto de abstrações que nos interessa como um conjunto e. onde cada um está num estado específico e em um determinado relacionamento com demais objetos. atributos e generalização usando logicamente outras abstrações quando forem necessárias. associações.2 Diagrama de Objet os Os diagramas de objetos são utilizados para visualizar. Na definição das classes podemos usar para definir os nomes substantivos. deste ponto de vista. defini-los. reduzindo o número de objetos. especificar. 9. Devemos nos direcionar mais as abstrações comportamentais. .5. Atribuir-lhe um nome que indique sua finalidade. A atenção em todos os detalhes desenvolvidos neste diagrama será de grande influência na construção de um bom sistema. Cria-se modelos apenas das áreas chaves do sistema. • Não devemos nos preocupar muito em usar toda a teoria envolvida nos diagramas de classes. Os diagramas de objetos ajudam principalmente na modelagem de estruturas complexas. classificá-los e identificar os relacionamentos entre eles. construir e documentar a estrutura de um conjunto de objetos. mas sim as mais simples: classes.85 iniciais destes objetos. • • • • Ter conhecimento e compreensão da idéia do projeto é fundamental. Quando construímos diagramas de classes.

5. encontraremos um conjunto de objetos. • Considere apenas um único cenário capaz de percorrer tudo isto. congele o cenário em determinado momento e represente cada objeto participante. cada um em um estado específico e em um determinado relacionamento com os demais objetos.86 mostra-se sua semântica e seus relacionamentos com outras abstrações existentes neste conjunto. para compreensão do cenário. interfaces e outros itens. citamos algumas considerações para desenvolvimento de diagramas de objetos [1995]: • Identifique alguma função ou comportamento de parte do sistema cuja modelagem você está fazendo e que é resultante da interação de uma sociedade de classes. • De forma semelhante. representando instâncias de associações entre eles.3 Diagramas de Inter ação O diagrama de interação enfatiza a interação de objetos. interfaces e outros elementos e seus relacionamentos entre si que participem nessa colaboração. Segundo Booch. uma especificação comportamental que inclui uma seqüência de trocas de . exponha os vínculos existentes entre esses objetos. Se imaginarmos um determinado momento num sistema modelado. conforme seja necessário. • Exponha o estado e os valores dos atributos de cada um desses objetos. 9. • Para cada função ou comportamento. identifique as classes. Um diagrama de objetos mostra um único conjunto de objetos relacionados uns com os outros em um momento específico.

colaborações e histórias de estado em seqüência temporal de mensagem e representação explícita de ativação de operações [Furlan. As mensagens são representadas por linhas horizontais entre as linhas verticais de dois objetos. O diagrama de seqüência mostra uma seqüência explícita de mensagens e devemos usá-lo para especificações de tempo real e para cenários complexos. incluindo suas operações. Estes diagramas modelam os aspectos dinâmicos do sistema. Em um diagrama de seqüência.3. .5. 1998]. Devemos utilizar diagramas de interação quando necessitamos ver o comportamento de vários objetos dentro de um único caso de uso. um objeto é representado por um retângulo no topo de uma linha vertical tracejada projetada para baixo. Os diagramas de interação podem ser apresentados de duas formas: Diagrama de Seqüência e Diagrama de Colaboração. interações. Esta linha representa o ciclo de vida de um objeto durante uma interação.1 Diagrama de Seqüê ncia O diagrama de seqüência expõe o aspecto do modelo que enfatiza o comportamento dos objetos em um sistema.87 mensagens entre objetos dentro de um contexto a fim de realizar um determinado propósito. e a ordem de como as mensagens acontecem também é mostrada de cima para baixo. 9. a partir de mensagens que são trocadas entre eles.

Em diagramas complexos devemos separá-los em diagramas menores para facilitar seu entendimento.88 9.3. os objetos são desenhados como ícones. e as setas indicam as mensagens enviadas entre objetos para realizar um caso de uso. Utilizamos a descrição do caso de uso como ponto de partida para a confecção do diagrama. Quando tivermos que decidir entre qual diagrama devemos adotar para estudar uma interação. Uma colaboração é anexada a um tipo. e somente escolher o diagrama de seqüência se a seqüência precisar ser evidenciada. através deste diagrama podemos ver somente os objetos e as mensagens envolvidas. um gráfico de objetos e vínculos com fluxos de mensagens anexados [Furlan. O diagrama de colaboração auxilia no entendimento de um comportamento de um conjunto de objetos que trocam mensagens entre si para realizar um propósito em uma interação global.2 Diagrama de Colab oração Um diagrama de colaboração é um contexto. Num diagrama de colaboração. . podemos escolher primeiramente o diagrama de colaboração quando o objeto e seus vínculos facilitam a compreensão da interação. uma operação ou um caso de uso para descrever seus efeitos externos. Como podemos observar os diagramas de seqüência e colaboração expressam informações semelhantes. porém de forma diferente. 1998].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. deve-se desenvolver de forma individualizada um diagrama para cada classe existente. compartimento de variáveis e compartimento de atividade interna. Deve-se considerar alguns procedimentos no desenvolvimento de diagramas de estados: • • Atribuir-lhe um nome capaz de comunicar seu propósito Comece modelando os estados estáveis do objeto e. . pois os diagramas de atividades controlam o fluxo de controle de uma atividade para outra.5 Diagrama de Ativid ade Podemos fazer uma analogia com um gráfico de fluxo(fluxograma).89 9. Focalizando as atividades que ocorrem entre objetos.5. 9.5. desta forma detalhando todos os estados da classe. procure organizar seus componentes de forma que reduza o cruzamento de ligações de componentes. modelando aspectos dinâmicos do sistema. • No gráfico deste diagrama. Um estado é representado por um retângulo com cantos arredondados e pode ter de um à três compartimentos que são: compartimento do nome do estado. Este diagrama faz a modelagem dos aspectos dinâmicos de sistemas. em seguida faça a modelagem das transições legais de um estado para outro. O diagrama de estado implica na importância da ordem de execução dos eventos. Para melhor definir estes diagramas.

• • • Capturar o funcionamento interno de um objeto. o que os diferencia de um fluxograma que são limitados a processos seqüênciais. . • Mostrar como um conjunto de ações relacionadas pode ser executado e como afetará objetos ao seu redor. os quais estão divididos em diagramas de componentes e implantação.6 Projeto Baseado na análise. em processos seqüências ou paralelos. fluxos de trabalho.90 Nos Diagramas de Atividades modelamos a ordem pela qual as coisas devem ser feitas. Mostrar o funcionamento de um processo de negócio em termos de atores. 9. organizações e objetos. trataremos nesta fase de soluções técnicas. • Mostrar como uma instância de caso de uso pode ser realizada em termos de ação e mudanças de estado de objetos. Entender as ações quando executamos uma operação. Para essas soluções serão usados os diagramas de implementação. Usamos os Diagrama de Atividades para diferentes propósitos como: • Análise de Caso de Uso e compreensão do fluxo de trabalho entre vários casos de uso.

9.1 Diagrama de imple mentação Os diagramas de implementação modelam os aspectos físicos. Devemos atribuir-lhe um nome que demonstre seu propósito.1. Usamos os Diagramas de Componentes nas seguintes formas: • Para modelagem de código-fonte: • Identificar um conjunto de arquivos de código-fonte de interesse e transformá-lo em componentes. Podem conter notas e restrições. Apresentam aspectos de implementação. seu conteúdo costuma conter: componentes. Modelam os itens físicos que residem em um nó como executáveis. Estão divididos em diagramas de Componentes e diagramas de implantação.6. relacionamentos de dependência. transformam seu projeto lógico em bits. inclusive da estrutura de código fonte e de implementação de runtime. bibliotecas. A reunião das partes modeladas ajudarão na formação do sistema executável. interfaces. São usados para a modelagem da visão estática de implementação de um sistema. tabelas.6. Os diagramas de componentes mostram a organização e as dependências existentes entre um conjunto de componentes.1 Diagrama de comp onente O diagrama de implantação mostra a configuração dos nós de processamento em tempo de execução e os componentes que nele existem.91 9. associação e realização. generalização. arquivos e documentos. .

92 • Em sistemas grandes. devemos usar pacotes para mostrar grupos de arquivos de código-fonte. • Para modelagem de bancos de dados físicos: • Identificar as classes existentes no modelo que representam o esquema de seu banco de dados lógico. faça seus relacionamentos. Transforme seu projeto lógico em físico Para modelagem de sistemas adaptáveis: • Identificar a distribuição física dos componentes que poderão mover de um nó para outro. • • • • Faça o mapeamento de suas classes em tabelas. Para uma melhor compreensão dos diagramas de componentes podemos usar notas e cores como indicações visuais com a finalidade de . isso envolverá alguns ou todos que vivem em um único nó ou a distribuição desse conjunto de componentes por todos os nós existentes no sistema. Especifique a localização de uma instância do componente. Estereótipe suas tabelas para um diagrama de componentes. • No diagrama de componentes a exposição da versão do arquivo de código-fonte ajuda no entendimento das dependências de compilação. atribua a ela o valor location. • Para modelagem das causas de mudanças de um componente use um diagrama de interação para auxiliá-lo. • • Considere o estereótipo de cada componente desse conjunto. Para cada componente existente no conjunto. • Para modelagem de versões executáveis: • Identificar o conjunto de componentes.

Se necessário crie diagramas de implantação mais detalhado em dispositivos inteligentes. • Para modelar sistema Cliente/Servidor : • Identificar os nós que representem os processadores do cliente e do servidor do sistema. Este diagrama denota vários dispositivos de hardware e interfaces físicas determinadas por seus estereótipos. Usamos os Diagramas de Implantação em uma das três formas : • Para modelar Sistemas Embutidos : • • Identificar os dispositivos e os nós que são únicos para o sistema. 9. suficientes para que o engenheiro de software especifique a plataforma em que o sistema é executado. O diagrama de implantação modela a visão estática da implantação de um sistema entre seus nós físicos e seus relacionamentos e para especificar seus detalhes referente a construção. . disco. como processador.93 chamar a atenção a pontos importantes do diagrama. Crie indicações visuais para dispositivos de hardware e outros tipos dispositivos.2 Diagrama de impla ntação Diagrama de Implantação é usada para mostrar a organização do hardware e a ligação do software aos dispositivos físicos. • • Modele os relacionamentos entre os dispositivos. memória.1. escolhendo um conjunto pequeno de ícones e utilizando-o de maneira consistente. E também devemos usar elementos estereotipados com cuidado.6. impressora.

Identifique a topologia do seu sistema. especificando seus relacionamentos. modem pessoal) dessa máquina. mouse. • Caso precise analisar o desempenho da rede do sistema ou modificações na rede. monitor. podemos usar .O. que já são gerenciados pelo S. Para uma melhor compreensão dos diagramas de implantação devemos atribuir-lhe um nome que identifique seu propósito.94 • • Junte os dispositivos importantes para o comportamento do sistema. Crie indicações visuais para processadores e dispositivos usando estereótipos • • Modele a topologia dos nós. modele esses dispositivos em um nível de detalhe que previna essas avaliações. Em contrapartida se estiver desenvolvendo software que interaja com dispositivos que o sistema operacional host tipicamente não gerencia. Para modelar sistema totalmente distribuído : • Identificar os dispositivos e processadores para sistemas cliente/servidor mais simples. especificando-os em pacotes. introduza diagramas de casos de uso para especificar o comportamento em foco e crie diagrama de interação para expandir esses casos de uso. host. Os diagramas de implantação não são muito utilizados em sistema que residem em uma máquina e que interagem somente com dispositivos padrão(teclado. • • • Analise os agrupamentos lógicos de nós. Se for preciso focalizar a dinâmica do sistema. ou por processadores distribuídos fisicamente no mesmo host. o diagrama de implantação ajudará a analisar o mapeamento de software para hardware de seu sistema.

É onde todos os modelos desenvolvidos no projeto são traduzidos para código que a máquina possa reconhecer. pois a codificação é uma conseqüência natural do projeto. escolhendo um conjunto pequeno de ícones e utilizando-o de maneira consistente.7 Implementação A fase da implementação é. É muito importante que as fases anteriores já estejam concluídas. 9. deve-se ter todos os detalhes do projeto bem elaborados e estudados. 9.7. Para que o código-fonte não seja gerado de maneira diferente do projeto. a construção física do sistema proposto [Silva. na prática. E também devemos usar elementos estereotipados com cuidado.2 Escolha da Lingua gem Linguagem de codificação complexa ou pouco conhecida pode levar a códigos mal elaborado e de difícil legibilidade. Devemos nos concentrar em escolher linguagens de codificação que tenha suporte ao projeto.95 notas e cores como indicações visuais com a finalidade de chamar a atenção a pontos importantes do diagrama.1998].1 Tradução O processo de tradução acontece quando a compilador aceita o código-fonte como entrada e gera um código-objeto como saída.7. . 9.

PRESSMAN sugere alguns critérios a serem avaliados durante a escolha de uma linguagem de programação [1995]: • • • • • • • A área de aplicação geral. O ambiente em que o software será executado. A disponibilidade de um bom compilador. A complexidade da estrutura de dados. que geralmente não são os últimos lançamentos. Na escolha de uma linguagem orientada a objetos deve-se considerar suporte para definições de classes. com isto elas podem gerar códigos-fonte baseadas no modelo . O conhecimento da equipe de desenvolvimento do software. O lançamento de novas linguagens ou versões é muito constante. herança. Porém novas linguagens devem ser cuidadosamente estudadas e a mudança da linguagem atual para nova tem que ocorrer. As novas gerações de ferramentas CASE possuem uma variedade de linguagens. Considerações de desempenho. Geralmente considera-se a área de aplicação geral como um dos itens mais estudados na escolha da linguagem. A complexidade computacional e algorítmica. portanto muitas vezes necessitamos escolher linguagens do conhecimento da equipe.96 A escolha de uma linguagem de programação para um projeto específico deve-se considerar as suas facilidades e aonde ela irá ajudar o melhor desenvolvimento do projeto. encapsulação e transmissão de mensagens ou ainda características adicionais como herança múltipla e polimorfismo.

local) no sistema.3 Documentação do Código Um código-fonte bem estruturado e documentado será de grande importância para futuras manutenções no sistema. • Não usar nomes muito extensos. Na escolha de nomes de identificadores devemos considerar alguns itens a fim de facilitar a interpretação : • • Expressar diretamente o seu propósito. prosseguindo com a colocação e composição do comentário e por fim com a organização visual do código.97 desenvolvido. Isto é de extrema importância no desenvolvimento de sistemas e/ou funções complexas. 9. mas que expresse o seu propósito. e seguem o formato abaixo [1995]: . eles aparecem no início de cada módulo.7. comentários em forma de prólogo são bastante usados. Na colocação e composição de comentários. A estruturação e documentação começa com a escolha de nomes identificadores(variáveis e rótulos). tomaremos alguns cuidados para que estes realmente ajudem outros leitores de código na compreensão do código e até mesmo para que o desenvolvedor possa localizar-se com mais facilidade e rapidez em futuras manutenções. Identificação do tipo e de sua abrangência(global. Podem ser feitas algumas definições de nomes antes do início da programação. Porém devem ser bastante estudadas pois uma falha no modelo pode comprometer todo o produto final. Segundo PRESSMAN. Neste caso deverá prevalecer o bom censo e experiência por parte do programador.

datas e descrição das modificações). descrição de todos os argumentos e uma lista de todos os módulos subordinados). Evitar um intenso alinhamento de laços ou condições. Usar parênteses para esclarecer expressões lógicas ou aritméticas. tais como variáveis importantes e suas restrições e limitações de uso. não é necessário documentar outros dados como datas. Usar símbolos de espaçamento e/ou legibilidade para esclarecer o conteúdo da instrução. procuramos sempre elaborar códigos identados e seus comentários devem sempre ter uma boa visualização. Uma descrição da interface("seqüência de chamada". Algumas dicas de PRESSMAN para simplificar a codificação [1995]: • • • • • Evitar o uso de testes condicionais complicados. Evitar os testes em condições negativas. • Uma discussão de dados pertinente. auditor e data. autores. Este comentário deverá sempre anteceder o bloco de comandos que se deseja documentar. Ao escrevermos código-fontes e também seus comentários devemos sempre nos preocupar com sua estética. Para uma melhor documentação em módulos e/ou funções muito complexas devemos utilizar também comentários descritivos embutidos no decorrer do código-fonte. etc. • Um histórico de desenvolvimento(autor do módulo. Este tipo de comentário será de grande utilidade para documentarmos linhas ou conjunto de linhas específicas em determinado local dentro de um módulo e/ou função. . faça apenas a identificação da funcionalidade de tal linha ou conjunto de linhas.98 • • Uma declaração de propósitos que indique a função do módulo.

em um tempo e esforço mínimo. Auto questionar-se: Será que entenderia este código se não fosse eu o autor deste? 9. envolvendo também os desenvolvedores principalmente na etapa de teste de unidade da fase de execução que será abordado a seguir. objetivando a redução de custos e tempo adotamos a seguinte estratégia : planejamento. execução de teste e a resultante coleta e avaliação de dados [Pressman. Devemos formar um grupo de testes independentes (GTI). . Uma estratégia de teste de software deve estar dividida nas seguintes fases : planejamento de teste.8. 1995]. Um teste bem executado é aquele que encontra um maior número de erros com o menor número de tentativas. Para tornar esta estratégia mais flexível e customizada sem perder sua validade e regidez.8 Testes A atividade de teste visa executar um programa ou parte dele com a intenção de encontrar erros.99 • • Usar somente características com padrão ANSI. Certamente que os projetistas codificam o software para que não haja erros. execução e avaliação dos resultados. projeto de casos de teste.1 Planejamento de T estes Antes do início dos teste devemos definir a equipe responsável pelos testes. 9.

observando seu fluxo normal e quando este fluxo não é seguido se os fluxos alternativos estão atendendo tal situação. em busca de erros de passagem de dados para dentro e para fora do módulo. Durante a execução dos testes. função. Consistência entre o número e o tipo de parâmetros de entrada com o número e tipo de argumentos. 9. pois estes tem um melhor conhecimento interno de cada unidade. as estruturas de dados.100 Devemos tomar como base para testes os casos de usos desenvolvido na fase de análise de requisitos. durante a realização deste teste os seguintes aspectos devem ser observados : 1. Aqui a participação dos desenvolvedores também é recomendada. abordaremos os testes de Unidade. os caminhos independentes e os caminhos de tratamento de erros. • A interface. etc) é testado individualmente garantindo que ele funcione adequadamente. Validação e Sistema. 9. arquivo.1 Teste de Unidade Nestes testes cada unidade de software(classe. Integração.2 Execução de Teste s Nesta etapa são realizados os testes na integra. procedimento. deve-se fazer um relatório de acompanhamento para registro de todos as ocorrências encontradas.8. verificando se seu propósito está contemplado. Deve ser realizada em primeiro lugar. .2. as condições limite.8. Alguns aspectos a serem testados: são a interface.

Tipos de dados errados. . • As condições limite. • As estruturas de dados locais. Erros de precisão. Inicialização incorreta. Iniciação ou valores default errôneos. Neste teste devemos nos preocupar em : 1. 5. 4. Underflow e Overflow. • Os caminhos independentes (ou caminhos básicos) da estrutura de controle são analisados para ter garantia de que todas as instruções do módulo foram executadas pelo menos uma vez. 4. Os erros mais comuns são : 1. 2. Consistência entre o número e o tipo de argumentos transmitidos aos módulos chamados com os parâmetros. 5. 2. Modificação de argumentos de entrada/saída. Digitação inconsistente ou imprópria. para se prover a garantia de que todos os dados armazenados localmente mantêm sua integridade ao longo da execução do módulo.101 2. 6. Consistência de variáveis globais ao longo dos módulos. Laços mal definidos. que permitem verificar que o módulo executa respeitando os valores máximos e mínimos estabelecidos para seu processamento. 3. Precedência aritmética incorreta. Operações em modo misto. 4. Representação simbólica de uma expressão incorreta. 3. 3. Existência de referências a parâmetros não associados ao ponto de entrada atual.

testes com o objetivo de descobrir erros associados a interfaces. um conjunto de erros é encontrado e sua correção é difícil porque o isolamento das causas é complicado pela vasta amplitude do programa inteiro [Pressman. O processamento das condições de exceções é incorreto. 5. 4.1995]. Devemos observar os seguintes itens : 1. realizando-se em paralelo. Descrição incompreensível do erro. Este teste está divido em incremental e não incremental. Incremental aborda o teste de integração top-down o programa é construído e testado em pequenos seguimentos. Seu objetivo é montar. a partir dos módulos testados ao nível de unidade construir a estrutura de programa que foi determinado pelo projeto. Integração top-down : Os módulos são integrados movimentando-se de cima para baixo através da hierarquia de controle. O erro exibido não é o erro encontrado.2. 1. A descrição do erro não ajuda na localização da causa do erro. O teste não incremental aborda o teste de integração bottom-up o programa é testado como um todo. 8.8.102 7. 9. Comparação de diferentes tipos de dados. serão testados para observar a robustez do módulo. • Os caminhos de tratamento de erros (se existirem). Intervenção da condição de erro no sistema antes do seu tratamento. 2. iniciado-se do .2 Teste de Integraçã o O teste de integração é uma técnica sistemática para a construção da estrutura de programa. onde os erros são mais fáceis de ser isolados e corrigidos. 3. Operadores lógicos utilizados incorretamente.

103 módulo principal. Os módulos subordinados ao módulo principal de uma maneira depth-first(pela profundidade) ou breadth-first(pela largura). 2. Integração bottom-up : Inicia-se a construção e testes com módulos localizados nos níveis mais baixos da estrutura do programa dirigindo-se ao módulo principal.

9.8.2.3 Teste de Validação
Ao final do teste de integração, o software é finalmente estruturado na forma de um pacote ou sistema. O teste de validação é a validação e verificação de que o software como um todo cumpre os requisitos do sistema. Na fase de análise de requisitos são definidos critérios que servirão de validação para aprovação ou não do software. O teste de validação aborda as seguintes estratégias : revisão de configuração e teste alfa e beta. 1. Revisão de configuração: é onde são verificados os elementos de configuração do software se estão adequadamente desenvolvidos e detalhados para futuras manutenções. 2. Teste alfa: é feito por um cliente nas instalações do desenvolvedor. O software é usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros" do usuário e registrando erros e problemas de uso. 3. Teste beta: é feito nas instalações do cliente pelo usuário final do sistema. O desenvolvedor não está presente. O cliente registra os problemas(reais ou imagináveis) que são 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 número de diferentes testes, cujo propósito é pôr completamente à prova o sistema baseado em computador. Entre os tipos de testes de sistemas destacamos: De recuperação, de segurança, de estresse e de desempenho. • O teste de recuperação é um teste de sistema que força o software a falhar de diversas maneiras e verifica se a recuperação é executada. • O teste de segurança verifica se todos os mecanismos de proteção embutidos no sistema o protegerão. • O teste de estresse força o sistema a usar recursos em quantidade, freqüência ou volumes anormais. • O teste de desempenho é feito para testar o desempenho do software em tempo real.

9.8.3 Avaliação dos Res ultados
Completadas a fase de execução dos testes, passaremos para a avaliação dos mesmos. Isto será feito analisando os relatórios elaborados durante a fase anterior. Esta fase é de grande valia para vários aspectos do sistema. Nesta poderemos ter uma idéia por completo de todo o desenvolvimento do projeto. Podemos apontar falhas em determinadas fases do projeto baseando-se nesta avaliação, bem como certificar-se da qualidade e/ou bom desempenho do projeto.

105 Ocorrendo pequenos erros ou observações que não interfiram no objetivo do projeto, estes deverão ser tratados diretamente com o responsável pela fase onde ocorreu o problema. Quando na avaliação 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. Após feitas as correções dos problemas encontrados, estando de acordo com as especificações definidas na análise de requisitos e aceitas pelo cliente, o software estará pronto para uso.

Resumo do Projeto. Ata da Reunião. Lista de Caso de Uso. Diagrama de Caso de Uso.Capítulo 10 .1 Introdução Neste capítulo documentaremos o protótipo desenvolvido baseado na metodologia.Validação da Metodologia 10.2 Formulário de Do cumentação Fonte Tipo : Times New Roman Gravação Tamanho : 12 . Serão abordados os seguintes itens : Formulário de Documentação. 10. mostrando a idéia principal do sistema. Contatos Iniciais. Diagrama de Classes e Escolha da Linguagem. Escopo.

107 Pasta Mãe : Contabilidade Descrição : Esta pasta contém toda a documentação do projeto do sistema de contabilidade.br Descrição: Sistema de Contabilidade com capacidade de emitir os relatórios legais como: diário. Irá receber também . razão. balancete após os lançamentos nas contas contábeis do plano de contas da empresa.rtf Impressão Tamanho do papel: A4(210 X 297mm) Backup Responsável: Reginaldo Darolt / Alexandre de Almeida Periodicidade: Semanal.3 Contatos Iniciais Data: 14/03/2001 Razão Social: Escritório Criciumense de Contabilidade Solicitante: João da Silva Departamento: Gerencial Fone: 048-4371159 Fax : 048-4376020 Ramal: 203 Email: joaocri@terra.com. Versão: 1.0A-01 10. Extensão de Arquivos : .

Definir os possíveis tipos de usuário do sistema. folha de pagamento e controle patrimonial. 5. estes deverão estar conectados no .As possíveis entradas de dados no sistema serão: Manual(através de digitação) e também automáticas por outros sistemas. Quando geradas por outros sistemas. 2. Definições da reunião: 1. 3.4 Ata da Reunião Data : 21/03/2001 Hora Início : 19:00 Hora Final: 22:30 Participantes: Alexandre de Almeida.Definir as saídas/relatórios que o usuário necessita. Irá gerar informações gerenciais para o administrativo.O sistema irá abranger somente o módulo de contabilidade 2. 4.108 lançamentos dos sistemas de livros fiscais.Definir os procedimentos padrões do sistema.Definir a abrangência do sistema. Tipo do pedido: (X ) Novo ( ) Alteração Área de negócio do problema: Contábil Prioridade: (X) Normal ( ) Alta ( ) Urgente Data pretendida para solução: 12 meses 10. Observações: Utilizamos o método questionário para alcançar os objetivos da reunião.Definir as possíveis entradas de dados. Reginaldo Darolt e João da Silva Objetivos: 1.

Razão.109 mesmo banco de dados e sem o auxílio de nenhuma rotina do módulo de contabilidade para execução de tal tarefa. 3. Balanço e Livro Caixa. Emissão de relatórios.Relatórios: • • • • Cadastrais: Contas e Históricos. Recebe lançamentos do sistema de Livros Fiscais nos . 10. Definição de parâmetros do sistema como período de lançamento e máscara contábil. 4.5 Resumo do Proje to Um sistema de Contabilidade com cadastros de contas. Lançamentos. históricos e lançamentos.Procedimentos: • • • • • Cadastro de Usuários. Tempo gasto no sistema por usuário. Acompanhamento de lançamentos. 5. Legais: Diários.Usuários: • • • Contador Digitador Usuários de outros sistemas que somente farão lançamentos no sistema quando conectados no mesmo banco de dados. Cadastro de Contas Contábeis e Históricos Padrões. DRE.

Na Folha de Pagamento recebe lançamentos no momento do cálculo mensal. Este sistema gera informações sobre tempo gasto do usuário para o sistema administrativo. Ambiente Windows95 ou Windows98.1 apresentamos o escopo do sistema: . DRE. Do Controle Patrimonial recebe lançamentos na atualização dos bens e no fechamento de período. No caso de mais de uma estação de trabalho. Balanço e Livro Caixa. Emite relatórios cadastrais. Razão. 10. estas deverão estar conectadas através de uma rede que suporte as estações no ambiente citado.6 Escopo Na figura 10. apuração e pagamento de impostos. e para uma boa apresentação dos relatórios faz-se necessário impressora Jato de Tinta ou Laser. de acompanhamentos e também os relatórios legais tais como: Diário.110 lançamentos de notas. Para um bom desempenho do sistema será necessário o uso de máquinas com configuração igual ou superior a PII 233 Mhz com 32 Mb.

1 Escopo do Sistema 10.7 Lista de Casos de Uso UC001 .111 Figura 10.MANTER PERMISSÕES .EFETUAR LANÇAMENTO UC002 .MANTER PARÂMETROS UC004 .MANTER CONTA CONTÁBIL UC003 .

8 Diagrama de Caso de Uso A figura 10.2 mostra o diagrama de casos de uso do Sistema de Contabilidade.EFETUAR LANÇAMENTOS LIVROS FISCAIS UC006 .MANTER BENS CONTROLE PATRIMONIAL UC010 .FECHAR PERÍODO CONTROLE PATRIMONIAL UC009 .112 UC005 . .NAVEGAR EM REGISTROS UC011 .CALCULAR FOLHA DE PAGAMENTO 10.APURAR IMPOSTOS LIVROS FISCAIS UC007 .PAGAR IMPOSTOS LIVROS FISCAIS UC008 .

3 mostramos o diagrama de classes do Sistema de Contabilidade.2 Diagrama de Caso de Uso do Sistema de Contabilidade 10. .9 Diagrama de Clas ses Na figura 10.113 Figura 10.

03.114 Figura 10.02 da Powersoft com o banco de dados Sybase SQL Anywhere versão 5.0.10 Escolha da Lingu agem Para desenvolvimento do Sistema de Contabilidade.3 Diagrama de Classes do Sistema de Contabilidade 10. escolhemos a linguagem PowerBuilder versão 5.0. .

• Documentação Pontos Fortes: • A extensão de arquivos utilizada nos auxiliou na comunicação entre a equipe envolvida no projeto. • O backup nos salvou de refazer boa parte do projeto.rtf contendo todos os arquivos utilizados no desenvolvimento do projeto e uma pequena descrição de cada arquivo. • Estabelecimento de uma padronização para nome de arquivos. . obtemos alguns resultados os quais julgamos ser necessários destacar. Neste capítulo discriminaremos os pontos fortes e pontos fracos de cada fase da metodologia desenvolvida. devido ao fato de poder ser manipulado nos diversos ambientes encontrados. pois tivemos problemas com vírus na máquina principal onde estava o projeto e a mesma teve de ser formatada.Capítulo 11 .RESULTADOS OBTIDOS Após a validação da metodologia desenvolvida. Pontos Fracos: • Necessidade de um arquivo leia-me.

. Ao final ficou registrado na ata da reunião. Pontos Fracos: • Na lista de Atores deveria ter também a data da criação do ator e o autor que o criou. facilitando as próximas etapas. obteve-se os objetivos gerais e específicos pretendidos com o sistema. desta forma facilitaria no esclarecimento de possíveis dúvidas sobre o ator. tudo foi registrado. pois desde o primeiro contato do cliente com a empresa.116 • Eventos Iniciais Pontos Fortes: • De um modo geral atendeu as necessidades. Com o estudo da área de negócio ficou definido que a empresa atenderia a solicitação do cliente. • Análise Pontos Fortes: • Seguindo as definições da metodologia. • Os casos de uso foram bem detalhados. o diagrama de classes foi facilmente desenvolvido e compreendido por toda a equipe. de modo que qualquer membro do projeto entendeu o seu funcionamento. • Análise de Requisitos Pontos Fortes: • Com os tópicos abordados na reunião. • O diagrama de caso de uso auxiliou na comunicação entre o cliente e os desenvolvedores. Facilitou no desenvolvimento durante a fase de implementação.

Pontos Fracos: • O diagrama de objetos deveria ser detalhado na metodologia para facilitar seu desenvolvimento. Auxiliando desta forma na compreensão comportamental do sistema. bem como informações essenciais para o software como por exemplo o servidor de banco de dados. • O diagrama de implantação mostrou a toda a equipe a estrutura física do cliente. • O diagrama de atividade mostrou de forma clara a ordem de funcionamento do caso de uso manter contas. . separando seus objetos de acordo com sua finalidade. como as informações trafegam no mesmo. • Implementação Pontos Fortes: • Conforme sugerido na metodologia.117 • Os diagramas de interação mostraram o fluxo de funcionamento do sistema. escolhemos uma linguagem conhecida pelos desenvolvedores e que atendesse os requisitos do projeto. • Projeto Pontos Fortes: • O diagrama de componentes nos auxiliaram na estruturação do código fonte. • O diagrama de estado mostrou de forma clara os eventos da principal rotina do sistema que é a rotina de lançamentos.

cujo no nosso ponto de vista é o mais importante. pois todos os programadores poderiam facilmente compreender as rotinas independentes do autor da mesma. • Testes Na estratégia de testes não adotamos a fase de projetos porque seus métodos torna essa tarefa cansativa e também eleva os custos.118 • A documentação do código foi de grande importância durante o desenvolvimento do sistema. É uma fase que pode ser eliminada sem comprometer a fase de testes do projeto. os demais são apenas citados para que sejam explorados caso alguém tenha esta necessidade. . Esta documentação ainda será muito utilizada em futuras manutenções do sistema. Nas fases de teste demos ênfase ao teste de unidade.

é necessário o uso de uma metodologia unificada. tanto para a comunicação entre toda a equipe envolvida (cliente. implementação e testes. Neste contexto. desde os eventos iniciais. Após o estudo da ferramenta CASE Rational Rose da Rational Software Corporation.119 Capítulo 12 . passando pela análise de requisitos. programador. de uma metodologia deste nível. quanto para a documentação(requisitos e código-fonte).CONCLUSÃO Em virtude das constantes inovações que surgem em ferramentas de desenvolvimento de sistemas orientadas a objetos. Durante a realização do trabalho constatamos o interesse por parte de desenvolvedores de software. foi proposta uma metodologia de desenvolvimento de sistemas orientados a objetos baseada em UML(Unified Modeling Language). análise. a partir da qual o desenvolvedor poderá seguir suas etapas para o fluxo correto do desenvolvimento de um projeto. utilizamos a mesma no apoio a validação da . projeto. etc). analista. Com o desenvolvimento de sistemas mais complexos. podemos afirmar a importância do uso de uma metodologia que englobe todas as fases do processo.

Esta ferramenta mostrou-se bastante complexa e eficaz. Com o desenvolvimento do protótipo utilizando a metodologia. Estudo de novas ferramentas CASE.1 Recomendações Este trabalho está aberto a futuros melhoramentos. • Utilização da metodologia no apoio às aulas de engenharia de software. bem como pelo conhecimento que todos envolvidos tinham da mesma. 12. Na implementação do sistema utilizamos a ferramenta de desenvolvimento chamada Power Builder pela facilidade da programação orientada a objetos. permitindo até mesmo gerar código-fonte a partir do modelo. pois ela possui uma documentação interativa e automática dos processos de modelagem.120 metodologia. Desenvolver encontrados. Desta forma podemos dizer que a metodologia se torna necessária para um bom desenvolvimento de sistema orientados a objetos. • Desenvolvimento de uma ferramenta CASE baseado-se na metodologia desenvolvida. novas pesquisas visando corrigir os pontos-fracos . e como recomendações futuras podemos ressaltar: • • • Aplicação da metodologia em um sistema complexo. tendo em vista que esta atendeu todas as fases de desenvolvimento do protótipo. podemos afirmar que os resultados esperados foram alcançados.

tutprog. estamos criando uma simplificação da realidade para um melhor entendimento do sistema. Consultada em http://www.cjb. Campus. Addison-Wesley.addtech. O mais avançado tutorial sobre Unified Modeling Language. 6. Leonardo de Araújo et al. UML : Unified Modeling Language. Adelino Manuel de Oliveira et al.br/~marcosfg/. http://www.dcc. 1998. CABRAL.Capítulo 13 . Geri et al. 7.ufmg. 5. 3.ufmg. .html. Rio de Janeioro.br/~gorgulho/tbd/seminario.net. 2.ufmg.htm.Diagramas de Implementação : importantes quando trata de questões como reutilização e desempenho. BOOCH Grady et al.br/~lucanaan/tbd/texto.dcc.com. 24/03/2001. http://www. Histórico da UML. ADD. SCHNEIDER.BIBLIOGRAFIA 1. Consultada em 24/03/2001. UML : Diagrama de Atividade. Applying Use Cases : A Pratical Guide. 2000. Technologies. UML . http://www. http://www.br. Consultada 24/03/2001. Consultada em 24/03/2001. SILVA. Massachusetts.dcc. UML – Introdução : ao modelar alguma coisa. UML : Guia do Usuário. 4. Consultada em 24/03/2001.

em http://www. .br/~wolff .br/pos/html/spg98/node3. 14. Craig.html 24/03/2001. 2000. Uma Contribuição para o Problema de Compatibilização de Modelos . http://cc.122 8.dcc.1995. BARROS. MODELAGEM E PROJETOS BASEADOS EM Bookman. definições. UTILIZANDO UML E PADRÕES : Uma introdução à análise e ao projeto orientados a objetos. 9. http://www. OBJETOS. TECHMARK.br/download. 13. FURLAN.ufmg.techmark. Bethânia Lagoeiro. 16. Michael Blaha. na Consultada UML. Kendal Scott. 11.Campus. MODELAGEM DE OBJETOS ATRAVÉS DA UML : The Unified Modeling Languagem.usu. Pablo. Rio de Janeiro . James.eps. FOWLER. UFSC. Roger S.html . UML ESSENCIAL : Um breve guia para a linguagem padrão de modelagem de objetos. 10. PRESSMAN.com. São Paulo Makron Books . Consultada em 24/03/2001. LARMAN. ARAÚJO.ufsc. UML : Unified Modeling Language. Martin. Abrange sua história. UML : Linguagem de Modelagem Unificada em Português. Engenharia de Software. 1998. . Tutoriais.Makron Books. 12. CNPQ. Willian Lorensen.Bookman. Frederick Eddy. Porto Alegre 2000. Consultada em 24/03/2001 . José Davi. RUMBAUGH. William Premerlani. Consultada em 24/03/2001.edu/~slqz9/uml . http://www. São Paulo . ENGENHARIA DE SOFTWARE. 1994. 15. Porto Alegre . arquivos e sites relacionados.

Campus. SILVA. 1999. Consultada em 05/04/2001. 1991. MIZRAHI.Érica. ANÁLISE E PROJETO ORINTADOS A OBJETOS : Estudos de Casos. Edward Yourdon.rational. Ferramentas Case.com. São Paulo . CONCEITOS BÁSICOS DA ORIENTAÇÃO A OBJETOS : Capítulo 1. Rio de Janeiro . Victorine Viviane. YOURDON.com. www. Nelson Peres da.Makron Books. RATIONAL. 22. Consultada em 30/10/2001. COOD.br. www. Rational Rose. 19. Parceria Rational. ANÁLISE BASEADA EM OBJETOS. . DBSERVER. 1998. São Paulo .123 17.dbserver. 18. Edward.Makron Books. Vitório Bruno. TREINAMENTO EM C++. MAZZOLA. São Paulo . Software Corporation. 23. 1999. 20. 21. PROJETO E DESENVOLVIMENTO DE SISTEMAS. Peter. Carl Argila.

Extensão de Arquivos : <tipo da extensão> Tamanho : <tamanho da fonte> Impressão Tamanho do papel: <medidas do formulário> Backup Responsável: <Nome do responsável pelo Backup> Periodicidade: Versão: <N.Formulário de documentação.124 1. Anexo 01 . Fonte Tipo : <nome da fonte> Gravação Pasta Mãe : <Nome do Sistema> Descrição : <Abaixo desta pasta mãe estão todos os arquivos necessários referentes a documentação do software>.NX-NN> .

Data: <dd/mm/aaaa> Data do contato do cliente Razão Social: <Nome da Empresa solicitante do software> Solicitante: <Nome para contato na empresa> Departamento: <Departamento do solicitante> Fone: Fax : Ramal: Email: Descrição: <Neste item deve-se tentar passar o máximo de informações possíveis sobre a solicitação> Tipo do pedido: ( ) Novo ( ) Alteração <Informar neste item se trata-se de software e/ou rotina novos ou alteração> Área de negócio do problema: < De acordo com o pedido deve-se definir a área de negócio.125 2.Formulário de contato. para que os envolvidos possam verificar se podem atender ou não> Prioridade: prioridade do pedido> Data pretendida para solução: <O preenchimento se faz necessário. Anexo 02 . pois será estudada pela equipe onde será discutido a possibilidade ou não de ser efetuada> ( ) Normal ( ) Alta ( ) Urgente <Definir aqui a .

Objetivos: <Deve definir o que se pretende alcançar com o sistema. Anexo 03 .126 3.....Formulário da ata de reunião Data : <dd/mm/aaaa> Hora Início : <hh:mm>Hora Final: <hh:mm> Participantes: <Nome1>. <Nome2>. os setores atendidos> Observações: <Definição dos itens que ajudarão no desenvolvimento do sistema> Definições da reunião: <A definição engloba tudo o que foi definido na reunião> .

127 4.Formulário lista de atores Nome <Nome do ator> o que o ator faz e com o que ele interage> Descrição <Descrever em poucas palavras . Anexo 04 .

arquivo <nome do arquivo > caso de uso <Nome do caso de uso que está no arquivo> . Anexo 05 .128 5.Formulário lista de casos de uso.

Anexo 06 . Esta seqüência deverá ser ordenada e cada passo corresponde a uma ação do usuário e uma resposta do sistema ou vice-versa> FLUXOS ALTERNATIVOS: <Usa-se quando o fluxo normal não for seguido. NOME : <Nome do caso de uso> DESCRIÇÃO: <Descrever a funcionalidade do caso de uso> ATORES: <Listar os atores que interagem no caso de uso> DATA <data> ALTERAÇÃO <Descrição da alteração> AUTOR <Listar os autores> SITUAÇÃO INICIAL DO PROCESSO : <O que precisa para existir o caso de uso> FLUXO NORMAL: <Seqüência de passos que ocorre naturalmente com maior freqüência. também serão feitas seqüências de passos alternativos ordenados e identados conforme o fluxo normal que o gerou> REQUISITOS MÍNIMOS: <Os dados que tem que existir ou eventos que tem que ocorrer para que o caso de uso seja válido> PONTOS DE EXTENSÃO: <São casos de uso que usam outro caso de uso> VARIAÇÕES DE DADOS E TECNOLÓGICAS: <Mudanças que podem ocorrem que irão afetar no funcionamento do sistema> .129 6. Neste caso.Formulário de requisitos de caso de uso.

Formulário Diagrama de caso uso NOME : <Nome do diagrama> DESCRIÇÃO: <Descrever em poucas palavras o propósito 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 criação/alteração> ALTERAÇÃO <descrição da alteração> AUTOR <nome do responsável da criação/alteração> .130 7. Anexo 07 .

Formulário de Cronograma Fase: <Fase do projeto> Responsáveis: Nome do Responsável Assinatura <Nome(s) do(s) responsável(is) pela fase> <Assinatura de cada responsável> Data Prevista: <Data prevista para conclusão da fase> .131 8. Anexo 08 .

132 9. Aprovado por Nome Assinatura <Nome(s) do(s) responsável(is) pela fase> <Assinatura de cada responsável> Data da Aprovação: <Data que fase foi aprovada> .Formulário de Aprovação Fase: <Fase do projeto> Declaramos que a presente fase está de acordo com o propósito do sistema. Anexo 09 .

Sign up to vote on this title
UsefulNot useful