UNIFEI Universidade Federal de Itajub

IEE Instituto de Engenharia Eltrica DON Departamento de Eletrnica

MODELO PRTICO PARA DESENVOLVIMENTO DE SISTEMAS ORIENTADO A OBJETO BASEADO NA UML

Dissertao de Mestrado apresentada Universidade Federal de Itajub para obteno do ttulo de Mestre em Engenharia Eltrica.

Orientadora: Prof Dr Lcia R. Horta Rodrigues Franco

Autor: Carlos Henrique Rodrigues Cardoso

ITAJUB - MG Novembro/2002

UNIFEI Universidade Federal de Itajub

IEE Instituto de Engenharia Eltrica DON Departamento de Eletrnica

MODELO PRTICO PARA DESENVOLVIMENTO DE SISTEMAS ORIENTADO A OBJETO BASEADO NA UML

Dissertao de Mestrado apresentada Universidade Federal de Itajub para obteno do ttulo de Mestre em Engenharia Eltrica.

Orientadora: Prof Dr Lcia R. Horta Rodrigues Franco Participantes da Banca Examinadora: Prof. Dr. Jorge Luis Risco Becerra (USP) Prof. Dr. Leonardo de Mello Honrio (UNIFEI) Prof Dr Lcia Regina Horta Rodrigues Franco (UNIFEI)

Autor: Carlos Henrique Rodrigues Cardoso

Pgina 2

DEDICATRIA

Eu dedico este trabalho ao Grande Arquiteto do Universo que tornou a nossa existncia possvel, minha esposa Rita pela incansvel parceria, compreenso e amor, a meus filhos Bruno e Carla que justificam qualquer esforo e a meus pais Jair e Marilda pelo investimento que fizeram durante toda a minha vida.

Pgina 3

AGRADECIMENTOS

Agradeo a toda a minha famlia pela compreenso durante o desenvolvimento deste trabalho. Agradeo ainda minha orientadora Lcia pelas valiosas orientaes durante a pesquisa e montagem deste trabalho. Agradeo ao Afonso Soares pelas longas horas de discusso (e teimosia) sobre engenharia de software, ao Prof. Dr. Mauro Spinola pelas valiosas orientaes e a toda equipe do Inatel Competence Center - SW que permitiu o desenvolvimento de ferramentas e a aplicao e validao prtica do modelo.

Pgina 4

NDICE
1. INTRODUO............................................................................................................... 15 1.1 1.2 1.3 1.4 1.5 1.6 O INCIO DA ENGENHARIA DE SOFTWARE .............................................................. 15 OS PROBLEMAS ...................................................................................................... 17 A ENGENHARIA DE SOFTWARE E O SURGIMENTO DA UML .................................... 19 O CONTEXTO DESTA DISSERTAO ........................................................................ 20 OS RESULTADOS ALCANADOS .............................................................................. 20 O MODELO PRTICO PARA DESENVOLVIMENTO DE SISTEMAS ORIENTADOS A

OBJETOS BASEADA NA UML (MPDS) ............................................................................... 21 2. ORIENTAO OBJETOS ........................................................................................... 27 2.1 2.2 2.3 2.4 O QUE ? ............................................................................................................... 27 CLASSES, OBJETOS E INSTNCIAS .......................................................................... 28 ATRIBUTOS E OPERAES ...................................................................................... 29 RELACIONAMENTOS ............................................................................................... 30 2.4.1 2.4.2 2.4.3 2.5 Herana......................................................................................................... 31 Agregao, Composio e Dependncia ...................................................... 31 Multiplicidade ............................................................................................... 33

POLIMORFISMO ...................................................................................................... 34 2.5.1 2.5.2 Polimorfismo Esttico ................................................................................... 34 Polimorfismo Dinmico ................................................................................ 35

3. CAPTURANDO REQUISITOS ......................................................................................... 38 3.1 3.2 3.3 3.4 3.5 REQUISITOS DO CLIENTE X CLASSES DE PROJETO ................................................. 38 COMO OBTER OS REQUISITOS ................................................................................. 38 OS RISCOS E PRIORIDADES ASSOCIADOS A REQUISITOS ......................................... 40 GERENCIAMENTO DE REQUISITOS .......................................................................... 42 EXEMPLO DE REQUISITOS....................................................................................... 42

Pgina 5

3.5.1 3.5.2 3.5.3 3.5.4 3.5.5

ERaF0001.1 Sacar Dinheiro...................................................................... 42 ERaF0001.2 Movimentar valores entre contas.......................................... 43 ERaF0001.3 Emitir extrato com saldo e completo por perodo ................ 43 ERaI0001.4 Propaganda dos produtos do Banco...................................... 44 ERaF0001.5 Instruo fcil para uso de qualquer opo do Caixa

Eletrnico .................................................................................................................... 44 3.5.6 ERaF0001.6 Informao ao usurio do no funcionamento do Caixa

Eletrnico .................................................................................................................... 45 3.6 AVALIAO ........................................................................................................... 46

4. COMO TRANSFORMAR REQUISITOS EM CASOS DE USO ............................................ 47 4.1 4.2 4.3 ATORES .................................................................................................................. 47 CASO DE USO ......................................................................................................... 49 DIAGRAMA DE CASO DE USO ................................................................................. 55 4.3.1 4.3.2 4.3.3 4.4 Incluso ......................................................................................................... 56 Extenso ........................................................................................................ 57 Derivao ...................................................................................................... 58

AVALIAO ........................................................................................................... 58

5. CLASSES DE ANLISE (ROBUSTNESS MODELING) ...................................................... 60 5.1 5.2 5.3 5.4 5.5 INTRODUO .......................................................................................................... 60 CLASSES DE FRONTEIRA ......................................................................................... 61 CLASSES DE ENTIDADE .......................................................................................... 62 CLASSES DE CONTROLE.......................................................................................... 63 AVALIAO ........................................................................................................... 64

6. DIAGRAMAS DE INTERAO ....................................................................................... 66 6.1 6.2 6.3 AS RELAES ENTRE AS CLASSES DE ANLISE ...................................................... 66 DIAGRAMA DE SEQNCIA ..................................................................................... 66 DIAGRAMA DE COLABORAO .............................................................................. 69

Pgina 6

6.4

EXEMPLO DE DIAGRAMAS DE SEQNCIA.............................................................. 69

7. SUBSISTEMAS .............................................................................................................. 72 7.1 7.2 DESENVOLVIMENTO PARALELO ............................................................................. 72 SUBSISTEMAS ......................................................................................................... 72

8. CLASSES DE PROJETO ................................................................................................. 75 8.1 CLASSES DE PROJETO ............................................................................................. 75 8.1.1 8.1.2 8.1.3 8.2 8.3 8.4 8.5 Tcnicas para implementar classes de fronteira........................................... 76 Tcnicas para implementar classes de entidade ........................................... 77 Tcnicas para implementar classes de controle ........................................... 77

OPERAES ............................................................................................................ 78 ATRIBUTOS............................................................................................................. 80 OPERAES E ATRIBUTOS DE ESCOPO .................................................................... 81 RELACIONAMENTO ENTRE AS CLASSES................................................................... 82 8.5.1 8.5.2 8.5.3 Dependncia.................................................................................................. 83 Associao..................................................................................................... 87 Generalizao ............................................................................................... 91

8.6 8.7

DIAGRAMA DE CLASSES DE PROJETO ..................................................................... 94 GERAO DE CDIGO ............................................................................................ 95

9. TESTES ........................................................................................................................ 96 9.1 9.2 9.3 9.4 10. 10.1 10.2 INTRODUO .......................................................................................................... 96 TESTE DE CLASSE ................................................................................................... 97 TESTE DE STRESS .................................................................................................... 97 TESTE DE FUNCIONALIDADE .................................................................................. 97 SISTEMAS MULTICAMADAS E SISTEMAS DE TEMPO REAL ................................. 98 INTRODUO ...................................................................................................... 98 COMPONENTES ................................................................................................... 98

Pgina 7

10.3 10.4 10.5 10.6

PACOTES .......................................................................................................... 100 CAMADAS ........................................................................................................ 101 SISTEMAS DE TEMPO REAL .............................................................................. 103 EXEMPLO DE SISTEMA DE TEMPO REAL: RECONHECIMENTO DE CHAMADA

TELEFNICA ..................................................................................................................... 104 11. 11.1 11.2 11.2.1 11.2.2 11.3 11.4 11.5 ANLISE DOS RESULTADOS ................................................................................ 106 APLICANDO O MODELO .................................................................................... 106 OS PRS E CONTRA DO MODELO PROPOSTO ..................................................... 107 As vantagens do MPDS ............................................................................... 107 As desvantagens do MPDS.......................................................................... 108 COMPARAES COM OUTROS MODELOS E/OU PROCESSOS ............................... 108 AVALIAO EM PROJETOS REAIS ...................................................................... 110 APLICABILIDADE EM PEQUENAS EMPRESAS/EQUIPES DE DESENVOLVIMENTO DE

SOFTWARE ........................................................................................................................ 111

12. 12.1

CONCLUSES ...................................................................................................... 112 CONTRIBUIES PRTICAS DA PESQUISA ......................................................... 112 A Ferramenta Cattleya................................................................................ 112 CONTRIBUIES DIDTICAS DA PESQUISA ....................................................... 112 Curso de Engenharia de Software .............................................................. 112 Livro UML na prtica Do Problema ao Sistema................................. 113 TRABALHOS FUTUROS ...................................................................................... 113 Melhorias no modelo e atualizao da ferramenta Cattleya...................... 113 Sistemas Embarcados.................................................................................. 114 Modelagem de sistemas com componentes ................................................. 114

12.1.1 12.2 12.2.1 12.2.2 12.3 12.3.1 12.3.2 12.3.3 13.

REFERNCIAS BIBLIOGRFICAS ........................................................................ 115

Pgina 8

ABSTRACT
This paper shows a process, or model, of software development based on UML, focusing the practical use of UML diagrams. This process generates diagrams step by step so it can change the development activities interconnected. The processs name is Practical Model to Software Development oriented to objects based on UML, or MPDS. The MPDS is a modeling process presented through activities and diagrams (i.e., the UML diagrams) and oriented to Use Case[40]. It allows in a clear and consistent way to develop a system of medium duration from 6 to 12 months of continuous work, developed by a team with no or little experience in software modeling. The MPDSs purpose is to allow a system that can be developed and maintained in a consistent way and that the performed work can, as always as possible be used in new projects. The models use as MPDS[3][22] can increase considerably the quality associated with the speed in the systems development, making the small companies obtain a high competitive level.

Pgina 9

RESUMO
Este trabalho apresenta um processo, ou modelo, de desenvolvimento de software baseado na UML focalizando o uso prtico dos diagramas da UML. Este processo gera os diagramas passo-a-passo de modo a tornar as atividades de desenvolvimento interligadas. O nome deste processo Modelo Prtico para Desenvolvimento de Software orientado a Objetos baseado na UML, ou MPDS. O MPDS um processo de modelagem apresentado atravs de atividades e diagramas (no caso, os diagramas da UML) e orientado ao caso de uso[40]. Ele permite de forma clara e consistente desenvolver um sistema de durao mdia de 6 a 12 meses de trabalho contnuo, desenvolvido por uma equipe com nenhuma ou pouca experincia em modelagem. A finalidade do MPDS permitir que um sistema possa ser desenvolvido e mantido de forma consistente e que o trabalho realizado possa, sempre que possvel, ser aproveitado em novos projetos. O uso de modelos como o MPDS [3][22] pode aumentar consideravelmente a qualidade associada rapidez no desenvolvimento de sistemas fazendo com que pequenas empresas tenham um alto grau de competitividade.

Pgina 10

LISTA DE FIGURAS
Figura 1.3 .MPDS - Atividades e Diagramas da UML................................................................................. 26 Figura 2.1 Relacionamento entre cliente e caixa ...................................................................................... 28 Figura 2.2 Exemplo de Classe e Objeto (Instanciao da Classe)............................................................ 29 Figura 2.3 Modelagem da Classe Vaca..................................................................................................... 30 Figura 2.4 Exemplo de Herana entre Classes.......................................................................................... 31 Figura 2.5 Exemplo de Agregao entre Classes ...................................................................................... 32 Figura 2.6 Exemplo de multiplicidade de relacionamento entre classes................................................... 34 Figura 2.7 Exemplo de polimorfismo esttico ........................................................................................... 35 Figura 2.8 Exemplo de Classe Abstrata .................................................................................................... 36 Figura 2.9 Exemplo de polimorfismo dinmico......................................................................................... 36 Figura 4.1 Smbolo associado a Ator na UML .......................................................................................... 47 Figura 4.2 Diagrama de Especializao (Generalizao) de Atores. ....................................................... 48 Figura 4.3 Exemplo do uso de Diagrama de Atividades para Caso de Uso............................................. 54 Figura 4.4 Exemplo de Diagrama de Casos de Uso.................................................................................. 55 Figura 4.5 Caso de Uso Includo............................................................................................................... 56 Figura 4.6 Caso de Uso Estendida ............................................................................................................ 57 Figura 4.7 Derivao entre Casos de Uso................................................................................................ 58 Figura 4.8 Exemplo de fragmentao do Caso de Uso ............................................................................. 59 Figura 5.1 - Smbolo para Classe de Fronteira........................................................................................... 61 Figura 5.2 - Exemplos Classes de Fronteira ............................................................................................... 62 Figura 5.3 - Smbolo para Classe de Entidade............................................................................................. 63 Figura 5.4 - Exemplos Classes de Entidade ................................................................................................. 63 Figura 5.5 - Smbolo para Classe de Controle ............................................................................................. 64 Figura 5.6 - Exemplo de Classes de Controle .............................................................................................. 64 Figura 5.7 - Exemplo de Realizao de Caso de Uso ou Classes de Anlise ............................................... 65 Figura 6.1 - Diagrama de Seqncia............................................................................................................ 68 Figura 6.2 - Diagrama de Colaborao....................................................................................................... 69 Figura 6.3 - Exemplo do uso do Diagrama de Seqncia ............................................................................ 71 Figura 7.1 - Smbolo de Subsistema para UML ........................................................................................... 73 Figura 7.2 - Exemplo de Subsistema ............................................................................................................ 74 Figura 8.1 - Exemplo de classe com 3 tipos de operaes ........................................................................... 79 Figura 8.2 - Exemplo de atributos de classe................................................................................................. 81

Pgina 11

Figura 8.3 - Exemplo de classe com atributo de escopo .............................................................................. 82 Figura 8.4 - rvore de herana de relacionamentos .................................................................................... 83 Figura 8.5 - Relacionamento entre Cliente e Fornecedor ............................................................................ 84 Figura 8.6 - Representao na UML de dependncia e associao............................................................. 85 Figura 8.7 - Exemplo de implementao de dependncia com varivel local.............................................. 85 Figura 8.8 - Exemplo de implementao de dependncia por passagem de parmetro............................... 86 Figura 8.9 - Exemplo de uma dependncia por Classe Utilitria ................................................................ 86 Figura 8.10 - Exemplo de Composio ........................................................................................................ 87 Figura 8.11 - Exemplos de Agregao ......................................................................................................... 88 Figura 8.12 - Representao de templates na UML ..................................................................................... 89 Figura 8.13 - Relacionamento Muitos para Muitos...................................................................................... 90 Figura 8.14 - Implementao com uma Classe de Associao..................................................................... 90 Figura 8.15 - Exemplo de Generalizao (Herana) e outros relacionamentos .......................................... 92 Figura 8.16 - Exemplo de relacionamento de generalizao com classe abstrata....................................... 93 Figura 8.17 - Exemplos de mltipla herana ............................................................................................... 93 Figura 8.18 - Como solucionar o problema de mltipla herana ................................................................ 94 Figura 10.1 - Componentes em sistemas distribudos e camadas ................................................................ 99 Figura 10.2 - Smbolo de pacote na UML .................................................................................................. 101 Figura 10.3 - Sistema de trs camadas....................................................................................................... 102 Figura 10.4 - Exemplo de sistema com 4 camadas..................................................................................... 103 Figura 10.5 - Exemplo de Diagrama de Estado ......................................................................................... 105

Pgina 12

SMBOLOS, SIGLAS E ABREVIATURAS

UML Unified Modeling Laguage (Linguagem de Modelagem Unificada) OO Object Orientation (Orientao a Objetos) MPDS Modelo Prtico para Desenvolvimento de Sistema OMG Object Management Group Grupo responsvel pela definio da UML Sistemas Embarcados Programas desenvolvidos para executar em hardware dedicado como por exemplo: telefones celulares, elevadores, ou seja, equipamentos eletro-eletrnicos em geral que no sejam microcomputadores. Clientes ou Clientes do Sistema so as pessoas responsveis pelo fornecimento dos requisitos do sistema, ou seja, as pessoas que conhecem as necessidades do usurio. Pode eventualmente ser os prprios usurios. Usurios ou Usurios do Sistema so as pessoas que iro utilizar o sistema aps o desenvolvimento, ou seja, as pessoas que tero de fato interao com o sistema, que utilizaro o sistema. Pode eventualmente ser os prprios clientes. Framework Representa um conjunto de componentes (classes ou subsistemas) que pode e deve ser utilizado no desenvolvimento de novos sistemas. Os componentes de um framework devem ser testados e documentados para facilitar a reutilizao. Desenvolvimento Paralelo a capacidade de se distribuir adequadamente as atividades entre os componentes da equipe para agilizar o processo de desenvolvimento. Incremento Um incremento representa uma diferena de tempo entre duas verses do sistema.

Pgina 13

Iterao Uma iterao representa uma seqncia de atividades distinta e planejada e com uma forma de avaliao resultando em uma verso.

Pgina 14

1. INTRODUO

1.1 O Incio da Engenharia de Software

