Trabalho de UML

UNIP - Universidade Paulista

TRABALHO MODELAGEM DE PROCESSOS UML - UNIFIED MODELING LANGUAGE

Chacara Santo Antonio - So Paulo

2011

UNIP - Universidade Paulista

TRABALHO MODELAGEM DE PROCESSOS UML - UNIFIED MODELING LANGUAGE

Aluno (a): Elen Cristiane Donda RA: B0970J-1 Curso: Gesto em Tecnologia da Informao Semestre: Primeiro

Chacara Santo Antonio - So PauloTRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

2

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.

TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

3

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


4

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


5

Introduo UML - Uma Breve HistriaA UML surgiu da unio de trs metodologias de modelagem: o mtodo do americano Grady Booch, o mtodo OMT (Object Modeling Technique) do sueco Ivar Jacobson e o mtodo OOSE (Object-Oriented Software Engineering) do americano James Rumbaugh. Estas eram at meados da dcada de 90, as trs metodologias de modelagem orientada a objetos mais populares. A unio dessas tecnologias contou com o apoio da Rational Software, que incentivou e financiou a unio das trs metodologias. O esforo inicial do projeto comeou com a unio do mtodo de Booch com o mtodo OMT de Jacobson, o que resultou no lanamento do Mtodo Unificado no final de 1995. Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software e seu mtodo OOSE comeou a ser incorporado nova metodologia. O trabalho de Booch, Jacobson e Rumbaugh conhecidos popularmente como "Os Trs Amigos", resultou no lanamento, em 1996, da primeira verso da UML propriamente dita. Assim que a primeira verso foi lanada, diversas grandes empresas atuantes na rea de software passaram a contribuir com o projeto, fornecendo sugestes para melhorar e ampliar a linguagem. Finalmente a UML foi adotada pela OMG (Object Management Group) em 1997, como a linguagem padro de modelagem. Em 2007, a UML foi atualizada para a verso 2.0. Os esforos de Rumbaugh, Booch e Jacobson resultaram as verses 0.9 e 0.91 da UML em junho e outubro de 1996 respectivamente. A UML a sucessora da linguagem de modelagem encontrada nos mtodos Booch, OOSE/Jacobson, OMT e outros como Modelos de Entidades e Relacionamentos. Cada um desses mtodos era reconhecido mediante alguma forte caracterstica. O OOSE orientado a use case e prov um excelente recurso para a anlise de requisitos. A OMT foi expressiva para anlise e sistemas centrados a dados. Booch93 foi relevante na fase de projeto e construo de sistemas voltados para Engenharia.TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

6

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:


7

Motivao Necessidade de uma Modelagem VisualNecessidade de estabelecer uma padronizao para facilitar a comunicao entre os analistas (responsveis pelo levantamento dos requisitos) e o time de desenvolvimento (responsveis pela implementao). Diagramas nos ajudam a ver ou explorar mais do panorama e relacionamentos entre elementos, ao mesmo tempo em que nos permite ignorar ou ocultar detalhes desinteressantes.

Conceitos Bsicos de UMLUML uma linguagem visual para especificao (modelagem) de sistemas orientados a objeto. A UML privilegia a descrio de um sistema seguindo trs perspectivas: Os diagramas de classes - (Dados estruturais); Os diagramas de casos de uso (Operaes funcionais); Os diagramas de seqncia, atividades e transio de Estados (Eventos temporais).

Por que usar UML?Uma das grandes vantagens da UML o fato dela ser totalmente extensvel e adaptvel. Voc no adapta sua modelagem UML. Voc seleciona os elementos da UML que melhor expressaro sua modelagem. E se para isto for necessrio estender os modelos da UML, voc o faz sem perder compreenso. Qualquer um que leia seu modelo entender que foi feita uma extenso. Alm disso, acabam-se as fronteiras entre as fases de anlise e projeto. Um mesmo diagrama utilizado em todas as fases, mudando-se, apenas, sua viso. O mapeamento direto dos modelos para as linguagens de programao orientadas a objeto e vice-versa tambm um dos grandes ganhos da UML. Esses so alguns dos inmeros benefcios que a UML nos fornece, sem que percamos a liberdade de criar.


