UML

Linguagem de Modelagem Unificada

Sumrio

RESUMO.......................................................................................................................IV NDICE DE FIGURAS..................................................................................................V 1.INTRODUO............................................................................................................8 DESENVOLVIMENTO DE SOFTWARES ORIENTADO A OBJETOS..............10 UML A UNIFICAO DOS MTODOS PARA A CRIAO DE UM NOVO PADRO........................................................................................................................12 USO DA UML................................................................................................................15 FASES DO DESENVOLVIMENTO DE UM SISTEMA EM UML........................17
ANLISE DE REQUISITOS...............................................................................................................................17 ANLISE.....................................................................................................................................................17 DESIGN (PROJETO).......................................................................................................................................18 PROGRAMAO............................................................................................................................................18 TESTES.......................................................................................................................................................19

A NOTAO DA LINGUAGEM DE MODELAGEM UNIFICADA UML ......20 VISES...........................................................................................................................22 MODELOS DE ELEMENTOS....................................................................................25

CLASSES.....................................................................................................................................................25 OBJETOS.....................................................................................................................................................27 ESTADOS.....................................................................................................................................................28 PACOTES.....................................................................................................................................................29 COMPONENTES.............................................................................................................................................30 RELACIONAMENTOS.......................................................................................................................................30 Associaes..........................................................................................................................................31 Generalizaes....................................................................................................................................36 Dependncia e Refinamentos...............................................................................................................39 MECANISMOS GERAIS...................................................................................................................................40

DIAGRAMAS................................................................................................................42
DIAGRAMA USE-CASE..................................................................................................................................42 DIAGRAMA DE CLASSES................................................................................................................................44 DIAGRAMA DE OBJETOS ..............................................................................................................................45 DIAGRAMA DE ESTADO ................................................................................................................................46 DIAGRAMA DE SEQNCIA ............................................................................................................................48 DIAGRAMA DE COLABORAO........................................................................................................................49 DIAGRAMA DE ATIVIDADE.............................................................................................................................50 DIAGRAMA DE COMPONENTE..........................................................................................................................52 DIAGRAMA DE EXECUO.............................................................................................................................53

UM PROCESSO PARA UTILIZAR A UML.............................................................55 O FUTURO DA UML...................................................................................................57

II

UM ESTUDO DE CASO EM UML.............................................................................58

ANLISE DE REQUISITOS...............................................................................................................................59 ANLISE.....................................................................................................................................................61 DESIGN ......................................................................................................................................................64 IMPLEMENTAO..........................................................................................................................................68 TESTES.......................................................................................................................................................69

CONCLUSO................................................................................................................70 BIBLIOGRAFIA...........................................................................................................71

III

Resumo UML siginica Unified Modeling Language e a padronizao das metodologias de desenvolvimento de sistemas baseados na orientao a objetos. A UML foi criada por trs grandes desenvolvedores de sistemas orientados a objetos: Grady Booch, James Rumbaugh, e Ivar Jacobson, que j haviam criado outras notaes de desenvolvimento de software. A UML incorpora as noes do desenvolvimento de software totalmente visual. Ela se baseia em diagramas que so modelados e classificados em vises de abstrao. O desenvolvimento de um sistema em UML divide-se em 5 fases: anlise de requisitos, anlise, design, implementao (programao) e testes. A UML se prope a ser a linguagem definitiva para modelagem de sistemas orientados a objetos modelos por ser unificada por e facilitar analistas que ou grupos grupos de de desenvolvimentos de software interpretem de uma maneira correta e sem ambiguidades gerados outros desenvolvimento.

IV

ndice de Figuras

FIGURA 1 - DIAGRAMA DE VISES DA UML.....................................................23 FIGURA 2 REPRESENTAO DE CLASSE........................................................27 FIGURA 3 REPRESENTAO DE UM OBJETO...............................................27 FIGURA 4 REPRESENTAO DE UM ESTADO DE UMA CLASSE OU OBJETO.........................................................................................................................28 FIGURA 5 REPRESENTAO DE PACOTES COM RELACIONAMENTOS ENTRE SI.......................................................................................................................29 FIGURA 6 REPRESENTAO DE COMPONENTES........................................30 FIGURA 7 DUAS CLASSES SE RELACIONANDO POR ASSOCIAO NORMAL.......................................................................................................................32 FIGURA 8 EXEMPLO DE UMA ASSOCIAO RECURSIVA.........................32 FIGURA 9 REPRESENTAO DE COMPONENTES........................................33 FIGURA 10 EXEMPLO DE UMA ASSOCIAO EXCLUSIVA.......................33 FIGURA 11 EXEMPLO DE UMA ASSOCIAO DE CLASSES......................34 FIGURA 12 EXEMPLO DE UMA ASSOCIAO TERNRIA.........................35 FIGURA 13 EXEMPLO DE UMA AGREGAO ENTRE DUAS CLASSES. .35 FIGURA 14 EXEMPLO DE UMA AGREGAO COMPARTILHADA..........36 FIGURA 15 EXEMPLO DE UMA AGREGAO DE COMPOSIO............36 FIGURA 16 EXEMPLO DE UMA GENERALIZAO NORMAL...................37 FIGURA 17 EXEMPLO DE UMA GENERALIZAO DE SOBREPOSIO 38 FIGURA 18 EXEMPLO DE UMA GENERALIZAO COMPLETA..............39 FIGURA 19 EXEMPLO DE UMA DEPENDNCIA ENTRE CLASSES...........39 FIGURA 20 EXEMPLO DE UM REFINAMENTO...............................................40 FIGURA 21 EXEMPLO DE UMA NOTA...............................................................41 FIGURA 22 DIAGRAMA DE USE-CASE..............................................................44

FIGURA 23 DIAGRAMA DE CLASSES UMA SIMPLES REPRESENTAO DE UMA EMPRESA DE ALUGUEL DE VECULOS. ...........................................45 FIGURA 24 DIAGRAMA DE OBJETOS A CLASSE CLIENTE SE RELACIONA DE 1 PARA N COM CONTRATO DE ALUGUEL, POR ISSO, UM OBJETO DA CLASSE CLIENTE PODE TER 1 OU VRIOS CONTRATOS. ...........................................46 FIGURA 25 DIAGRAMA DE ESTADOS DIAGRAMA DE ESTADOS DE UM ELEVADOR. .................................................................................................................47 FIGURA 26 DIAGRAMA DE SEQUENCIA SERVIDOR DE IMPRESSO..49 FIGURA 27 DIAGRAMA DE CLABORAO SERVIDOR DE IMPRESSO. 50 FIGURA 28 DIAGRAMA DE ATIVIDADE SERVIDOR DE IMPRESSO...52 FIGURA 29 DIAGRAMA DE COMPONENTES...................................................53 FIGURA 30 DIAGRAMA DE EXECUO ASSOCIAES ENTRE NODES. 54 FIGURA 31 DIAGRAMA DE USE-CASE FASE DE ANLISE DE REQUISITOS................................................................................................................61 FIGURA 32 DIAGRAMA DE CLASSES FASE DE ANLISE.........................62 FIGURA 33 DIAGRAMA DE SEQUNCIA FASE DE ANLISE...................63 FIGURA 34 FASE DE DESIGN DEFINIO DOS PACOTES.......................65 FIGURA 35 DIAGRAMA DE CLASSES FASE DE DESIGN...........................67

VI

VII

1. Introduo O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objetos nas fases de anlise de requisitos, anlise de sistemas e design que no existe uma notao padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada simbologia existente possui seus prprios conceitos, grficos e terminologias, resultando numa grande confuso, especialmente para aqueles que querem utilizar a orientao a objetos no s sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajud-los a construir e manter sistemas cada vez mais eficazes. Quando a Unified Modeling Language (UML) foi lanada, muitos desenvolvedores da rea da orientao a objetos ficaram entusiasmados j que essa padronizao proposta pela UML era o tipo de fora que eles sempre esperaram. A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de novos conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da UML no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar orientado a objetos no estado da arte. UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos como os trs amigos. Eles possuem um extenso conhecimento na rea de modelagem orientado a objetos j que as trs mais conceituadas metodologias de modelagem orientadas a objetos foram eles que desenvolveram e a UML a juno do que havia de melhor nestas trs metodologias adicionado novos conceitos e vises da linguagem. Veremos caractersticas de cada uma destas metodologias no desenvolver deste documento.