Durante muito tempo o desenvolvimento de software foi realizado de forma emprica, sem um processo definido. Por muitas vezes os autores e usurios do sistema eram as mesmas pessoas ou faziam parte da mesma equipe. O que implicava que o uso e o conhecimento do sistema ficasse restrito a um grupo. Com a popularizao dos computadores, o nmero de usurios aumentou drasticamente e foi necessrio o desenvolvimento de interfaces amigveis que permitissem que no especialistas em computao pudessem utiliz-los. Porm o desenvolvimento dos sistemas continuava catico. Algumas tcnicas surgiram como orientao a objetos que, a principio, prometiam melhorar o desenvolvimento e a reutilizao de cdigo. Porm a popularizao das linguagens orientadas a objeto, que permitiriam que o processo de desenvolvimento fosse alterado, no ocorreu de forma substancial. Na dcada de 90 cada pesquisador imaginava que o seu modelo era o melhor. Houve uma poca conhecida como a guerra dos modelos at que os trs principais pesquisadores (Jacobson, Rumbaugh e Booch) decidiram unir os trabalhos. Eles criaram um novo modelo utilizando o que cada um tinha de melhor. Esta unio gerou a Linguagem de Modelagem Unificada - UML (Unified Modeling Language). Isto foi decisivo para a padronizao. Submeteram este nova linguagem ao OMG (Object Management Group) que a transformou em um padro aberto. A UML tem a cada dia se estabelecido como um padro para o desenvolvimento de software e mais e mais pessoas esto utilizando-a. Normalmente o desenvolvimento de projetos realizado por pequenas empresas (ou grupos) no utiliza nenhum tipo de modelagem em funo do desconhecimento e da complexidade dos diagramas. Os sistemas so desenvolvidos de forma ad hoc e as promessas da Orientao a Objetos, como reutilizao de cdigo ou facilidade de manuteno no tem acontecido na maioria dos projetos.

Este trabalho cria um processo, ou modelo, de desenvolvimento de software baseado na UML focalizando o uso prtico dos diagramas da UML. Tal processo gera os diagramas passo-a-passo de modo a tornar as atividades de desenvolvimento interligadas. O nome deste processo Modelo Prtico para Desenvolvimento de Software Orientado a Objetos baseado na UML, ou MPDS. O Prtico do nome do processo esta relacionado a principal fonte de informaes para a sua criao, ou seja, projetos reais. O MPDS um processo de modelagem apresentado atravs de atividades e diagramas (no caso, os diagramas da UML) e orientado ao caso de uso[40]. Este processo permite de forma clara e consistente desenvolver um sistema de durao mdia de 6 a 12 meses de trabalho contnuo, desenvolvido por uma equipe com nenhuma ou pouca experincia em modelagem. A finalidade do MPDS permitir que um sistema possa ser desenvolvido e mantido de forma consistente e que o trabalho realizado possa, sempre que possvel, ser aproveitado em novos projetos. O uso de modelos como o MPDS [3][22] pode aumentar consideravelmente a qualidade associada rapidez no desenvolvimento de sistemas fazendo com que empresas inexperientes (empresas incubadas por exemplo) tenham um alto grau de competitividade. O aumento da qualidade e rapidez esta relacionado com a possibilidade de descoberta e diminuio dos riscos associados a um projeto. Alm disso a padronizao ir facilitar o aproveitamento de conhecimento adquirido em projetos anteriores. Na maioria das vezes a documentao de projeto considerada um peso extra e normalmente feita parte do projeto. A vantagem de se utilizar um processo como MPDS que a documentao gerada como base para o desenvolvimento, para negociar com o cliente, para o desenvolvimento e para testar, faz parte do processo. O MPDS utiliza um nico documento para todo o projeto. Deste modo serve de auxlio e troca de informaes entre os membros da equipe. Mesmo porque se for necessrio utilizar a documentao, quando feita parte, no ser aderente ao produto desenvolvido. Vale a pena ressaltar que a finalidade primordial do MPDS no gerar documentao. A documentao um produto natural do trabalho durante o desenvolvimento do projeto.

Pgina 16

1.2 Os problemas
O desenvolvimento de software uma atividade extremamente complexa e subjetiva por envolver como principal matria prima pessoas (a principal preocupao do CMM Capabity Maturity Model[35] no nvel 2 a gerncia intimamente ligado a pessoas) e por envolver tecnologia muito nova [17][25]. Alm disto, o relacionamento entre clientes e desenvolvedores sem um procedimento definido gera dificuldades e no raro leva a atritos que terminam em quebra de contrato e prejuzo para ambas as partes. Uma tentativa de organizar o desenvolvimento foi a criao da tcnica de programao estruturada utilizada em linguagens como Cobol, Fortran, C entre outras. O desenvolvimento utilizando a tcnica estruturada baseado no fluxo de execuo do sistema. Nesta tcnia difcil a mudana aps o incio da implementao. O uso de um procedimento estruturado mais artificial do que outras tcnicas, o que dificulta muito a mudana. Via de regra o cliente, muitas vezes, muda de opinio depois do incio do desenvolvimento. E isto acontece principalmente por falta de conhecimento das necessidades reais do sistema ou da dificuldade de priorizar [41][51]. Tempos mais tarde e tentando fazer com que o desenvolvimento fosse mais prximo do mundo real foi criada a tcnica de desenvolvimento orientado a objetos. Os dados e operaes so armazenados em classes que possuem um comportamento claro. As principais linguagens so Ada, Java e C++[45][54]. As tcnicas de desenvolvimento vem evoluindo muito nos ltimos anos. Porm a tcnica de Orientao a Objetos no consegue resolver sozinha os problemas ligados a desenvolvimento de software. A orientao a objetos permitiu a criao de uma linguagem grfica chamada UML (Unified Modeling Language) que serve de base para o MPDS. Muitas vezes programas orientados a objetos no foram desenvolvidos utilizando realmente as tcnicas de orientao a objetos. As definies como encapsulamentos, isolamento, atribuio de responsabilidades, entre outras nem sempre so aplicadas ao desenvolvimento. impossvel desenvolver um sistema que satisfaa a todas as necessidades de uma s vez, principalmente se estas necessidades vo surgindo enquanto se desenvolve.

Pgina 17

 importante estar preparado para administrar e gerenciar as necessidades do cliente[27][29]. mais fcil ter um modelo que preveja as mudanas e incluso de requisitos, do que tentar congelar as necessidades em um determinado momento, no d para escolher e definir o que o cliente precisa. Alm do cliente tem-se um problema na outra ponta, a equipe de desenvolvimento. Existe uma frase que diz que o desenvolvedor de software discpulo de Ivonsaf, ou seja discpulo da Irresistvel vontade de sair fazendo. Isto talvez seja uma caracterstica normal engenharia, principalmente s novas engenharias, como a engenharia de software, em funo da facilidade de se iniciar um projeto. Neste campo as ferramentas e novas linguagens visuais fizeram um desservio a tecnologia de desenvolvimento, principalmente para pequenos grupos. A frase que mais se ouve No h tempo a perder com projeto, precisamos iniciar o desenvolvimento. Comear o desenvolvimento de imediato como fazer uma casa sem planta baixa. A chance de dar errado muito grande. O desenvolvimento de software nos ltimos anos passou a ser realizado em pases do terceiro mundo em funo do barateamento dos computadores e facilidade no acesso a informaes atravs da internet (ver exemplo da ndia). A cada dia o hardware esta mais barato e potente. A inteno facilitar o desenvolvimento rpido de novos programas com qualidade, escopo, prazos e custos adequados e atendendo a um maior nmero de clientes com necessidades diferentes. O desenvolvimento de software uma atividade que demanda um planejamento extremamente eficiente ao qual os projetistas no esto acostumadas a fazer. No muito difcil de se aprender uma nova linguagem de programao. Porm cada desenvolvedor possui um mtodo de trabalho prprio que foi desenvolvido durante a carreira e que lhe totalmente particular. Isto um dos maiores problemas no desenvolvimento em equipe, unem-se vrios artistas que acham que meu jeito o melhor e no se consegue padronizar o desenvolvimento. Algum sai da equipe e ningum sabe como substitu-lo. importante que exista um estudo acadmico no sentido de gerar tecnologia de modelagem e processo de desenvolvimento dedicado a empresas inexperientes em

Pgina 18

engenharia de software. Esta a motivao desta dissertao: apresentar um processo baseado em um modelo conhecido e unificado como a UML. Porm apresentando: os caminhos, as atividades que devem ser feitas, o porqu deve ser feito, como uma atividade est ligada a prxima, como um diagrama est ligado ao prximo.

1.3 A Engenharia de Software e o surgimento da UML

At o incio da dcada de noventa pouco se dizia a respeito de engenharia de software. Alis nem este termo era muito utilizado, dando-se preferncia para o termo programao. Alguns como Roger S. Pressman foram pioneiros em encarar o desenvolvimento de sistemas como sendo uma engenharia. Porm com caractersticas muito particulares. Software considerado como sendo uma moeda com duas faces: ao mesmo tempo um produto e um veculo que entrega um produto[39]. Este o caso dos programas que esto em aparelhos celulares por exemplo. No incio da dcada de 90 viu-se o que ficou conhecido como a guerra das metodologias [9], ou seja, vrios pesquisadores de engenharia de software diziam que a sua metodologia era o melhor e iria resolver todos os problemas. Infelizmente as coisas no so to simples assim e em meados da dcada decidiu-se que era mais prudente reunir o que houvesse de melhor em cada proposta e criar um modelo nico. Foi assim que Jacobson, Booch e Rumbaugh criaram a UML (Unified Model Language) onde pretendia-se apresentar uma ferramenta unificada que servisse de sustentao ao desenvolvimento. A UML inicialmente foi apresentada como um padro e um dos fatores mais importantes para o uso da UML foi o fato de existir uma ferramenta chamada Rose. Esta ferramenta foi desenvolvida pela Rational, uma empresa composta pelos trs principais criadores da linguagem. Aderiram ao modelo empresas como Digital, HP, I-Logix, Intelicorp, IBM, ICON, MCI, Microsoft, Oracle, Rational, Texas e Unisys. Isto permitiu a criao da verso 1.0 da UML que foi padronizado pela OMG em janeiro de 1997. Entre janeiro e junho de 97 outras empresas, como Ericsson e Andersen, passaram a fazer parte do grupo e em

Pgina 19

novembro de 97 foram aprovadas as revises na UML gerando a verso 1.1. Em junho de 98 foi lanada a verso 1.2 e em dezembro de 98 foi lanada a verso 1.3 que a verso mais utilizada[56]. A UML, apesar de baseada em estudos com mais de 10 anos, ainda muito recente. Isto faz com que muitos cursos e profissionais ainda no tenham tido tempo de adquirir o conhecimento e aplic-lo no dia a dia do desenvolvimento. A UML uma ferramenta. apresentada como um conjunto de diagramas com suas respectivas finalidades, porm no responsvel em apresentar um processo de engenharia. Por isto no orienta o processo de desenvolvimento[57].

1.4 O contexto desta dissertao

Esta dissertao apresenta o MPDS, cuja finalidade servir de metodologia de desenvolvimento de sistemas para empresas inexperientes (empresas incubadas) que estejam envolvidos em projetos com durao de 6 a 12 meses. Estes fatores, considerados como condio de contorno, fazem com que o uso de um processo adequado e bem sustentado possa servir de guia ao desenvolvimento. A UML muito abrangente e complexa para ser utilizada sem um processo, principalmente por grupos inexperientes. O MPDS foi desenvolvido para atender estes grupos.

1.5 Os resultados alcanados

Apresenta-se com este trabalho um mtodo chamado de Modelo Prtico para Desenvolvimento de Sistemas Orientados a Objetos (MPDS) baseado em uma seqncia de diagramas da UML associados a atividades constituindo um processo de modelagem. O MPDS foi aplicado em projetos acadmicos no Curso de Computao III do Instituto Nacional de Telecomunicaes Inatel, alm disto foi utilizado em projetos comerciais do Inatel Competence Center to diferentes quanto ferramenta CASE, Sistema de Monitoramento de Cho de Fbrica via Web ou ainda Sistema de Tempo Real para Gerenciamento de Chamadas Telefnicas. Espera-se que com o MPDS os profissionais

Pgina 20

da rea de desenvolvimento de software assim como professores e estudantes possam utiliz-lo como uma ferramenta prtica de desenvolvimento de sistemas. O Processo Unificado UP(Unified Process que deu origem ao Rational Unified Process RUP)[9] foi desenvolvido pelos trs amigos, criadores da UML, alm do Philip Krutchen. A Inteno do UP apresentar um processo que atende-se a qualquer tipo de projeto. Porm a complexidade deste processo muito grande e existem vrios papis a serem desempenhados. Empresas incubadas (inexperientes e normalmente pequenas) no conseguem utilizar o UP e acabam no adotando processo algum.

1.6 O Modelo Prtico para Desenvolvimento de Sistemas Orientados a Objetos baseada na UML (MPDS)
O desenvolvimento de software pode ser considerado uma atividade de raciocnio humano nica e sem precedentes na histria. uma mistura de criatividade com tecnologia o que faz com que se necessite de um processo que atenda as expectativas tecnolgicas sem restringir a criatividade no desenvolvimento do projeto. A criatividade uma caracterstica humana difcil de ser aprendida, quase impossvel de ser ensinada e muito menos determinada por um processo. J o conhecimento e a aplicao do conhecimento tecnolgico pode e deve ser modelado, uniformizado e transmitido a fim de aumentar a produtividade e a qualidade do produto gerado[30][31]. Um ponto muito importante no desenvolvimento de um sistema (software) a definio da arquitetura adequada. Isto no um trabalho trivial e depende de experincia em projetos. muito difcil para uma empresa incubada (e muitas vezes inexperiente) ter um arquiteto. Por isso empresas inexperientes devem definir uma rea especfica de produtos ligados a um nico tipo de arquitetura (Sistemas embarcados, Sistemas para E-Comerce, Sistemas para Controle de Processo, etc). Isto at que a experincia e a estabilidade da empresa permitam experimentar reas que exijam novos conhecimentos de arquitetura. O MPDS foi baseado em uma linguagem j conhecida e abrangente, a UML, e prope uma forma de desenvolvimento criado principalmente do prisma do desenvolvedor.

Pgina 21

Apresenta de forma clara a seqncia do trabalho a ser desenvolvida, ou seja, onde comea e onde termina o trabalho e quais so as etapas a serem seguidas. Vale salientar que o MPDS um processo de engenharia de software. Est focado no desenvolvimento em si e no na gerncia do desenvolvimento. O MPDS segue a linha do Problema ao Sistema que permite identificar o(s) problema(s) que suscitou(aram) a necessidade de uma soluo e desenvolver um sistema com prazo, custo e qualidade adequados. Os passos do MPDS so:

Problema: O problema na realidade composto pelo conjunto de requisitos que o cliente tem que um sistema possa resolver. Existem inmeras formas de resolver o mesmo problema, ou seja, existiro vrios tipos de sistemas que podem ser desenvolvidos a partir destas necessidades. O que se quer garantir utilizando um modelo de engenharia de software que o resultado atenda as necessidades com qualidade e que as melhorias possam ser feitas.

Levantamento e Anlise de Requisitos: Uma vez sendo apresentado aos problemas preciso format-los e analis-los de forma a levantar os possveis riscos da no implementao do sistema nas condies apresentadas pelo cliente. Esta fase fundamental porque representa um compromisso do que se est contratando e o que ser entregue no final do projeto.

Modelagem de caso de uso: Com os requisitos em mos definem-se os atores e os casos de uso que iro atender a estes requisitos. Deve-se colher nos requisitos funcionais do sistema (requisitos com os quais o usurio ir interagir) os casos de uso que permitiro atend-los.

Escolha do(s) caso(s) de uso a ser(em) trabalhada(s): A escolha do ou dos caos de uso a serem trabalhadas deve utilizar as avaliaes de riscos e prioridades j

Pgina 22

levantadas. Deve-se atacar os problemas mais difceis primeiro e deixar o que j se tem domnio da soluo para depois. Esta escolha tambm deve levar em conta quais os casos de uso so bsicas para o funcionamento do sistema para que as outras a serem desenvolvidas possam ser incorporadas no incremento seguinte. Nesta fase criam-se prottipos de partes do sistema a fim de diminuir os riscos dos casos de uso o mais cedo possvel.

Modelagem de classes de anlise: A partir dos casos de uso a serem trabalhadas determinam-se as classes de anlise que as compem. Este trabalho representa o primeiro passo de fragmentao do caso de uso no sentido do sistema.

Modelagem dinmica utilizando o diagrama de seqncia: A modelagem dinmica formada principalmente por duas entradas: Para cada caso de uso os objetos referentes as classes de anlise e os atores so colocados no diagrama de seqncia e, O fluxo de eventos do caso de uso utilizado para determinar as mensagens e sua seqncia no diagrama. As classes de anlise sero fundidas ou desmembradas durante o processo de anlise dinmica dos objetos que representam estas classes. Este trabalho

representa a ponte entre a anlise e o projeto. difcil definir neste ponto onde termina a anlise e onde comea o projeto. O trabalho na modelagem dinmica, principalmente no diagrama de seqncia dever gerar a maioria das classes de projeto. Isto facilitar a busca das operaes (e por conseqncia os mtodos) e dos atributos, que as classes de projeto tero, alm de permitir identificar os subsistemas que faro parte do sistema. Isto tambm facilita a reutilizao de cdigo j desenvolvido. Deve-se desenvolver os diagramas seqncia de anlise com as mensagens do fluxo de eventos do caso de uso e as classes (objetos) de anlise. Isto permite inclusive a validao dos fluxos de eventos. E aps a

Pgina 23

compreenso do modelo, permite desenvolver os diagramas de seqncia de projeto com operaes no lugar das mensagens.

Modelagem de classes de projeto: Aps a modelagem dinmica passa-se a modelagem esttica das classes de projeto detalhando os relacionamentos, atributos e mtodos, comportamento definido, subsistemas, pacotes, etc. As classes de projeto representam a ltima fase do projeto. A partir da passa-se a gerao de cdigo que representa a implementao do projeto.

Gerao de cdigo: A gerao de cdigos executveis representam o incio do final do incremento do MPDS que comeou com a anlise do problema. Um novo cdigo ser gerado e testado ao final de cada ciclo de processo, construindo assim as partes do sistema.

Testes: Os testes dos cdigos gerados a cada incremento facilitam a integrao e o funcionamento do sistema. Todos os testes devem ser documentados para que possam ser repetidos a qualquer momento durante o desenvolvimento do projeto.

Sistema: O sistema a concluso da montagem de cada parte de cdigo gerado e testado em cada ciclo de desenvolvimento ou incremento. O ciclo ser responsvel por uma parte de cdigo que adicionado ao cdigo j existente. Todas as partes do cdigo devem ser testadas. O sistema est concludo quando todos os caos de uso forem desenvolvidas ou todos os requisitos forem atendidos.

Modelagem de Sistemas de Tempo Real: Caso o sistema necessite se comportar de modo a responder a mensagens quase que instantaneamente onde dado atrasado um dado errado [12], caracterizando um sistema de tempo real, devese utilizar o diagrama de estado para modelar o comportamento dinmico relativo

Pgina 24

aos estados. Os estados geralmente so implementados em mtodos de estado de uma classe de controle.