8

Estrutura da UMLA 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 EstruturaTRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

9

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 EstruturaisOs 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).

1.1 Diagrama de Classes (Class Diagram)O diagrama de classes apresenta elementos conectados por relacionamentos. Este diagrama representa o modelo da estrutura de um sistema orientado a objetos, demonstrando as classes, os tipos e os relacionamentos. usado para exibir entidades do mundo real, alm de elementos de anlise e projeto. uma modelagem muito til para o sistema, define todas as classes que o sistema necessita possuir e a base para a construo dos diagramas de comunicao, seqncia e estados. uma representao da estrutura e relaes das classes que servem de modelo para objetos.


10

1.2 Diagrama de Objetos (Object Diagram)O diagrama de objetos apresenta objetos e valores de dados. Este diagrama representa a modelagem de instncias das classes de um sistema em determinado ponto e momento de execuo. Corresponde a uma instncia do diagrama de classes, mostrando o estado de um sistema em um determinado ponto do tempo. O diagrama de objetos uma variao do diagrama de classes e utiliza quase a mesma notao, com duas excees: os objetos so escritos com seus nomes sublinhados e todas as instncias num relacionamento so mostradas. como se fosse o perfil do sistema em certo momento de sua execuo, mostrando os objetos que foram instanciados das classes. Os diagramas de objetos no so to importantes como os diagramas de classes, mas eles so muito teis para exemplificar diagramas complexos de classes ajudando muito em sua compreenso. Diagramas de objetos tambm so usados como parte dos diagramas de colaborao, onde a colaborao dinmica entre os objetos do sistema so mostrados.


11

1.3 Diagrama de Estrutura Composta (Composite Structure Diagram)O diagrama de estrutura composta usado para mostrar colaboraes entre um conjunto de entidades que cooperam entre si para executar uma determinada funo. A estrutura, neste caso, representa uma composio de elementos que esto interconectados (conectados entre si) para se atingir um objetivo comum. Definido a partir da UML 2.0 destina-se descrio dos relacionamentos entre os elementos. utilizado para descrever a colaborao interna de classes, interfaces ou componentes para especificar uma funcionalidade e muito til para representar uma estrutura formada por um conjunto de estruturas complexas ou em projetos baseados em componentes. Embora este diagrama seja semelhante ao diagrama de classes, ele expressa arquiteturas de tempo de execuo, padres de uso e os relacionamentos dos elementos participantes, enquanto que o diagrama de classes representa uma viso esttica da estrutura de classes.


12

1.4 Diagrama de Componentes (Component Diagram)O diagrama de componentes representa os componentes que faro parte dos sistemas em construo, demonstrando as dependncias entre esses componentes, ou seja, mostra as dependncias entre componentes de software, apresentando suas interfaces. Ilustra como as classes devero ser organizadas atravs da noo de componentes de trabalho. Por exemplo, pode-se explicitar (tornar claro), para cada componente, qual das classes que ele representa. utilizado para: modelar os componentes do cdigo-fonte e do cdigo-executvel do software; destacar a funo de cada mdulo para facilitar a sua reutilizao; auxiliar no processo de engenharia reversa, por meio da organizao dos mdulos do sistema e seus relacionamentos.


13

1.5 Diagrama de Implantao (Deployment Diagram)O diagrama de implantao representa configurao e a arquitetura de um sistema em que estaro ligados seus respectivos componentes, podendo ser representada tambm a arquitetura fsica de hardware, processadores, etc. Mostra a arquitetura do sistema em tempo de execuo, as plataformas de hardware, artefatos de software e ambientes de software (como sistemas operacionais e mquinas virtuais). Descreve os componentes de hardware e software e sua interao com outros elementos de suporte ao processamento.