Veremos como a UML aborda o carter esttico e dinmico do sistema a ser analisado levando em considerao, j no perodo de modelagem, todas as futuras caractersticas do sistema em relao a utilizao de packages prprios da linguagem a ser utilizada, utilizao do banco de dados bem como as diversas especificaes do sistema a ser desenvolvido de acordo com as mtricas finais do sistema. No intuito deste documento definir e explicar os significados de classes, objetos, relacionamentos, fluxos, mensagens e outras entidades comuns da orientao a objetos, e sim apresentarmos como essas entidades so criadas, simbolizadas, organizadas e como sero utilizadas dentro de um desenvolvimento utilizando a UML.

Desenvolvimento de Softwares orientado a objetos O conceito de orientao a objetos j vem sido discutido h muito tempo, desde o lanamento da 1 linguagem orientada a objetos, a SIMULA. Vrios papas da engenharia de software mundial como Peter Coad, Edward Yourdon e Roger Pressman abordaram extensamente a anlise orientada a objetos como realmente um grande avano no desenvolvimento de sistemas. Mas mesmo assim, eles citam que no existe (ou que no existia no momento de suas publicaes) uma linguagem que possibilitasse o desenvolvimento de qualquer software utilizando a anlise orientada a objetos. Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram em suas publicaes foram que: A orientao a objetos uma tecnologia para a produo de modelos que especifiquem o domnio do problema de um sistema. Quando construdos corretamente, sistemas orientados a objetos so flexveis a mudanas, possuem estruturas bem conhecidas e provm a oportunidade de criar e implementar componentes totalmente reutilizveis. Modelos orientados a objetos so implementados convenientemente utilizando uma linguagem de programao orientada a objetos. A engenharia de software orientada a objetos muito mais que utilizar mecanismos de sua linguagem de programao, saber utilizar, da melhor forma possvel, todas as tcnicas da modelagem orientada a objetos.. A orientao a objetos no s teoria, mas uma tecnologia de eficincia e qualidade comprovadas usadas em inmeros projetos e para construo de diferentes tipos de sistemas.

10

A orientao a objetos requer um mtodo que integre o processo de desenvolvimento e a linguagem de modelagem com a construo de tcnicas e ferramentas adequadas.

11

UML A unificao dos mtodos para a criao de um novo padro A UML uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistncia, fcil de se comunicar com outras aplicaes, simples de ser atualizado e compreensvel. Existem vrias metodologias de modelagem orientada a objetos que at o surgimento da UML causavam uma guerra entre a comunidade de desenvolvedores orientado a objetos. A UML acabou com esta guerra trazendo as melhores idias de cada uma destas metodologias, e mostrando como deveria ser a migrao de cada uma para a UML. Falaremos sobre algumas das principais metodologias que se tornaram populares nos anos 90: Booch O mtodo de Grady Booch para desenvolvimento orientado a objetos est disponvel em muitas verses. Booch definiu a noo de que um sistema analisado a partir de um nmero de vises, onde cada viso descrita por um nmero de modelos e diagramas. O Mtodo de Booch trazia uma simbologia complexa de ser desenhada a mo, continha tambm o processo pelo qual os sistemas so analisados por macro e micro vises. OMT Tcnica de Modelagem de Objetos (Object Modelling Technique) um mtodo desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava. O mtodo especialmente voltado para o teste dos modelos, baseado nas especificaes da anlise de requisitos do sistema. O modelo total do sistema baseado no mtodo OMT composto pela juno dos modelos de objetos, funcional e use-cases. OOSE/Objectory Os mtodos OOSE e o Objectory foram desenvolvidos baseados no mesmo ponto de vista formado por Ivar Jacobson. O mtodo

12

OOSE a viso de Jacobson de um mtodo orientado a objetos, j o Objectory usado para a construo de sistemas to diversos quanto eles forem. Ambos os mtodos so baseados na utilizao de use-cases, que definem os requisitos iniciais do sistema, vistos por um ator externo. O mtodo Objectory tambm foi adaptado para a engenharia de negcios, onde usado para modelar e melhorar os processos envolvidos no funcionamento de empresas. Cada um destes mtodos possui sua prpria notao (seus prprios smbolos para representar modelos orientados a objetos), processos (que atividades so desenvolvidas em diferentes partes do desenvolvimento), e ferramentas (as ferramentas CASE que suportam cada uma destas notaes e processos). Diante desta diversidade de conceitos, os trs amigos, Grady Booch, James Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de Modelagem Unificada. Eles disponibilizaram inmeras verses preliminares da UML para a comunidade de desenvolvedores e a resposta incrementou muitas novas idias que melhoraram ainda mais a linguagem. Os objetivos da UML so: A modelagem de sistemas (no apenas de software) usando os conceitos da orientao a objetos; Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm executveis;

Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina.

13

A UML est destinada a ser dominante, a linguagem de modelagem comum a ser usada nas indstrias. Ela est totalmente baseada em conceitos e padres extensivamentes testados provenientes das metodologias existentes anteriormente, e tambm muito bem documentada com toda a especificao da semntica da linguagem representada em meta-modelos.

14

Uso da UML A UML usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer caracterstica de um sistema em um de seus diagramas e tambm aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificao da anlise de requisitos at a finalizao com a fase de testes. O objetivo da UML descrever qualquer tipo de sistema, em termos de diagramas orientado a objetos. Naturalmente, o uso mais comum para criar modelos de sistemas de software, mas a UML tambm usada para representar sistemas mecnicos sem nenhum software. Aqui esto alguns tipos diferentes de sistemas com suas caractersticas mais comuns: Sistemas de Informao: Armazenar, pesquisar, editar e mostrar

informaes para os usurios. Manter grandes quantidades de dados com relacionamentos complexos, que so guardados em bancos de dados relacionais ou orientados a objetos. Sistemas Tcnicos: Manter e controlar equipamentos tcnicos como de telecomunicaes, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programao de software de que os sistemas de informao. Sistemas Tcnicos so geralmente sistemas real-time. Sistemas Real-time Integrados: Executados em simples peas de hardware integrados a telefones celulares, carros, alarmes etc. Estes sistemas implementam programao de baixo nvel e requerem suporte real-time. Sistemas Distribudos: Distribudos em mquinas onde os dados so transferidos facilmente de uma mquina para outra. Eles requerem mecanismos de comunicao sincronizados para garantir a integridade dos

15

dados e geralmente so construdos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI. Sistemas de Software: Definem uma infra-estrutura tcnica que outros softwares utilizam. Sistemas Operacionais, bancos de dados, e aes de usurios que executam aes de baixo nvel no hardware, ao mesmo tempo em que disponibilizam interfaces genricas de uso de outros softwares. Sistemas de Negcios: descreve os objetivos, especificaes (pessoas, computadores etc.), as regras (leis, estratgias de negcios etc.), e o atual trabalho desempenhado nos processos do negcio. importante perceber que a maioria dos sistemas no possui apenas uma destas caractersticas acima relacionadas, mas vrias delas ao mesmo tempo. Sistemas de informaes de hoje, por exemplo, podem ter tanto caractersticas distribudas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas.

16

Fases do Desenvolvimento de um Sistema em UML Existem cinco fases no desenvolvimento de sistemas de software: anlise de requisitos, anlise, design (projeto), programao e testes. Estas cinco fases no devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e performance. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML:

Anlise de Requisitos

Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes chamadas use-cases. Atravs do desenvolvimento de use-case, as entidades externas ao sistema (em UML chamados de atores externos) que interagem e possuem interesse no sistema so modelados entre as funes que eles requerem, funes estas chamadas de use-cases. Os atores externos e os use-cases so modelados com relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Cada use-case modelado descrito atravs de um texto, e este especifica os requerimentos do ator externo que utilizar este use-case. conhecendo toda O diagrama de use-cases mostrar o que os atores sua funcionalidade sem importar como esta ser externos, ou seja, os usurios do futuro sistema devero esperar do aplicativo, implementada. A anlise de requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no apenas para sistemas de software. Anlise

A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras

17

classes, e so descritas no Diagrama de Classe. As colaboraes entre classes tambm so mostradas neste diagrama para desenvolver os usecases modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero modeladas classes que pertenam ao domnio principal do problema do software, ou seja, classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.

Design (Projeto)

Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero adicionadas para prover uma infra-estrutura tcnica: a interface do usurio e de perifricos, gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes do domnio do problema modeladas na fase de anlise so mescladas nessa nova infra-estrutura tcnica tornando possvel alterar tanto o domnio do problema quanto a infra-estrutura. O design resulta no detalhamento das especificaes para a fase de programao do sistema.