Modelagem de Pacotes/Componentes: O desenvolvimento de sistemas complexos ou de sistemas para internet iro necessitar da diviso em pacotes e componentes. Eles determinaro a forma de desenvolvimento e da montagem final. Os componentes so normalmente utilizados para sistemas de 3 ou mais camadas desenvolvidos, por exemplo com: COM+ (Microsoft) JavaBeans, J2EE (Sun). Existem sistemas que utilizam componentes e possuem somente uma camada.

A figura 1.1 a seguir mostra um diagrama de atividades a serem executadas e labels, representando os diagramas da UML utilizado durante o desenvolvimento. Este diagrama o MPDS. A explicao dos tpicos anteriores deve ser acompanhada da visualizao anlise desta figura. Os captulos 2 a seguir ir fazer uma apresentao introdutria da orientao a objetos e os captulos 3 a 10 iro apresentar em detalhes cada passo do MPDS mostrado na figura 1.1. Os captulos 11 e 12 apresentam as concluses do trabalho.

Pgina 25

Figura 1.3 .MPDS - Atividades e Diagramas da UML

Pgina 26

2. ORIENTAO OBJETOS

2.1 O que ?
O desenvolvimento de software sofreu evolues que marcaram os rumos e geraram correntes como o desenvolvimento estruturado, que ainda hoje utilizado, principalmente para sistemas embarcados. Apesar de ser muito utilizado, e com sucesso, o desenvolvimento estruturado possui uma caracterstica negativa em muitos projetos quando o sistema cresce fica cada vez mais difcil a manuteno e continuidade do sistema. Uma das correntes e que tem evoludo muito o desenvolvimento orientado a objetos[54] onde as responsabilidades so divididas entre objetos que se relacionam e se comunicam[4][13]. Para exemplificar podemos imaginar o desenvolvimento de um software que simulasse uma agncia bancria simples. Em um projeto estruturado definiramos algumas estruturas como por exemplo, cliente, caixa, conta que iriam armazenar os dados e desenvolveramos mtodos que manipulariam estes dados para executar funes como pagamento, retirada, depsito, etc. O sistema se comporta em um looping onde os mtodos so chamados em uma determinada seqncia para executar as operaes necessrias. Esta no a forma como uma agncia bancria funciona, as operaes no so seqenciais, as estruturas como cliente, caixa ou conta alm de dados podem e devem executar operaes. Em um sistema orientados a objetos o cliente teria alm dos dados(nome, cpf, endereo, etc) operaes como por exemplo: retirarDinheiro, pagarConta, depositarDinheiro, etc, que so tpicas de todos os clientes. J o caixa realizaria operaes como: fazerPagamento, verificarSaldo, transferirSaldo, etc. E o cliente teria um relacionamento com o caixa da agncia para executar as operaes. desta forma que uma agncia bancria funciona e desta forma que a modelagem orientada a objetos encara o sistema a ser desenvolvido. Caso quisssemos criar, por exemplo, um cliente especial,

Pgina 27

deveramos atualizar somente o cliente e no seria necessrio alterar todo o programa, ou seja, os objetos esto isolados. A figura 2.1 mostra o diagrama de relacionamento entre cliente e caixa.

Figura 2.1 Relacionamento entre cliente e caixa

2.2 Classes, Objetos e Instncias

Objeto um conceito que existe no mundo real (existem objetos no mundo real). Objeto tudo aquilo com o qual nos podemos relacionar ou que relacionam entre si, de uma agulha a um vaso, de uma nuvem a uma vaca, o mundo real repleto de objetos diferentes e com diferentes formas de relacionamentos. O fato de utilizar uma tcnica de desenvolvimento que se aproxime do mundo real facilita a manuteno e evoluo de sistemas. O desenvolvimento de software orientado a objetos utiliza os mesmos conceitos do mundo real para simular o que ocorre no dia-a-dia quando um sistema esta em execuo. Outra caracterstica do desenvolvimento orientado a objetos, e que tambm pertence ao mundo real, a definio do conceito de classe que representa um conjunto de objetos com caractersticas similares, quando foi dito que uma vaca um objeto, na verdade refere-se a classe vaca, porque no foi identificada nenhuma vaca em particular, podemos ento dizer que a Mimosa, a Fartura e a Malhada so objetos que pertencem a classe vaca. Em modelagem orientada a objetos diz-se que um objeto uma instanciao de uma classe, ou seja, um objeto o que existe de fato enquanto a classe um conceito abstrato. E podemos dizer que apesar das vacas no serem semelhantes elas possuem uma srie de caractersticas que permite associ-las a classe Vaca. A figura 2.2 mostra a relao de classe e objetos.

Pgina 28

Figura 2.2 Exemplo de Classe e Objeto (Instanciao da Classe)

2.3 Atributos e Operaes

Um conceito associado a uma classe ou a um objeto a propriedade ou um conjunto de propriedades que uma classe possui, por exemplo podemos associar a propriedade fazer mooo a classe Vaca. A propriedade de uma classe pode ser dividida em duas partes: Atributos: Onde armazenado os dados do objeto, como no caso da classe Vaca podemos exemplificar o nome, idade, produo mdia de leite, entre outras. Operaes: o comportamento do objeto. Normalmente o termo operao usado, porm algumas vezes pode ser chamado de servio ou mtodo ou ainda atividade. Na classe vaca temos, por exemplo, as seguinte operaes: dar leite, pastar, ruminar, e outras.

Pgina 29

A UML criou uma notao especfica para representar uma classe[8][30] e podemos ver o exemplo na figura 2.3 a seguir:

Figura 2.3 Modelagem da Classe Vaca claro que o animal Vaca real bem mais complexa que o nosso modelo(classe), porm o modelo deve ser suficiente para a representao da classe do ponto de vista de desenvolvimento de software ou do que se pretende que o sistema faa.

2.4 Relacionamentos
Como foi dito anteriormente os objetos relacionam entre si e como o que se faz modelar os objetos muito importante que os objetos possuam operaes que permitam o relacionamento. Imagine um objeto da classe Fazendeiro que possui um operao chamada RetirarLeite que executado quando o fazendeiro se relaciona com o objeto da classe Vaca, ou seja, importante que o modelo contemple a operao produzirLeite para a classe Vaca, caso contrrio este relacionamento no ser possvel. A seguir so apresentados os principais relacionamentos entre classes.

Pgina 30

2.4.1 Herana
Uma classe pode possuir um relacionamento de herana com outra classe. Nestes casos dizemos que a classe me menos especializada, ou seja, mais genrica e a classe filha mais especializada. Este relacionamento conhecido como um tipo, ou do tipo, por exemplo, vaca um tipo de mamfero, portanto podemos dizer que a classe vaca possui um relacionamento de herana com a classe mamfero, ou tambm, que a classe vaca derivada da classe mamfero. A representao de um relacionamento de herana feito atravs de uma seta que vai da classe filha para a classe me[18], como mostrado na figura a seguir.

Figura 2.4 Exemplo de Herana entre Classes

2.4.2 Agregao, Composio e Dependncia

Outras formas de relacionamento so agregao, composio ou dependncia[14][33]. Estes relacionamentos so semelhantes diferenciando em relao a intensidade. Um relacionamento de composio existe quando uma classe composta por outra de tal

Pgina 31

forma que a parte que compe no existe se no existir o todo, ou seja, a parte no vive sem o todo o caso por exemplo de um pedido de compras e os itens do pedido, se destruirmos o pedido de compras todos os itens sero destrudos, obrigatoriamente, porque no haver mais compra. A agregao semelhante, porm a parte vive sem o todo, ou seja, se no existir o todo a parte continuar existindo, o caso da vaca e o fazendeiro, onde existe um relacionamento de agregao. A figura 2.5 mostra o diagrama de classe com os

relacionamentos de herana e agregao.

Figura 2.5 Exemplo de Agregao entre Classes

J uma dependncia quando uma classe depende de outra porm isto ocorre esporadicamente durante a vida dos objetos, o exemplo entre uma fbrica e uma consultoria de marketing. Estes conceitos facilitam o desenvolvimento da modelagem, porm na maioria dos casos prticos a gerao do cdigo, que o que em ltima anlise estamos buscando, pode mudar pouco e isto varia de linguagem para linguagem mas a compreenso do modelo

Pgina 32

fundamental para os grupos de desenvolvedores. So os relacionamentos que iro determinar a princpio as operaes que uma classe dever possuir para satisfazer ao relacionamento; esta uma das formas de se determinar que operaes deveremos ter.

2.4.3 Multiplicidade
No relacionamento entre duas classes existe uma determinada multiplicidade, por exemplo um fazendeiro pode possuir vrias vacas, portanto o relacionamento chamando ordenhar que esta exemplificado na figura a seguir do tipo 1 para muitos. A princpio no se pode definir de antemo quantas vacas um fazendeiro ter que ordenhar, ento deixamos o relacionamento em relao a vaca com o smbolo * (que a notao de UML para muitos[8][14]) e do lado do fazendeiro 1 que esta em destaque na figura a seguir. Existem outros relacionamentos possveis neste exemplo(todo fazendeiro tambm mamfero, por exemplo) mas que no so relevantes para o modelo, devemos nos concentrar no comportamento que cada objeto deve ter para atender as necessidades do sistema. A figura 2.6 ressalta a multiplicidade entre as classes fazendeiro e vaca.

Pgina 33

Figura 2.6 Exemplo de multiplicidade de relacionamento entre classes

2.5 Polimorfismo
Polimorfismo uma das caractersticas importantes no desenvolvimento orientado a objetos, polimorfismo a propriedade que indica que uma operao pode, apesar de ter o mesmo nome, executar aes diferentes[54]. Existem dois tipos de polimorfismo, o esttico e o dinmico.

2.5.1 Polimorfismo Esttico

Este conceito no de simples compreenso e mais uma utiliza-se um exemplo para explicar. Imaginemos uma classe chamada Data que armazena os dados de dia, ms e ano alm de hora, minuto e segundo, como mostrado, na figura 2.7, a seguir.

Pgina 34

Figura 2.7 Exemplo de polimorfismo esttico Ao chamar a operao AjustaData a operao exata que ir ser executada depender dos parmetros que so passados, ou seja: Se utilizarmos AjustaData(15/09/2001) ser executada a primeira operao, porm Se utilizarmos AjustaData(15,9,2001) ser executada a segunda operao

A classe que se relaciona com a classe Data no necessita saber os detalhes da operao AjustaData, deve simplesmente usar a que melhor lhe convier. A vantagem disto que a classe pode atender a vrios usurios da classe e cada um enxerg-la de maneira diferente. Os objetos do mundo real tambm executam as mesmas atividades porm atendendo de forma diferente; dependendo de como e quais os parmetros so passados.

2.5.2 Polimorfismo Dinmico

Uma outra forma de polimorfismo o dinmico, vamos mais uma vez utilizar um exemplo, imaginemos a classe FormaGeomtrica que esta apresentada na figura 2.8 a seguir.

Pgina 35

Figura 2.8 Exemplo de Classe Abstrata

Esta classe possui uma operao chamada Desenhar, porm como desenhar uma forma geomtrica se no sabemos exatamente como ela ? Esta operao chamada operao abstrata (o que faz com que a classe FormaGeomtrica seja chamada de classe abstrata), ou seja, serve como referncia, porm no implementada, a implementao fica a cargo da classe filha(classe derivada) mostrada na figura 2.9 a seguir.

Figura 2.9 Exemplo de polimorfismo dinmico

Pgina 36