14

1.6 Diagrama de Pacotes (Package Diagram)O diagrama de pacotes usado para organizar elementos de modelo e mostrar dependncias entre eles. Descreve os pacotes ou pedaos do sistema, como o sistema dividido em agrupamentos lgicos e mostra as dependncias entre estes.


15

Diagramas ComportamentaisOs 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.

2.0 Diagrama de Casos de Uso (Use Case Diagram)O diagrama de casos de uso representa um conjunto de cenrios identificados (vrios casos de uso), que seja til aos usurios de um sistema. utilizado nas fases de levantamento e anlise de requisitos, embora seja consultado durante todo o processo de modelagem, alm de servir de base para a construo de outros diagramas. Mostra os casos de uso, atores e seus relacionamentos que expressam a funcionalidade de um sistema. Em sistemas complexos so necessrios muitos casos de uso para uma correta e completa descrio de todas as funcionalidades requeridas pelo sistema.TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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.

2.0.1 Diagrama de um Caso de UsoO diagrama de um caso de uso a representao de uma funo, manipulada por uma entidade do sistema, conhecida como ator. Identificar um caso de uso, portanto, um esforo que envolve: descobrir um ator; verificar para esse ator aes das quais ele participa; agrupar tais aes de forma que possuam um nome em comum (geralmente um verbo no infinitivo: Cadastrarpessoa, Gerarpedido, etc.).

Passos que auxiliam na sua criao:1. Identifique aqueles que usaro o sistema de maneira direta, ou seja, identifique os atores; 2. Escolha um desses atores;TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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.

2.1 Diagrama de Mquina de Estados (Statechart Diagram)[Diagrama de Grfico de Estados] Diagrama de mquina de estados representa estados possveis de um objeto em particular. Neste diagrama so demonstrados os estados de um objeto, eventos, transies e atividades. Representa as aes ocorridas em resposta ao recebimento de eventos.


18

2.2 Diagrama de Atividades (Activity Diagram)Diagrama de atividades representa a execuo de aes ou atividades e os fluxos que so disparados pela concluso de outras aes ou atividades. Representa um fluxo de controle de atividades que ocorrem no processo de um sistema, oferecendo suporte para comportamentos condicionais e paralelos. Representa o negcio e o processo operacional do sistema.


19

2.3 Diagramas de InteraoDiagrama de interao (nome coletivo atribudo a diagramas de seqncias e de comunicao) exibe uma interao - ao que se exerce mutuamente entre duas ou mais coisas -, consistindo de um conjunto de objetos ou papis, incluindo as mensagens que podem ser trocadas entre eles. Os diagramas de interaes abrangem a viso dinmica de um sistema.