Programao

Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a objetos escolhida (a utilizao de linguagens procedurais extremamente no recomendada). Dependendo da capacidade da linguagem usada, essa converso pode ser uma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases anteriores, os modelos criados so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema. A

18

programao uma fase separada e distinta, onde os modelos criados so convertidos em cdigo.

Testes

Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando as classes e componentes integrados para se confirmar se as classes esto cooperando uma com as outras como especificado nos modelos. Os testes de aceitao observam o sistema como uma caixa preta e verificam se o sistema est funcionando como o especificado nos primeiros diagramas de use-cases. O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente de acordo com as intenes do usurio final.

19

A Notao da Linguagem de Modelagem Unificada UML Tendo em mente as cinco fases do desenvolvimento de softwares, as fases de anlise de requisitos, anlise e design utilizam-se em seu desenvolvimento cinco tipos de vises, nove tipos de diagramas e vrios modelos de elementos que sero utilizados na criao dos diagramas e mecanismos gerais que todos em conjunto especificam e exemplifica a definio do sistema, tanto a definio no que diz respeito funcionalidade esttica e dinmica do desenvolvimento de um sistema. Antes de abordarmos cada um destes componentes separadamente, definiremos as partes que compem a UML: Vises: As Vises mostram diferentes aspectos do sistema que est sendo modelado. A viso no um grfico, mas uma abstrao consistindo em uma srie de diagramas. Definindo um nmero de vises, cada uma mostrar aspectos particulares do sistema, dando enfoque a ngulos e nveis de abstraes diferentes e uma figura completa do sistema poder ser construda. As vises tambm podem servir de ligao entre a linguagem de modelagem e o mtodo/processo de desenvolvimento escolhido. Modelos de Elementos: Os conceitos usados nos diagramas so modelos de elementos que representam definies comuns da orientao a objetos como as classes, objetos, mensagem, relacionamentos entre classes incluindo associaes, dependncias e heranas. Mecanismos Gerais: Os mecanismos gerais provm comentrios

suplementares, informaes, ou semntica sobre os elementos que compem os modelos; eles provm tambm mecanismos de extenso para adaptar ou estender a UML para um mtodo/processo, organizao ou usurio especfico.

20

Diagramas: Os diagramas so os grficos que descrevem o contedo em uma viso. UML possui nove tipos de diagramas que so usados em combinao para prover todas as vises do sistema.

21

Vises O desenvolvimento de um sistema complexo no uma tarefa fcil. O ideal seria que o sistema inteiro pudesse ser descrito em um nico grfico e que este representasse por completo as reais intenes do sistema sem ambiguidades, sendo facilmente interpretvel. Infelizmente, isso impossvel. Um nico grfico incapaz de capturar todas as informaes necessrias para descrever um sistema. Um sistema composto por diversos aspectos: funcional (que sua estrutura esttica e suas interaes dinmicas), no funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo, etc.). Ento o sistema descrito em um certo nmero de vises, cada uma representando uma projeo da descrio completa e mostrando aspectos particulares do sistema. Cada viso descrita por um nmero de diagramas que contm informaes que do nfase aos aspectos particulares do sistema. Existe em alguns casos uma certa sobreposio entre os diagramas o que significa que um deste pode fazer parte de mais de uma viso. Os diagramas que compem as vises contm os modelos de elementos do sistema. As vises que compem um sistema so:

22

Viso de Componentes

Viso Lgica

Viso de Use-case

Viso de Organizao

Viso de Concorrncia

Figura 1 - Diagrama de Vises da UML

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

Viso

Lgica:

Descreve

como

funcionalidade

do

sistema

ser

implementada. feita principalmente pelos analistas e desenvolvedores. Em contraste com a viso use-case, a viso lgica observa e estuda o sistema internamente. Ela descreve e especifica a estrutura esttica do sistema (classes, objetos, e relacionamentos) e as colaboraes dinmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funes do sistema. Propriedades como persistncia e concorrncia so definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura esttica descrita pelos diagramas de classes e objetos. A modelagem dinmica descrita pelos diagramas de estado, seqncia, colaborao e atividade. Viso de Componentes: uma descrio da implementao dos mdulos e suas dependncias. principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas.

23

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

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

24

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

Classes

Uma classe a descrio de um tipo de objeto. Todos os objetos so instncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Objetos s podem ser instanciados de classes. Usam-se classes para classificar os objetos que identificamos no mundo real. Tomando como exemplo Charles Darwin, que usou classes para classificar os animais conhecidos, e combinou suas classes por herana para descrever a Teoria da Evoluo. A tcnica de herana entre classes tambm usada em orientao a objetos. Uma classe pode ser a descrio de um objeto em qualquer tipo de sistema sistemas de informao, tcnicos, integrados real-time, distribudos, software etc. Num sistema de software, por exemplo, existem classes que representam entidades de software num sistema operacional como arquivos, programas executveis, janelas, barras de rolagem, etc.

25

Identificar as classes de um sistema pode ser complicado, e deve ser feito por experts no domnio do problema a que o software modelado se baseia. As classes devem ser retiradas do domnio do problema e serem nomeadas pelo que elas representam no sistema. Quando procuramos definir as classes de um sistema, existem algumas questes que podem ajudar a identific-las: Existem informaes que devem ser armazenadas ou analisadas? Se existir alguma informao que tenha que ser guardada, transformada ou analisada de alguma forma, ento uma possvel candidata para ser uma classe. Existem sistemas externos ao modelado? Se existir, eles devero ser vistos como classes pelo sistema para que possa interagir com outros externos. Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo sistema modelado? Se sim, normalmente essas classes, componentes e modelos contero classes candidatas ao nosso sistema. Qual o papel dos atores dentro do sistema? Talvez o papel deles possa ser visto como classes, por exemplo, usurio, operador, cliente e da por diante. Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que possuir a relao de atributos que a classe possui em sua estrutura interna, e o compartimento de operaes, que sero os mtodos de manipulao de dados e de comunicao de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem de programao, embora podem ser usadas outras sintaxes como a do C++, Java, e etc.

26

Cliente Nome : String Idade : Num Criar() Destruir()

Nome da Classe Atributos Operaes

Figura 2 Representao de Classe

Objetos

Um objeto um elemento que podemos manipular, acompanhar seu comportamento, criar, destruir etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por exemplo, uma mquina, uma organizao, ou negcio. Existem objetos que no encontramos no mundo real, mas que podem ser vistos de derivaes de estudos da estrutura e comportamento de outros objetos do mundo real. Em UML um objeto mostrado como uma classe s que seu nome (do objeto) sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da classe.

Pablo Barros:Cliente Nome : "Pablo Barros" Idade : 20 Criar() Destruir()

Nome do Objeto Atributos Operaes

Figura 3 Representao de um objeto

27

Estados

Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, e normalmente determinada pelos valores de seus atributos e ligaes com outros objetos. Um objeto muda de estado quando acontece algo, o fato de acontecer alguma coisa com o objeto chamado de evento. Atravs da anlise da mudana de estados dos tipos de objetos de um sistema, podemos prever todos os possveis comportamentos de um objeto de acordo com os eventos que o mesmo possa sofrer.

Figura 4 Representao de um estado de uma classe ou objeto

Um estado, em sua notao, pode conter trs compartimentos. O primeiro mostra o nome do estado. O segundo opcional e mostra a varivel do estado, onde os atributos do objeto em questo podem ser listados e atualizados. Os atributos so aqueles mostrados na representao da classe, e em algumas vezes, podem ser mostradas tambm as variveis temporrias, que so muito teis em diagramas de estado, j que atravs da observncia de seus valores podemos perceber a sua influncia na mudana de estados de um objeto. O terceiro compartimento opcional e chamado de compartimento de atividade, onde eventos e aes podem ser listados. Trs eventos padres podem ser mostrados no compartimento de atividades de um estado: entrar, sair e fazer. O evento entrar pode ser usado para definir atividades no momento em que o objeto entra naquele estado. O evento sair, define atividades que o objeto

28

executa antes de passar para o prximo estado e o evento fazer define as atividades do objeto enquanto se encontra naquele estado. Pacotes

Pacote um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados. Em UML, um pacote definido como: Um mecanismo de propsito geral para organizar elementos semanticamente relacionados em grupos. Todos os modelos de elementos que so ligados ou referenciados por um pacote so chamados de Contedo do pacote. Um pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em outros pacotes.