Imagine que temos dois objetos (ou instanciao da classe) Retangulo e Circulo e o ponteiro para FormaGeometrica: Retangulo R; Circulo C; FormaGeometrica *pFG; Tem-se o seguinte cdigo: void Desenhar() { pFG = &R; //O ponteiro aponta para o objeto retngulo pFG->Desenhar(); // desenhado um retngulo pFG = &C; //O ponteiro aponta para o objeto crculo pFG->Desenhar(); // desenhado um crculo }

Podemos observar que simplesmente chamando a operao Desenhar de um objeto abstrato FormaGeometrica que aponta para o objeto no abstrato, e o objeto executa a operao Desenhar correta.

Pgina 37

3. CAPTURANDO REQUISITOS

3.1 Requisitos do Cliente X Classes de Projeto

O objetivo final da modelagem desenvolver o diagrama de classes de projeto, ou seja, desenvolver de classes onde ser implementado o cdigo que executar as funes do sistema. O diagrama de classes de projeto composto pelas classes com seus atributos e operaes e pelo relacionamento entre elas. O processo de desenvolvimento deve ser feito por incrementos[9][35]. O que ser descrito deste ponto em diante como adquirir os requisitos (ou necessidades do cliente, o problema) e como caminhar at o diagrama de classes de projeto (o sistema). Como o processo incremental, ao final do primeiro incremento, gera-se parte do cdigo e inicia-se novamente o processo para os requisitos que no foram trabalhados, caminhando-se novamente pela seqncia de atividades e diagramas que sero apresentados, e assim repetindo para cada incremento.

3.2 Como obter os Requisitos

Requisito o nome dado a todos os tipos de necessidades que se identificam para um sistema[26]. Normalmente obtido atravs de entrevistas com os clientes ou algum que conhea a necessidade dos usurios. Estas entrevistas devem ser conduzidas utilizando-se checklists para orientar as perguntas. A obteno dos requisitos do sistema no uma atividade trivial[39], uma vez que quem os fornecer muitas vezes no sabe de antemo tudo que deva ser implementado, ou seja, sabe qual o problema mas no tem idia de como a soluo. por estas e outras razes que se deve dedicar uma ateno muito especial para obt-los. , normalmente, durante a obteno dos requisitos que os responsveis pelo desenvolvimento interagem com os problemas e necessidades do cliente e acabam conhecendo e aprendendo sobre o negcio[58] no qual o sistema estar envolvido. Portanto esta fase fundamental para o sucesso do sistema.

Pgina 38

O responsvel pelo desenvolvimento deve ser capaz e estar disposto a aprofundar-se nos problemas do cliente. No se deve deixar nenhum tipo de requisito de fora do levantamento[59] por mais que parea impossvel de realiz-lo no momento. Esta avaliao deve ser feita em um outro momento. Nestes casos deve ser negociado para que estes requisitos se transformem em requisitos futuros. bvio que isto s ser possvel caso estes os mesmos no sejam prioritrios. Deve-se deixar claro que este requisito ter um impacto muito grande no desenvolvimento do projeto, devendo ter grande influncia no prazo de entrega do sistema[47].

Uma forma de facilitar a especificao dos requisitos dividi-los nos seguintes tipos:

Requisitos Funcionais(F) Especifica uma ao que o sistema dever ser capaz de realizar, sem levar em considerao restries fsicas como por exemplo, um requisito que especifique o comportamento das entradas e sadas do sistema.

Requisitos de Dado(D) Referem-se estrutura esttica do software. Estes requisitos podem ser atributos simples ou aqueles que iro formar uma base de dados lgica. Para este ltimo tipo devero possuir especificaes tais como: tipo de informaes usadas por vrias funes, freqncia de uso, capacidade de acesso, entidades e relacionamentos, restries de integridade e requisitos de reteno de dados.

Requisito de Interface(I) Refere-se a interfaces de cliente e tambm com outros sistemas de software ou de hardware ou ainda de comunicao. Deve-se detalhar as interfaces do cliente (formato de tela, formato de relatrios, estruturas de menus, funes de teclas, etc.), interfaces do software e hardware (outros produtos de software requeridos tais como, DBMS, Browser Web, sistema operacionais e interfaces com outros sistemas de aplicao, indicando nome, verso e fabricante, incluindo definies do comportamento de cada uma delas) e ainda como exemplo, interfaces de comunicao tais como redes LAN (TCP/IP, Sockets, RPC, etc.).

Requisito no funcional(N) Requisito no funcional ou requisito especial pode incluir; requisitos legais ou referente a algum regulamento, a aplicao de padres e tambm os atributos de qualidade do sistema a ser construdo. Adicionalmente, outros

Pgina 39

requisitos tais como; o sistema operacional a ser utilizado, requisitos de compatibilidade e restries de projeto, tambm devero ser capturados neste item.

Uma forma interessante para identificar os requisitos utilizar a seguinte definio:

ER[f|a][F|D|I|N][XXXX].N onde ER significa Especificao de Requisitos [f|a] significa requisito futuro ou atual F|D|I|N apresenta em qual tipo de requisito esta associado XXXX o nmero ou sigla do projeto que o requisito esta associado N o nmero seqencial de requisitos do projeto

3.3 Os Riscos e Prioridades associados a Requisitos

Uma atividade muito importante na Especificao de Requisitos determinar qual a prioridade o cliente associa a cada um dos requisitos levantados. Em geral o cliente tem uma tendncia de dizer que todos so de altssima prioridade, porm isto nem sempre verdade. Esta negociao muito importante e uma atividade muito subjetiva e difcil de ser conduzida por pessoas extremamente tcnicas. nesse momento que o papel de gerncia de desenvolvimento de software entra em cena, no se pode dizer sim a tudo que o cliente pede, deve-se ser bastante claro ao mostrar as dificuldades de se desenvolver um sistema e o impacto em custo e prazo. As prioridades iro facilitar na conduo do projeto e em quais atividades sero realizadas e a que tempo. Os nveis de prioridade podem ser divididos da seguinte forma: . Altssima . Alta . Mdia . Baixa . Baixssima

Pgina 40

Outro fator importante determinar o nvel de risco associado a um requisito. O que determina o risco de desenvolvimento de um sistema ? O risco de um requisito medido relativo a: Qual o risco do requisito no ser entregue no prazo pedido pelo cliente Qual o conhecimento tcnico para implementao Qual a dificuldade de obteno de informaes tcnicas.

Enfim a avaliao deve refletir o conhecimento tcnico da equipe e das necessidades do projeto. Os nveis de risco podem ser divididos da seguinte forma: . Altssimo . Alto . Mdio . Baixo . Baixssimo

A determinao do conjunto Prioridade/Risco (P/R) ir orientar o desenvolvimento, ou seja, assim que possvel deve-se baixar o nvel dos riscos associados aos requisitos de maior prioridade. Faa a anlise de riscos, mesmo que se erre na avaliao, isto ir auxiliar em projetos futuros. Uma das maneiras o desenvolvimento de prottipos que possam ou permitir que o risco seja reduzido ou negociar com o cliente uma nova forma de atender o requisito, e importante que isto ocorra durante a fase inicial do projeto de modo que todos os riscos estejam no nvel baixo ou baixssimo antes da fase de implementao[21]. Deve-se ter em mente que o sucesso do projeto se baseia em levantar e especificar da forma mais precisa possvel os requisitos e em seguida determinar uma estratgia que permita no prazo mais curto possvel reduzir o nvel dos riscos associados aos requisitos[31].

Pgina 41

3.4 Gerenciamento de Requisitos

O Gerenciamento de Requisitos uma atividade que permite monitorar as necessidades apresentadas pelo cliente e o andamento da soluo destas do ponto de vista de projeto. impossvel congelar os requisitos do cliente, uma vez que a cada passo e conforme o sistema vai sendo construdo vai tambm se tornando mais claro como o sistema deve funcionar, que caractersticas tecnolgicas o sistema deve ter. Assim o cliente vai sentindo a necessidade de novos recursos a serem implementados. importante salientar a necessidade de se documentar e controlar todos os requisitos associados ao sistema, sejam eles oriundos do cliente ou determinados pela anlise do sistema. de fundamental importncia que se possa rastre-los de modo a medir o quanto um determinado requisito (que pode surgir a qualquer momento) ter impacto no prazo final do projeto. A documentao, identificao e anlise de risco associado aos requisitos servem de base para gerenci-los a fim de minorar os problemas quando a mudana. Um erro neste ponto ir se propagar durante o projeto e gerar um srie de problemas que na maioria das vezes leva ao cancelamento do projeto e/ou ao reprojeto em novas bases o que sempre desastroso, caro e desgastante tanto para o cliente quanto para a equipe.

3.5 Exemplo de Requisitos

Para facilitar a compreenso de como devem ser especificados os requisitos de um sistema vamos exemplificar utilizando alguns necessrios para desenvolvimento de um Caixa Eletrnico de Banco. A seguir so apresentados alguns requisitos para demonstrar como so avaliados e descritos.

3.5.1 ERaF0001.1 Sacar Dinheiro

O sistema dever permitir que usurio saque dinheiro do caixa eletrnico. Esta atividade responsvel pelo ciclo que se inicia quando o usurio solicita o saque de dinheiro e se encerra, no fluxo timo, quando o usurio recebe em dinheiro o valor solicitado e o documento de comprovao de saque.

Pgina 42

Tabela 3-1- Risco do Requisito Sacar Dinheiro Descrio do risco A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio Risco Altssimo Prioridade Altssima

3.5.2 ERaF0001.2 Movimentar valores entre contas

O sistema dever permitir movimentar valores entre contas do mesmo usurio. Tabela 3-3 Risco do Requisito Movimentar valores entre contas Descrio do risco A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio Risco Altssimo Prioridade Altssima

3.5.3 ERaF0001.3 Emitir extrato com saldo e completo por perodo

O sistema dever permitir emitir extrato com o saldo da conta selecionado pela usurio ou emitir extrato com dados completos de crdito e dbito por perodo no maior que 3 meses anteriores a data atual configurado pelo usurio.

Pgina 43

Tabela 3-5 - Risco do Requisito Emitir extrato com saldo da contra e extrato completo por perodo Descrio do risco A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio Risco Altssimo Prioridade Altssima

3.5.4 ERaI0001.4 Propaganda dos produtos do Banco

O sistema dever permitir apresentar propaganda dos produtos do banco quando o sistema de caixa eletrnico no estiver em uso. Tabela 3-7- Risco do Requisito Propaganda dos produtos do Banco Descrio do risco A implementao conhecida, existe pessoal disponvel para o desenvolvimento e o prazo para desenvolvimento razovel. Risco Baixo Prioridade Mdia

3.5.5 ERaF0001.5 Instruo fcil para uso de qualquer opo do Caixa Eletrnico
O sistema dever permitir, que a qualquer momento do uso de uma opo (servio) do caixa eletrnico, o usurio possa ser auxiliado no uso e nas informaes que esto sendo solicitadas.

Pgina 44

Tabela 3-9- Risco do Requisito Instruo fcil para o uso de qualquer opo do Caixa Eletrnico Descrio do risco A implementao no totalmente conhecida, existe pessoal disponvel para o desenvolvimento e o prazo para desenvolvimento razovel. Risco Mdio Prioridade Alta

3.5.6 ERaF0001.6 Informao ao usurio do no funcionamento do Caixa Eletrnico

O sistema dever permitir em caso de falta de dinheiro, falta de comunicao com o sistema central ou qualquer outra falha o usurio seja informado.

Tabela 3-11 - Risco do Requisito Informao ao usurio do no funcionamento do Caixa Eletrnico Descrio do risco A implementao totalmente conhecida, existe pessoal disponvel para o desenvolvimento e o prazo para desenvolvimento razovel. Risco Baixo Prioridade Alta

Pgina 45

3.6 Avaliao
Os requisitos apresentados so alguns exemplos para o desenvolvimento de um sistema de Caixa Eletrnico, e neste caso esto colocados somente os funcionais. Os requisitos apresentados tem nveis diferentes de risco. Devemos avaliar os de mais alto risco e eliminar o risco associado o mais rpido possvel, por exemplo para o requisito ERaF0001.1 Sacar Dinheiro deve-se desenvolver prottipos ainda na fase de levantamento e especificao e negociar com o cliente qual a melhor soluo encontrada para o atend-lo antes de iniciar a fase de implementao do sistema (Note que o risco deste requisito esta associado a outros). Alm dos requisitos de alto risco deve-se desenvolver prottipos de interface, ou seja, janelas de interface com o usurio para que possa ser avaliada pelo cliente como uma prvia do produto final.

Pgina 46

4. COMO TRANSFORMAR REQUISITOS EM CASOS DE USO

Uma vez especificados os requisitos (vale salientar que no necessrio obter e especificar todos os requisitos do sistema, pode-se iniciar a determinao dos casos de uso logo com os primeiros requisitos a mo)inicia-se o processo de especificao do caso de uso [15][40][47] que foi introduzido por Ivar Jacobson[8][9] e que veremos com mais detalhes neste captulo.

4.1 Atores
Um ator [8] qualquer pessoa ou sistema externo (SE) que tenha interao com o sistema que esta em desenvolvimento. O nome ideal seria papel e no ator. Isto tem confundido alguns projetistas que acabam identificando somente as pessoas que acessam o sistema e no levam em considerao que outros SEs podem e devem ser representados como ator. Alm do nome foi definido para a UML um smbolo que ajuda nesta associao com pessoas interagindo com o sistema como mostrado na figura a seguir.

Figura 4.1 Smbolo associado a Ator na UML

A identificao dos atores o primeiro passo para a criao do caso de uso, um ator representa uma classe fora do sistema que se envolve de alguma forma com o mesmo. O uso do conceito classe importante porque o ator no um objeto, ou seja, no uma pessoa (ou SE) em particular que ir utilizar o sistema sim o papel que esta pessoa (ou SE)especfica ou conjunto de pessoas representam para o sistema. Um ator pode ser representado atravs de um diagrama de especializao (ou generalizao) como utilizamos com classes. A figura a seguir representa um diagrama

Pgina 47

de atores com relacionamento de especializao. Neste exemplo estamos identificando alguns dos possveis atores do caixa eletrnico de banco. Um ator o cliente do banco, porm temos neste caso trs tipos diferentes de ator que derivam do ator genrico cliente de banco, so eles:

Cliente VIP Cliente Especial Cliente Padro

Estes clientes possuem papis comuns, porm em funo da forma de atendimento existem caractersticas que so especficas para cada tipo de cliente do banco e por conseqncia do caixa eletrnico.

Cliente do Banco

Cliente VIP

Cliente Padro

Cliente Especial

Figura 4.2 Diagrama de Especializao (Generalizao) de Atores. O primeiro passo para identificar os atores e realizado entre o analista juntamente com o cliente (sempre que possvel) que os identificam e os organizam em categorias (classes) de atores [8]. Dois critrios so importantes para identificar um ator:

Pgina 48

1. Deve ser possvel de identificar pelo menos um usurio que representa o ator candidato, isto ajuda a encontrar somente os atores relevantes e ignorar os atores fictcios. 2. Deve existir um mnimo de sobreposio de papis entre os diferentes atores que relacionam com o sistema, no deve existir dois atores com os papis semelhantes em relao ao sistema, se isto ocorrer devemos combin-los em um ator ou tentar utilizar a generalizao. O analista aps identificar os atores deve dar um nome e fazer uma breve descrio dos papis de cada ator no sistema. muito importante definir nomes que representem o maior nmero de papis de um determinado ator, isto ir facilitar a identificao.

4.2 Caso de Uso

Um caso de uso [8][14] pode ser definida como:

Um conjunto de funcionalidades de um sistema, representado por fluxos de eventos iniciados por um ator e apresentando um resultado de valor a um ator.

Aps identificar os atores do sistema deve-se iniciar a identificao dos casos de uso de modo a transformar os requisitos do sistema passado pelo cliente em algo que possa ser entendido pela equipe de desenvolvimento. Esta passagem representa o elo de ligao entre o processo de desenvolvimento e as necessidades do cliente. A identificao dos casos de uso baseado nos requisitos no uma atividade trivial[10][44], uma vez que cada sistema necessariamente diferente do outro. Porm representa um avano do ponto de vista do processo de desenvolvimento, pois qualquer identificao por mais precria que seja melhor do que nenhuma. O processo de desenvolvimento incremental, ou seja, o analista ter oportunidade de passar outras vezes por este trabalho. Existe sempre a possibilidade de se corrigir e aprofundar o detalhamento dos casos de uso. Para identificar um caso de uso devemos seguir os seguintes passos[8][49]:

Pgina 49

1. Analisar e agrupar todos os requisitos do ponto de vista das funcionalidades(requisitos funcionais) do sistema a ser desenvolvido, ou seja, imagine um ciclo completo de uso dos sistema e determine quais os requisitos esto associados a este ciclo. 2. Uma vez agrupados determine quais os atores interagem com este ciclo. 3. Descreva o fluxo timo para este ciclo, ou seja, o fluxo onde nada de errado acontece e a entrada do ator levar ao resultado no final sem erros ou problemas. 4. Descreva os fluxos alternativos ou de exceo para este ciclo, ou seja, quando e onde algo pode der errado. 5. Caso o fluxo seja complexo ser necessrio desenvolver um diagrama de atividades para este ciclo. Sempre que possvel interessante gerar um diagrama de atividades para demonstrar o fluxo de eventos graficamente. 6. Partes de um caso de uso pode aparecer em outros casos de uso, por exemplo o caso de uso para identificar o login do usurio analisando nome e senha, desta forma interessante dividir o caso de uso em partes para no repetir a descrio. Existem trs tipos de relacionamento entre casos de uso, que so: 1. Herana : equivalente a herana entre classes ou atores, os casos de uso podem herdar o comportamento do caso de uso da qual deriva. 2. Incluso : O caso de uso que includa sempre executada, ou seja, o fluxo de eventos deste caso de uso sempre acessado, porm pode ser representada por um caso de uso independente. 3. Extenso : O caso de uso estende o comportamento do caso de uso, ou seja, o fluxo de eventos do caso de uso pode ou no ser acessado.

O desenvolvimento dos seis itens apresentados representa a criao de um caso de uso. importante ao final da criao de cada caso de uso reunir-se com o cliente no sentido de discutir se o que foi analisado esta de acordo com as necessidades. Os casos de uso so

Pgina 50

uma traduo das necessidades do cliente, pea que o cliente analise o que foi criado. Os casos de uso e os prottipos, como as janelas de interface com o usurio representam a primeira viso do cliente do produto final e tem importncia fundamental no desenvolvimento do projeto. No se deve tentar detalhar todos os casos de uso ao mesmo tempo. Da mesma forma que foi feito para os requisitos deve-se determinar qual(is) casos de uso(s) (so) fundamental(is) para o incio do desenvolvimento do sistema e detalh-la ao mximo na primeira fase. A determinao de quais casos de uso sero trabalhadas de responsabilidade do arquiteto do sistema que deve possuir uma viso completa do sistema que a ser desenvolvido, o arquiteto ir basear-se no levantamento de prioridades e riscos dos requisitos que esto associados a um caso de uso. Considerando os atores do caixa eletrnico um caso de uso sacar dinheiro, portanto podemos descrev-la da seguinte forma: Caso de Uso Sacar Dinheiro

Breve Descrio: Esta caso de uso responsvel pelo ciclo que se inicia quando o usurio solicita ao Caixa Eletrnico o saque de dinheiro e se encerra, no fluxo timo, quando o usurio recebe o dinheiro e o documento de saque. Pr condio: O usurio solicitar o saque de dinheiro. Incio do caso de uso Este caso de uso inicia quando o usurio solicita o saque de dinheiro do caixa eletrnico. Tabela 4-1 Fluxo timo Aes Recebidas 1. O usurio solicita o saque de dinheiro Aes Realizadas 2. O terminal pede que ele passe o carto 3. O usurio passa o carto solicitado pelo terminal 4. O terminal l os dados do carto 5. Verifica se o carto vlido 6. Solicita a senha 7. A senha digitada pelo usurio 8. Avalia a senha

Pgina 51

9. Solicita que o usurio entre com a quantia a ser sacada 10. A quantia digitada pelo usurio 11. verificada a quantia de recursos na conta do usurio 12. feita a impresso do recibo de saque 13. liberado o valor solicitado 14. O sistema volta ao estado inicial para a execuo de outros servios para o mesmo ou para outros usurios. Fluxos Alternativo: Tabela 4-2 - Carto invlido ou passado de forma incorreta pelo leitor Aes Recebidas 1. O usurio passa o carto solicitado pelo terminal Aes Realizadas 2. O terminal l os dados do carto 3. Verifica se o carto vlido 4. Determina que o carto invalido 5. Pede ao usurio que passe o carto novamente e mostra isto graficamente 6. Volta ao ponto 3 do fluxo timo Tabela 4-3 Senha Incorreta Aes Recebidas 1. A senha digitada pelo usurio Aes Realizadas 2. Avalia a senha 3. Verifica que a senha no vlida e solicita que o usurio

Pgina 52

digite novamente a senha 4. Volta ao ponto 7 do fluxo timo e aps a terceira tentativa o sistema informa que no poder mais executar qualquer operao com este carto por um prazo de 24 horas

Tabela 4-4 Saldo Insuficiente Aes Recebidas 1. A quantia digitada pelo usurio Aes Realizadas 2. verificada a quantia de recursos na conta do usurio 3. No h recursos suficientes para a finalizao do saque 4. solicitado um novo valor de acordo com o saldo do usurio 5. Volta ao ponto 10 do fluxo timo

A figura 4.3 a seguir apresenta o mesmo fluxo de eventos, porm na forma de um diagrama de atividades, onde todos os fluxos so mostrados de uma forma nica. O diagrama de atividades permite apresentar as atividades executadas e as mudanas de fluxo, ou questes.

Pgina 53

Incio do fluxo Sacar Dinheiro

Usurio solicita o saque de dinheiro

O terminal pede que ele passe o carto

O usurio passa o carto solicitado pelo terminal

O terminal l os dados do carto Pede ao usurio que passe o carto novamente e mostra isto graficamente [No] [Sim] Informa que a senha incorreta Solicita a senha

O carto vli do ?

A senha digitada pelo usurio [No] Fim da contagem ? [Sim] Informa que o carto no ser mais acei to por 24 horas Incrementa contador de erros [No] [Sim] Solicita ao usurio que entre com a quantia a ser sacada A senha correta ?

Sada por execesso de erro na digitao da senha

A quantia digitada pelo usurio

solicitado um novo valor de acordo com o saldo do usurio

[No] [Sim]

Saldo suficiente ?

feita a impresso do reci bo de saque

liberado o valor solicitado

Fim do fluxo de Saque de Dinheiro

Figura 4.3 Exemplo do uso de Diagrama de Atividades para Caso de Uso

Pgina 54

4.3 Diagrama de Caso de Uso

A fim de complementar o caso de uso a UML definiu um diagrama que a apresenta como uma elipse com o nome e o relacionamento com os atores do sistema. O diagrama de caso de uso no substitui a descrio dos fluxos de eventos e do prprio caso de uso, porm permite determinar o relacionamento entre atores e casos de uso e ainda permite dividi-la.

Cliente do Banco

Sacar Dinheiro

Sistema Central

Figura 4.4 Exemplo de Diagrama de Casos de Uso Observaes: Para o caso de uso Sacar Dinheiro existem mais dois atores: Impressora, que responsvel por imprimir o recibo de retirada de dinheiro Equipamento de Liberao de Dinheiro, que responsvel, como o prprio

nome diz, pela liberao das notas correspondente ao valor solicitado pelo usurio. Estes atores no sero modelados para facilitar didaticamente a compreenso do modelo.

A criao do caso de uso de derivao ou incluso[8] permite fragmentar um caso de uso e deve ser feito em duas situaes: O fluxo de eventos utilizado por outros casos de uso ou O fluxo de eventos muito complexo e ir dificultar o detalhamento em um nico caso de uso.

Como j foi dito anteriormente, alm da derivao os casos de uso podem ser divididas por incluso e extenso que sero apresentados a seguir.

Pgina 55

4.3.1 Incluso
A incluso representa um fluxo de eventos que se repete em outros casos de uso, desta forma possvel criar o caso de uso uma nica vez e inclu-la nas outras que tenham o mesmo fluxo de eventos. Na tabela de fluxo de eventos quando for necessrio citar o fluxo deve-se colocar o texto: Incluir o caso de uso [Nome do caso de uso]. Um exemplo o fluxo de eventos que avalia a senha do usurio do caixa eletrnico, este caso de uso ser utilizada por outros casos de uso do sistema e sempre ser necessrio execut-la.

Cliente do Banco

Sacar Dinheiro

Sistema Central

<<include>>

Validar Usurio

Figura 4.5 Caso de Uso Includo Desta forma o fluxo de eventos de Verificar Senha ser independente do caso de uso Sacar Dinheiro porm includo nesta e se chama Validar Usurio. Caso de Uso Validar Usurio Aes Recebidas 1. O usurio inicia um servio do sistema 3. A senha digitada pelo usurio Aes Realizadas 2. A senha solicitada 4. Avalia a senha, se vlida encerra com resposta afirmativa 5. Verifica que a senha no vlida e solicita que o usurio digite novamente a senha 6. Volta ao ponto 2 deste fluxo e aps a terceira tentativa o sistema informa que no poder

Pgina 56

mais executar qualquer operao com este carto por um prazo de 24 horas

4.3.2 Extenso
Quando um fluxo de eventos faz parte de um caso de uso mas nem sempre este fluxo executado pode-se retir-lo do caso de uso e coloc-lo como uma extenso do caso de uso. Como para incluso, deve-se quebrar o caso de uso caso o fluxo de eventos se repita em outro(s) caso(s). Um exemplo seria o caso de uso Saldo Insuficiente que no executada para alguns clientes do banco(se for cliente VIP no necessrio consultar a conta).

Cliente do Banco

Sacar Dinheiro

Sistema Central <<extend>>

Saldo Insuficiente

Figura 4.6 Caso de Uso Estendida Caso de Uso Saldo Insuficiente Aes Recebidas 1. No h recursos suficientes para a finalizao do saque 3. A nova quantia digitada pelo usurio Aes Realizadas 2. solicitado ao usurio um valor inferior ao digitado de acordo com o saldo do usurio 4. verificada a quantia de recursos na conta do usurio 5. Se valor correto retorna com resposta positiva, seno 6. Volta ao passo 2 do fluxo

Pgina 57

4.3.3 Derivao
A derivao entre caso de uso semelhante a derivao em classes, ou seja, o caso de uso filho herda as propriedades do caso de uso pai. Para exemplificar imagine que tenhamos dois tipos de validao do usurio, uma seria atravs da senha e outro atravs de identificao das impresses digitais do usurio, neste caso temos o caso de uso Validar Usurio dividida em duas como mostrado na figura a seguir.

Validar Usurio

Verificar Senha

Verificar Impresso Digital

Figura 4.7 Derivao entre Casos de Uso

4.4 Avaliao
A anlise dos requisitos e transformao em caso de uso um passo muito importante[7][55] e deve ser feito com muita ateno. Por isto deve ser discutido com o cliente e revisitado sempre que alguma dvida surgir[10][28]. Lembre-se que o fluxo de eventos que representa, na forma de tabela, um conjunto de requisitos do cliente, pea que seja avaliado com o mximo critrio possvel. A subdiviso do caso de uso depende do nvel de complexidade e deve ser avaliado se deve ou no ser feito, a figura a seguir mostra o diagrama completo da caso de uso Sacar Dinheiro.

Pgina 58

Cliente do Banco

Sacar Dinheiro <<include>>

Sistema Central <<extend>>

Validar Usurio

Saldo Insuficiente

Verificar Impresso Digital

Verificar Senha

Figura 4.8 Exemplo de fragmentao do Caso de Uso

Pgina 59

5. CLASSES DE ANLISE (ROBUSTNESS MODELING)

5.1 Introduo
Aps a definio dos casos de uso que atendem os requisitos do cliente o passo seguinte transformar o caso de uso em classes de anlise[43]. A transformao consiste em determinar classes de fronteira, controle e entidade que so mostrados em detalhes neste captulo. Classes de Anlise representam uma abstrao de uma ou mais classes de projeto e/ou subsistemas[9].As classes de anlise possuem as seguintes caractersticas preliminares: As classes de anlise representam o comportamento relacionado a requisitos funcionais (caso de uso) no incio da anlise e vo adquirindo novas funcionalidades com a seqncia do projeto. As classes de anlise raramente possuem operaes ou argumentos (que so caractersticos das classes de projeto). O comportamento da classe definido sem se preocupar com os detalhes, ou seja, a responsabilidade e o comportamento da classe deve ser descrita na forma de texto. Um comportamento muito importante das classes de anlise o relacionamento com as outras classes. Estes relacionamentos iro gerar no futuro as operaes que definem o comportamento da classe. As classes de anlise podem definir atributos, porm estes atributos so sempre conceituais, ou seja, no feito o detalhamento.

As caractersticas das classes de anlise so mutantes, ou seja, conforme se evolui na anlise a caminho do projeto sero agregadas mais informaes at que em um determinado ponto a classe de anlise se torna uma classe de projeto[42]. Com as classes de anlise inicia-se o processo de distribuio do comportamento do caso de uso em classes. Na primeira avaliao do caso de uso provavelmente ir se chegar a um nmero de classes de anlise pequeno que representam de forma macro o

Pgina 60

comportamento do caso de uso. Porm com o aprofundamento da anlise novas classes surgiro e outras sero fundidas de modo que no final do processo as classes de anlise estaro muito prximas das classes de projeto. Existem trs tipos de classes de anlise: Classes de Fronteira, Classes de Controle e Classes de Entidade.

5.2 Classes de Fronteira

As classes de fronteira so responsveis pela comunicao entre o caso de uso e o Ator[37], sendo assim existe uma regra bsica que determina que cada relao entre Ator e o caso de uso responsvel por uma classe de fronteira e este relacionamento envolve receber ou apresentar informaes do sistema ao ator. Os comportamentos destas classes esto intimamente ligados com o ator que mantm relacionamento com o caso de uso. atravs da classe de fronteira que o ator ter os seus requisitos atendidos. Uma interface com o usurio ou na interface de comunicao deve ser isolada em uma ou mais classes de fronteira. Classes de fronteira muitas vezes esto associadas a janelas, forms, interfaces de

comunicao, interface de impressora, sensores, terminais e APIs(Aplication Program Interfaces). A figura 5.1 a seguir mostra como o smbolo para classes de fronteira.

Fronteira

Figura 5.1 - Smbolo para Classe de Fronteira

Para o exemplo de caso de uso Sacar Dinheiro identificamos na primeira anlise que existem duas classes de fronteira que so:

Pgina 61

Janela de Interface com o usurio, que ir ser responsvel por obter e enviar informaes para o usurio Interface de Comunicao com o sistema central, que ser responsvel por buscar informaes do cliente no sistema central onde se encontram os dados dos correntistas

Interface de Comunicao com o sistema central

Janela de Interface com o usurio

Figura 5.2 - Exemplos Classes de Fronteira Observaes: Existem mais duas classes de fronteira, uma que interage com a impressora que imprime o recibo de liberao de dinheiro e outra responsvel por enviar as informaes para o equipamento que libera o dinheiro, mas para facilitar a compreenso e simplicidade do modelo, estas duas classes no sero modeladas.

5.3 Classes de Entidade

As classes de entidade so utilizadas para modelar informaes que so duradouras e persistem durante a execuo do sistema. So informaes e comportamentos associados a conceitos como objetos ou eventos da vida real. Um objeto de entidade (instancia de uma classe de entidade) no necessariamente passivo; pode e deve possuir um comportamento mais complexo relacionado as informaes que representam e isolam as mudanas no sistema relativo a estas informaes. No existe uma regra bsica para determinar as classes de entidade, deve-se analisar as informaes relativas ao caso de

Pgina 62

uso, normalmente em uma primeira anlise so determinadas de 1 a 3 classes de entidade por caso de uso. As classes de entidade so representadas como mostrado na figura 5.3 a seguir.

Entidade

Figura 5.3 - Smbolo para Classe de Entidade

Avaliando o caso de uso Sacar Dinheiro identificamos as seguintes classes de entidade: Cliente, que responsvel por armazenar as informaes do usurio durante o processo de saque de dinheiro no caixa eletrnico Carto/Conta, que responsvel por armazenar as informaes do carto e conta do usurio durante o processo de saque de dinheiro no caixa eletrnico

Cliente

Carto/ Conta

Figura 5.4 - Exemplos Classes de Entidade

5.4 Classes de Controle

As classes de controle representam a coordenao, sequenciamento, transaes e controle entre os objetos do caso de uso, isto , todo o controle do caso de uso ser encapsulado nas classes de controle. As classes de controle so tambm utilizadas para representar aes complexas como lgica do negcio que represente o comportamento do caso de uso e que no representam uma informao duradoura como no caso das informaes das classes de entidade.

Pgina 63

A parte dinmica do sistema ser modelada em classes de controle uma vez que elas manipulam e coordenam as principais aes e controle de fluxos e distribuem o trabalho a ser executado pelas classes de entidade ou de fronteira. A regra para a primeira anlise uma classe de controle para cada caso de uso, normalmente a classe de controle recebe mensagens das classes de fronteira e distribuem as tarefas e informaes para outras classes de entidade ou de fronteira e normalmente retornam informaes para a classe de fronteira que enviou a primeira mensagem. Com a evoluo da anlise outras classes de controle podero surgir. As classes de controle so representadas como mostrado na figura 5.5 a seguir.

Controle

Figura 5.5 - Smbolo para Classe de Controle Para o caso de uso Sacar Dinheiro e seguindo a regra identificamos a classe controlar informaes cuja imagem mostrada a seguir.

Sacar

Figura 5.6 - Exemplo de Classes de Controle Um sistema pode no ter classes de controle. Neste caso o controle pode ser uma operao de controle que esteja em uma classe de entidade ou de fronteira.

5.5 Avaliao
chamado de realizao do caso de uso a determinao das classes de anlise relacionados a este caso de uso e o relacionamento entre estas classes. Este passo permite

Pgina 64

passar a fase seguinte determinando os comportamentos do relacionamento entre as classes. A figura 5.7 a seguir mostra a realizao do caso de uso Sacar Dinheiro.

Figura 5.7 - Exemplo de Realizao de Caso de Uso ou Classes de Anlise

Pgina 65

6. DIAGRAMAS DE INTERAO

6.1 As relaes entre as Classes de Anlise

Uma vez determinadas as classes de anlise devemos, tendo em mos os fluxos de evento dos casos de uso (e/ou um diagrama de atividades), trabalhar no relacionamento entre estas classes ou melhor entre os objetos de anlise uma vez que o relacionamento existe entre objetos. Na definio de classes e objetos vimos que a classe vaca tem a propriedade de produzir leite porm quem produz mesmo a mimosa ou malhada por exemplo. Vaca uma classe e portanto abstrata, produto do raciocnio humano, no existe no mundo real e portanto no pode produzir leite. Neste momento estamos interessados nas mensagens que so enviadas de um objeto para outro e nos servios realizados que esto descritos no fluxo de eventos dos casos de uso. Estas mensagens e servios esto, de alguma forma, descritas no fluxo de eventos do caso de uso. Esta fase , inclusive, importante para validar o fluxo de eventos e verificar se nenhum dos requisitos deixou de ser atendido pelo caso de uso. A UML define dois diagramas de Interao[8]: Diagrama de Seqncia e o Diagrama de Colaborao

Estes dois diagramas so duas formas diferentes de apresentar os relacionamentos entre os objetos de anlise, ser utilizado o Diagrama de Seqncia uma vez que este diagrama esta mais ligado ao fluxo de eventos que foi desenvolvido para o caso de uso[42][50], desta forma aumenta-se a consistncia na evoluo do processo de desenvolvimento.

6.2 Diagrama de Seqncia

O Diagrama de Seqncia, como o nome diz, apresenta uma seqncia de eventos que determinam o comportamento dinmico do caso de uso e que esto so descritos no fluxo de eventos. Neste diagrama, para esta fase, so apresentados os atores e as classes de

Pgina 66

anlise na parte superior do diagrama e as linhas que se seguem abaixo de cada um deles representa a linha de vida do objeto ou da ao do ator sobre o objeto. A figura 6.1 a seguir mostra um exemplo onde um Ator 1 inicia o processo enviando a mensagem para uma classe de fronteira, esta passa a mensagem para a classe de controle; estas mensagens e servios devem ser levantadas a partir do fluxo de eventos. Um exemplo de instanciao (construo) do objeto mostrado no relacionamento entre o objeto controlar e o objeto entidade, que constri e destri o objeto onde colocado um sinal X. A figura a seguir mostra o diagrama de seqncia com este exemplo de instanciao. Quando o objeto envia uma mensagem a si prprio, isto representado por uma linha de ida e volta como no caso do exemplo da mensagem chamada Auto Mensagem no objeto controlar. O diagrama de seqncia deve ser depurado at o momento onde todos os comportamentos necessrios e conhecidos e representados no diagrama e nesse momento que iniciamos o processo de desenvolvimento das classes de projeto.

Pgina 67

: Ator 1 Mensagem 1

: Fronteira

: Controlar

: Fronteira

: Ator 2

Mensagem 2

: Entidade Mensagem 3

Mensagem 4 Mensagem 5 Resposta 2 Resposta 3 Auto Mensagem

Figura 6.1 - Diagrama de Seqncia

Pgina 68

6.3 Diagrama de Colaborao

O diagrama de colaborao muito semelhante ao diagrama de seqncia, porm mostra o relacionamento das classes no que diz respeito ao sentido das mensagens e o nmero de mensagens dando nfase organizao dos objetos que participam de uma interao[8]. A figura a seguir mostra um exemplo de diagrama de colaborao baseado no mesmo exemplo do diagrama de seqncia da figura anterior.

10: Auto Mensagem

2: Mensagem 2 1: Mensagem 1

3: 4: Mensagem 3

5: Resposta 1 : Ator 1 : Fronteira : Controlar : Entidade

9: Resposta 3

6: Mensagem 4

7: Mensagem 5

8: Resposta 2 : Fronteira : Ator 2

Figura 6.2 - Diagrama de Colaborao

6.4 Exemplo de Diagramas de Seqncia

Considerando os atores, as classes de anlise e o fluxo de eventos determinados para o caso de uso Sacar Dinheiro visto anteriormente foi desenvolvido o diagrama de seqncia apresentado na 6.3 seguir para o fluxo timo. Neste diagrama os objetos foram representados pelo nome das classes sem utilizar os smbolos das classes de anlise.

Pgina 69

Esto preparados para iniciar o processo de determinao das primeiras operaes das classes de projeto. As mensagens do diagrama sero as primeiras mensagens que cada objeto (e por conseqncia a classe) ter para atender para cumprir os requisitos do sistema.

Pgina 70

Figura 6.3 - Exemplo do uso do Diagrama de Seqncia

Pgina 71

7. SUBSISTEMAS

7.1 Desenvolvimento Paralelo

Com a criao do diagrama de seqncia possvel iniciar a modelagem de classes de projeto. Porm nem sempre possvel implementar todo o projeto simultaneamente, necessrio avaliar o diagrama no sentido de dividi-lo em partes que podem ser implementados por grupos ou individualmente. Para isto o sistema deve ser dividido em pacotes ou subsistemas[8][14]. Esta diviso no possui uma regra definitiva, importante avaliar os recursos humanos e tcnicos (como subsistemas j existentes) disponveis para dar incio a implementao do projeto[20]. O desenvolvimento paralelo permite realizar um conjunto de tarefas simultneas, sem a perda de controle do trabalho. A utilizao de subsistemas fora a definio de fronteiras entre os implementaes. Isto ir garantir a no interferncia entre os projetos, ou seja, define-se um contrato de comunicao entre pacotes ou subsistemas que garanta um desenvolvimento adequado. Caso seja necessrio mudar a interface negocia-se novamente, porm mantendo sincronismo entre as diferentes partes do sistema.

7.2 Subsistemas
O subsistema um tipo especial de pacote. A grande diferena que um subsistema possui um comportamento definido, ou seja, tem responsabilidades claras e uma forma conhecida de ser acessado, a esta forma d-se o nome de interface. Do ponto de vista conceitual um subsistema esta a meio caminho entre um pacote e uma classe. A figura 7.1 a seguir mostra a representao para subsistemas na UML.

Pgina 72

Subsitema

Interf ace

Figura 7.1 - Smbolo de Subsistema para UML

A identificao de subsistemas um passo importante no projeto de software. Permite a criao de uma biblioteca de classes que compem um subsistema e que ir formar um framework de desenvolvimento que, uma vez bem modelado e documentado, pode ser utilizado em outros projetos. Pode-se implement-los utilizando-se padres de projeto[20]. Quando se decide desenvolver um subsistema esta se buscando diminuir os acoplamentos entre as partes do projeto e consequentemente aumentar a portabilidade entre as partes. O isolamento de funcionalidades em subsistemas (que tambm ocorre na definio dos pacotes mas de uma forma menos definida) facilita as mudanas no sistema. Em particular nas mudanas de requisitos durante o desenvolvimento. Isto permite uma evoluo independente entre as partes do projeto. A identificao de subsistemas feita a partir da anlise dos diagramas de seqncia. No incio no se deve preocupar com detalhes internos do subsistema, concentrando as atenes na interface (o contrato entre os subsistemas e sistema). Deve-se focar no encapsulamento do comportamento e responsabilidades do subsistema e abstrair-se do desenvolvimento das classes. A seguir so apresentados o passos para desenvolver um subsistema: Distribuir o comportamento nos elementos (classes) pertencentes ao subsistema. Documentar os elementos. Descrever os relacionamentos (contratos de interface) entre os elementos.

Pgina 73

 importante definir uma lista de avaliao para verificar se todos os comportamentos necessrios foram atendidos. As responsabilidades de um subsistema so representadas pelas operaes de interface que devem ser claras e bem definidas para facilitar a reutilizao. interessante que esta documentao seja focada nas responsabilidades e na interface, detalhando e exemplificando. desejvel desenvolver programas-exemplo que facilitem a compreenso do uso prtico do subsistema. Os subsistemas devero ter ao final do desenvolvimento os diagramas de caso de uso e classes de projeto com relacionamento entre as classes. Um exemplo de subsistema para o projeto de caixa eletrnico, mostrado na figura 7.2, e para o caso de uso Sacar Dinheiro o que faz a interface com o sistema central do banco para buscar informaes do cliente do banco.

<<subsystem>> Sistema Central Interface

Figura 7.2 - Exemplo de Subsistema Isto isolaria o acesso ao sistema central do banco o que provavelmente ser utilizado por outros casos de uso.

Pgina 74

8. CLASSES DE PROJETO

8.1 Classes de Projeto

Uma vez trabalhado o diagrama de seqncia, transformando as mensagens em mtodos, no sentido de levantar todas as possveis classes e subsistemas que iro compor o caso de uso inicia-se a montagem das classes de projeto[52]. Elas representam o ltimo passo antes da gerao de cdigo. Vale lembrar que o aprofundamento do trabalho no diagrama de seqncia vai depender da complexidade e do conhecimento tcnico. As classes de projeto foram introduzidas no captulo Orientao a Objetos, porm neste captulo iremos analisar as classes do ponto de vista de projeto, ou seja, como desenvolve-las a partir dos caos de uso, classes de anlise e do diagrama de seqncia. Para identificarmos as classes de projeto deve-se: Codificar as classes de projeto inicias que so retiradas diretamente do diagrama de seqncia Definir as operaes de relacionamento que aparecem nos diagramas de seqncia Definir atributos e outras operaes Definir dependncias, associaes e generalizaes Verificar a consistncia da classe quanto aos requisitos no funcionais Criar, se necessrio, novas classes de projeto

Isto ser apresentado ao longo deste captulo. A quantidade de classes que devem existir em um projeto depende da complexidade do projeto e em especial do caso de uso que se esta desenvolvendo, podemos dizer que: Muitas classes simples significam que: Encapsulam um pouco de toda a inteligncia do sistema So fortes candidatas a serem reutilizadas So mais fceis de serem implementadas

Pgina 75

Poucas classes complexas significam que: Encapsulam boa parte da inteligncia do sistema So mais difceis de serem reutilizadas So mais difceis de serem implementadas

Uma classe deve possuir um propsito bem definido e deve ser responsvel por fazer uma coisa e faz-la bem. Sabe-se que o aprofundamento do estudo do diagrama de seqncia ir gerar em ltima anlise um conjunto de classes dos tipos fronteira, controle ou entidade. importante estabelecer estratgias que facilitem a implementao destas classes. As estratgias para esta implementao esto apresentadas a seguir.

8.1.1 Tcnicas para implementar classes de fronteira

Quando inicia-se a implementao de classes de fronteira deve-se primeiro identific-las nos dois tipos principais, que so: Classes de Fronteira que executam interface com o usurio. Neste caso devemos analisar se existe alguma ferramenta que ir gerar automaticamente esta interface e o quanto desta interface ser gerado pela ferramenta. A escolha certa ir implicar na facilidade ou no do desenvolvimento destas classes o que pode, em alguns casos, implicar em atrasos na entrega do sistema. O fato destas classes estarem diretamente ligadas ao usurio faz com que aos olhos do cliente represente o prprio sistema. importante o desenvolvimento de prottipos(o quanto antes) com estas classes (interfaces) de modo a deixar a interface o mais prximo possvel da necessidade do cliente. Classes de Fronteira que fazem interface com sistemas externos. Neste caso normalmente existe um protocolo, aberto ou proprietrio, de comunicao entre os sistemas. muito importante isolar este comportamento do resto do sistema de modo a no influenciar o desenvolvimento em caso de mudana por qualquer razo do protocolo. Estas classes so muito importantes e na maioria das vezes implicam em um risco alto (as vezes altssimo) em funo do no conhecimento do protocolo ou

Pgina 76

uma documentao insuficiente do sistema. Por isto na maioria dos casos deve-se ter muita ateno com este tipo de classe de fronteira.

8.1.2 Tcnicas para implementar classes de entidade

As classes de entidade representam o conhecimento e/ou dados do sistema e portanto devem conter os mtodos e atributos que representem este comportamento as informaes definidas em casos de uso. Estas classes executam a maioria dos comportamentos do caso de uso. importante ressaltar que as classes de entidade so responsveis pelos dados e por qualquer outra informao relativa a estes dados. Estes dados no esto, necessariamente, relacionados a banco de dados que representam uma forma de dar persistncia aos dados. Em alguns casos os requisitos de performance podem influenciar na reavaliao destas classes, em particular os mtodos que esto diretamente ligados a estes requisitos. Em alguns casos de uso talvez seja mais prudente que os comportamentos das classes de entidade sejam incorporados as classes de controle.

8.1.3 Tcnicas para implementar classes de controle

Antes da implementao de uma classe de controle deve-se primeiro avaliar se a(s) classe(s) de controle (so) realmente necessria(s), uma vez que a distribuio do controle pode no ser complexo o suficiente para determinar a existncia de uma classe de controle especfica. Em outros casos a distribuio do controle pode ser muito complexa e seria necessrio dividi-la em duas ou mais classes. Como foi colocado no tpico anterior talvez as responsabilidades de algumas (ou todas) classes de entidade podem ser transferidas s classes de controle. A deciso do que fazer esta relacionado com a complexidade, probabilidade de mudanas, performance, distribuio do comportamento ou gerenciamento da transao.

Pgina 77

8.2 Operaes
Muitas operaes viro diretamente do diagrama de seqncia que quanto mais trabalhado mais ir fornecer informaes que determinaro as operaes. No necessrio obter todas as operaes diretamente do diagrama de seqncia uma vez que outras operaes necessariamente iro surgir da modelagem do diagrama de classes de projeto. E esta modelagem das classes de projeto importante porque outras operaes sero descobertas atravs do estudo do comportamento da classe, como: Operaes de gerenciamento Clculos necessrios com os atributos da classe Operaes de teste Operaes internas que facilitem a compreenso e a distribuio das funcionalidades Uma caracterstica muito importante de uma operao o nome apropriado, indicando a finalidade, deve levar em conta a perspectiva do cliente da classe, ser consistente e relativo a responsabilidade da operao. Deve-se tambm definir claramente a assinatura da operao, por assinatura da operao entende-se os tipos dos parmetros (inteiro, string, etc) e os prprios parmetros que so passados a operao, o retorno da operao e o nome da operao. Deve-se definir se os parmetros so opcionais ou no, se forem devero possuir um valor default (que caso no se envie nenhum valor ser utilizado este valor default, por exemplo int iValue=10, onde 10 este valor). Deve-se definir se os parmetros sero passados por valor, por referncia ou por ponteiro: Por valor: o valor o prprio parmetro, deve ser utilizando quando se deseja simplesmente utiliz-lo. Por referncia: o valor passado o prprio parmetro que poder ser alterado dentro da operao, este uso tem vantagens para parmetros (ou objetos) pequenos, caso contrrio interessante a passagem de ponteiro.

Pgina 78

Por ponteiro: o valor passado o endereo de onde esta armazenado o parmetro, deve ser utilizado quando se necessita alterar o valor do parmetro dentro da operao.

No caso de muitos parmetros a serem passados para a operao deve-se utilizar um objeto com todos os dados e operaes de manipulao destes dados que os representem e que permitam uma assinatura mais clara e limpa. As operaes possuem visibilidade que permitem reforar o encapsulamento na classe e podem ser de trs tipos: + pblica, so operaes que podem ser acessadas por operaes de outras classes e que representam a interface da classe com as classes cliente(+ o smbolo da UML para operaes pblicas) # protegida, so operaes que podem ser acessados pelas operaes da prpria classe e pelas classes derivadas (especializao) (# o smbolo da UML para operaes protegidas). - privada, so operaes que podem ser acessados somente pelas operaes da prpria classe, sendo totalmente encapsuladas (- o smbolo da UML para operaes privadas).

A figura a seguir mostra uma classe com um exemplo de cada tipo de operao. Neste exemplo ao invs do caractere determinado pela UML utilizado um cone que tambm possvel.

Classe Op Publica() Op Protegida() Op Privada()

Figura 8.1 - Exemplo de classe com 3 tipos de operaes

Pgina 79

Uma vez determinados as operaes deve-se definir os mtodos, ou seja, deve-se descrever e implementar o corpo da operao. A palavra mtodo muitas vezes utilizada no mesmo sentido de operao (o que a princpio no faz muita diferena), mas mtodo a construo da operao. Nesta construo deve ser avaliado algoritmos especiais, que outros objetos ou operaes sero utilizadas, como os atributos sero utilizados, como ser implementado o relacionamento entre as classes e como isto reflete no mtodo.

8.3 Atributos
Inicialmente determinamos os atributos da classe que se originou de classes de entidade. Estas classes possuem atributos que fazem parte da prpria modelagem. Para identificar outros atributos devemos estudar as descries dos mtodos e determinar quais informaes devem ser mantidas. Os atributos possuem uma representao determinada por um nome, um tipo e um valor padro (default) que opcional. importante na representao dos atributos seguir normas que facilitem a identificao. O atributos, assim como as operaes, possuem visibilidade que so: + pblico, so atributos que podem ser acessadas por operaes de outras classes. No recomendado o uso de atributos pblicos porque isto ir degradar consideravelmente o encapsulamento da classe. Se for necessrio a informao ou alterar o valor de um atributo deve-se desenvolver uma operao pblica que permita acessar o atributo(+ o smbolo da UML para atributos pblicos) # protegido, so atributos que podem ser acessados pelas operaes da prpria classe e pelas classes derivadas (especializao) (# o smbolo da UML para atributos protegidos). - privado, so atributos que podem ser acessados somente pelas operaes da prpria classe, sendo totalmente encapsulados (- o smbolo da UML para atributos privados).

Pgina 80

A figura a seguir mostra uma classe com um exemplo de cada tipo de atributo, neste exemplo ao invs do caractere determinado pela UML utilizado um cone que tambm previsto.

Classe Publico Privado Protegido Op Publica() Op Protegida() Op Privada()

Figura 8.2 - Exemplo de atributos de classe

8.4 Operaes e Atributos de escopo

Normalmente os atributos e as operaes de uma classe s iro existir quando a classe for instanciada, ou seja, se transforme em um objeto. Porm existe a possibilidade de se ter um atributo ou operao que seja relacionado com a classe. Um exemplo de atributo de escopo o valor mximo de um determinado valor. No sistema para Sacar Dinheiro poderia ser o valor mximo retirado do caixa por vez ou o tempo mnimo entre um saque e outro. Nestes exemplos estes valores no esto relacionados ao objeto e sim ao sistema. O mtodo que permitisse ler ou alterar um valor de escopo teria que ser realizado por um mtodo de escopo.

Pgina 81

A figura a seguir mostra um exemplo de varivel de escopo que na UML representado por um atributo sublinhado. Como a varivel de escopo esta associado com todo o sistema ela pode ser pblica.

Classe Publico Privado Protegido Escopo Op Publica() Op Protegida() Op Privada()

Figura 8.3 - Exemplo de classe com atributo de escopo

8.5 Relacionamento entre as classes

Toda classe possui um relacionamento, no faz sentido desenvolver uma classe que no possua um cliente, seria desenvolver uma classe sem finalidade. Os relacionamento sempre so feitos atravs da parte pblica da classe, para ser mais exato, pelas operaes (mtodos) pblicas uma vez que no deve existir atributos pblicos. Considerando o relacionamento de herana (especializao/generalizao) podemos demostrar o relacionamento como na figura 8.4 a seguir.

Pgina 82

Relaciona mento

por Instncia

por Classe

Associao

Dependncia

Generalizao

Composio

Agregao

Figura 8.4 - rvore de herana de relacionamentos O relacionamento dividido em dois tipos: por Instncia: Neste tipo existe um objeto ou mais objetos da outra classe que realizam o relacionamento por Classe: Neste tipo existe um relacionamento de herana (generalizao \ especializao) entre as classes e neste caso o relacionamento no por objeto.

8.5.1 Dependncia
A dependncia se caracteriza por uma relao leve entre dois objetos, ou seja, a relao no estrutural. Nos relacionamentos por instncia existe sempre a figura do objeto fornecedor e do objeto cliente, ou seja, um objeto ir fornecer um determinado servio que ser consumido pelo cliente. Para determinar o tipo de relacionamento importante

Pgina 83

avaliar como cliente e fornecedor se relacionam e como o cliente visvel ao fornecedor. A figura 8.5 o exemplo de diagrama de classe com dependncia.

Fornecedor1

Cliente

Figura 8.5 - Relacionamento entre Cliente e Fornecedor No tpico seguinte iremos detalhar a associao, porm importante fazer uma comparao no sentido de avaliar se um relacionamento uma dependncia ou uma associao. Associaes so relacionamentos estruturais, ou seja, so relacionamento mais duradouros e normalmente o cliente est o tempo todo necessitando de servios do fornecedor. Um relacionamento de dependncia pode ser implementado como: Uma varivel local a uma operao Um parmetro por referncia Uma classe utilitria

Um relacionamento de associao pode ser implementado como: Um atributo da classe

Na figura 8.6 a seguir Cliente tem um relacionamento de dependncia com o Fornecedor1 uma associao com o Fornecedor2, e esta a forma de representao na UML.

Pgina 84

Fornecedor2

Fornecedor1

Cliente

Figura 8.6 - Representao na UML de dependncia e associao

8.5.1.1 Dependncia com varivel local

A implementao de uma varivel local a uma operao exemplificado na figura a seguir, a operao op1() contm um objeto instanciado do objeto fornecedor 1.

void op1()
Fornecedor1

{ Fornecedor1 Fornecedor; Fornecedor.lerDado();

Cliente op1()

Figura 8.7 - Exemplo de implementao de dependncia com varivel local A dependncia nem sempre deve ser modelada e isto deve ser avaliado para que no poluir o diagrama de classes de projeto.

8.5.1.2 Dependncia com parmetro por referncia

A implementao de dependncia exemplificada na figura a seguir onde a instncia (um objeto) da classe Forncedor1 passado para a classe cliente que ir utilizar os servios.

Pgina 85

Fornecedor1

void op1(Fornecedor1* pFornecedor) {

Cliente op1(pFornecedor : Fornecedor1 *)

pFornecedor->lerDado(); }

Figura 8.8 - Exemplo de implementao de dependncia por passagem de parmetro Esta modelagem deve ser feita dependendo da necessidade de compreenso do relacionamento.

8.5.1.3 Dependncia com classe utilitria

Uma instncia de uma classe utilitria (Utility Class) visvel para todas as classes, considerada uma classe global.
Cliente op1(pFornecedor : Fornecedor1 *)

void op1(pFornecedor* pFornecedor) { double dValue; dValue = Math.cos(30);

Math cos(dAngle : double) : double

Figura 8.9 - Exemplo de uma dependncia por Classe Utilitria Uma classe utilitria uma classe de auxlio e normalmente no modelado, ou seja, no aparece no modelo, este relacionamento poder aparecer em vrias classes que ir poluir

Pgina 86

o diagrama. As classes utilitrias so representadas na UML com o lado direito e inferior com uma faixa cinza.

8.5.2 Associao
Como j foi dito anteriormente uma associao um relacionamento duradouro e pode ser dividido em composio e agregao. Em alguns casos implementado como um atributo da classe e no modelado, em outros casos modelado no diagrama (apesar que na gerao de cdigo o efeito ser o mesmo). importante determinar qual a navegabilidade, ou seja, que classe conhece a outra ou se as duas classes se conhecem, ou seja, podem acessar os servios uma da outra. A multiplicidade que determina quantos objetos de uma classe esta associado a outra classe. Outra caracterstica importante determinar se necessrio o desenvolvimento de uma classe de associao que ser responsvel pelo relacionamento.

8.5.2.1 Composio

Composio uma associao muito forte e representa que o tempo de vida entre os objetos coincide, uma frase representa este relacionamento:

A parte no vive sem o todo Um exemplo a classe rvore que composta de galhos, ento valeria dizer que um galho no vive sem a rvore e isto verdade.

rvore

Galho

Figura 8.10 - Exemplo de Composio

Pgina 87

A representao de agregao na UML um losango colorido(normalmente preto) no lado da classe que possui a parte (o todo), a seta representa a navegabilidade, ou seja, quem utiliza os servios de quem. Uma pergunta que se deve fazer se devemos utilizar atributos ou composio e devemos seguir as seguintes regras: Usamos composio quando: As classes necessitam de modelagem independente O relacionamento implica no comportamento do sistema Existe necessidade de mostrar a visibilidade entre as classes relacionadas

Caso contrrio utilizamos atributos e o relacionamento no aparece na modelagem

8.5.2.2 Agregao

Uma agregao uma associao de fora mdia em que o tempo de vida no coincide e os objetos podem existir independente um do outro. Como exemplo podemos dizer que os pssaros esto agregados a floresta assim como as rvores ( em tese rvores e pssaros podem existem sem florestas).
Floresta rvore

Pssaro Galho

Figura 8.11 - Exemplos de Agregao

A agregao representado na UML como um losango branco como mostrado na figura anterior. importante ter em mente que o modelo representa um mundo real mas sem

Pgina 88

expressar todos os detalhes do mundo real seria impossvel. Portanto devemos modelar o que realmente importante para que possamos entender completamente o que se deseja do sistema. Use o bom senso sempre que estiver modelando, no exagere nos relacionamentos, porm no deixe de fora relacionamentos importantes para a compreenso, evoluo ou manuteno do sistema.

8.5.2.3 Classes de Associao

Uma classe de associao contm as propriedades do relacionamento existindo uma instncia por relacionamento. A classe de associao sugerida quando se tem uma associao mltipla (um para muitos 1 -> *) para composio ou agregao. As classes de associao para este tipo de relacionamento normalmente so listas de objetos e so responsveis pela passagem de parmetros entre os objetos e pela manuteno dos objetos nesta lista. Uma forma de implementar uma lista utilizar classes parametrizadas (template) que so classes que definem outras classes e que so implementas em tempo de compilao, representam classes conhecidas como container, por exemplo listas, pilhas, filas, etc. Uma classe template apresentada na UML como a seguir:
argumento Classe Paramet rizada

Figura 8.12 - Representao de templates na UML

Existem basicamente trs tipos de multiplicidade em agregao ou composio: 1 para 1 (1 -> 1) Um objeto de uma classe possui relacionamento com um objeto da outra classe. 1 para muitos (1 -> *) ou (1 -> n) Um objeto de uma classe possui relacionamento com vrios objetos da outra classe.

Pgina 89

Muitos para muitos (* -> *) ou (n -> n) Muitos objetos de uma classe possuem relacionamento com vrios objetos da outra classe. Esta opo deve ser evitada, optando-se por uma classe de associao entre as classes de tal forma que temos:

Classe1 n n

Classe2

Figura 8.13 - Relacionamento Muitos para Muitos

Classe1 n 1

ClasseAssociao 1 n

Classe2

Figura 8.14 - Implementao com uma Classe de Associao

As outras formas de multiplicidade so derivadas destas trs.

8.5.2.4 Navegabilidade

A navegabilidade indica que a classe de origem tem visibilidade da classe destino e se no houver direo identificada as classes podem visualizar uma a outra. Um exemplo de composio bidirecional de 1 para 1 pode ser implementada em C++ da seguinte forma:

Pgina 90

class Fornecedor { private: Cliente *m_pCliente; public: Fornecedor(Cliente *pCliente){m_pCliente = pCliente}; // Construtor com ligao com o cliente ~Fornecedor(); }

class Cliente { private: Fornecedor *m_pFornecedor; public: Cliente(){ m_pFornecedor = new Fornecedor(this); //Construtor inicializando objeto do fornecedor }; ~Cliente(); }

O que indica que uma composio que o Fornecedor no existe sem o Cliente e bidirecional porque ambos os objetos podem chamar mtodos de um para o outro. O relacionamento um para um, ou seja, um objeto de uma classe ter um objeto da outra classe.

8.5.3 Generalizao
Uma classe pode compartilhar a estrutura e/ou o comportamento de outra classe e este compartilhamento chamado de generalizao que tambm conhecido como um tipo de ou um, ou seja, quando ao descrever a classe se utilizar esta expresses provavelmente existir um relacionamento de generalizao entre as classes. Se utilizarmos o exemplo de florestas e rvores, sabemos que florestas so compostas por Jatobs, Cedros, Anjico, Perba, e por ai vai. Estes exemplos so todos tipos de rvore e Jatob uma rvore.

Pgina 91

Pssaro

Galho

Floresta

rvore

Cedro

Anjico

Jatob

Perba

Figura 8.15 - Exemplo de Generalizao (Herana) e outros relacionamentos

Uma classe muito utilizada em generalizao a classe abstrata. Classes abstratas representam comportamentos genricos mas se instanciarmos estas classes elas no tem como implementar o comportamento. Para implementar ser necessrio que uma classe concreta faa o trabalho. Por exemplo, sabemos que uma rvore tem o comportamento de gerar frutos, porm se formos instanciar a classe rvore no saberemos como implementar este comportamento mas podemos implementar a operao caso a classe seja Jatob este comportamento conhecido. Em C++ no existe o conceito de interface, por isto podemos utilizar classes abstratas para implementar uma interface.

Pgina 92

Forma <<abs tract>> draw()

Quadrado draw()

Crculo draw()

Tringulo draw()

Figura 8.16 - Exemplo de relacionamento de generalizao com classe abstrata

Em desenvolvimento no se deve utilizar mltipla herana, ou seja, uma classe que herda o comportamento de outras duas. Isto pode causar problemas de execuo. A seguir mostrado um exemplo de mltipla herana, onde no possvel determinar qual operao da classe ser executada quando for solicitado o servio Draw.
Forma <<abs tract>> draw() Linha draw()
Pssaro Galho

Floresta

rvore

Vegetal

Quadrado draw()

Crculo draw()

Tringulo draw()
Cedro Anjico Jatob Perba

Figura 8.17 - Exemplos de mltipla herana Mas como resolver o problema quando se necessita de um relacionamento mais duradouro? Muitas vezes resolvemos o problema substituindo uma das generalizaes por composio. Uma outra forma verificar se na realidade o que temos no herana

Pgina 93

em seqncia, por exemplo, sabemos que Perba realmente uma rvore e um vegetal, porm todos as outras rvores so vegetais ento podemos mudar o modelo como mostrado a seguir.

Forma

Pssaro
<<abstract>> draw()

Vegetal

Quadrado draw()

Crculo draw()

Tringulo draw()

Floresta

rvore

Galho

Cedro
Linha draw()

Anjico

Jatob

Perba

Figura 8.18 - Como solucionar o problema de mltipla herana

8.6 Diagrama de Classes de Projeto

O diagrama de classes de projeto representa o ponto onde o MPDS inicia o final do ciclo. Neste ponto o desenvolvimento do modelo toma a forma do projeto e as classes desenvolvidas sero apresentadas com os relacionamentos, operaes e atributos. possvel iniciar o trabalho de transformao de operaes em mtodos que o preenchimento das operaes com a seqncia de cdigo que ir prover o servio. No diagrama de classes de projeto possvel avaliar a modelagem do ou dos casos de uso que foram trabalhadas e analisar do ponto de vista da arquitetura escolhida para o sistema se esta tudo de acordo ou se necessrio que se altere alguma coisa na modelagem. As ferramentas de gerao de cdigo automtico so capazes de gerar o esqueleto do projeto que ser implementado, gerando ento um cdigo executvel. A montagem do modelo de classes de projeto depende da experincia do projetista com a linguagem e

Pgina 94

com orientao a objetos. Um projeto ser tanto melhor quanto mais simples e fcil de manter ele for, alm claro de corresponder aos requisitos de funcionalidade, robustez e performance.

8.7 Gerao de Cdigo

A gerao de cdigo o penltimo passo do MPDS e est intimamente ligado a linguagem que foi escolhida para o desenvolvimento. A cada gerao e teste (que veremos mais no prximo captulo) de cdigo considera-se o final de um incremento. Ento a seqncia do projeto deve ser avaliada e os caminhos orientados a partir da avaliao dos riscos. Determina-se que outras partes do projeto sero trabalhadas. O processo cclico e vai-se a cada ciclo gerando-se mais codificao que permitir ao final do ltimo ciclo a integrao final do sistema. As classes de anlise de vrias casos de uso so mapeadas em classes de projeto que permitam executar as funcionalidades.

Pgina 95

9. TESTES

9.1 Introduo
Existem vrios estudos e ferramentas para facilitar a execuo de testes que detectem o quanto antes os famosos bugs de software que podem comprometer todo o desenvolvimento e consequentemente todo o produto[5][11]. Existe um consenso que diz que todo software tem algum bug que pode nunca ser descoberto, porm a funo do teste permitir que um sistema seja consistente e confivel o bastante para ser utilizado[16]. No MPDS o teste representa o final do ciclo quando o executvel gerado. Os testes de sistema dependem fundamentalmente do tipo de sistema que esta em desenvolvimento, existem 3 tipos de teste que devem ser utilizados, dependendo do tipo de sistema. Para todos os trs tipos de teste deve-se preencher a seguinte tabela[24]. Responsvel: Inclua o nome da pessoa responsvel pela execuo do teste Recursos necessrios: Inclua a especificao de hardware e software da(s) mquina(s) envolvida(s) no teste. Hardware Configurao Software Data: Inclua a data de execuo do teste no formato dd/mm/aa

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

Pgina 96

9.2 Teste de Classe

A classe representa, em orientao a objetos, a menor parte de um projeto. Quanto melhor for desenvolvido o sistema, mais especfica e simples devem ser as classes. Desta forma importante garantir que todos os mtodos da classes executem de acordo com o que foi determinado, inclusive, em casos de exceo que devem ser tratados pelos mtodos. Sendo assim, o foco testar a classe, ou seja, confirmar se a classe atende as responsabilidades atribudas. Para este fim so desenvolvidos mtodos especficos para teste que devem ser diferenciados dos demais com, por exemplo, a incluso da palavra test antes do nome do mtodo. A criao de mtodos especficos para teste facilita que aps cada incremento os testes sejam repetidos para verificar se o comportamento da classe no foi alterado de forma incorreta.

9.3 Teste de Stress

O teste de stress utilizado para aplicar ao sistema um conjunto muito grande de dados e analisar o comportamento do sistema. Ao final do incremento o executvel gerado submetido a um programa especificamente desenvolvido para se comunicar com o sistema em desenvolvimento e intensificar o uso. Normalmente este teste aplicado a sistemas que manipulem dados, ou sistemas de tempo real.

9.4 Teste de Funcionalidade

O teste de funcionalidade baseado nos casos de uso desenvolvidas para o sistema. Os fluxos de evento timos e alternativos, so aplicados ao sistema a fim de garantir o funcionamento do sistema de acordo com os casos de uso (ou requisitos funcionais) trabalhadas no incremento. A utilizao de caso de uso para testes normalmente chamada de test case[32], ou caso de teste, o que na prtica representa utilizar os fluxos de eventos para verificar se o sistema os atende.

Pgina 97

10. SISTEMAS MULTICAMADAS E SISTEMAS DE TEMPO REAL

10.1 Introduo
A complexidade do sistemas pode variar de um simples programa de consulta de dados at sistemas complexos utilizando a internet como meio de comunicao e com dados e usurios espalhados por todo o mundo. Como desenvolver um sistema to complexo ? A complexidade e a responsabilidade pode deve ser dividida em pequenas partes especializadas em determinadas atividades. Esta tcnica conhecida como Objeto Distribudo[19], e est relacionada com as decises de arquitetura do projeto que dependem de muito de fatores como: experincia da equipe nas tecnologias, tempo hbil para aquisio de novos conhecimentos, necessidades do sistema, etc. Neste ponto do desenvolvimento deve-se iniciar o projeto do sistema do ponto de vista de pacotes, que representam os agrupamentos de partes do sistema que facilite o desenvolvimento e a manuteno do sistema; de camadas, que representam os nveis de negcio representado na construo do sistema; e de componentes que representam os cdigos gerados e como se comunicam.

10.2 Componentes
Os componentes so as partes reais que compem o produto como por exemplo arquivos executveis, bibliotecas como DLL, ActiveX, componentes COM, COM+ ou DCOM, ou ainda componentes java como por exemplo JavaBeans ou Java Enterprise Beans. Estes componentes so responsveis pelo funcionamento do sistema principalmente quando se trata de um sistema que funciona em camadas. Em especial sistemas para internet e como o desenvolvimento de sistemas distribudos para este ambiente esta crescendo a cada dia (principalmente com o surgimento de tecnologias como .NET e J2EE). fundamental a modelagem dos componentes para facilitar a distribuio do comportamento dos casos de

Pgina 98

uso. O momento de fazer esta modelagem vai depender do conhecimento das necessidades do sistema, o quanto antes melhor porm talvez seja necessrio aprofundar o desenvolvimento para definir o modelo de componentes, as vezes necessrio realizar o primeiro incremento para definir corretamente este modelo. A figura a seguir mostra um exemplo de quatro componentes para um sistema que, por exemplo, funcionaria na internet.
<<Client>> Client

IMiddleware <<Middleware>> Component 2

IBusiness <<Business>> Business

IData <<Data>> Data

Database

Figura 10.1 - Componentes em sistemas distribudos e camadas

Pgina 99

A tcnica do uso de componentes ir cada vez mais fazer parte do desenvolvimento de projetos e portanto a modelagem dos componentes fundamental para o desenvolvimento do projeto sistema. A diviso do sistemas em componentes fora a definio de interfaces claras que permitam a comunicao entre eles, esta interface um contrato entre as partes do projeto.

10.3 Pacotes
Os pacotes so unidades menores e que facilitam a melhor compreenso do sistema, porm na maioria dos casos o pacote no possui um comportamento nico e determinado, ou seja, um pacote existe em funo da subdiviso de um projeto. Os pacotes iro possuir relacionamento entre si e que esta relacionado com o contrato estabelecido no uso de cada parte do sistema. Os pacotes permitem um detalhamento mais apurado e o isolamento de comportamentos do sistema. Estudando as classes de anlise deve-se verificar que grupos de classes podero fazer parte de um pacote e sempre que possvel faa a diviso em pacotes, isto ir facilitar a continuao do desenvolvimento. As classes internas a um pacote podem ser pblicas ou privadas: Classes pblicas podem ser acessadas de fora do pacote e representam a interface do pacote, porm estas classes no necessariamente executam algum tipo de ao de conformidade. Classes privadas s podem ser acessadas por classes internas ao pacote e representam as classes que executam funes que so necessrias a uma ou mais classe do pacote As classes pblicas representam o contrato de desenvolvimento que permitir o

desenvolvimento em paralelo e qualquer alterao destas classes devem ser feitas de comum acordo entre as equipes de desenvolvimento. Na UML o pacote apresentado como mostrado na figura a seguir.

Pgina 100

Pacote

Figura 10.2 - Smbolo de pacote na UML

10.4 Camadas
No incio os sistemas eram desenvolvidos em uma camada, ou seja, era construdo um nico sistema que era responsvel pelos dados e pela interface com o cliente. Em funo da complexidade dos sistemas, principalmente em sistemas desenvolvidos para a internet, foi necessrio criar meios que permitissem a comunicao entre estas partes e surgiu (como mostrado na figura a seguir) o sistema de 3 camadas: uma camada cliente (ou client), onde feita a interface de dados com o usurio do sistema, uma camada servidor (ou server), onde feita o fornecimento dos dados e uma camada meio (ou middleware) que responsvel pela comunicao e troca de dados entre cliente e servidor.

Pgina 101

<<lay er>> Client

<<lay er>> Middleware

<<lay er>> Serv er

Figura 10.3 - Sistema de trs camadas

Em funo dos sistemas se tornarem mais complexos e da necessidade de distribuio dos dados (que originalmente estavam na camada servidor) que pode estar em qualquer lugar(fisicamente falando), foi necessrio a diviso da camada server (como mostra a figura a seguir)em duas partes: camada de negcio, que responsvel pelo tratamento dos dados que so enviados ou recebidos do cliente e camada de dados, que responsvel pela interface com o repositrio de dados.

Pgina 102

<<lay er>> Client

<<lay er>> Middleware

<<lay er>> Business

<<lay er>> Data

Figura 10.4 - Exemplo de sistema com 4 camadas

A deciso da diviso do sistema em camadas vai depender da complexidade e necessidades do sistema. Esta deciso ir influenciar diretamente na tecnologia a ser adotada e no conhecimento tcnico necessrio da equipe para o desenvolvimento do projeto. O uso de padres de componentes ir facilitar a escolha da melhor forma de dimensionar o projeto em funo da tecnologia existente. As camadas normalmente so consideradas pacotes e vo naturalmente influenciar na distribuio da atividade de desenvolvimento em paralelo.

10.5 Sistemas de Tempo Real

Um sistema de tempo real leva em considerao o tempo de resposta a um estimulo externo, normalmente esta associado a um equipamento o sistema externo ao sistema em desenvolvimento[12][53]. Alguns sistemas operacionais (como QNX por exemplo) permitem a execuo de processos de modo a atender a estas necessidades. Os processos

Pgina 103

so executadas obedecendo uma determinada poltica e prioridade. Nestes casos os processos compartilham um mesmo processador no sentido de atender a reposta a evento to rpida quanto possvel. Porm no necessrio que o sistema operacional seja especificamente para tempo real, pois esta avaliao feita em termos do estmulo e da resposta a este estmulo, ou seja, o sistema operacional deve ser capaz de executar tarefas mltiplas (multi task) pseudo simultneas. Isto a maioria dos sistemas operacionais atuais permite. O sistemas de automao industrial via de regra so de tempo real, uma vez que as respostas devem atender a uma necessidade real do processo ou linha de produo[19][23]. Uma vez identificado que o sistema de tempo real deve-se utilizar o diagrama de estado da UML para demostrar o comportamento dinmico do objeto(ou classe) responsvel pelos estados, que no possvel de ser analisado no diagrama de seqncia. A implementao do diagrama de estado no complexa e muitas vezes um mtodo de controle analisa o estado atual e o evento recebido e promove a mudana de estado ou no em funo do evento recebido. Os mtodos da classe responsveis por cada estado iro atualizar os valores de estado da classe.

10.6 Exemplo de Sistema de Tempo Real: Reconhecimento de Chamada Telefnica

Um sistema de reconhecimento de chamada esta ligado a linha telefnica e ao receber as chamadas recebe tambm o nmero do telefone que esta chamando, estes nmeros so lidos, armazenados na memria para uma futura consulta e apresentados em um display. A figura a seguir mostra o diagrama de estado que representa estes estados.

Pgina 104

Figura 10.5 - Exemplo de Diagrama de Estado

Pgina 105

11. ANLISE DOS RESULTADOS

11.1 Aplicando o Modelo

Para a utilizao do MPDS necessrio o conhecimento dos diagramas da UML e de treinamento na forma de utilizao do modelo. importante tambm que se disponha de uma ferramenta de apoio ao desenvolvimento que facilite a gerao dos diagramas. As fases que so abrangidas pelo MPDS esto ligadas a Analistas, Projetistas e Arquitetos de Sistemas que normalmente so as pessoas com mais experincia da equipe, o que facilitar a utilizao. Porm como o MPDS est baseado em uma linguagem conhecida e aberta, a UML, possvel que estudantes possam se utilizar das tcnicas apresentadas aqui no desenvolvimento de projetos. O MPDS foi desenvolvido para pequenos projetos e pequenas equipes(equipes inexperientes em engenharia de software como empresas incubadas por exemplo), porm tanto grandes projetos como pequenos podem utiliz-lo. Neste caso o que poder diferenciar ser a quantidade de diagramas gerados, o nmero de casos de uso encontrados e o nmero de interaes necessrias para o desenvolvimento completo do sistema. Normalmente projetos mais complexos necessitam de um nmero maior de pessoas/equipes e isto influenciar o gerenciamento do projeto. Este trabalho mostrou a necessidade de criao de um livro e um curso que pudessem ser utilizados como base para o treinamento de desenvolvedores e pessoas envolvidas no processo de desenvolvimento de software. Alm do material didtico esta pesquisa propiciou a base tecnolgica necessria para a implementao de uma ferramenta de auxilio ao desenvolvimento que facilitasse a automao do processo de engenharia. Esta ferramenta permite a ligao entre as atividades e produz os diagramas e documentos relativos ao desenvolvimento. Esta ferramenta foi chamada de Cattleya (uma orqudea brasileira) e ser apresentada em mais detalhes no captulo de concluses do trabalho.

Pgina 106

11.2 Os prs e contra do Modelo Proposto

Neste tpico abordam-se as vantagens e desvantagens do modelo. Principalmente no que se refere a aplicao prtica, uma vez que a inteno do modelo facilitar e dar consistncia ao processo de desenvolvimento de software.

11.2.1
11.2.1.1

As vantagens do MPDS
baseado na UML

O MPDS no um novo modelo e sim uma abordagem prtica do uso da UML no processo de engenharia para desenvolvimento de software. Isto faz do MPDS um modelo baseado em um conceito padro de mercado e utilizado por vrias empresas ao redor do mundo.
11.2.1.2 Um Modelo Prtico

O MPDS um modelo com uma viso totalmente prtica. Transformando uma tcnica conhecida e padronizada em um processo prtico levando em considerao a viso do desenvolvedor e do grupo de desenvolvedores. E ainda levando em considerao as novas tecnologias relacionadas com o desenvolvimento de software, como objetos distribudos e extreme programming por exemplo.
11.2.1.3 O uso de uma ferramenta de desenvolvimento

Para o desenvolvimento de software importante o uso de uma ferramenta CASE (Computer-Aided Software Engineer) que automatize a modelagem do sistema como apresentado pelo MPDS. O uso de uma ferramenta d agilidade durante o desenvolvimento do sistema. O MPDS sendo baseado na UML facilita o uso de ferramentas uma vez que existe um nmero muito grande de opes no mercado.
11.2.1.4 Qualidade, Produtividade e Manuteno

O foco principal do MPDS permitir um processo de engenharia claro e consistente. Isto poder levar ao desenvolvimento em um nvel crescente de produtividade, que produza um produto final com qualidade que facilite a manuteno e evoluo. A maior

Pgina 107

eficincia no uso do modelo ser conseguida quanto mais projetos forem desenvolvidos utilizando-o e aprimorando o processo com adaptaes pontuais.

11.2.2

As desvantagens do MPDS
11.2.2.1 Implantao

Como todo novo processo o MPDS necessita de uma fase de implantao onde projetos sero escolhidos para facilitar a compreenso das equipes envolvidas em

desenvolvimento de software. Esta fase pode causar atrasos e num primeiro momento parecer que o processo mais atrapalha do que ajuda porque a produtividade ir cair at que o modelo esteja implementado.
11.2.2.2 Treinamento

Na fase de implantao ser necessrio o treinamento da equipe e sempre que novos pessoas forem contratadas tambm devero ser treinadas. Isto ir causar o investimento de tempo e recursos financeiros que devem ser levados em conta na utilizao do modelo.
11.2.2.3 Necessita de uma ferramenta de desenvolvimento

Uma das grandes vantagens de se utilizar um modelo a utilizao de ferramentas que facilitem o processo de desenvolvimento. Em alguns casos isto pode inviabilizar o uso do modelo. Este trabalho de pesquisa serviu de base para o desenvolvimento de uma ferramenta, que na sua verso mais avanada, ir permitir desenvolver o sistema utilizando todo o MPDS. Gerando toda a documentao e cdigo (para as principais linguagens orientadas a objeto) necessrios ao desenvolvimento do sistema.

11.3 Comparaes com outros Modelos e/ou Processos

O MPDS possui caractersticas de alguns modelos e/ou processos j existentes focalizando a necessidade de pequenas empresas/grupos de desenvolvimento de software. Um modelo, que apresenta solues de engenharia de software e que est sendo seguido por vrias empresas o RUP (Rational Unified Process)[46] da Rational Corporation. O RUP possui o inconveniente de ser um produto comercial, o que no interessante para pequenas empresas. O RUP extremamente poderoso porm complexo e difcil de ser

Pgina 108

adaptado a uma pequena empresa/grupo. Segundo Martin Fowler o RUP um framework de processos e como tal pode acomodar uma grande variedade de processos, e esta sua crtica a respeito do RUP: Como o RUP pode ser qualquer coisa, acaba no sendo nada[17]. O processo de engenharia de software no RUP est associado gerncia de projeto e gerncia de configurao e mudana. O MPDS focado no processo de engenharia para pequenas empresas/grupos de desenvolvimento de software permitindo agilidade no desenvolvimento do projeto. Recentemente surgiu um movimento chamado Extreme Programming (XP)[3]. O XP sugere que o grupo de desenvolvimento deve adaptar a necessidade de modelagem e documentao para a engenharia de software s necessidade do projeto. Porm em pequenas empresas/grupos que no sejam experientes e que no conheam algum processo difcil realizar a adaptao. Algumas prticas estabelecidas para XP esto presentes no MPDS ou podem ser utilizadas sem nenhuma alterao, como por exemplo: planejamento de verso, planejamento de iterao, verses pequenas em cada iterao, programao aos pares, desenvolvimento orientado a testes, integrao contnua, padronizao de cdigo, entre outras. Em relao ao projeto e documentao do sistema o MPDS complementa o XP, fornecendo uma soluo de engenharia baseado nos diagramas da UML e seguindo uma seqncia de atividades que muito se prxima do XP. Uma linha de trabalho que se baseou no XP o Agile Modeling (AM)[6][1]. O AM definido por Scott Ambler como sendo uma coleo de princpios que quando aplicados no desenvolvimento de software representam uma coleo de prticas de modelagem. Muitas prticas do AM so semelhantes ao XP(como por exemplo: use o diagrama correto), e podem ser utilizadas em conjunto com o MPDS. Com relao a modelagem a sugesto do AM modelar com um propsito e utilizar mltiplos diagramas o que corresponde ao MPDS. No entanto o MPDS vai alm, propondo um template (este template pode ser adquirido na pgina de documentos do site www.umlnapratica.com.br) nico que apresente toda a documentao do projeto. Alm disso o MPDS apresenta o onde e o como utilizar os diagramas, dando propsito a modelagem, atravs da apresentao da seqncia de atividades a serem desenvolvidas durante o

Pgina 109

desenvolvimento. importante ressaltar que nem XP e nem AM utilizam-se especificamente de diagramas da UML para a modelagem do sistemas. Outros diagramas podem ser utilizados(principalmente no AM) para a modelagem do sistema. Existe um outro processo chamado de ICONIX process[40] da empresa ICONIX Software Engineering, Inc que, assim como o MPDS e o RUP, orientado a casos de uso. Este processo tem a desvantagem, assim como o RUP, de ser comercial. Alm de orientado a caso de uso o processo ICONIX tambm orientado a prottipo. Diferente do MPDS, o processo ICONIX sugere que seja feita uma modelagem de domnio que represente uma primeira verso do diagrama de classes de alto nvel. Uma importante contribuio deste processo para o MPDS foi a definio e uso das classes de anlise [43] que no faz parte da UML. Os autores, Doug Rosenberg e Kendall Scott, consideram que este modelo situa-se entre o RUP e o XP. O processo ICONIX considera o desenvolvimento das classes de anlise como a ponte entre os casos de uso e o diagrama de seqncia. Este raciocnio aproveitado no MPDS. Diferente do processo ICONIX, o MPDS utiliza o diagrama de seqncia como o elo de ligao entre o final da anlise e incio do projeto. Alm disto o MPDS mostra e d nfase a seqncia das atividades de desenvolvimento e no somente aos diagramas a serem utilizados. O MPDS utiliza conceitos encontradas no RUP, no XP, no AM e no processo ICONIX. Estas metodologias foram incorporadas a um processo incremental e interativo, simples e que fornece orientaes claras no processo de desenvolvimento de software. Para facilitar a utilizao do processo um template simples foi criado para ser utilizado como documentao do projeto. O MPDS ainda se baseia fortemente nos diagramas da UML para facilitar a compreenso e troca de informao dos desenvolvedores entre si e com o cliente.

11.4 Avaliao em projetos reais

Com a inteno de avaliar a aplicao do MPDS em projetos reais o modelo foi aplicado a 17 grupos de alunos do curso de Computao III do Inatel, sendo cada grupo formado

Pgina 110

por 6 ou 7 alunos com a inteno de desenvolver um produto de software completo utilizando o MPDS. Vale salientar que os alunos no possuam qualquer conhecimento de orientao a objetos, possuindo um conhecimento bsico da linguagem C. A avaliao dos projetos foi a seguinte: 10 grupos (59%) atingiram os objetivos acadmicos porm os projetos no foram satisfatrios. 3 grupos (18%) atingiram os objetivos acadmicos e os projetos foram modelados e implementados corretamente. 4 grupos (23%) atingiram os objetivos acadmicos, os projetos foram modelados e implementados corretamente e foram tratados como produtos, sendo que os alunos continuaram o desenvolvimento do projeto. Apesar de mais da metade dos grupos ter atingido somente os objetos acadmicos (que em ltima anlise o foco do curso) 41 % dos grupos conseguiu utilizar as tcnicas do MPDS em um projeto real. O uso do modelo no curso permitiu a assimilao muito rpida do conceito de engenharia de software em grupos inexperientes em desenvolvimento orientado a objetos.

11.5

Aplicabilidade em pequenas empresas/equipes de

desenvolvimento de software
O MPDS foi desenvolvido com foco em pequenas empresas/equipes de software com a inteno de definir um modelo de engenharia de software que pudesse ser adotado sem representar um peso para estas empresas. A motivao para o desenvolvimento e difuso do MPDS que do conjunto de empresas brasileiras de desenvolvimento de software, 77,4 % dele composto por micro ou pequenas, sendo que as micro (que representam 35,7 % do total) possuem de 1 a 9 pessoas[36]. Em virtude do nmero muito pequeno de pessoas a maioria esta envolvida na produo e comercializao dos produtos de software.

Pgina 111

12. CONCLUSES

12.1 Contribuies Prticas da Pesquisa

12.1.1 A Ferramenta Cattleya

Este trabalho de pesquisa iniciou-se com o estudo da UML e a possibilidade de aplicao no desenvolvimento de projetos prticos. Junto a este estudo iniciou-se a avaliao de ferramentas de apoio ao desenvolvimento, ferramentas CASE. Chegou-se a concluso que as ferramentas ou so muito caras ou so simples e no atendem a todo o processo de desenvolvimento. Para dar suporte ao desenvolvimento iniciou-se o desenvolvimento da ferramenta Cattleya que na sua primeira verso teria as seguintes caractersticas: Diagrama de classes de forma a facilitar o desenvolvimento das classes de projeto e seu relacionamento Gerao de cdigo em C++

Esta primeira fase do sistema foi encerrada em dezembro de 2001 com o produto sendo disponibilizado para uso a partir de maro de 2002. O sistema Cattleya pode ser adquirido gratuitamente atravs de download pela internet.

12.2 Contribuies Didticas da Pesquisa

12.2.1Curso de Engenharia de Software
Esta pesquisa proporcionou o desenvolvimento de um curso de engenharia de software a ser aplicado em cursos de engenharia eltrica e em engenharia de computao. A parte terica do curso composta dos seguintes mdulos:

Sistemas Orientados a Objetos Especificao de Requisitos Modelagem de caso de uso

Pgina 112

Classes de Anlise Diagrama de Seqncia Pacotes e Subsistemas Classes de Projeto Projeto de Sistemas

A ferramenta Cattleya esta sendo usada no laboratrio para o desenvolvimento de projetos de curso. Este curso foi iniciado em fevereiro de 2002 para o terceiro perodo de Engenharia Eltrica do Inatel.

12.2.2

Livro UML na prtica Do Problema ao Sistema

Em funo da necessidade de um processo de engenharia que facilite o uso da UML esta pesquisa proporcionou a criao de um livro. Este livro servir de base para o treinamento, inclusive o curso de engenharia de software, de profissionais que participem de projetos de desenvolvimento. Servir tambm de um guia prtico para o processo de engenharia de software.

12.3 Trabalhos Futuros

12.3.1 Melhoria no modelo e atualizao ferramentaCattleya

O modelo, fruto desta pesquisa, resultado de um estudo de tcnicas desenvolvidas ao longo dos ltimos anos para o desenvolvimento de software e em especial da UML. fruto ainda de anos de experincia no desenvolvimento de sistemas e dos problemas associados a esta atividade. A inteno do MPDS representar a viso prtica e ser aderente s necessidades das equipes de desenvolvimento. Por esta razo o aprimoramento do modelo deve ser contnuo e busca sempre encontrar solues que dem esta to esperada aderncia. A ferramenta Cattleya dever suportar todas as atividades para que as equipes possam ter uma ferramenta de alto valor agregado que

Pgina 113

aumente a competitividade das empresas desenvolvedoras. Isto permitir que os produtos possam ter sempre o mais alto nvel de qualidade que se exige dos sistemas cada vez mais complexos.

12.3.2

Sistemas Embarcados

Para o processo de desenvolvimento de software j existe um volume de estudo bastante grande realizado durante os ltimos anos. Vrios modelos e processos foram criados. Os sistemas embarcados (tambm conhecidos como firmware), so responsveis por um percentual muito maior do software desenvolvido no mundo e possuem peculiaridades e caractersticas muito diferentes. Vrias caractersticas, como dependncia direta do projeto de hardware, dificultam muito o trabalho e apesar disto muito menos estudo foi e tem sido feito no sentido de desenvolver modelos que possam ser utilizados para o desenvolvimento de firmware. O MPDS apresenta solues ainda incompletas para sistemas embarcados ou de tempo real.

12.3.3

Modelagem de sistema com componentes

Os novos desafios para o desenvolvimento de software esto intimamente ligados a sistemas que utilizaro a internet como base operacional . Isso implica no aprimoramento das tcnicas de engenharia de software[2], uma vez que os sistemas passaro a ser compostos de partes, os chamados componentes. Estes podero estar em qualquer lugar do mundo e podero se comunicar. Este campo da engenharia de software dever requisitar muitas pesquisas nos prximos anos de modo a permitir que os produtos finais, que na verdade sero uma coletnea de vrios produtos associados, possam funcionar adequadamente. Este trabalho faz uma introduo, nos captulos Modelagem de Componentes e Modelagem de Pacotes e Camadas, ao desenvolvimento de sistemas baseados em componentes.

Pgina 114

13. REFERNCIAS BIBLIOGRFICAS

[1] Ambler, S. ,Architectural Modeling, Software Development Magazine, 1999, Online de http://www.sdmagazine.com [2] Ambler, S., Distributed Object Transactions, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [3] Ambler, S. ,Extreme Modeling, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [4] Ambler, S. ,Object-Oriented Business Rules, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [5] Ambler, S. ,Object Testing Patterns, Software Development Magazine, 1999, Online de http://www.sdmagazine.com [6] Ambler, S., The Principles of Agile Modeling, The Official Agile Modeling(AM) Site, 2002, On-line de http://www.agilemodeling.com/principles.htm [7] Berard, E. ,Be Careful With Use Cases, The Object Agency, Inc, 2000, On-line de http://www.toa.com/pub/use_cases.htm [8] Booch, G., Rumbaugh J., Jacobson, I., The Unified Modeling Language User Guide, Addison-Wesley, 1999. [9] Booch, G., Rumbaugh J., Jacobson, I., The Unified Software Development Process , Addison-Wesley, 1999. [10] Cockburn, A. ,Writing Effective Use Case, Addison-Wesley, 2001. [11] Dimaggio, L. ,A Roadmap for Software Test Engineering, Software Development Magazine, 2001, On-line de http://www.sdmagazine.com [12] Douglass, B., Real-Time UML, Addison-Wesley Longman, 1998 [13] Evans, G., Object Think: It Really is Different, 1999, Evanetics, Inc., On-line de http://www.evanetics.com [14] Eriksson, H., Penker, M., UML Toolkit, Wiley Computer Publishing, 1998. [15] Firesmith, D., Use Case Modeling Guidelines, Lante Corporation, IEEE Transaction Software Engineer , 1999, pp. 184-193

Pgina 115

[16] Fowler, M. ,A UML Testing Framework, Software Development Magazine, 1999, On-line de http://www.sdmagazine.com [17] Fowler, M. ,The New Methodology, Martin Fowler web site, 2001, On-line de http://www.martinfowler.com [18] Fowler, M., Scott, K., UML Distilled, Addison-Wesley, 1998 [19] Fleisch, W., Applying Use Cases for the Requirements Validation of ComponentBased Real-Time Software, IEEE Transaction Software Engineer , 1999, pp. 75-84 [20] Gamma, E., Helm, R., Johnson, R. Vlissides, J., Design Patterns, Addison-Wesley, 1997 [21] Hantos, P., A Systems Engineering View of Requirements Management for Software-intensive Systems , IEEE Transaction Software Engineer 1999, pp. 620-621 [22] Henderson-Sellers, B., Collins, G., Graham, I. UML-Compatible Process, IEEE Transaction Software Engineer, 34th Hawaii International Conference on System Sciences, 2001. [23] Heverhagen, T. Tracht, R., Implementing Function Block Adapters, Rational Corporation, 2001, On-line de http://www.rational.com [24] Jeffries, R., RecordMap, Test First, X Programming, XP Magazine, 2002, On-line de http://www.xprogramming.com [25] Jeffries, R., XP and Reliability, X Programming, XP Magazine, 2001, On-line de http://www.xprogramming.com [26] Kiedaisch, F., Pohl, M., Bauer, S. Ortmann, S., Requirements Archaeology: From Unstructured Information to High Quality Specifications, IEEE Transaction Software Engineer , 2001, pp. 304-305 [27] Keuffel, W. ,Best Practices Actually Applied, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [28] Korson, M. ,Constructing Useful Use Case, McGregor Korson web site, 2000, Online de http://www.korson-mcgregor.com [29] Kruchten, P., The Rational Unified Process, an Introduction, Addison-Wesley, 2000. [30] Larman, C., Utilizando UML e Padres, Bookman, 2000 [31] McConnell, S., Rapid Development, Microsoft Press, 1996

Pgina 116

[32] McGregor, J., Major, M., Selecting Test Case Based on User Priorities, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [33] Oestereich, B. ,Developing Software with UML, , Addison-Wesley, 1999 [34] Paulk, M. ,Extreme Programming from a CMM Perspective, Software Engineering Institute, 2001 [35] Paulk, M., Weber, C. Curtis, B., Chrissis, M., The Capability Maturity Model, Addison-Wesley, 1997. [36] Pesquisa Censo SW, MCT/SEPIN/DSI, 2001. [37] Phillips, C., Kemp, E., Sai, K., Extending UML Use Case Modeling to Support Graphical User Interface Design , IEEE Transaction Software Engineer , 2001, pp.48-52 [38] Pressman, R., Software Engineering, McGraw-Hill, 2001 [39] Rosemberg, D., Scott, K., Driving Design: The Problem Domain, Software Development Magazine, 2001, On-line de http://www.sdmagazine.com [40] Rosemberg, D., Scott, K., Driving Design with Use Cases, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [41] Rosemberg, D., Scott, K. ,Give Them What They Want, Software Development Magazine, 2001, On-line de http://www.sdmagazine.com [42] Rosemberg, D., Scott, K., Sequence Diagram: One Step at a Time, Software Development Magazine, 2001, On-line de http://www.sdmagazine.com [43] Rosemberg, D., Scott, K., Successful Robustness Analysis, Software Development Magazine, 2001, On-line de http://www.sdmagazine.com [44] Rosemberg, D., Scott, K. ,Top Ten Use Case Mistakes, Software Development Magazine, 2001, On-line de http://www.sdmagazine.com [45] Rumbaugh, J., Blaha, M. Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modeling and Design, Prentice Hall International Editions, 1991. [46] Rumbaugh, J., Rational Unified Process, Rational Corporation, 2001 . [47] Saeki, M, Reusing Use Case Descriptions for Requirements Specification: Towards Use Case Patterns, IEEE Transaction Software Engineer , 1999, pp. 309-316

Pgina 117

[48] Sawyer, P., Sommerville, I., Viller, S., Capturing The Benefits of Requirements Engineering, IEEE Transaction Software Engineer , 1999, pp. 78-85 [49] Schneider, G., Winters, J., Applying Use Cases, Addison-Wesley, 2001. [50] Selonen, P., Generating Structured Implementation Schemes from UML Sequence Diagrams, IEEE Transaction Software Engineer , 2001, pp. 317-328 [51] Selonen, P., Koskimies, K, Sakkinem, M. How to Make Apples from Oranges in UML, IEEE Transaction Software Engineer, 34th Hawaii International Conference on System Sciences, 2001. [52] Smith, R. ,Defining the UML Kernel, Software Development Magazine, 2000, On-line de http://www.sdmagazine.com [53] Spionla, M., Diretrizes para desenvolvimento de software de sistemas embutidos, Tese de Doutorado, Universidade de So Paulo USP, 1999 [54] Stroustrup, B., The C++ Programming Language, Addison-Wesley, 1997. [55] Susan, L., Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases, IEEE Transaction Software Engineer , 1999, pp. 174-183 [56] Unified Modeling Language Specification Version 1.3 , Object Management Group (OMG), 1999 [57] What Is OMG-UML And Why Is It Important, OMG, 2001, On-line de http://www.omg.org [58] Wiegers, K., Karl Wiegers Describes 10 Requirements Traps to Avoid, Process Impact, Software Testing & Quality Engineering, 2000, On-line de

http://www.processimpact.com [59] Wiegers, K., Writing Quality Requirements, Process Impact, 1999, On-line de http://www.processimpact.com

Pgina 118

Pgina 119