Escolar Documentos
Profissional Documentos
Cultura Documentos
Apostila Uml PDF
Apostila Uml PDF
Introduo
2. Desenvolvimento de Softwares orientado a objetos
3. UML A unificao dos mtodos para a criao de um novo padro
4. Uso da UML
5. Fases do Desenvolvimento de um Sistema em UML
1. Anlise de Requisitos
2. Anlise
3. Design (Projeto)
4. Programao
5. Testes
6. A Notao da Linguagem de Modelagem Unificada UML
7. Vises
8. Modelos de Elementos
1. Classes
2. Objetos
3. Estados
4. Pacotes
5. Componentes
6. Relacionamentos
7. Mecanismos Gerais
9. Diagramas
1. Diagrama Use-Case
2. Diagrama de Classes
3. Diagrama de Objetos
4. Diagrama de Estado
5. Diagrama de Sequncia
6. Diagrama de Colaborao
7. Diagrama de Atividade
8. Diagrama de Componente
2
9. Diagrama de Execuo
10. Um processo para utilizar a UML
11. O Futuro da UML
12. Um estudo de caso em UML - Sistema de Controle de Contas Correntes,
Poupana e Aplicaes Pr-fixadas
1. Anlise de Requisitos
2. Anlise
3. Design
4. Implementao
5. Testes
13. Concluso
1. Introduo
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.
UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so
conhecidos como "os trs amigos". Eles possuem uma extenso conhecimento na rea de
modelagem orientado a objetos j que as trs mais conceituadas metodologias de modelagem
orientado 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 trabalho.
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.
Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram
em suas publicaes foram que:
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.
Falaremos sobre algumas das principais metodologias que se tornaram populares nos anos 90:
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.
Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm
executveis;
Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina.
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 extensivamente testados
provenientes das metodologias existentes anteriormente, e tambm muito bem documentada
com toda a especificao da semntica da linguagem representada em meta-modelos
4. 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.
importante perceber que a maioria dos sistemas no possuem 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.
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". O diagrama de "use-cases"
mostrar o que os atores externos, ou seja, os usurios do futuro sistema devero esperar do
aplicativo, conhecendo toda sua funcionalidade sem importar como esta ser implementada. A
anlise de requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no
apenas para sistemas de software.
5.2. Anlise
5.4. Programao
5.5. Testes
O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto
realmente de acordo com as intenes do usurio final.
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.
10
7. 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:
11
8. Modelos de Elementos
8.1. Classes
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.
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:
12
Existem sistemas externos ao modelado? Se existir, eles devero ser vistos como
classes pelo sistema para que possa interagir com outros externos.
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.
8.2. Objetos
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.
13
8.3. 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 objetos de acordo
com os eventos que o mesmo possa sofrer.
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 listadas. 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 executa antes de passar para o prximo estado e o evento fazer define as
atividades do objeto enquanto se encontra naquele estado.
8.4. Pacotes
14
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.
8.5. Componentes
15
8.6. Relacionamentos
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.
8.6.1 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 tambm podem possuir dois nomes,
significando um nome para cada sentido da associao.
16
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.
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.
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 parte da associao exclusiva, com a especificao "{ou}" sobre
a linha tracejada.
17
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
desordenada (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
conectada 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.
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.
Associao Ternria
18
Mais de duas classes podem ser associadas entre si, a associao ternria associa trs
classes. Ela mostrada como um 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.
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".
Agregao Compartilhada: dita compartilhada quando uma das classes uma parte,
ou est contida na outra, mas esta parte pode fazer estar contida na outra vrias vezes
em um mesmo momento.
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.
19
8.6.2. Generalizaes
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
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 coloca-se um seta no lado da linha onde encontra-se 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:
20
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.
21
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.
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.
A UML utiliza alguns mecanismos em seus diagramas para tratar informaes adicionais.
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 capacidade de adicionar Notas. Uma
Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer
tipo de informao.
22
9. Diagramas
Os diagramas utilizados pela UML so compostos de nove tipos: diagrama de use case, de
classes, de objeto, de estado, de sequncia, de colaborao, de atividade, de componente e o
de execuo.
23
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 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 classes pode
participar de vrios diagramas de classes.
24
Uma classe num diagrama pode ser diretamente implementada utilizando-se 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.
25
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.
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.
26
Diagramas de sequncia possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo
horizontal, que mostra os objetos envolvidos na sequncia de uma certa atividade. Eles
tambm mostram as interaes para um cenrio especfico de uma certa atividade do sistema.
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.
Os diagramas de sequncia 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 destroi um objeto geralmente sncrona, representada
por uma seta slida.
27
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.
Para capturar os trabalhos que sero executados quando uma operao disparada
(aes). Este o uso mais comum para o diagrama de atividade.
Para mostrar como um grupo de aes relacionadas podem ser executadas, e como
elas vo afetar os objetos em torno delas.
Para mostrar como uma instncia pode ser executada em termos de aes e objetos.
28
O diagrama de atividade mostra o fluxo sequencial 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
mostrados na diagrama de atividade. O diagrama tambm pode conter especificaes de
mensagens enviadas e recebidas como partes de aes executadas.
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.
29
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.
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.
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.
30
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.
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.
31
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.
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.
Diante do apresentado no decorrer do trabalho, 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 na fases de anlise de requisitos, anlise e design, j que
as principais abstraes dos modelos do sistema se encontram nestas fases do
desenvolvimento.
32
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, 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).
Uma conta corrente poder ter vrias aplicaes pr-fixadas ligadas a ela.
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 dependente
Abrir poupana
Fechar poupana
Aplicar em pr-fixados
33
Cadastrar Agncia
34
12.2. Anlise
35
36
Para modelarmos como os objetos do sistema iro interagir entre si, utilizamos o diagrama de
sequncia ou o de colaborao. E modelaremos um diagrama para cada funo (use-case)
definida no diagrama de use-cases. Escolhemos o diagrama de sequncia 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.
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.
12.3. Design
Design detalhado: Esta parte detalha o contedo dos pacotes, ento todas classes
sero totalmente descritas para mostrar especificaes claras para o programador que
37
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.
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
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.
38
Design detalhado
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.
39
Criamos os diagramas de sequencia para funes do sistema, descritas no diagrama de usecases, j possuindo os parmetros para cada mensagem entre os objetos.
40
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.
12.4. Implementao
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.
12.5. 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.
13. Concluso
41
42