Interface do Usurio

Objetos do Sistema

Utilidades

Banco de Dados

Figura 5 Representao de Pacotes com relacionamentos entre si

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

29

O pacote tem uma grande similaridade com a agregao (relacionamento que ser tratado em seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregao de composio. Se este for destrudo, todo o seu contedo tambm ser.

Componentes

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

Cliente.java

Grficos.dll

Figura 6 Representao de componentes

Relacionamentos

Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados.

30

Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido.

Dependncia e Refinamentos: Dependncia um relacionamento entre elementos, um independente e outro dependente. Uma modificao um elemento independente afetar diretamente elementos dependentes do anterior. Refinamento um relacionamento entre duas descries de uma mesma entidade, mas em nveis diferentes de abstrao. Abordaremos agora cada tipo de relacionamento e suas respectivas sub-

divises:

Associaes

Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando por exemplo que elas conhecem uma a outra, esto conectadas com, para cada X existe um Y e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas complexos. Associaes Normais O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos. Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes

31

tambm podem possuir dois nomes, significando um nome para cada sentido da associao. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrita nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).

Cliente

Possui possudo

Conta Corrente

Figura 7 Duas classes se relacionando por associao normal

No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associao. Associao Recursiva possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe. Uma associao deste tipo chamada de associao recursiva.

Pessoa Esposa

Marido casado com

Figura 8 Exemplo de uma associao recursiva

32

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

Cliente

Cd_Conta Corrente

Conta Corrente

Figura 9 Representao de componentes

Associao Exclusiva Em alguns modelos nem todas as combinaes so vlidas, e isto pode causar problemas que devem ser tratados. Uma associao exclusiva uma restrio em duas ou mais associaes. Ela especifica que objetos de uma classe podem participar de no mximo uma das associaes em um dado momento. Uma associao exclusiva representada por uma linha tracejada entre as associaes que so partes da associao exclusiva, com a especificao {ou} sobre a linha tracejada.

Contrato

0 ..*

0 ..* 1 ..* Pessoa

{ou} 1 ..* Empresa

Figura 10 Exemplo de uma associao exclusiva

33

No diagrama acima um contrato no pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento exclusivo a somente uma das duas classes. Associao Ordenada As associaes entre objetos podem ter uma ordem implcita. O padro para uma associao desordenado (ou sem nenhuma ordem especfica). Mas uma ordem pode ser especificada atravs da associao ordenada. Este tipo de associao pode ser muito til em casos como este: janelas de um sistema tm que ser ordenadas na tela (uma est no topo, uma est no fundo e assim por diante). A associao ordenada pode ser escrita apenas colocando {ordenada} junto a linha de associao entre as duas classes. Associao de Classe Uma classe pode ser associada a uma outra associao. Este tipo de associao no conectado a nenhuma das extremidades da associao j existente, mas na prpria linha da associao. Esta associao serve para se adicionar informaes extra a associao j existente.

Cliente

Processo

Fila

Figura 11 Exemplo de uma associao de classes

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

Associao Ternria Mais de duas classes podem ser associadas entre si, a associao

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

Contrato

0 ..*

1 ..*

Cliente

1 ..* Regras Contratuais

Figura 12 Exemplo de uma associao ternria

No exemplo acima a associao ternria especifica que um cliente poder possuir 1 ou mais contratos e cada contrato ser composto de 1 ou vrias regras contratuais.

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

Marinha contm

Navios

Figura 13 Exemplo de uma agregao entre duas classes

35

Existem

tipos

especiais

de

agregao

que

so

as

agregaes

compartilhadas e as compostas. Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou est contida na outra, mas esta parte pode estar contida na outra vrias vezes em um mesmo momento.

Time

* Membros

Pessoa

Figura 14 Exemplo de uma agregao compartilhada

No exemplo acima uma pessoa pode ser membro de um time ou vrios times e em determinado momento. Agregao de Composio: uma agregao onde uma classe que est contida na outra vive e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de composio sero destrudas juntamente j que as mesmas fazem parte da outra.

* Janela * * *

Text ListBox Boto Menu

Figura 15 Exemplo de uma agregao de composio

Generalizaes

A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais particularidades. Um objeto mais

36

especfico pode ser usado como uma instncia do elemento mais geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados em outros. Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta. Generalizao Normal Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdados.

Conta Corrente

Poupana

Figura 16 Exemplo de uma generalizao normal

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes. A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalizao. Generalizao Restrita Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem as generalizaes restritas com mais de uma subclasse:

37

Generalizaes

de

Sobreposio

Disjuntiva:

Generalizao

de

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

Veculo

{sobreposio} Carro Barco

Anfbio

Figura 17 Exemplo de uma generalizao de sobreposio

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

38

Pessoa

{completa}

Homem

Mulher

Figura 18 Exemplo de uma generalizao completa

Dependncia e Refinamentos Alm das associaes e generalizaes, existem ainda dois tipos de relacionamentos em UML. O relacionamento de dependncia uma conexo semntica entre dois modelos de elementos, um independente e outro dependente. Uma mudana no elemento independente ir afetar o modelo dependente. Como no caso anterior com generalizaes, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante. Quando uma classe recebe um objeto de outra classe como parmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependncia entre estas duas classes, apesar de no ser explcita. Uma relao de dependncia simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de dependncia que existe entre as duas classes. As classes Amigas provenientes do C++ so um exemplo de um relacionamento de dependncia.

Classe A

<< friend >>

Classe B

Figura 19 Exemplo de uma dependncia entre classes

Os refinamentos so um tipo de relacionamento entre duas descries de uma mesma coisa, mas em nveis de abstrao diferentes, e podem ser usados para modelar diferentes implementaes de uma mesma coisa (uma implementao simples e outra mais complexa, mas tambm mais eficiente).

39

Os refinamentos so simbolizados por uma linha tracejada com um tringulo no final de um dos lados do relacionamento e so usados em modelos de coordenao. Em grandes projetos, todos os modelos que so feitos devem ser coordenados. Coordenao de modelos pode ser usada para mostrar modelos em diferentes nveis de abstrao que se relacionam e mostram tambm como modelos em diferentes fases de desenvolvimento se relacionam.

Classe de Anlise

Classe de Design

Figura 20 Exemplo de um refinamento

Mecanismos Gerais

A UML utiliza alguns mecanismos em seus diagramas para tratar informaes adicionais. Ornamentos: Ornamentos grficos so anexados aos modelos de elementos em diagramas e adicionam semnticas ao elemento. Um exemplo de um ornamento o da tcnica de separar um tipo de uma instncia. Quando um elemento representa um tipo, seu nome mostrado em negrito. Quando o mesmo elemento representa a instncia de um tipo, seu nome escrito sublinhado e pode significar tanto o nome da instncia quanto o nome do tipo. Outros ornamentos so os de especificao de multiplicidade de relacionamentos, onde a multiplicidade um nmero ou um intervalo que indica quantas instncias de um tipo conectado pode estar envolvido na relao. Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem importar o quanto extensa ela seja. Para permitir adicionar informaes a um modelo no poderia ser representado de outra forma, UML prov a

40

capacidade de adicionar Notas. Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informao.

Cliente

A classe Cliente manter um vetor com todos os clientes do banco

Figura 21 Exemplo de uma nota

41

Diagramas Os diagramas utilizados pela UML so compostos de nove tipos: diagrama de use case, de classes, de objeto, de estado, de seqncia, de colaborao, de atividade, de componente e o de execuo. Todos os sistemas possuem uma estrutura esttica e um comportamento dinmico. A UML suporta modelos estticos (estrutura esttica), dinmicos (comportamento dinmico) e funcional. A Modelagem esttica suportada pelo diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos podem ser de associaes, herana (generalizao), dependncia ou refinamentos. Os modelamentos dinmicos so suportados pelos diagramas de estado, seqncia, colaborao e atividade. E a modelagem funcional suportada pelos diagramas de componente e execuo. Abordaremos agora cada um destes tipos de diagrama:

Diagrama Use-Case

A modelagem de um diagrama use-case uma tcnica usada para descrever e definir os requisitos funcionais de um sistema. Eles so escritos em termos de atores externos, use-cases e o sistema modelado. Os atores representam o papel de uma entidade externa ao sistema como um usurio, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicao com o sistema atravs dos use-cases, onde o use-case representa uma seqncia de aes executadas pelo sistema e recebe do ator que lhe utiliza dados tangveis de um tipo ou formato j conhecido, e o valor de resposta da execuo de um use-case (contedo) tambm j de um tipo conhecido, tudo isso definido juntamente com o usecase atravs de texto de documentao.

