Escolar Documentos
Profissional Documentos
Cultura Documentos
2011
Aluno (a): Elen Cristiane Donda RA: B0970J-1 Curso: Gesto em Tecnologia da Informao Semestre: Primeiro
2011
Resumo:
Vivemos uma grande evoluo tecnolgica e, com ela, um aumento exponencial na demanda de novos softwares. Precisamos desenvolver mais e em menos tempo. Nossos softwares precisam carregar um "algo a mais". Assim, hora de repensar antigos modelos de desenvolvimento e gerncia. Este trabalho trata de como a orientao a objetos e a UML podem melhorar o quadro atual de desenvolvimento de sistemas e sua histria de uma forma objetiva, a necessidade de sua criao, os conceitos de modelagem, estruturas e casos. Sero apresentadas formas de Modelagem Estruturada e Orientada a Objetos trabalhando com a UML. Estudos de casos sero apresentados ao longo do trabalho com o intuito de aprimorarmos nosso conceito sobre UML e a sua estruturao dentro das anlises, processos, mtodos e distribuio de dados na linguagem estruturada e orientada a objetos, tambm ser apresentado a diferena entre os modelos de estruturao de modelagem de processos. As condies favorveis e no favorveis para a aplicao de cada modelo dentro do desenvolvimento de sistemas. Cabe cada desenvolvedor verificar qual o conceito o melhor para seu aprimoramento e processo de desenvolvimento dentro do meio e projeto de sistema que ir elaborar e executar.
Sumrio:
Introduo..................................................................................................................06 UML - Uma Breve Histria.........................................................................................06 Motivao...................................................................................................................08 Necessidade de uma Modelagem Visual...................................................................08 Conceitos Bsicos de UML........................................................................................08 Por que usar UML? ...................................................................................................08 Estrutura da UML.......................................................................................................09 Diagramas Estruturais: ..............................................................................................09 Diagramas Comportamentais: ...................................................................................10 Diagramas Estruturais................................................................................................10 1.1 Diagrama de Classes (Class Diagram) ..................................................10 1.2 Diagrama de Objetos (Object Diagram)..................................................11 1.3 Diagrama de Estrutura Composta (Composite Structure Diagram)........12 1.4 Diagrama de Componentes (Component Diagram)...............................13 1.5 Diagrama de Implantao (Deployment Diagram)..................................14 1.6 Diagrama de Pacotes (Package Diagram).............................................15 Diagramas Comportamentais.....................................................................................16 2.0 Diagrama de Casos de Uso (Use Case Diagram)..................................16 2.0.1 Diagrama de um Caso de Uso.............................................................17 Passos que auxiliam na sua criao:.........................................................................17 2.1 Diagrama de Mquina de Estados (Statechart Diagram).......................18 2.2 Diagrama de Atividades (Activity Diagram)............................................19 2.3 Diagramas de Interao..........................................................................20 2.4 Diagrama de Seqncias (Sequence Diagram).....................................20 2.5 Diagrama de Comunicao (Communication Diagram).........................21 2.6 Diagrama de Viso Geral (Interaction-Overview Diagram).....................22 2.7 Diagrama Temporal (Timing Diagram)...................................................23 Por que Orientao a Objetos?..................................................................................24 Modelagem Orientada Por Objetos............................................................................24 Introduo...................................................................................................................24 Princpios da Modelagem...........................................................................................26
3.0 - Abstrao de Dados.............................................................................26 3.1 - Tcnica de Modelagem de Objetos......................................................27 3.2 - Classes.................................................................................................28 3.3 - Associao, Ligao e Multiplicidade...................................................29 3.4 - Atributo de Ligao...............................................................................30 3.5 - Agregao............................................................................................30 3.6 - Generalizao, Especializao e Herana...........................................31 3.7 - Polimorfismo.........................................................................................34 3.8 - Persistncia de Objetos em Ambientes Relacionais............................34 3.9 - Mapeamento de Classes......................................................................35 4.0 Mapeamento de Associaes Muitos para Muitos.................................36 4.1 - Mapeamento de Associaes Um para Muitos....................................36 4.2 - Mapeamento de Associaes Um para Um ........................................38 4.3 - Mapeamento de Generalizaes..........................................................39 Modelagem Estruturada.............................................................................................42 Introduo...................................................................................................................42 1. Uma ferramenta eficaz...........................................................................................42 2. Analise Estruturada, Benefcios e Problemas........................................................46 3. Diagrama de Fluxo de Dados Lgico (DFD)..........................................................47 4. Caractersticas da Tcnica de Anlise Estruturada de Sistemas................47 4.1 Fatores externos........................................................................................47 4.2 Fluxo de Informaes................................................................................48 4.3 Processos..................................................................................................48 4.4 Banco de Informaes...............................................................................49 5. Convenes para Exploso de Processos.............................................................49 6.Crtica Anlise Estruturada...................................................................................50 7. Quando Usar a Anlise Estruturada.......................................................................52 Concluso: .................................................................................................................53 Referncias Bibliogrficas: ........................................................................................55
Durante 1996 a Rational Software Corporation contou com a participao de outras Instituies parceiras como: Hewlett-Packard, IBM, Microsoft, Oracle, Unisys, Platinum Technology, etc. Essa colaborao contribuiu para a produo da verso 1.0, uma verso bem definida, expressiva, poderosa e aplicvel, a qual foi submetida OMG para adoo. Em setembro de 1997 liberaram a verso1. 1 da UML e em dezembro a mesma foi aprovada como padro pela OMG. Com a unificao dos mtodos a UML alcanou dois objetivos: Acabou com as diferenas existentes entre os mtodos anteriores; Unificaram as perspectivas entre os diferentes tipos de sistemas, fases de desenvolvimento e conceitos internos. Segue abaixo um exemplo da evoluo da UML:
Estrutura da UML
A UML tem sua estrutura basicamente dividida em: elementos de modelo (por exemplo: classes, casos de uso, componentes, etc), diagramas e relacionamentos. Possumos, ainda, os mecanismos de extenso, que do ao desenvolvedor a flexibilidade de estender seu modelo. Os diagramas da UML so: Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Objetos, Diagrama de Grfico de Estados, Diagrama de Atividades, Diagrama de Seqncias, Diagrama de Colaboraes, Diagrama de Componentes e Diagrama de Implantao. Esses diagramas permitem a modelagem de todas as fases do projeto. Neles modelamos nossos elementos, como classes e casos de uso, apresentando seus relacionamentos. Relembro que temos a liberdade de utilizar os diagramas conforme as necessidades de nosso projeto. Em setembro de 1997 liberaram a verso 1.1 da UML e em dezembro a mesma foi aprovada como padro pela OMG. Com a unificao dos mtodos a UML alcanou dois objetivos: Acabou com as diferenas existentes entre os mtodos anteriores; Unificaram as perspectivas entre os diferentes tipos de sistemas, fases de desenvolvimento e conceitos internos. Atualmente a UML est na sua verso 2.1, ela contempla 13 diagramas, divididos em duas categorias (Diagramas Estruturais e Diagramas Comportamentais) e uma subcategoria (Diagramas de Interao). A subcategoria pertence est localizada em Diagramas Comportamentais.
Diagramas Estruturais:
Diagrama de Objeto Diagrama de Classes Diagrama de Componentes Diagrama de Instalao Diagrama de Pacotes Diagrama de Estrutura
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
Diagramas Comportamentais:
Diagrama de Casos de Uso Diagrama de Mquina de Estado Diagrama de Atividades Sub-Categoria: Diagramas de Interao: Diagrama de Seqncia Diagrama de Interatividade Diagrama de Colaborao / Comunicao Diagrama de Tempo
Diagramas Estruturais
Os diagramas estruturais da UML so utilizados para que se possa visualizar, especificar, construir e documentar os aspectos estticos de um sistema. Aspectos estticos de um sistema podem ser considerados como sendo uma representao de seu esqueleto e estrutura relativamente estveis (inalterveis).
10
11
12
13
14
15
Diagramas Comportamentais
Os diagramas comportamentais da UML so utilizados para que se possa visualizar, especificar, construir e documentar os aspectos dinmicos de um sistema. Aspectos dinmicos de um sistema podem ser considerados como sendo uma representao de suas partes que sofrem alteraes. Os aspectos dinmicos de um sistema envolvem itens como o fluxo de mensagens ao longo do tempo e a movimentao fsica de componentes em uma rede.
16
Os casos de uso devem ser identificados atravs de nomes curtos que identifiquem a sua atividade sem ambigidade. Para facilitar a viso geral do sistema muito comum reunir casos de uso similares em pacotes e criar diagramas que ilustrem essa reunio e qual a interao com outros sistemas.
17
3. Defina a viso desse ator, ou seja, o que ele quer do sistema cada um desses desejos torna-se um caso de uso; 4. Para cada caso de uso, identifique o curso da relao ator-caso de uso; 5. Observe se o caso de uso em questo possui alguma alternativa de uso. Essa observao importante para identificar se esse caso de uso tem algo em comum com outros casos de uso. Se isso for verdade, necessrio desmembrar essa poro comum, de forma a criar um caso de uso genrico. Os diagramas de caso de uso ajudam os stakeholders a entenderem a natureza e escopo da rea de negcio ou sistema em desenvolvimento.
18
19
20
temporal). Ele registra o comportamento de um nico caso de uso, exibindo os objetos e as mensagens passadas entre esses objetos no caso de uso.
21
22
23
24
Tradicionalmente, a formulao inicial do problema, a anlise, o projeto, a implementao, os testes e a operao (manuteno e aperfeioamento) compem estas etapas do ciclo de vida. A modelagem de dados uma das etapas mais importantes do projeto de um SIG, pois a escolha de uma modelo que melhor se ajuste realidade que pretende expressar fator crtico para o sucesso ou fracasso do projeto (Worboys, 95). So apresentadas a seguir as definies de autores como base de discusso: Modelo de dados uma coleo de ferramentas conceituais para descrio dos dados, relacionamento entre os dados, semntica e restries dos dados (Korth e Silberschatz, 1989). Um modelo uma abstrao de alguma coisa, cujo propsito permitir que se conhea essa coisa antes de se constru-la (Rumbaugh, 94). Sinteticamente, modelar os dados uma maneira de expressar uma realidade atravs de um formalismo que requer abstrao por parte do modelador. Existem diversas tcnicas para modelagem de dados, cada uma com ferramentas de abstrao diferenciadas determinando a classe de problemas mais adequada ao seu uso. Um modelo completo de um sistema composto por sub-modelos que expressam vises diferentes da mesma realidade. Essas vises esto divididas em trs (Rumbaugh, 1994): 1) Viso de objetos: descreve estaticamente os objetos que compem o sistema e seus relacionamentos atravs de diagramas de objetos. 2) Viso dinmica: descreve os aspectos do sistema que se modificam com o passar do tempo, especificando o controle do sistema. Os diagramas de estado so usados como ferramenta de descrio. 3) Viso funcional: descreve as transformaes dos valores dos dados de um sistema. Os diagramas de fluxo de dados so usados como ferramenta de trabalho. Cada viso descreve um aspecto do sistema, mas contm referncias s outras vises. A viso de objetos descreve as estruturas de dados sobre as quais atuam as vises dinmica e funcional. As operaes da viso de objetos correspondem a eventos nas vises dinmicas, e a funes na viso funcional. A viso funcional descreve as funes chamadas pelas operaes da viso de objetos e pelas aes na viso dinmica.
25
Por se tratar de abstrao, natural que exista alguma ambigidade quando alguma informao representada por uma viso, pois a meta simplificar a descrio sem sobrecarregar uma viso com construes complexas, de modo a se tornarem um auxlio e no um peso no desenvolvimento do sistema.
Esses inter-relacionamentos entre vises so inevitveis, compondo um fator delicado na modelagem. Segundo (Rumbaugh, 1994) essas vises so partes ortogonais, que se inter-relacionam, na modelagem de um sistema. A figura acima ilustra as vises. As metodologias estruturadas abordam as trs perspectivas. Por ter como princpio a decomposio funcional para modelar sistemas, essas metodologias do mais nfase viso funcional; em um segundo grau de importncia, vem viso dinmica e por fim a de objetos. A viso de objetos, para as metodologias estruturadas, restringe-se apenas aos dados. As metodologias orientadas por objetos, da mesma forma que as estruturadas, abordam as trs perspectivas, com nfases diferentes. A viso de objetos a mais enfatizada, depois a viso dinmica e a funcional (Rumbaugh, 1994). A realidade geogrfica modelada pelos SIGs complexa e heterognea. Com o estudo e anlise destas tcnicas de modelagem este trabalho buscar criar um embasamento conceitual para melhor compreender os modelos atuais destes SIGs.
26
mesmo problema para propsitos diferentes. A construo de modelos pela abstrao possui o carter de simplificao da realidade a ser modelada, por isso no deve procurar a verdade absoluta, mas sim a adequao ao propsito (Rumbaugh, 1994). Para auxiliar na construo destes modelos atravs da abstrao foram desenvolvidas algumas tcnicas e notaes grficas. Uma delas a Tcnica de Modelagem de Objetos - TMO que ser apresentada a seguir.
27
Os objetos so responsveis por atuar sobre os seus atributos e tambm sobre outros objetos, para isto desempenham diversas operaes. Essas operaes descrevem o comportamento do objeto. Os mtodos so a implementao essas operaes. A seguir so mostrados dois exemplos de operao: A cidade de So Jos os Campos incrementou sua populao de 50.000 novos habitantes. Neste caso, operao de incrementar ser implementada por um mtodo do objeto So Jos dos Campos que adicionar 50.000 no atributo 60Populao. No segundo exemplo: A populao do Brasil de 140.000.000. de habitantes., o objeto Brasil poder se relacionar com todos os objetos que representam os estados brasileiros (objeto So Paulo, objeto Amazonas, etc.) para acumular os respectivos valores dos atributos populao ou poder se relacionar as cidades brasileiras e acumular seus valores. Da mesma forma, esses objetos representantes dos estados brasileiros se relacionam com cada objeto representante da cidade de seu estado (objeto So Jos dos Campos, objeto Ribeiro Preto, etc.) para acumular suas populaes.
3.2 - Classes
Uma classe de objetos descreve um grupo de objetos com propriedades semelhantes (atributos), o mesmo comportamento (operaes) e conseqentemente a mesma semntica (Rumbaugh, 1994). No exemplo anterior, j tocamos nesta definio, quando expressamos objetos que representam..., ou seja, objetos de uma mesma classe, por exemplo: estados brasileiros e cidades. Os objetos de uma classe compartilham um objetivo semntico comum, alm dos requisitos de atributos e comportamento. Dessa maneira, embora um celeiro e um cavalo tenham ambos um preo e uma idade, provavelmente pertencem a classes diferentes. Se o celeiro e o cavalo fossem vistos apenas como bens contbeis, provavelmente pertenceriam mesma classe. Se o desenvolvedor levar em considerao que um celeiro deve ser pintado, e um cavalo, alimentado, eles seriam modelados como classes distintas. A interpretao da semntica depende do propsito de cada aplicao, sendo uma questo de critrio. Cada metodologia de modelagem utiliza uma notao grfica prpria. Esta discusso utiliza a notao de Rumbaugh (1994). A Figura abaixo indica esta notao para o diagrama de objetos.
28
Para completar a apresentao da modelagem orientada por objetos, tornamse necessrios outros conceitos chaves da TMO que sero discutidos a seguir.
29
3.5 Agregao
A agregao um tipo de associao forte onde um objeto agregado constitudo de componentes. A agregao representada pelo relacionamento parte-todo ou uma-parte-de no quais os objetos que representam os
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
30
componentes de alguma coisa so associados a um objeto que representa a estrutura inteira. Em termos semnticos, o objeto agregado um objeto estendido tratado como uma unidade em muitas operaes, embora fisicamente ele seja composto por objetos menores. Uma agregao representada graficamente pelo smbolo de losango. O exemplo da figura ilustra a idia exposta.
31
Figura 3.6
A herana mltipla um conceito que consideramos relevante para o trabalho, uma vez que aumenta a capacidade de especificao das classes. A herana mltipla permite que uma classe possua mais de uma superclasse e herde as caractersticas de todos os seus ancestrais. Isto possibilita a mesclagem de informaes de duas ou mais classes. A desvantagem desta prtica est na perda de simplicidade conceitual e de implementao. A Figura 3.6 expressa a idia. Por esta possibilidade de modelagem, uma caracterstica proveniente da mesma classe ancestral encontrada em mais de um caminho herdada apenas uma vez. Os conflitos de definies paralelas criam ambigidades que precisam ser resolvidas seja pelas implementaes ou por ajustes no modelo, que impeam a herana mltipla. No exemplo da Figura 3.6.1 uma possvel soluo para se evitar a herana mltipla, na modelagem, elevar a classe Veculo Anfbio para o mesmo nvel de
32
Veculo Terrestre e Veculo Aqutico, tornando-se uma outra especializao de Veculo. Desta forma o novo modelo seria como apresentado pela 3.6.2. Em razo deste ajuste deve-se adicionar explicitamente classe Veculo Anfbio, em forma de novos atributos, as caractersticas que antes eram herdadas de ambos os ancestrais e que tambm eram motivo de conflitos. Outras solues so possveis no nvel de implementao, no sentido de fazer uso de mecanismos oferecidos pela linguagem escolhida. Esta abordagem no ser detalhada neste trabalho por entendermos tratar-se de um nvel mais baixo de detalhes, fora do nvel conceitual o qual pretendemos seguir. Uma boa explicao sobre este assunto encontra-se em (Rumbaugh, 1994). Figura 3.61
Figura 3.6.2
33
3.7 Polimorfismo
Um outro conceito utilizado na abordagem orientada por objetos denomina-se polimorfismo. Trata-se da possibilidade que uma mesma operao possui de atuar de modos diferentes em classes diferentes. Isto possvel quando uma operao esteja declarada em classes diferentes, porm com o mesmo nome, executando processamentos diferentes para atender os requisitos semnticos de sua classe. Por exemplo, uma operao de mover para classe Janela executa um processo diferente do que a operao mover para classe Pea-de-Xadrez. Enquanto uma operao modifica a posio de uma janela a outra movimenta uma pea de xadrez.
34
Municpio acrescenta-se a coluna Id-Municipio, pois a classe no possui um atributo ou um conjunto de atributos que possa ser considerado chave. Essa estratgia compatvel com as linguagens baseadas em objetos, onde os objetos tm identidades independentes das suas propriedades.
35
36
Caso 2: No segundo caso cria-se uma tabela correspondente associao, transpondo para ela as chaves das duas classes. Um exemplo dado na figura a seguir (foram usadas as classes Quadras e Lotes do exemplo anterior).
37
Caso 2. Transpe-se a chave de IPTU para LOTES, como mostra a Figura a seguir.
38
Figura 4.2.1
39
A coluna Tipo acrescentada tabela Pontos para que se possa saber que tabela pesquisar, se a tabela de nos ou se a tabela de vrtices. A navegao nas tabelas do exemplo anterior poderia ser feita da seguinte forma Figura 4.3
Figura 4.3.1
1) Dado o identificador de um ponto, descobre-se a linha da tabela Pontos correspondente a ele. 2) Recupera-se o tipo do ponto para essa linha da tabela.
40
3) Vai-se para a tabela da classe de especializao indicada pelo tipo do ponto e encontram-se a linha com o mesmo identificador da linha da tabela pontos. Caso 2. Cada classe de especializao mapeada para uma tabela. A classe de generalizao eliminada, e seus atributos so reproduzidos em cada tabela de especializao. Um exemplo dado na figura 4.3.2 a seguir. Figura 4.3.2
Caso 3: A classe de generalizao mapeada para uma tabela juntamente com os atributos das classes de especializao. Um exemplo dado na Figura 4.3.3. Figura 4.3.3
Porm em que situao deve-se usar cada caso? Abaixo seguem algumas vantagens e desvantagens de cada abordagem. Elas devem ser analisadas de
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
41
acordo com os requisitos estabelecidos pelo sistema que est sendo desenvolvido (Rumbaugh, 1994): 1) A Figura 4.3.1 apresenta a abordagem padro, que a mais correta e extensiva logicamente. Contudo ela envolve muitas tabelas, e a navegao das classes de generalizao para as classes de especializao pode ser lenta. 2) A Figura 4.3.2 apresenta uma abordagem que pode ser utilizada se as classes de especializao possuir muitos atributos, se a classe de generalizao tiver poucos atributos, e se a aplicao souber qual classe deve ser pesquisada. 3) A Figura 4.3.3 apresenta a abordagem menos satisfatria, porm ela pode ser til se existirem somente duas ou trs classes de generalizao com poucos atributos. 4) As abordagens da Figura 4.3.2 e Figura 4.3.3 so abordagens alternativas motivadas pelo desejo de eliminar a navegao da classe de generalizao para as classes de especializao, melhorando o desempenho de consultas; contudo, esta melhora de desempenho incorre em outros problemas, tal como armazenamento de valores nulos.
42
No fcil descrever os requisitos do sistema em uma forma precisa. A linguagem do usurio e a linguagem do responsvel pelo desenvolvimento so to diferentes que torna complicada uma comunicao eficaz. Os requisitos, no entanto, apresentam um alvo mvel que continua a modificar-se por todo o desenvolvimento do sistema e por todo o seu ciclo de vida. A anlise estruturada tem como objetivo resolver essas dificuldades fornecendo uma abordagem sistemtica, etapa por etapa, para desenvolver a anlise e produzir uma especificao de sistema nova e melhorada. Para conseguir este objetivo, a anlise estruturada centraliza-se em uma comunicao clara e concisa. A especificao do sistema o elo entre a anlise e o projeto. Ela fornece uma descrio dos requisitos do sistema a ser construdo. O principal objetivo da anlise produzir uma especificao do sistema que defina a estrutura do problema a ser resolvido de acordo com a viso do usurio. O objetivo do projeto definir a estrutura do problema e com os requisitos do usurio. Os defensores da anlise estruturada afirmam que o uso do mesmo mtodo de construo para a especificao e para o projeto obriga os dois a ficarem mais coesos e a mais provavelmente representarem um sistema que satisfar s necessidades e expectativas do usurio. Anlise estruturada foi projetada para ser compatvel com o projeto estruturado e fornecer a melhor entrada possvel para ele. A especificao composta de diagrama de fluxo de dados, um dicionrio de dados e especificaes dos processos. A anlise estruturada de sistemas compe-se de um conjunto de tcnicas e ferramentas, em constante evoluo. Seu conceito fundamental a construo de um modelo lgico (no fsico) de um sistema, utilizando tcnicas grficas capazes de levar usurios, analistas e projetistas a formarem um quadro claro e geral do sistema e de como suas partes se encaixam para atender s necessidades daquele que dele precisam. Antes do desenvolvimento dessas ferramentas de Anlise Estruturada de Sistemas, todos os detalhes da implementao fsica eram perdidas. O analista serve de intermedirio entre a comunidade de usurios e a comunidade de programadores, portanto ele deve combinar o que atualmente possvel nessa tecnologia (minis, micros, banco de dados, etc...) e o que vale a pena ser feito para a empresa, em relao maneira como administradas, por este motivo torna-se necessrio o uso de melhores ferramentas.
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
43
Os problemas que o analista enfrenta so entrelaados, esta uma das razes que os tornam difceis, como por exemplo: - O analista acha difcil aprender o bastante sobre a empresa para conseguir determinar os requisitos do sistema atravs dos olhos do usurio. - Os usurios ainda no conhecem o suficiente sobre PD para saberem o que , ou no vivel. Em geral, a propaganda a respeito dos computadores no proporciona s pessoas idias especficas ou precisas sobre o que tais mquinas podem ou no fazer. - O analista pode ficar sobre carregado de detalhes rapidamente, no somente de detalhes tcnicas inerentes ao novo sistema. - O documento que define os detalhes de um novo sistema (que podemos chamar especificao do sistema, projeto geral, especificao funcional, ou qualquer nome equivalente) forma efetivamente um contrato entre o departamento do usurio e o grupo de desenvolvimento de sistema, apesar de muitas vezes ser impossvel aos usurios entenderem, por causa de seu tamanho e dos conceitos tcnicos associados a ele. - Se o documento da especificao puder ser escrito de forma a fazer sentido para os usurios, poder no ser muito til para os projetistas e programadores que iro construir o sistema. Mesmo utilizando as melhores ferramentas analticas possveis, alguns dos problemas acima sempre estaro presentes, pois no existem ferramentas analticas que possibilita ao analista saber o que o usurio pensa, mas no diz. No h como mostrar um modelo concreto e claro do sistema para os usurios, pois difcil para os usurios imaginar o que o novo sistema lhes fornecer at que esteja realmente em funcionamento. At agora, a nica ilustrao para um sistema tem sido o Fluxograma. Embora um Fluxograma possa valor mil palavras, o analista fica preso a um compromisso; o uso dos smbolos padronizados de Fluxograma significa, inevitavelmente, que o analista deve se comprometer a uma implementao fsica do novo sistema. O prprio ato de desenhar um Fluxograma significa que preciso tomar uma deciso quanto entrada de dados a ser feita por meio de cartes ou atravs de um terminal de vdeo, quais arquivos estaro em fita e quais em disco, que programas produziro sadas e assim por diante. Todavia, essas, decises so a essncias do
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
44
trabalho do projetista. A partir do momento em que o analista tiver desenhado um Fluxograma do sistema, o projetista poder escolher entre aceitar o projeto fsico do analista e ento lidar com os detalhes de estrutura de programa e arquivo, de ento (como muitas vezes acontece) retornar especificao escrita para gerar um novo projeto. Nenhum dos caminhos satisfatrio. A especificao no somente dever descrever tudo o que o usurio v, incluindo todas as interfaces, como tambm dever evitar a descrio do que o usurio no v. Essa a tarefa do implementador, e aqui sua liberdade deve ser limitada. O analista deve estar sempre preparado para mostrar uma implementao de qualquer aspecto que ele descreve, mas no deve tentar ditar a implementao. O Fluxograma no til na modelagem do sistema para os usurios. Embora alguns usurios possam aprender a ler Fluxograma, para a maioria deles o Fluxograma representa um Jargo visual.
45
As interfaces entre o novo sistema e outros j existentes, so mostrados de modo bem mais claro.
46
Um diagrama de fluxo de dados uma representao em rede dos processos (funes os procedimentos) de um sistema e dos dados que ligam estes processos. Mostra o que um sistema/procedimento faz, mas no como faz. a ferramenta principal de modelagem da anlise estruturada e usado para dividir o sistema em uma hierarquia de processos. Os smbolos e os conceitos que o representa encontram-se no nvel lgico; um fluxo de dados pode estar contido fisicamente em qualquer lugar em que os dados passem de uma entidade ou processo para outro. Utilizando os quatro smbolos do D.F.D., podemos desenhar um quadro do sistema sem nos comprometermos com a sua implementao.
47
smbolos usados nos diagramas. identificado por uma letra minscula colocada no canto superior esquerdo. Para evitar que as linhas dos fluxos de informaes se cruzem em demasia, pode-se repetir o mesmo fator no mesmo fluxo, mais de uma vez, denotando tal fato por meio de uma linha diagonal que colocado no canto inferior direito. Portanto, se um fator precisar ser repetido, coloca-se uma linha diagonal no canto inferior da mesma; se outro tambm precisar ser repetido, colocam-se duas linhas diagonais, e assim por diante, independentemente do nmero de vezes que o fator aparecer repetido. Exemplo:
4.3 Processos
So as vrias atividades realizadas no sistema. So representado graficamente por um retngulo de bordas arredondadas, opcionalmente dividido em trs reas. Nos processos tm-se as seguintes atividades. Identificao: um nmero atribudo ao processo, exclusivamente para identific-lo, no tendo, portanto, outro significado. Geralmente, esses nmeros so colocados da esquerda para a direita no diagrama de fluxo de informaes;
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
48
Descrio: uma frase imperativa, formada por um verbo referente a uma ao (registro, controle, preencha, etc) seguido por um objeto. Exemplo: Remeta Pagamento Atraso; Localizao Fsica: o nome da unidade organizacional responsvel pela atividade, no caso de o sistemas ser implementado.
49
eventualmente aparecer no fluxo detalhado, metade fora e metade dentro da linhalimite, se isso facilitar o desenho. Os depsitos de dados e informaes internos a um processo aparecem apenas no diagrama detalhado, desenhados internamente do lado de dentro da linha-limite, e seus nmeros de identificao dever ser atribudos da seguinte maneira: a letra D seguida do nmero do processo do diagrama geral, uma barra / e depois um dgito. Exemplo: pode-se ter deposito D3/3 - Arq. de relao X. As entidades externas no devem, de modo algum, aparecer desenhado no interior da linha-limite do diagrama detalhado. Quando fluxos de dados e informaes se cruzam (at mesmo no diagrama geral), deve-se usar a seguinte notao: g) quando um fluxo de dados e informaes cruza com uma banco de dados e informaes cruzar com um banco de informaes, deve-se usar a seguinte notao:
50
seja fundamentado no fluxo de dados, sua nfase est nos componentes do processo, e a anlise de dados recebe apenas uma ateno secundria. Uma outra melhoria bsica que a anlise estruturada apresenta a aplicao de o princpio dividir para conquistar ao processo de anlise e especificao do sistema. O processo de anlise dever ser dividido em etapas, e a especificao dever ser dividida em partes fceis de serem entendidas e modificadas. Os defensores da anlise estruturada consideram a especificao estruturada como o elo entre a anlise e o projeto. O diagrama de fluxo de dados usado como a base sobre a qual deve ser construdo um projeto estruturado e finalmente um programa estruturado. Contudo, preciso muita f para complementar a falta de rigor quando se transforma um diagrama de fluxo de dados em um diagrama de estrutura que representa um projeto estruturado.
P a g a m e n to C lie n te
a s s o c ia r p a g a m e n to fa tu ra
P a g a m e n to d a fa tu r a D e ta lh e d a fa tu r a
E x e m p lo d e D ia g r a m a d e F lu x o d e D a d o s
D 3
C o n ta s a r e c e b e r D e ta lh e d o P a g a m e n to 4 .8
Banco
D e p s ito
C ondensar p a g a m e n to e d e p o s it a r n o banco
Financeiro
C o t r o le d e c a ix a / F a tu ra m e n to
51
52
Concluso:
No desenvolvimento de softwares tm que desdobrar os problemas
complexos em tarefas menores para que sejam compreensveis e de fcil visualizao. Usando os diagramas da UML podemos aplicar boas abordagens para a construo do sistema, e a equipe analisa os riscos enquanto produz um produto de qualidade. Bons projetos requerem um bom modelo. Assim como um engenheiro desenha a planta antes do incio de uma construo temos que fazer o mesmo antes do incio do desenvolvimento de nossos sistemas. A UML e seus diagramas nos auxiliam neste processo de desenho do sistema. Mas ela sozinha no faz tudo, temos que usar uma metodologia para que nossos sistemas ganhem vida e a UML nos ajude a manter todo o ciclo de vida do projeto. No precisamos usar todos os diagramas da UML, at porque alguns so semelhantes e podemos usar um ou outro dependendo do contexto do que formos documentar. Um sistema tem que ter pelo menos estes diagramas, Casos de Uso, Classes, Seqncia, Tempo e Implantao. Seguindo esta ordem definimos o desenho do nosso projeto, documentamos nossas classes (objetos e tabelas) e seus relacionamentos, mostramos a seqncia em que as coisas acontecem e o tempo que cada ao leva para acontecer, juntando tudo implantamos o nosso sistema. Muito se fala em modelos de qualidade. Todavia, precisamos ajustar as engrenagens de um processo de desenvolvimento, para que tenhamos um produto final de qualidade. Uma das engrenagens mais importantes o paradigma de desenvolvimento de sistemas. Precisamos produzir mais, em menos tempo, e sem erros. Precisamos acompanhar a evoluo tecnolgica, sem que para isso tenhamos que nos sacrificar. Foram apresentados os principais conceitos da Programao Estruturada e da Orientada a Objetos. Ambos os paradigmas so herdeiros do Paradigma Imperativo, mas provem novas funes, criando novas abordagens para o mesmo. O Paradigma Estruturado o que domina atualmente cursos introdutrios de programao, mas o Paradigma Orientado a Objetos que a estrela da festa em sistemas maiores. Dificilmente encontra-se um grande projeto de software sem a
TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE
53
utilizao de POO, sendo este, requisito fundamental para profissionais da rea de programao. Em suma, cada paradigma tem suas vantagens e desvantagens, sendo indicados para fins especficos. Enquanto que no Estruturado temos simplicidade de termos e facilidade de aprendizagem, que o levam para as primeiras aulas de programao, no Orientado a Objetos, temos mais recursos e melhores organizaes e reaproveitamento de cdigo, colocando em um novo nvel, os paradigmas Imperativo e Estruturado, dos quais ele herda caractersticas. Segue comparativo: OOP Vantagens Prov uma melhor organizao do cdigo. Contribui para o reaproveitamento de cdigo. Estruturada Vantagens Prov um melhor controle sobre o fluxo de execuo do cdigo, quando comparada com a programao imperativa. fcil de entender, sendo amplamente usada em cursos introdutrios de programao. Desvantagens Ainda se foca em como a tarefa deve ser feita e no em o que deve ser feito. Tende a gerar cdigos confusos, onde tratamentos dos dados so misturados com o comportamento do programa.
Desvantagens No possui o mesmo desempenho de cdigos estruturados similares. Seus conceitos so de difcil compreenso se comparados aos conceitos da Programao estruturada.
Um bom comeo voltar ateno para as tecnologias que o mercado j aprovou. A orientao a objetos e a UML no possa mais ser enxergada como modismo (at porque nunca foram). hora de repensarmos nossos conceitos e, enfim, estarmos um passo frente do desenvolvimento.
54
1. UML [Castellani 1998] Xavier Castellani: evaluation of models defined with charts of concepts: application to the UML model, in [Siau 1998]. [UML notation 1997] UML notation guide, version 1.1, rational software corporation, 1997, vi+142 p.; (www.rational.com/uml 1997). 1. Booch, g; rumbaugh, j e Jacobson, i: UML: guia do usurio: traduo; Fbio Freitas da silva, rio de janeiro, campus, 2000. 2. Orientao a Objetos [Pablo Dall'Oglio]. PHP Programando com Orientao a Objetos: Inclui Design Patterns. 1 ed. So Paulo: Novatec, 2007. 576 p. ISBN 978-85-7522-137-2 [1] Barnes, Klling. Programao orientada a objetos com Java: Uma introduo Prtica Usando o BlueJ. Editora Pearson Prentice Hall, 4 Edio. [5] Koffman, Elliot e Wolfgang, Paul. Objetos, Abstrao, Estruturas de Dados e Projeto Usando C++. Editora LTD. 3. Analise Estruturada de Sistemas [Chris Gane e Trish Sarson] - Editora LTC (Livros Tcnicos e Cientficos), 1993.
55