2.4 Diagrama de Seqncias (Sequence Diagram)Um projeto pode ter uma grande quantidade de mtodos em classes diferentes. Isso torna difcil determinar a seqncia global do comportamento. Diagrama de seqncias mostra as interaes que correspondem a um conjunto de mensagens trocadas entre objetos e a ordem que essas mensagens acontecem. um dos diagramas de interao que d nfase ordenao seqencial em que os comportamentos acontecem. O diagrama de seqncias um tipo de diagrama usado na UML que representa a seqncia de processos mais especificamente, a seqncia de mensagens passadas entre objetos num programa de computador. Esse diagrama simples e lgico, a fim de tornar bvios a seqncia e o fluxo de controle. Um diagrama de seqncias descreve a maneira como os grupos de objetos colaboram entre si em algum comportamento ao longo do tempo (seqncia


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.

2.5 Diagrama de Comunicao (Communication Diagram)[Diagrama de Colaborao] Diagrama de comunicao mostra objetos, seus inter-relacionamentos e o fluxo de mensagens entre eles. um dos diagramas de interao que d nfase organizao estrutural dos objetos que colaboram entre si. O diagrama de comunicao [diagrama de colaborao na verso anterior da UML] exibe uma interao, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Nos diagramas de seqncia e de comunicao existe uma correspondncia biunvoca entre seus elementos preservando as operaes de ambos.


21

2.6 Diagrama de Viso Geral (Interaction-Overview Diagram)Diagrama de viso geral uma variao do diagrama de atividades que mostra de uma forma geral o fluxo de controle dentro de um sistema ou processo de negcios. Cada n ou atividade dentro do diagrama pode representar outro diagrama de interao.


22

2.7 Diagrama Temporal (Timing Diagram)Diagrama temporal mostra a mudana de estado de um objeto numa passagem de tempo, em resposta a eventos externos. Apresenta o comportamento dos objetos e sua interao em uma escala de tempo, focalizando as condies que mudam no decorrer desse perodo.


23

Por que Orientao a Objetos?Atualmente, ser que conseguimos imaginar instituies financeiras, grandes lojas de departamentos, companhias areas, entre tantos outros setores, sem associ-las tecnologia? A resposta a esta pergunta nos leva ao quadro atual de desenvolvimento de sistemas. Precisamos, cada vez mais, oferecer servios de melhor qualidade, pois muitos setores dependem de nossos sistemas. Todavia, nos deparamos com um problema antigo: como desenvolver aplicaes que atendam s novas ondas da Tecnologia de Informao, se ainda se houve falar em crise de software? Para resolver essa questo, temos que levar em conta que no podemos desenvolver como h 15 anos, pois a nossa demanda e necessidades tecnolgicas so muito superiores quela poca. Precisamos de sistemas desenvolvidos mais rapidamente, com custos menores, que permitam s organizaes gerenciar melhor e competir com armas poderosas. Sabemos que a Anlise Estruturada e Essencial no conseguem suprir essas necessidades. A rea de Hardware h muito tempo encontrou seu 'caminho das pedras, quando aprenderam a componentizar e reutilizar esforos. E esse o caminho que devemos trilhar no software. Devemos componentizar, reutilizar esforos e para isso, necessitamos da orientao a objetos. Com a orientao a objetos, deixamos de abstrair dados e funes como elementos independentes. Focalizamos personagens de nosso mundo real, que so os objetos. A partir deles, idealizamos nossos sistemas. Passamos, ento, a pensar da mesma forma que visualizamos o mundo real.

Modelagem Orientada Por Objetos IntroduoO objetivo deste captulo apresentar alguns conceitos associados ao desenvolvimento de sistemas de software, baseados no trabalho de Rumbaugh (1994), e a tcnica de modelagem de objetos TMO. A modelagem de dados parte integrante de uma metodologia de desenvolvimento de software. Uma metodologia um processo organizado de produo de software, que utiliza tcnicas predefinidas e notaes convencionais. As etapas que compem este processo correspondem ao ciclo de vida do software.TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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.

Princpios da Modelagem 3.0 - Abstrao de DadosAbstrao uma capacidade de viso de alto nvel que nos permite examinar problemas de forma a selecionar grupos comuns, encontrar generalidades, para melhor compreender o problema e construir modelos. A abstrao deve estar associada a um propsito. Desta forma, podem-se ter vrias abstraes de umTRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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.

3.1 - Tcnica de Modelagem de ObjetosA TMO aborda as trs vises definidas anteriormente. A partir do uso da abstrao, constroem-se trs modelos: de objetos, dinmico e funcional, alm da relao entre os modelos. Neste trabalho, sero tratados aspectos ligados a banco de dados, logo ser enfatizado a modelagem das estruturas estticas e seus relacionamentos: o modelo de objetos. Precedendo a notao TMO, sero mostrados alguns conceitos bsicos de modelagem de objetos como: objeto, atributo, operaes e classes. - Objeto, Atributo e Operaes. Define-se um objeto como um conceito, uma abstrao, algo com limites ntidos e significado em relao realidade estudada (Rumbaugh, 1994). Os objetos facilitam a compreenso do mundo real e oferecem uma base real para a implementao em um sistema de software. Eles possuem identidade e so distinguveis. Os exemplos a seguir ilustram a idia de objeto: o homem Mohandas K. Gandhi, o rio Amazonas, a cidade de So Jos dos Campos, a empresa Human Tecnologies Ltda., etc. Objetos possuem caractersticas prprias que descrevem o seu estado em um determinado momento, e a isso se denomina atributos ou propriedades de um objeto. O exemplo a seguir ilustra o conceito de atributo: A cidade de So Jos dos Campos possui uma populao de 450.000 habitantes. Neste caso populao um atributo que descreve o objeto So Jos dos Campos em um determinado momento.


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 - ClassesUma 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.

3.3 - Associao, Ligao e MultiplicidadeA associao descreve um conjunto de ligao com estrutura e semntica comuns. Exemplo: Uma cidade pertence a um estado. Assim como as classes, as associaes podem possuir atributos provenientes da semntica de cada ligao. Ligao a conexo fsica ou conceitual entre instncias de objetos. Exemplo: A cidade de Ribeiro Preto pertence ao estado de So Paulo. Uma ligao uma instncia de uma associao. A multiplicidade especifica quantas instncias de uma classe relacionam-se a uma nica instncia de uma classe associada, restringindo a quantidade de objetos relacionados. A multiplicidade pode ser expressa, de maneira geral, por um ou muitos. No entanto, possvel utilizar intervalos bem definidos. A simbologia adotada representa por uma bola cheia na extremidade do relacionamento a multiplicidade muitos significando zero ou mais, e para bola vazia a multiplicidade zero ou um. Na figura abaixo so ilustradas o emprego dessas notaes.


29

3.4 - Atributo de LigaoAssim como um atributo uma propriedade dos objetos de uma classe, um atributo de ligao uma propriedade das ligaes de uma associao. Na figura acima, avaliao um exemplo de propriedade de associao que do tipo muitos ou zero para muitos ou zero. Desta forma, dado um determinado aluno, este dever ter muitas avaliaes dependendo de cada disciplina que cursar. No modo inverso, dado uma disciplina, esta avaliar os diversos alunos que a cursam.

3.5 AgregaoA 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 osTRABALHO 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.

3.6 - Generalizao, Especializao e HeranaEsses termos referem-se a aspectos da mesma idia e so freqentemente usados de forma intercambivel. Utilizamos generalizao para nos referirmos ao relacionamento entre classes, enquanto a herana refere-se ao mecanismo de compartilhamento de atributos e operaes utilizando o relacionamento de generalizao. Generalizao e especializao so dois diferentes pontos de vista do mesmo relacionamento, vistos a partir da superclasse ou das subclasses. Generalizao deriva do fato de que a superclasse generaliza as subclasses. Especializao refere-se ao fato de que as subclasses refinam ou especializam a superclasse. A figura ilustra esses conceitos.


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 PolimorfismoUm 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.

3.8 - Persistncia de Objetos em Ambientes RelacionaisEste tpico visa completar os tpicos antecessores sobre a TMO apresentando algumas tcnica de mapeamento das classes de dados e suas associaes em tabelas em um banco de dados relacional. Denominamos a isto persistncia de dados em ambientes relacionais. A discusso a seguir baseada no texto de Rumbaugh (1994).

3.9 - Mapeamento de ClassesDe uma maneira geral cada classe persistente d origem a uma tabela, onde cada atributo da classe corresponde a uma coluna, e os valores dos atributos para cada objeto na classe correspondem a uma linha. No entanto, deve-se, neste mapeamento, ter o cuidado de criar a coluna de identificao, ou seja, a chave primria de cada linha ou registro armazenado. Em um programa C++, quando ocorre a criao de um novo objeto, gerado automaticamente o identificador deste objeto. J em um banco de dados relacional cabe ao desenvolvedor a responsabilidade desta criao. Quando ocorre o mapeamento, recomenda-se armazenar no banco de dados relacional o identificador do objeto como chave primria, ou qualquer outro atributo do objeto que possa identific-lo de forma nica. A figura a seguir mostra um exemplo de converso de uma classe persistente em uma tabela. Nesse exemplo a classe Municpio possui os atributos Nome e Populacao_98. Quando ela convertida para a tabela 68


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.

4.0 Mapeamento de Associaes Muitos para MuitosCada associao muitos para muitos entre objetos persistentes deve ser mapeada em uma nova tabela. As chaves das tabelas das classes associadas transformam-se em atributos dessa nova tabela. Um exemplo do mapeamento de associao muitos para muitos dado na figura abaixo. Neste exemplo foi utilizada a propriedade Nro_lei da classe Leis para ser a chave primria ou identificador nico da tabela gerada pelo mapeamento desta classe no banco de dados relacional.


35

4.1 - Mapeamento de Associaes Um para MuitosExistem duas maneiras de se mapear associaes um para muitos entre objetos persistentes para o modelo relacional. So elas: Caso 1: No primeiro caso transpe-se a chave primria da tabela correspondente classe do lado Muitos, para a tabela correspondente classe do lado 1. (Por transpor deve-se entender criar uma coluna com a chave da tabela correspondente a uma determinada classe, em outra tabela). Um exemplo dado na figura a seguir.


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

4.2 - Mapeamento de Associaes Um para UmPara se fazer o mapeamento das associaes um para um entre objetos persistentes deve-se criar uma tabela para cada classe, e transpor a chave de uma tabela para a outra. O sentido da transposio depende das formas de acesso para ganho de eficincia. Os exemplos das figuras 4.2 e 4.2.1 a seguir mostram as duas maneiras de se mapear as associaes um para um em tabelas. O exemplo da figura 4.2 melhor, pois como todas as ocorrncias de IPTU possuem um lote associado, logo a transposio da chave de lotes para a tabela de IPTU no existir ocorrncia de valores vazios. J o contrrio, como mostrado pela figura 4.2.1, nem todas as ocorrncias de lotes possuem um IPTU associado. Os lotes da prefeitura so isentos de IPTU. Neste ltimo caso, na transposio da chave de IPTU para lotes, existiro valores vazios nesta chave transposta para as ocorrncias de lotes pertencentes a prefeitura, por exemplo. So eles: Caso 1. Transpe-se a chave de Lotes para IPTU, como mostra a figura a seguir. Figura 4.2

Caso 2. Transpe-se a chave de IPTU para LOTES, como mostra a Figura a seguir.


38

Figura 4.2.1

4.3 - Mapeamento de GeneralizaesExistem trs abordagens principais para o mapeamento de generalizaes de classes persistentes em tabelas. Sero dados exemplos das trs abordagens tomando-se como base a figura 4.3. So elas: Caso 1. A classe de generalizao e as classes de especializao so mapeadas cada uma para uma tabela. A chave da tabela da classe de generalizao reproduzida nas tabelas das classes de especializao. Um exemplo dado na Figura 4.3.1 Nesse exemplo, a identidade de um objeto atravs de uma generalizao preservada com a utilizao de um ID compartilhado. Desse modo, uma dada ocorrncia de n ter uma linha na tabela Pontos, e outra linha na tabela Nos, e em ambas as ocorrncias permanecer o mesmo valor para Id_ponto.


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 deTRABALHO 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.

Modelagem Estruturada IntroduoO uso de codificao estruturada torna possvel quantificarmos alguns benefcios resultantes: melhores produtividades em linhas de codificao por dia, usam mais apropriadas do tempo de teste e assim por diante. Com projeto estruturado, os benefcios tambm so reais, porm mais difceis de quantificar. Um estudo no publicado sugere que a modificao de um sistema que utilize projeto estruturado chega a ser sete vezes mais fcil e barato do que sistemas tradicionais. Realmente, sob certos aspectos, se o trabalho de anlise fosse realizado de forma perfeita, o nico resultado seria ausncia de problemas.

1. Uma ferramenta eficazA anlise estrutura uma fase crtica no desenvolvimento de sistemas e programas de software porque afeta as fases de desenvolvimento seguintes. Ela difcil por causa dos problemas de comunicao, das mudanas nos requisitos do sistema e das tcnicas inadequadas de avaliao.TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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 doTRABALHO 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

2. Analise Estruturada, Benefcios e ProblemasBenefcios Os usurios obtm uma idia mais clara do sistema proposto pelo diagrama de fluxo de dados, do que a obtida atravs da narrativa e Fluxograma de sistemas fsicos. Problemas O esforo, a formalidade e o grau de detalhes necessrios, especialmente na construo do dicionrio de dados, muitas vezes sofrem resistncia. Tem havido certa preocupao por parte dos programadores de que ao A apresentao em termos de fluxo lgico consegue mostrar malentendido e pontos controversos. obterem especificaes detalhadas da lgica no portugus estruturado, acabaro retirando todo o prazer da programao, tornando-os meros codificadores. Orientao dos usurios e treinamento dos analistas necessria, pois com a introduo da Anlise Estruturada foram mudadas as regras do jogo e todos devem. O uso de dicionrio de dados para guardar os itens do glossrio do projeto economiza tempo ao resolver rapidamente os casos em que pessoas chamam as mesmas coisas por diferentes nomes Ser bem esclarecidos quanto s novas regras e maneira como elas melhoram o jogo.

As interfaces entre o novo sistema e outros j existentes, so mostrados de modo bem mais claro.

3. Diagrama de Fluxo de Dados Lgico (DFD)TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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.

4. Caractersticas da Tcnica de Anlise Estruturada de SistemasA anlise estruturada de sistemas uma tcnica que consiste em construir, graficamente, um modelo lgico para o sistema de informaes gerenciais, a qual permite que usurios e analistas de sistemas, encontrem uma soluo clara e nica para o sistema de modo que este transmita as reais necessidades dos usurios. A anlise estruturada de sistemas apresenta um desenvolvimento do geral para o particular do sistema, comeando com um diagrama geral de fluxo de informaes e partindo depois por um refinamento sucessivo atravs da construo de diagrama de fluxo de informaes detalhadas. A anlise estruturada define o que o sistema deve fazer e torna-se bastante valiosa no momento de determinar as entradas para os sistemas de modo que estes fiquem os mais flexveis possveis.

4.1 Fatores externosGeralmente, so classes lgica, de atividades e ou pessoa que interagem com o sistema sendo fontes ou destinos das informaes. Exemplo: cliente, banco, fornecedores, etc. Pode tambm ser considerado fator externo outro sistema que forneam dados ou informaes para o sistema que est sendo descrito, ou que receba dados dos mesmos. O fator externo representado por um smbolo que um quadrado com as faces esquerda e de cima duplamente traadas, para distingui-lo dos demais


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.2 Fluxo de InformaesRepresenta, nos diagramas, um sistema de canalizao por onde as informaes fluem. Eles so representados por flechas direcionadas no sentido do fluxo das informaes e desenhadas, de preferncia, horizontal ou verticalmente. Dependendo do caso, pode-se usar uma flecha direcionada nos dois sentidos, se assim for conveniente (normalmente isso acontece quando se trata de uma atualizao num centro de informaes). Os fluxos so referenciados por suas respectivas origem e destinos, alm disso, devem receber um nome, o mais significativo possvel, para que os diagramas sejam facilmente entendidos pelos usurios. Salienta-se que, muitas vezes, um fluxo recebe um nome mais abrangente, mas, geralmente, fluem pelo mesmo vrios tipos de dados ou vice-versa, um fluxo recebe um nome bem detalhado, mas no necessariamente fluem por ele todos os dados ao mesmo tempo.

4.3 ProcessosSo 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.

4.4 Banco de InformaesSo os armazns que guardam dados e informaes entre os vrios processos so representados graficamente por um par de linhas paralelas, fechadas apenas de um lado por duas outras linhas, bem prxima perpendiculares as primeiras, formando, portanto, um pequeno quadrado do lado esquerdo. Nesse quadrado coloca-se uma referncia numrica arbitrria para o depsito, antecedida pela letra D e, no espao restante, coloca-se o nome atribudo ao banco de informaes, que dever ser aquele usado no dia-a-dia do usurio.

5. Convenes para Exploso de ProcessosExistem algumas convenes que devem ser seguidas na elaborao dessas exploses de processo. Os processos do diagrama detalhado devem receber como identificao um nmero que seja um decimal do nmero do processo que est sendo explodido. Exemplo: os processos do diagrama detalhado referentes exploso do processo 2 do diagrama geral recebem como identificao os nmeros; 2,1,2.2,2.3,etc... Da mesma forma, se estes forem detalhados, os processos devem ser identificados por 2,1.1,2.1.2,2.2.1, e assim sucessivamente. O diagrama detalhado desenhada dentro de um retngulo grande, com a forma do smbolo dos processos, determinado, desse modo, uma linha que delimita os processos da decomposio. Os fluxos que entram e saem do processo no nvel mais alto tambm devem cruzar a linha-limite, entrando ou saindo. Os fluxos que cruzam a linha-limite do diagrama detalhado e que no aparecem no diagrama geral, ao cruzar essa linha, devem ser assinalados com um X no ponto de interseco. Os depsitos de dados e informaes so externos ao processo expandido, isto , aparecem no diagrama geral usados por outros processos; podem


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:

6.Crtica Anlise EstruturadaEnquanto as mais avanadas tcnicas estruturadas esto disponveis para a fase de codificao do desenvolvimento de software, provavelmente as menos avanadas esto disponveis para a anlise e especificao de sistema. A anlise estruturada um exemplo de uma metodologia inicial e informal. Representa mais os princpios de um mtodo de anlise do que uma metodologia madura. Talvez a mais importante melhoria que a anlise estruturada introduz seja mudar a especificao do sistema de um grande e ilegvel torno para um modelo grfico de fcil uso. Um diagrama de fluxo de dados de alto nvel pode ser desenhado rapidamente, sendo facilmente modificado medida que o usurio e o analista se aprofundam sobre o problema a ser resolvido. Contudo, o diagrama de fluxo de dados no uma representao completa ou precisa do sistema. Embora um conjunto de diagramas de fluxo de dados nivelados possa mostrar a organizao hierrquica pela exploso dos retngulos de processos, um diagrama de fluxo de dados no apresenta nenhum embutimento lgico de fluxos de dados e nenhuma informao de controle. comum, tambm, aparecerem omisses e outros erros nos diagramas de fluxo de dados, uma vez que no h nenhum mecanismo de checagem. Embora o mtodo de anlise estruturadaTRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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 tea 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

7. Quando Usar a Anlise EstruturadaA anlise estruturada dever ser usada apenas para problemas pequenos e simples. Embora seja informal e no validado por computao, o diagrama de fluxo de dados a parte mais importante da anlise estruturada. de uso bem fcil. Pode ser utilizados para a determinao dos componentes bsicos de processamento e dos fluxos de dados de um sistema. Pode ser acompanhado por uma modelagem de dados mais formal. Para sistemas maiores e mais complexos, a diagramao de fluxos de dados pode ser usada para esboar uma viso de alto nvel do sistema. Porm, alm deste ponto, devem ser usados outros mtodos de anlise e de especificao mais rigorosos para desenvolver uma especificao precisa e validada por computao.


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 aTRABALHO 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.

Refer ncias Bibliogrficas:TRABALHO MODELAGEM DE PROCESSOS - UML - UNIFIED MODELING LANGUAGE

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

Documents

Trabalho de UML