42

Atores e use-cases so classes. Um ator conectado a um ou mais usecases atravs de associaes, e tanto atores quanto use-cases podem possuir relacionamentos de generalizao que definem um comportamento comum de herana em superclasses especializadas em subclasses. O uso de use-cases em colaboraes muito importante, onde estas so a descrio de um contexto, mostrando classes/objetos, seus relacionamentos e sua interao exemplificando como as classes/objetos interagem para executar uma atividade especfica no sistema. Uma colaborao descrita por diagramas de atividades e um diagrama de colaborao. Quando um use-case implementado, a responsabilidade de cada passo da execuo deve ser associada s classes que participam da colaborao, tipicamente especificando as operaes necessrias dentro destas classes juntamente com a definio de como elas iro interagir. Um cenrio uma instncia de um use-case, ou de uma colaborao, mostrando o caminho especfico de cada ao. Por isso, o cenrio um importante exemplo de um use-case ou de uma colaborao. Quando visto em nvel de um use-case, apenas a interao entre o ator externo e o use-case vista, mas j observando em nvel de uma colaborao, toda as interaes e passos da execuo que implementam o sistema sero descritos e especificados.

43

Abrir Conta corrente

Cadastrar Cliente

Remover ou Atualizar Cliente Cadastra Dependente

Fechar Conta corrente Cadastrar Operao (Histrico)

Abrir Poupana

Administrao do Banco

Remover ou Atualizar Operao (Histrico) Fechar Poupana Cadastrar Agncia Remover ou Atualizar Agncia

Figura 22 Diagrama de use-case

O diagrama de use-cases acima demonstra as funes de um ator externo de um sistema de controle bancrio de um banco fictcio que foi modelado no estudo de caso no final deste documento. O diagrama especifica que funes o administrador do banco poder desempenhar. Pode-se perceber que no existe nenhuma preocupao com a implementao de cada uma destas funes, j que este diagrama apenas se resume a determinar que funes devero ser suportadas pelo sistema modelado.

Diagrama de Classes

O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas representam as coisas" que so gerenciadas pela aplicao modelada. Classes podem se relacionar com outras atravs de diversas maneiras: associao (conectadas entre si), dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma especializao de outra classe), ou em pacotes (classes agrupadas por caractersticas similares). Todos estes relacionamentos so mostrados no

44

diagrama de classes juntamente com as suas estruturas internas, que so os atributos e operaes. O diagrama de classes considerado esttico j que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes que esto inseridas em um nico diagrama e uma certa classe pode participar de vrios diagramas de classes.

Cliente 1 0 ..* Contrato de Aluguel 0 ..1 0 ..* possui 1 Compahia de Aluguel de Veculos Caminho Carro Sport Carro de Passeio Tipos de Veculos refere a Veculo Alugado

possui

Figura 23 Diagrama de Classes Uma simples representao de uma empresa de aluguel de veculos.

Uma classe num diagrama pode ser diretamente implementada utilizandose uma linguagem de programao orientada a objetos que tenha suporte direto para construo de classes. Para criar um diagrama de classes, as classes tm que estar identificadas, descritas e relacionadas entre si.

Diagrama de Objetos

O diagrama de objetos uma variao do diagrama de classes e utiliza quase a mesma notao. A diferena que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos como se fosse o perfil do sistema em um certo momento de sua execuo. A mesma notao do diagrama de classes utilizada com 2 excees: os objetos so escritos com seus nomes sublinhados e todas as instncias num relacionamento so mostradas. Os diagramas de objetos no so to
45

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 as colaboraes dinmicas entre os objetos do sistema so mostradas.

Pablo: Cliente Nome : "Pablo F. Barros" Idade : 20 CPF : 94168912 -15

2678: Contrato de Aluguel Num_Contrato : 2678 Veculo : "BMW 914 "

2679 : Contrato de Aluguel Num_Contrato : 2679 Veculo : "Audi V8 "

Figura 24 Diagrama de Objetos A classe Cliente se relaciona de 1 para n com Contrato de Aluguel, por isso, um objeto da classe cliente pode ter 1 ou vrios contratos.

Diagrama de Estado

O diagrama de estado tipicamente um complemento para a descrio das classes. Este diagrama mostra todos os estados possveis que objetos de uma certa classe podem se encontrar e mostra tambm quais so os eventos do sistemas que provocam tais mudanas. Os diagramas de estado no so escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um nmero definido de estados conhecidos e onde o comportamento das classes afetado e modificado pelos diferentes estados. Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condies sendo satisfeitas) afetam estes estados ao passar do tempo.

46

No Trreo

subir (andar)

Subindo

Chegar no trreo Indo para o trreo

Chegar no andar

subir (andar)

Descendo

Chegar no andar

Parado

descer (andar)

tempo de espera

Figura 25 Diagrama de Estados Diagrama de estados de um elevador.

Diagramas de estado possuem um ponto de incio e vrios pontos de finalizao. Um ponto de incio (estado inicial) mostrado como um crculo todo preenchido, e um ponto de finalizao (estado final) mostrado como um crculo em volta de um outro crculo menor preenchido. Um estado mostrado como um retngulo com cantos arredondados. Entre os estados esto as transies, mostradas como uma linha com uma seta no final de um dos estados. A transio pode ser nomeada com o seu evento causador. Quando o evento acontece, a transio de um estado para outro executada ou disparada. Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um evento ligado a ela, a mesma ocorrer quando a ao interna do cdigo do estado for executada (se existir aes internas como entrar, sair, fazer ou outras aes definidas pelo desenvolvedor). Ento quando todas as aes forem executadas pelo estado, a transio ser disparada e sero iniciadas as atividades do prximo estado no diagrama de estados.

47

Diagrama de Seqncia

Um diagrama de seqncia mostra a colaborao dinmica entre os vrios objetos de um sistema. O mais importante aspecto deste diagrama que a partir dele percebe-se a seqncia de mensagens enviadas entre os objetos. Ele mostra a interao entre os objetos, alguma coisa que acontecer em um ponto especfico da execuo do sistema. O diagrama de seqncia consiste em um nmero de objetos mostrados em linhas verticais. O decorrer do tempo visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto so simbolizadas por setas entre os objetos que se relacionam. Diagramas de seqncia possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos na seqncia de uma certa atividade. Eles tambm mostram as interaes para um cenrio especfico de uma certa atividade do sistema. No eixo horizontal esto os objetos envolvidos na seqncia. Cada um representado por um retngulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de linha de vida do objeto, indicando a execuo do objeto durante a seqncia, como exemplo citamos: mensagens recebidas ou enviadas e ativao de objetos. A comunicao entre os objetos representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem sncrona, assncrona ou simples. As mensagens podem possuir tambm nmeros seqenciais, eles so utilizados para tornar mais explcito as seqncia no diagrama. Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execuo (thread). Se o sistema usa linhas concorrentes de controle, isto mostrado como ativao, mensagens assncronas, ou objetos assncronos.

48

: Computador

: Servidor de Impresso

: Impressora

: Fila

Imprimir (arquivo)

[Impressora Livre] Imprimir (arquivo)

[Impressora Ocupada] Imprimir (arquivo)

Figura 26 Diagrama de Sequencia Servidor de Impresso.

Os diagramas de seqncia podem mostrar objetos que so criados ou destrudos como parte do cenrio documentado pelo diagrama. Um objeto pode criar outros objetos atravs de mensagens. A mensagem que cria ou destri um objeto geralmente sncrona, representada por uma seta slida.

Diagrama de Colaborao

Um diagrama de colaborao mostra de maneira semelhante ao diagrama de seqncia, a colaborao dinmica entre os objetos. Normalmente pode-se escolher entre utilizar o diagrama de colaborao ou o diagrama de seqncia. No diagrama de colaborao, alm de mostrar a troca de mensagens entre os objetos, percebe-se tambm os objetos com os seus relacionamentos. A interao de mensagens mostrada em ambos os diagramas. Se a nfase do diagrama for o decorrer do tempo, melhor escolher o diagrama de seqncia, mas se a nfase for o contexto do sistema, melhor dar prioridade ao diagrama de colaborao. O diagrama de colaborao desenhado como um diagrama de objeto, onde os diversos objetos so mostrados juntamente com seus relacionamentos. As setas de mensagens so desenhadas entre os objetos

49

para mostrar o fluxo de mensagens entre eles. As mensagens so nomeadas, que entre outras coisas mostram a ordem em que as mensagens so enviadas. Tambm podem mostrar condies, interaes, valores de resposta, e etc. O diagrama de colaborao tambm pode conter objetos ativos, que executam paralelamente com outros.

: Computador
[Impressora Ocupada] 1 .2 : Armazenar (arq) 1 : Imprimir (arq)

: Fila

: Servidor de Impresso

[Impressora Livre] 1 .1 : Imprimir (arq)

: Impressora

Figura 27 Diagrama de Claborao Servidor de Impresso.

Diagrama de Atividade

Diagramas de atividade capturam aes e seus resultados. Eles focam o trabalho executado na implementao de uma operao (mtodo), e suas atividades numa instncia de um objeto. O diagrama de atividade uma variao do diagrama de estado e possui um propsito um pouco diferente do diagrama de estado, que o de capturar aes (trabalho e atividades que sero executados) e seus resultados em termos das mudanas de estados dos objetos. Os estados no diagrama de atividade mudam para um prximo estgio quando uma ao executada (sem ser necessrio especificar nenhum evento como no diagrama de estado). Outra diferena entre o diagrama de atividade e o de estado que podem ser colocadas como swimlanes. Uma swimlane agrupa atividades, com respeito a quem responsvel e onde estas atividades residem na organizao, e representada por retngulos que englobam todos os objetos que esto ligados a ela (swimlane).

50

Um diagrama de atividade uma maneira alternativa de se mostrar interaes, com a possibilidade de expressar como as aes so executadas, o que elas fazem (mudanas dos estados dos objetos), quando elas so executadas (seqncia das aes), e onde elas acontecem (swimlanes). Um diagrama de atividade pode ser usado com diferentes propsitos inclusive: Para capturar os trabalhos que sero executados quando uma operao disparada (aes). Este o uso mais comum para o diagrama de atividade. Para capturar o trabalho interno em um objeto. Para mostrar como um grupo de aes relacionadas pode ser executado, e como elas vo afetar os objetos em torno delas. Para mostrar como uma instncia pode ser executada em termos de aes e objetos. Para mostrar como um negcio funciona em termos de trabalhadores (atores), fluxos de trabalho, organizao, e objetos (fatores fsicos e intelectuais usados no negcio). O diagrama de atividade mostra o fluxo seqencial das atividades, normalmente utilizado para demonstrar as atividades executadas por uma operao especfica do sistema. Consistem em estados de ao, que contm a especificao de uma atividade a ser desempenhada por uma operao do sistema. Decises e condies, como execuo paralela, tambm podem ser mostradas na diagrama de atividade. O diagrama tambm pode conter especificaes de mensagens enviadas e recebidas como partes de aes executadas.

51

[Disco Cheio] ImprimirArquivo()

Mostrar Caixa de Mensagem Disco Cheio

[Espao em disco]

Mostrar Caixa de Mensagem Imprimindo

Remover Caixa de Mensagem

^Impressora.Imprimir(arq)

Criar arquivo PostScript

Figura 28 Diagrama de Atividade Servidor de Impresso.

Diagrama de Componente

O diagrama de componente e o de execuo so diagramas que mostram o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante sua execuo. O diagrama de componente descreve os componentes de software e suas dependncias entre si, representando a estrutura do cdigo gerado. Os componentes so a implementao na arquitetura fsica dos conceitos e da funcionalidade definidos na arquitetura lgica (classes, objetos e seus relacionamentos). Eles so tipicamente os arquivos implementados no ambiente de desenvolvimento. Um componente mostrado em UML como um retngulo com uma elipse e dois retngulos menores do seu lado esquerdo. O nome do componente escrito abaixo ou dentro de seu smbolo. Componentes so tipos, mas apenas componentes executveis podem ter instncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instncias de componentes, deve ser usado um diagrama de execuo, onde as instncias executveis so alocadas em nodes.
52

A dependncia entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definio completa. Com o diagrama de componentes facilmente visvel detectar que arquivos .dll so necessrios para executar a aplicao.

Gerenciador de Comunicao Comm.dll

Grficos Graficos.dll

Gerenciador de Banco de Dados Db.dll

Aplicao App.exel

Figura 29 Diagrama de Componentes.

Componentes podem definir interfaces que so visveis para outros componentes. As interfaces podem ser tanto definidas ao nvel de codificao (como em Java) quanto em interfaces binrias usadas em run-time (como em OLE). Uma interface mostrada como uma linha partindo do componente e com um crculo na outra extremidade. O nome colocado junto do crculo no final da linha. Dependncias entre componentes podem ento apontar para a interface do componente que est sendo usada.

Diagrama de Execuo

O diagrama de execuo mostra a arquitetura fsica do hardware e do software no sistema. Pode mostrar os atuais computadores e perifricos, juntamente com as conexes que eles estabelecem entre si e pode mostrar tambm os tipos de conexes entre esses computadores e perifricos. Especificam-se tambm os componentes executveis e objetos que so
53

alocados para mostrar quais unidades de software so executados e em que destes computadores so executados. O diagrama de execuo demonstra a arquitetura run-time de

processadores, componentes fsicos (devices), e de software que rodam no ambiente onde o sistema desenvolvido ser utilizado. a ltima descrio fsica da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade. O diagrama de execuo composto por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos fsicos que fazem parte do sistema, podendo ser uma mquina cliente numa LAN, uma mquina servidora, uma impressora, um roteador, etc., e conexes entre estes nodes e componentes que juntos compem toda a arquitetura fsica do sistema.

ClienteA : Pentium 200 MMX

<<TCP/IP>> Servidor de Aplicao : HP/UX SQL <<TCP/IP>> Servidor de Banco de Dados : ORACLE

ClienteB : Pentium 200 MMX

<<TCP/IP>>

Figura 30 Diagrama de Execuo Associaes entre Nodes.

54

Um processo para utilizar a UML A UML contm notaes e regras que tornam possvel expressar modelos orientados a objetos. Mas ela no prescreve como o trabalho tem que ser feito, ou seja, no possui um processo de como o trabalho tem que ser desenvolvido. J que a UML foi desenvolvida para ser usada em diversos mtodos de desenvolvimento. Para usar a UML com sucesso necessrio adotar algum tipo de mtodo de desenvolvimento, especialmente em sistema de grande porte onde a organizao de tarefas essencial. A utilizao de um processo de desenvolvimento torna mais eficiente calcular o progresso do projeto, controlar e melhorar o trabalho. Um processo de desenvolvimento descreve o que fazer, como fazer, quando fazer, e porque deve ser feito. Este tambm descreve um nmero de atividades que devem ser executadas em uma certa ordem. Quando so definidas e relacionadas as atividades de um processo, um objetivo especfico alcanado. Em seu uso normal, a palavra processo significa uma relao de atividades que devem ser executadas em uma certa ordem sem importar o objetivo, regras ou material a ser usado. No processo de desenvolvimento da engenharia de software, necessrio saber o objetivo final do processo, definir regras a serem seguidas e adotar um mtodo fixo de desenvolvimento. Um mtodo (processo) tradicional de desenvolvimento orientado a objetos dividido em anlise de requisitos, anlise, design (projeto), implementao, e testes. A anlise de requisitos captura as necessidades bsicas funcionais e no-funcionais do sistema que deve ser desenvolvido. A anlise modela o problema principal (classes, objetos) e cria um modelo ideal do sistema sem levar em conta requisitos tcnicos do sistema. O design expande e adapta os modelos da anlise para um ambiente tcnico, onde as solues tcnicas so
55

trabalhadas em detalhes. A implementao consiste em codificar em linguagem de programao e banco de dados os modelos criados. E as atividades de testes devem testar o sistema em diferentes nveis, verificando se o mesmo corresponde as expectativas do usurio. Existe um processo desenvolvido pela Rational Inc., mesma empresa que desenvolveu a UML, que monta duas vises do desenvolvimento de um sistema: viso gerencial e tcnica. A viso tcnica utiliza as tradicionais atividades de anlise, design e implementao, enquanto a viso gerencial utiliza as seguintes fases no desenvolvimento de cada gerao do sistema. Incio: Define o escopo e objetivo do projeto; Elaborao: Desenvolve o produto em detalhes atravs de uma srie de interaes. Isto envolve mais anlise, design e programao; Transio: Gera o sistema para o usurio final, incluindo as atividades de marketing, suporte, documentao e treinamento. Cada fase no ciclo executada em sries de interaes que podem sobrepor outras fases. Cada interao consiste tipicamente em atividades tradicionais como anlise e design, mas em diferentes propores dependendo da fase em que esteja a gerao do sistema em desenvolvimento. Ferramentas modernas devem dar suporte no apenas para linguagens de modelagem e programao, mas devem suportar um mtodo de desenvolvimento de sistemas tambm. Isso inclui conhecimento das fases em um processo, ajuda online, e aconselhamentos do que fazer em cada fase do desenvolvimento, suporte a desenvolvimento interativo e fcil integrao com outras ferramentas.

56

O Futuro da UML Embora a UML defina uma linguagem precisa, ela no uma barreira para futuros aperfeioamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em tcnicas antigas e marcantes da orientao a objetos, mas muitas outras influenciaro a linguagem em suas prximas verses. Muitas tcnicas avanadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessrio redefinir a sua estrutura interna. A UML ser a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulaes e ambientes de desenvolvimento. Em breve ferramentas de integrao e padres de implementao baseados em UML estaro disponveis para qualquer um. A UML integrou muitas idias adversas, e esta integrao vai acelerar o uso do desenvolvimento de softwares orientados a objetos.

57

Um estudo de caso em UML Diante do apresentado no decorrer do documento, aplicaremos aqui grande parte dos conceitos abordados diante de uma aplicao da UML num problema fictcio que poder ser de grande ajuda no melhor entendimento das potencialidades da linguagem de modelagem unificada. O estudo de caso dar mais nfase nas fases de anlise de requisitos, anlise e design, j que as principais abstraes dos modelos do sistema se encontram nestas fases do desenvolvimento. Desenvolveremos uma modelagem em UML para criarmos um sistema de manuteno e controle de contas correntes e aplicaes financeiras de um banco fictcio. Antes de dar incio primeira fase da modelagem, faremos algumas consideraes sobre o que o sistema se prope a fazer e outras observaes que consideramos de suma importncia para o bom entendimento do problema. O sistema suportar um cadastro de clientes, onde cada cliente cadastrado poder ter vrias contas correntes, ter vrios dependentes ligados a ele, e vrias contas de poupana. Cada dependente poder possuir vrias contas de poupana, mas no podero ter uma conta corrente prpria. Entendemos poupana como uma conta que possui um valor, um prazo de aplicao a uma taxa de juros (definida no vencimento da poupana). Entendemos Aplicaes Pr-fixadas como uma aplicao de um valor, em um prazo pr-determinado a uma taxa de juros previamente definida.

58

 Tanto a conta corrente quanto a poupana dever manter um histrico de todas as movimentaes de crdito, dbito, transferncias e aplicaes de pr-fixados (pr-fixados apenas para conta corrente). Uma conta corrente poder ter vrias aplicaes pr-fixadas ligadas a ela.

Anlise de Requisitos De acordo com nossa proposta o sistema implementar funes bsicas que sero desempenhadas pela Administrao do banco e pelos seus clientes. As principais funes do sistema so: Cadastrar novo cliente Excluir ou editar cliente Cadastrar dependente Excluir ou editar dependente Abrir conta corrente Fechar conta corrente Abrir poupana Fechar poupana Movimentar conta corrente Aplicar em pr-fixados

59

Consultar histrico de conta corrente ou poupana Cadastrar Agncia Excluir ou Editar Agncia Tendo em mos esta relao de atividades, j podemos modelar o

diagrama de use-case do sistema.

60

Abrir Conta corrente

Cadastrar Cliente

Remover ou Atualizar Cliente Cadastra Dependente

Fechar Conta corrente Cadastrar Operao (Histrico)

Abrir Poupana

Administrao do Banco

Remover ou Atualizar Operao (Histrico) Fechar Poupana Cadastrar Agncia Remover ou Atualizar Agncia <<uses>>

Movimentar Conta corrente Consulta Historico de Conta Corrente

Gerar Histrico

Cliente
(from Logical View)

Aplicar em Pre Fixados

Figura 31 Diagrama de use-case Fase de Anlise de Requisitos.

Anlise

Na fase de anlise, tendo em mos o diagrama de use-case, podemos definir o diagrama de classes do sistema. Este primeiro diagrama da fase de anlise dever ser totalmente despreocupado de qualquer tipo de tcnica relacionada a implementao do sistema, ou seja, mtodos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc. no devero aparecer nesse primeiro diagrama, apenas os tipos de objetos bsicos do sistema.

61

Analisamos e percebemos que existiro 8 classes no sistema e que se relacionaro segundo o diagrama de classes a seguir.

Agncia Cod_Agencia : String Nome_Agncia : String Criar() Destruir() Possui 1 * Possui

Historico Data : Date Operao : Operao Valor : Num Criar() Destruir() 1 * * Possui 1 Operao Cod_Operacao : String Desc_Operao : String Criar() Destruir() 0 Aplicaes Pr Fixadas Valor : Num Data_Venc : date Possui Taxa : Num Criar() Destruir() *

Conta Corrente Cod : String Saldo : Num Vetor_Aplic_PreFix : Aplic_Pre_Fixadas Vetor Historico : Historico Agncia : Agncia Depositar() Debitar() Transferir() Obter_Saldo() Aplicar_Prefix() Criar() Destruir() Tirar_Extrato() Rerirar_Aplic_Prefix() * Possui

Cliente Nome : String CPF : String Rua : String Fone : String Bairro : String Cidade : String CEP : String Estado : String Vetor Dependentes : Dependentes 1 Vetor Conta_Correntes : Conta_Corrente Vetor Poupanas : Poupana Criar() Destruir() Localizar() Abrir_Conta_Corrente() Remover_Conta_Corrente() Adic_Dependente() Excluir_Dependente() Abrir_Poupana() Fechar_Poupana()

Poupana Data_Venc : Date Criar() Destruir() * Possui 1 *

Possui

Dependente Nome : String CPF : Num Parentesco : String Vetor Poupanas : Poupana Criar() Destruir() Localizar() Abrir_Poupana() Fechar_Poupana()

Possui 1 *

Figura 32 Diagrama de Classes Fase de Anlise.

62

J temos em mos as funes primordiais do sistema (diagrama de usecases) e o diagrama de classes da anlise do domnio do problema, partiremos agora para traar como estas classes iro interagir para realizar as funes do sistema. Lembramos que, ainda nesta fase nenhum tipo de tcnica de implementao deve ser considerada. Para modelarmos como os objetos do sistema iro interagir entre si, utilizamos o diagrama de seqncia ou o de colaborao. E modelaremos um diagrama para cada funo (use-case) definida no diagrama de use-cases. Escolhemos o diagrama de seqncia para dar mais nfase a ordem cronolgica das interaes entre os objetos. J se faz necessrio utilizar idias bsicas da modelagem da interface do sistema como as janelas. Mas esses objetos de interface sero totalmente detalhados na fase de design.

Administrao do banco

: Janela Abrir Conta Corrente

: Cliente

:Conta Corrente

: Histrico

1 : Dados do Cliente()

2 : $localizar (String)

3: Create (Cliente) 4 : Create(Data)

Figura 33 Diagrama de Sequncia Fase de Anlise.

Nesta fase modela-se tambm o diagrama de estado das classes. Mas este se enquadra em situaes onde o comportamento dos objetos importante para aplicao. Em casos de modelagens de sistemas para equipamentos mecnicos.

63

Design

Nesta fase comearemos a implementar em nossos modelos os melhoramentos e tcnicas de como realmente cada funo do sistema ser concebida. Sero modelos mais detalhados com nfase nas solues para armazenamento dos dados, funes primordiais do sistema e interface com o usurio. A fase de design pode ser dividida em outras duas fases: Design da arquitetura: Este o design de alto nvel onde os pacotes (subsistemas) so definidos, incluindo as dependncias e mecanismos de comunicao entre eles. Naturalmente, o objetivo criar uma arquitetura simples e clara, onde as dependncias sejam poucas e que possam ser bidirecionais sempre que possvel. Design detalhado: Esta parte detalha o contedo dos pacotes, ento todas classes sero totalmente descritas para mostrar especificaes claras para o programador que ir gerar o cdigo da classe. Modelos dinmicos do UML so usados para demonstrar como os objetos se comportam em diferentes situaes. Design da arquitetura Uma arquitetura bem projetada a base para futuras expanses e modificaes no sistema. Os pacotes podem ser responsveis por funes lgicas ou tcnicas do sistema. de vital importncia separar a lgica da aplicao da lgica tcnica. Isso facilitar muito futuras mudanas no sistema.

64

Em nosso caso de estudo, identificamos 4 pacotes (subsistemas):

Interface do Usurio

Objetos do Sistema

Utilidades

Banco de Dados

Figura 34 Fase de Design Definio dos Pacotes.

Pacote da Interface do Usurio: Estaro contidas as classes para a criao da interface do usurio, para possibilitar que estes acessem e entrem com novos dados no sistema. Estas classes so baseadas no pacote Java AWT, que o padro Java para criao de interfaces. Este pacote coopera com o pacote de objetos do sistema, que contm as classes onde os dados esto guardados. O pacote de interface chama operaes no pacote de objetos do sistema para acessar e inserir novos dados. Pacote de Objetos do Sistema: Este pacote inclui classes bsicas, ou seja, classes que foram desenvolvidas exatamente para tornar o sistema em desenvolvimento funcional. Estas classes so detalhadas no design, ento so includos operaes e mtodos em sua estrutura e o suporte Persistncia adicionado. O pacote de objetos deve interagir com o de banco de dados e todas as suas classes devem herdar da classe Persistente do pacote de banco de dados

65

Pacote de Banco de Dados: Este pacote disponibiliza servios para as classes do pacote de objetos fazendo com que os dados armazenados no sistema sejam gravados em disco.

Pacote de Utilidades: Este contm servios que so usados por todos os outros pacotes do sistema. Atualmente a classe ObjId a nica no pacote, e usada para referenciar os objetos persistentes em todo o sistema. Design detalhado O propsito do design detalhado descrever as novas classes tcnicas do

sistema, como classes de criao da interface, de banco de dados e para expandir e detalhar a descrio das classes de objetos, que j foram definidas na fase de anlise. Tudo isto feito com a criao de novos diagramas de classes, de estado, e dinmicos. Sero os mesmos diagramas criados na fase de anlise, mas um nvel de detalhamento tcnico mais elevado. As descries de use-cases provenientes da fase de anlise so usadas para verificar se estes esto sendo suportados pelos diagramas gerados na fase de design, e diagramas de seqncia so usados para ilustrar como cada use-case tecnicamente implementada no sistema. Chegamos a um diagrama de classes mais evoludo com a incluso de persistncia.

66

Agncia Cod_Agencia : String Nome_Agncia : String Agencia() Atualizar_Dados() Gravar() Ler() 1 * Conta Corrente Cod : String Saldo : Num Aplic_PreFix : ObjId[ ] 1 Historico : ObjId[ ] Agncia : ObjId Depositar() Debitar() Transferir() Obter_Saldo() Aplicar_Prefix() Conta_Corrente() Tirar_Extrato() Rerirar_Aplic_Prefix() Localizar() Gravar() Ler() 0 * Aplicaes Pr Fixadas Valor : Num Data_Venc : date Taxa : Num Aplicaes_Pre_Fixadas() Gravar() Ler()

Historico Data : Date Operao : ObjId [ ] * Valor : Num Criar() Destruir() *

Operao 1 Cod_Operacao : String Desc_Operao : String Operacao() Atualizar_Dados() Gravar() Ler() Dependente

Persistente objid : int $ iter : RandomAccessFile Persistent() GetObjId() GetObject() Armazenar() Apagar() abstract Atualizar_Dados() abstract Gravar() abstract Ler()

Nome : String CPF : Num Parentesco : String Poupanas : ObjId [ ] Dependentes() Localizar() Abrir_Poupana() Fechar_Poupana() 1 Atualizar_Dados() Gravar() Ler() *

* * Poupana Data_Venc : Date Popanca() *

1 Cliente Nome : String CPF : String Rua : String Fone : String Bairro : String Cidade : String CEP : String 1 Estado : String Dependentes : ObjId [ ] Conta_Correntes : ObjId [ ] 1 Poupanas : ObjId [ ] Cliente() Gravar() Ler() Localizar() Abrir_Conta_Corrente() Remover_Conta_Corrente() Adic_Dependente() Excluir_Dependente() Abrir_Poupana() Fechar_Poupana() Atualizar_Dados()

Figura 35 Diagrama de Classes Fase de Design

67

Criamos os diagramas de seqncia para funes do sistema, descritas no diagrama de use-cases, j possuindo os parmetros para cada mensagem entre os objetos. O layout das janelas deve ser criado com alguma ferramenta visual de acordo com a preferncia do desenvolvedor. Ferramentas visuais j geram o cdigo necessrio para a criao de janelas. Algumas ferramentas j suportam a adio de controladores de eventos para eventos disparados por usurios como cliques em botes. O ambiente gera um mtodo okbutton_Clicked que ser chamado quando o boto OK for pressionado. A aplicao resultante da interface de usurio uma janela principal com um menu de opes. Cada opo escolhida do menu mostrar uma janela nova que juntas sero responsveis por receber as informaes do usurio e executar a funo a qual se propem a fazer.

Implementao

A fase de construo ou implementao quando as classes so codificadas. Os requisitos especificam que o sistema deve ser capaz de rodar em diversos tipos de processadores e sistemas operacionais, ento a linguagem escolhida foi Java. Pelo fato de em Java cada arquivo poder conter uma e somente uma classe, podemos facilmente escrever um diagrama de componentes contendo um mapeamento das classes provenientes da viso lgica. Agora codificamos cada classe do pacote de objetos do sistema, a interface, o banco de dados e o pacote de utilidades. A codificao deve ser baseada nos modelos desenvolvidos nas fases de anlise de requisitos, anlise e design, mais precisamente nas especificaes de classes, diagramas de classes, de estado, dinmicos, de use-cases e especificao.

68

Existiro algumas deficincias durante a fase de codificao. As necessidades da criao de novas operaes e modificaes em operaes j existentes sero identificadas, significando que o desenvolvedor ter que mudar seus modelos da fase de design. Isto ocorre em todos os projetos. O que mais importante que sejam sincronizadas a modelagem de design com a codificao, desta forma os modelos podero ser usados como documentao final do sistema.

Testes

A aplicao dever ser testada. Deve-se verificar se o programa suporta toda a funcionalidade que lhe foi especificada na fase de anlise de requisitos com o diagrama de use-cases. A aplicao deve ser tambm testada da forma mais informal colocando-se o sistema nas mos dos usurios.

69

Concluso A criao de uma linguagem para a comunidade de desenvolvedores em orientao a objetos era uma necessidade antiga. A UML realmente incorporou muitos recursos com do a linguagem uma extensibilidade muito grande. A organizao da modelagem em vises e a diviso dos diagramas especificando caractersticas estticas e dinmicas do sistema tornou a UML fcil de ser utilizada e fez com que qualquer tipo de comportamento possa ser visualizado em diagramas. A modelagem visual orientada a objetos agora possui um padro, e esse padro extremamente simples de ser escrito a mo, sendo robusto para especificar e descrever a grande maioria das funes, relacionamentos e tcnicas de desenvolvimento orientado a objetos que hoje so utilizados. Novas tcnicas iro surgir e a UML tambm estar preparada j que tudo estar baseado nas idias elementares da orientao a objetos. Sem dvida alguma a UML facilitar s grandes empresas de desenvolvimento de software uma maior comunicao e aproveitamento dos modelos desenvolvidos pelos seus vrios analistas envolvidos no processo de produo de software j que a linguagem que ser utilizada por todos ser a mesma, acabando assim com qualquer problema de interpretao e malentendimento de modelos criados por outros desenvolvedores. Os modelos criados hoje podero ser facilmente analisados por futuras geraes de desenvolvedores acabando com a diversidade de tipos de nomenclaturas de modelos, o grande empecilho do desenvolvimento de softwares orientados a objetos. Os fabricantes de ferramentas CASE agora suportaro a UML em seus softwares e a fase de codificao ser cada vez mais substituda pela gerao de cdigo automtico desempenhada pelas ferramentas CASE.

70

Bibliografia ERIKSSON, Hans-Erik & PENKER, Magnus. UML Toolkit. Editora Wiley, 1998. PRESSMAN, Roger. Engenharia de Software.3 ed. Editora McGrawHill, 1995. COAD, Peter & YOURDON, Edward. Anlise baseada em Objetos. 2 ed. Editora Campus, 1992. Documentao oficial da UML. Disponvel na Internet no endereo: http://www.rarional.com/uml

71