casos de uso

7/21/2019 casos de uso

http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 1/21

Fundamentei

c j e _ U M L

futuro. Assim, consegue-se reforçar a rentabilidade do s

d

significativos investimentos realizados no desenvolvimento do|sistemas e alargar o seu tempo de vida útil.

Complementarmente, a MDA procura contribuir para reforçar ograu de eficiência do processo de desenvolvimento, ao nível daautomatização da tarefa de geração de código, definindoorientações que podem ser adoptadas por ferramentas integradas dedesenvolvimento.

A MDA constitui um contributo concreto para a resolução de umconjunto fundamental de problemas, que desde sempre tempreocupado toda a comunidade que se dedica ao desenvolvimentode sistemas de informação: que o desenvolvimento seja eficiente,permitindo a redução de custos e o cumprimento de prazos; que o

processo seja cada vez mais eficaz, assegurando que ascaracterísticas dos sistemas reflectem os requisitos colocados pelosseus utilizadores; que os sistemas sejam construídos de formaflexível para poderem incorporar as alterações que a evolução iránaturalmente impor, quer no contexto da organização quer no datecnologia;

Estes têm sido temas recorrentes ao longo da curta história dossistemas de informação, todavia reforçado pelo facto de o ritmo damudança tecnológica e organizacional ser contínuo e cada vez maisacentuado.

Integrada no contexto de evolução da modelação visual orientadapor objectos, que inclui a UML e o Processo de ModelaçãoUnificado, a MDA representa o mais recente contributo pararesponder aos desafios que se colocam ao desenvolvimento desistemas de informação. Igualmente promissora, a MDA deve seracompanhada com particular atenção.

Casos de Estudos

Neste capítulo apresentamos dois casos de estudo. Com o casoPhonePizza, procuramos sistematizar de fornia integrada osdiversos exemplos que foram sendo apresentados ao longo do livro.O caso S lUniversitas surge num domínio de aplicação reconhecidopor grande parte dos leitores a quem esta obra se destina, o quesimplifica a compreensão do problema, facilita a identificação denovos requisitos e permite a exploração de soluções alternativas.

Os diagramas que se apresentam são simplificados. Não foram

explorados todos os aspectos que seriam requeridos para odesenvolvimento completo destes sistemas de informação, queapresentam um razoável nível de complexidade. O grau de detalheapresentado tem apenas em consideração os objectivos de naturezapedagógica que se pretendem atingir, estando sujeitos ao formatoda publicação que limita a representação de diagramas maisabrangentes.

Devemos realçar que este capítulo apresenta uma proposta deresolução possível para os problemas enunciados. Outras soluçõesalternativas são igualmente válidas. Os diagramas apresentados sãoainda passíveis de serem refinados através de sucessivas iterações.

iO.l

Considere que se pretende desenvolver um sistema de informaçãoque tem como objectivo apoiar a gestão de encomendas de umgrupo de pizzarias, a PhonePizza. Este sistema irá prestar serviçosde atendimento, acompanhamento de clientes e encomendas. Para

tal o grupo PhonePizza decidiu constituir uma equipa dentro do seu

154



Fundamental de UM L Tdepartamento de sistemas de informação para concretizar

projecto.

10.1.1 Modelo Negócio

A nova organização da PhonePizza será constituída por 4 unidadesorganizativas: Central, Centro de Chamadas, Internet e Pizzaria.

Na figura 10.1

utiliza-se um diagrama de objectos para representaresta estrutura organizacional.

Unidade Central Unidade Internet Centro de Chamadas Pizzaria

F I G U R A 10,1

-

E S T R U T U R A Q R G A N IZ A T IV A

D A P H O N E P I Z Z A

Unidade Central

Esta unidade é responsável pelo controlo de gestão da PhonePizza,recebendo regularmente os dados (encomendas) gerados pelasrestantes unidades.

Unidade Internet

Disponibiliza serviços de encomenda e consulta de produtos pela.Internet. Para encomendar, os clientes efectuam um

pré-registo|

onde indicam alguns dados pessoais.

Centro de Chamadas

Disponibiliza serviços de encomenda e consulta de produtos pelí

telefone.

Casos de Estudo

pizzaria

Efectua o atendimento ao público e satisfaz as encomendasrecebidas localmente, pela Internet ou pelo telefone.

Uma pizzaria é composta pelas seguintes áreas: Sala Restaurante(onde estão as mesas), Balcão, Entregas, Cozinha e Armazém. Umrestaurante possui um número variável de mesas numeradas que sepodem encontrar num dos seguintes estados: LIVRE, OCUPADA,INDISPONÍVEL.

As mesas podem ser reservadas por vários clientes, sendo a reservareferenciada por um número e data. Um cliente pode reservarvárias mesas.

Os funcionários distribuem-se pelas seguintes categorias: Gestor deLoja, Empregado de Mesa, Empregado de Balcão, Gestor deEncomendas e Estafeta. Todos os empregados são identificados porum número e podem trabalhar em várias lojas, sendo importantesaber a data e a duração do contrato de trabalho em cada uma daslojas.

As diversas pizzarias/lojas do grupo são caracterizadas através deum código, nome, descrição e zona de influência.

Catálogo de ProdutosO catálogo consiste numa listagem de produtos por código, nome,descrição e preço. O catálogo contém também as promoções domês.

f

-E

O

D

eN

M

C

__Códigp

0001

0002

[ Õ õ p s

NomePizza Marguerita

Pizza Barbeque

Mexicana

DescriçãoPizza Base

Pizza Base + MolhoBarbeque + Mozzarella +Frango + BaconPizza Base + Molho

Preço3 € P )

4,8 € (M)6 € F )

3,75 € (P)5,5 € (M)7 € F )

3,75 € (P)

156 15Z



Fundamental de UM L T0004

0005

0006

Tropical

Pizza Composta

Ingrediente

Mexicano + M ozzarella +Carne + CebolaPizza Base + Ananás +Extra Queijo + Fiambre

Pizza Base + Ingredientes àescolha

Preço único, variandoapenas no tamanho dapizza.

5,5 € (M)7€(F)

4 € P )

6 € M )

7,5 € (F)Preço da PizzaBase mais preço

ingredientes.0,5 € (P)0,75 € (M)0,95 € (F)

Encomenda

O procedimento de satisfação de uma encomenda é semelhantequando é efectuada na Internet, por telefone ou na

pizzaria,

se

variando a fornia como a informação é apresentada ao cliente^

(papel ou formato electrónico).

Os produtos disponíveis são pizzas, bebidas, saladas e ingredientes

podendo ser vendidos individualmente ou agrupados num menu.Uma pizza é constituída por uma pizza base (Marguerita) com 3tamanhos (Pequena, Média, Familiar), onde podem ser adicionadosaté 10 ingredientes. Existem também pizzas pré-definidas (isto éMexicana, Barbeque, etc.) que contêm determinados ingredientes.^

Todos os produtos possuem um código, nome, descrição e preço.

Uma encomenda contém vários produtos em diferentesquantidades. Assim que é inserida no sistema (sendo identificadapor um número e tipo: "Código da Pizzaria"; "Internet";"Telefone") é desencadeado o seguinte procedimento:

1. A loja da área do cliente recebe a encomenda no seu terminal(quando não efectuada na pizzaria), que é adicionada à listade encomendas a satisfazer. O estado inicial de umaencomenda é NOVA.

14.

Assim que a loja começa a satisfazer a encomenda(confeccionar a pizza, juntar o menu, etc.), o estado daencomenda passa a PROCESSO.

Quando os itens da encomenda estão todos prontos paraserem entregues, dependendo a entrega do tipo de

encomenda, esta será entregue por estafeta ou peloempregado de mesa. O empregado que estiver livre nomomento encarrega-se de efectuar a sua entrega, passando oestado da encomenda a CAMINHO.

Caso seja uma entrega ao domicílio, é gerada a factura; correspondente à encomenda, caso contrário, a factura só é

gerada quando o cliente a solicitar. Uma factura écaracterizada por possuir um número, data, itens de produtocom valor unitário e valor total.

5. Por fim, após a entrega da encomenda é registado que esta foientregue (estado ENTREGUE).

Este mecanismo de estados permite aos clientes saberem num dadomomento o estado da sua encomenda. O gestor de encomendasconsulta as encomendas, sendo a sua pesquisa orientada para asatisfação das seguintes necessidades:

* Saber a quantidade de encomendas efectuadas por área,

incluindo o telefone e morada do cliente.* Conhecer as encomendas efectuadas por cliente.

10.1.2 Modelo de Domínio

Seguindo a orientação do modelo de negócio da PhonePizzaorganizámos o sistema de informação em 4 subsistemas: Central,Telefone, Internet e Pizzaria (figura 10.2).

Com esta arquitectura pretende-se que cada um dos subsistemasfuncione com um elevado grau de autonomia, podendo continuar a

158159



Fundamentai de UM I

Casos de Estycte

assegurar um número significativo de serviços mesmo que s ã

interrompa a comunicação com os restantes subsistemas.

Cada um dos subsistemas terá uma base de dados própria, qud

contém a informação replicada necessária à realização dasoperações locais. Esta arquitectura exige a comunicação através de

mensagens (transacções em XML) para a realização dos use case\ que exigem a participação dos vários subsistemas.

É de referir que a redundância de informação é plenamente jus tificada pelo aumento de eficiência na operação de consultaefectuada localmente em cada um dos subsistemas, e pelapossibilidade de funcionamento autónomo de cada um dessessubsistemas.

Sistema PhonePizza

Subsistema

Central

Subsistema Telefone Subsistema Internet

Subsistema Pizzaria

F I G U R A 10,2 - M O D E L O D E D O M Í N I O P H O N E P I Z Z A

Subsistema Central

A função principal deste subsistema é centralizar e gerir toda

informação gerada no processo de encomenda. Logo, deve manteáinformação actualizada sobre produtos, clientes, pizzariasj

funcionários e encomendas, interagindo com os outros subsistemasatravés de um mecanismo de actualização regular por troca demensagens.

Subsistema Centro de Chamadas

Nas encomendas telefónicas, o cliente tem que se identificaratravés da utilização do número de telefone e morada. Em seguida,é verificado se existe alguma loja que distribua para aquela área;caso contrário, não se aceita o pedido. Uma loja distribuiexclusivamente para uma área, pelo que só existe uma loja porárea.

A área é caracterizada como a zona de influência de uma pizzaria,

que neste caso é identificada pelos vários códigos postal das

localidades onde distribui. Admite-se que os colaboradores doCentro de Chamadas confirmam se um dado cliente pertence à zonade distribuição.

Subsistema Internet

No caso de encomendas através da Internet, o utilizador tem queefectuar um pré-registo (indicando imediatamente um Username,

Password, Telefone e Morada), sendo confirmado através de umcódigo de acesso que será enviado através de uma mensagem de

correio electrónico. O código de acesso será utilizado para activaros serviços disponibilizados na Internet. Após a activação dosserviços, o código de acesso não será jamais utilizado.

Assim que o cliente recebe o código de acesso, poderá efectuarl encomendas através do seu Username e Password. No sistema^

s todos os clientes serão identificados pelo seu número de telefone.

160 161



Fundamental de U M L Casos de Estudo

Subsistema Loja • • •

w § f -

;

• ) ( - • « . « .

A encomenda na pizzaria abrange todos os pedidos efectuadospessoalmente pelo cliente, nos serviços de balcão e mesa. Noserviço ao balcão, o cliente efectua o seu pedido a um empregadodo atendimento que se encarregará de introduzir o pedido no

sistema.

Para efectuar o pedido na mesa, é disponibilizado um terminal d < j

sistema com um ecrã táctil em cada mesa, onde o cliente teracesso ao catálogo de produtos e ao conteúdo da sua encomenda.

O sistema dará apoio ao acompanhamento do procedimentoentrega ao domicílio.

10.1.3 Modelo de Use CasesActores

Existem os seguintes actores que interagem com o sistema deinformação do grupo PhonePizza:

« Cibernauta -todo aquele que, através da Internet, consulta aspáginas do grupo PhonePizza;

« Cliente - é a pessoa que encomenda produtos e/ou reservamesas;

» Colaborador do Centro de Chamadas - é o funcionário daPhonePizza que atende as chamadas telefónicas dos clientes nocentro de chamadas;

« Estafeta - é o funcionário da PhonePizza que se desloca a casados cibernautas e clientes para entregar os produtos;

* Empregado - é o funcionário da PhonePizza que atende osclientes na loja, quer no balcão: Empregado de Balcão, ou namesa: Empregado de Mesa;

* Gestor de Loja - é o funcionário da PhonePizza responsávelpor gerir uma loja do grupo.

* Gestor de Encomendas - é o funcionário da PhonePizzaresponsável por gerir o processamento das encomendas;

Para além destes actores humanos identifica-se ainda um outro tipode actores, que são os diversos subsistemas que constituem osistema PhonePizza. • ;

íDJí fo - .. ....

Subsistema Central

Subsistema Internet

Subsistema Centro de Chamadas

Subsistema Pizzaria

Use cases

Tomando como referencia cada um dos actores identificam-se os

use cases em que participam:

Do Cibernauta:

Consultar Catálogo de ProdutosConsultar PromoçõesEfectuar pré-registo por Internet

Do Cliente:

Efectuar EncomendaEfectuar Encomenda por Telefone

Efectuar Encomenda por Internet» Efectuar Encomenda na Pizzaria* Efectuar Encomenda na Pizzaria-

-Balcão* Efectuar Encomenda na Pizzaria-

-Mesa« Consultar Catálogo de Produtos• » Consultar Promoções* Activar Serviço Internet* Consultar Conteúdo de

Encomenda Consultar Estado da Encomenda

* Reservar Mesa* Emitir Factura

Do Colaborador do Centro de

Chamadas:

* Consultar Catálogo de Produtos« Consultar PromoçõesDo Empregado (Mesa ou Balcão):

» egistar Entrega Completa

Do Empregado de Balcão:

* Consultar Catálogo de Produtos5 Consultar Promoções

Do Gestor de Loja:

Consultar Encomendas•> Consultar Encomendas por Área» Consultar Encomendas por

Cliente

Do Gestor de Encomendas:

« Alterar Estado Encomenda

162



Fundamentai de UM L Casos de Estudo

Do subsistema Central . ^

* Actualização de Dados

Do subsistema Internet

* Efectuar pré-registo» Activar serviços central« Enviar encomenda pizzaria

* Consultar Catálogo de Produtos

Do subsistema Telefone

Enviar encomenda pizzaria

Do subsistema Pizzaria/Loja

Satisfazer encomendaEnviar encomendas do diaConsultar Catálogo de Produtos

Diagrama de use cases

Nesta apresentação optamos por elaborar diagramas de use casesí

para cada um dos subsistemas. É de notar que nos diagramas de usei

case aparecem representados como actores os restantes subsistemasj

com os quais o subsistema comunica.

o

Subsistema Internet

o

Subsistema Loja

Subsistema Central

O

SubsistemaCentro de Chamadas

Cibernauta

Sistema Central

Subsistema Internet

Sistema Pizzaria

Sistema Central

F I G U R A 1 0 , 4 - S U B S I S T E M A I N T E R N E T

F I G U R A 1 0 . 3 - D I A G R A M A U S E C A S E S U B S I S T E M A C E N T R A L

164l

§5



Fundamentai de UML

Subsistema Pizzaria

Sistema Telefone

Sistema Internet

RecepçãoEncomendas

Efectuar Encomenda

Mesa

Desconto p.5* 7

Efectuar Encomendainclude \ Balcão

extend»

Consultar CatálogoProdutos Calcular Desconto

Envio deencomendas

Consulta Promoções

ConsultaEncomendaspor Área

ConsultaEncomendas

Critério Área p.3Critério Cliente p.3 «extend»

ConsultaEncomendaspor Cliente

Alterar EstadoEncomendas

Sistema Central

Empregado Balcão

Casos de Estudo

Colaborador Centro Cl Sistema Pizzaria

Subsistema Telefone

Efectuar Encomenda^

«jnclude»

Telefone

F I G U R A 1 0 , 5 - S U B S I S T E M A P I Z Z A R I A

F I G U R A 1 0 , 6 - S U B S I S T E M A T E L E F O N E

Descrição dos use cases

Nesta secção, são descritos alguns dos use cases que serãoposteriormente detalhados através de diagramas de sequência eactividade. As restantes descrições encontram-se no Anexo H .

Alguns dos use cases são internos a cada um dos subsistemas. Porexemplo a consulta do catálogo de produtos pode ser feita atravésde um ecrã de utilizador disponibilizado pelo subsistema daInternet, e utilizando informação residente na base de dados local

sobre produtos e promoções. Existe um use case

semelhante parapermitir a consulta do catálogo na pizzaria através do terminal, mas

ii

167



Fundamentai de UML Casos de Estydo

utilizando informação residente na base de dados local dosubsistema da pizzaria. Por este motivo a descrição destes dois use |cases será muito semelhante, sugerindo a possibilidade dq

reaproveitamento de diagramas.

Existe um outro conjun to de use cases que implicam comunicação

entre 2 ou mais subsistemas. Nesta situação encontra-se o pré-registo que envolve comunicação entre o subsistema Internet e osubsistema central. A aceitação de uma encomenda pela Internet éum use case que exige o envio de uma mensagem do subsistemaInternet para o subsistema da Pizzaria. Por esse motivo estes usecases encontram-se identificados em ambos os subsistemas, aindaque a sua descrição detalhada e representação utilizando umdiagrama de sequência sejam distintas.A título de exemplo apresentamos a descrição de 3 use cases

associados ao subsistema de Internet.

» Consultar catálogo de produtos na Internet• Efectuar pré-registo pela Internet» Efectuar Encomenda na Internet

Estes use cases serão posteriormente representados através dediagramas de sequência.

Use Case: Consultar catálogo de produtos na Internet

f

1. O Cibernauta, o Cliente, o Colaborador do Centro de3 Chamadas e o Empregado de Balcão utilizam o sistema de

informação para consultar o catálogo de produtos.

2. O catálogo de produtos deverá ser apresentado sob a formade uma listagem de produtos com a seguinte informação:código, nome, descrição e preço.

'" 3. Caso seja pretendida a consulta das promoções do mês,então é utilizado o caso específico: Consultar Promoções

Use Case: Efectuar pré-registo por Internet

1. O Cibernauta utiliza o sistema de informação através dapágina Internet da PhonePizza para efectuar o pré-registo,requisitando um código de acesso.

2. O Cibernauta tem que indicar: username,

password,

telefone e morada.

3 . Includes Verificar a Existência de Loja numa Zona

Pós-condição: É gerado um código de acesso que será enviado porcorreio electrónico.

Use Case: Efectuar Encomenda na Internet

1.

O Cliente utiliza o sistema de informação através da página

Internet da PhonePizza para efectuar a encomenda.2. O cliente fornece os seus dados identificativos e estes sãovalidados.

3. Se pretender, o Cliente pode consultar:a. o catálogo de produtos: Includes Consultar

Catálogo de Produtosb. e/ou as promoções do mês: Includes Consultar

Promoções4. O Cliente escolhe o(s) produto(s) que pretende, (indicando

o código ou o nome do produto e a quantidade).5. Para cada produto escolhido, o sistema verifica o seu preço

e é adicionado ao custo total da encomenda.6. Se o produto está em promoção, existindo assim um

desconto:a. Extends Calcular Desconto.

l

O produto é adicionado aos itens da encomenda.8. O Cliente confirma a Encomenda9. A Encomenda é transmitida para a Pizzaria da zona da

morada do cliente.

1S8



Fundamentai deU M l Casos de Estudo

Diagramas de Sequência

Apresentamos nesta secção os diagramas desequência^

ètós usecases descritos anteriormente. >

(

f

•

;

T

Na figura 10.5 apresenta-se o diagrama de sequência que descrevea Consulta de Catálogo. No diagrama de sequênciaencontram-se representados os objectos de interface, os objectos denegócio e os objectos de dados. Ainda que a maioria dos objectosde negócio de um sistema de informação sejam persistentes, emgeral omitimos a representação dos correspondentes objectos dedados para evitar sobrecarregar os diagramas.

:Cliente

ActorConsulta produtos :

WebFormí : ProdutoPB

V »

í

•\

'* Selecciona

produto

•s

*^*-

>

Catalogo Produtos

T

* Selecciona produto

latalogo produtos

•ií, . FIGURA 10.7 - CONSULTA CATÁLOGO

Em use cases onde têm de ser tomadas decisões complexasutilizamos um objecto de controlo que assegura o acompanhamento

do fluxo de execução e valida as regras de negócio relevantes. Porexemplo, na descrição de Efectuar Encomenda pelaInternet surge um objecto designado por Gestor deEncomendas que desempenha essa tarefa.

Para descrever um use case onde seja necessário assegurarcomunicação com os outros subsistemas através do envio demensagens utilizamos um objecto de controlo, designado porGestor de Transacções.

n :Cihbrnauta

i NovoRegistoQ

3

Dados pré-registo()|

{Pertence à zona dedistribuição}

a

ré-registo efectuado^

z.

«destroy»

TransacçãoPré-registoQ

Transacção Enviada

!Sistema Central

Criatransacção)

Transacção pré-registo()

Confirmação

^ Mostra pré-registo efectuado

FIGURA10,8 - PRÉ-REGISTO CLIENTE

Para facilitar a representação do diagrama de sequência quedescreve a satisfação de uma encomenda, optamos por decompô-lo

em dois subdiagramas: um que descreve a recepção da informação

170 171



Fundamenta l deJJML

Casos de

da encomenda e um outro que descreve a operação de envio para osubsistema Central.

Form

Encomenda | í j l '• Cliente

:WebF oim [ V j

: Encomendajjtem

Dados Cliente .

Gestpr

Encomenda i

* Seleccionaproduto e

quantidade-

Confirma

Encomenda

F —

>

Valida Cliente

Regista

produto equantidade^

Confirma

Encomenda

1

Valida Cliente

Cria En

Calei.

J

Confirma

omenda

\

Valida

Adiciona Item

a Total^

'l

ncomenda

>

L

]

Produto

r

^ CalculaTotal

L

J

^

F I G U R A 1 0 , 9 - R E C E P Ç Ã O E N C O M E N D A

: G es to r

Encomenda : Encomenda

V J

Gestor Transações

: Sistema entral

Selecciona Encomenda

Transmite (encomenda)

î Mensagem Encomenda

F I G U R A 10.10 - T R A N S M I T I R E N C O M E N D A

10.1.4 Modelo de Desenho

Diagrama de Classes

Na figura 10.11 apresenta-se um diagrama das classes da camadade negócio do sistema.

Este é um diagrama geral que inclui todas as classes que suportam

informação necessária ao funcionamento global da PhonePizza.Para cada um dos subsistemas existirá um (sub)modelo que incluialgumas das classes deste modelo geral. Por exemplo no caso dosubsistema da Internet não se justifica que sejam consideradasclasses que descrevem a estrutura organizativa da Pizzaria(Restaurante, Balcão, Cozinha, etc.) ou aquelas associadas aoscolaboradores (Funcionário). Para simplificar o diagrama omitimostambém a representação das classes de controlo identificadas nosdiagramas de sequência.

123



wMesa

Reserva / -estadoMesa

n«Reserva , /-n=Mesa

data /hora \ /

\ / \ /

. • < .

l Pertence

/ 1

_ B I Etectua

(

O tí_ t

•-i-Pré-RegistoO

+

1 . . *

Are

Restaurante Balcão Cozinha

L1

a, - Plzzana

^ Funcionário-códiqoPostal v,

a

,

a

-n=Funcionário

-códigolnterno

i

0

,i,, 5»

\ -categoria \

TrabalhaEncomenda : data

lumeroE

Jata

poEncomeradicionaPro

calculaTotal

confirmaEnc

iiemencomenaa

n

°Horas

-numeroltem

da^ -quantidadedutoO 1 * -tamanho

)omenda()

Corresponde

1.*

Factura-n=Factura

-total

Constituição

quantidade

^

^

\

Menu Bebida

-tipo

l

1..*

-preço-tamanho

Re

ere

Heere

1 Preço

l 1 -tipoPreco

Produto -tamanho-cod.goProduto

Possu

.

dat

alnicio

-descnçaoProduto

u (

j-.

+devolvePreço()

_

^

1,.*

\-

ll

\J ;

Salada Pizza Ingrediente

-nome

O nome

|1

1..10

Restrcoes: L\

Preço.t

poPreco={Normal, Promoção}

Preço.tamanho={Único,Pequeno,

Médio,Grande}

|

Funcionário.categoria={Gestor de Loja, Empregado Balcão, Estafeta, GestorEncomendas}

j

F IG U R A 1 0,1 1 -D I A G R A M A D E P H O N E P IZ Z A

©

F C A -

E

T

O

D E

N

O

M

C

Casos deEstudo

Descrição das classes «

Todas as classes são descritas em pormenor no AnexoH .

i

Diagrama de Estados

A Encomenda constitui a classe com um comportamentodinâmico mais relevante neste sistema. No Capítulo 6 encontra-sedescrito o diagrama de estados desta classe.

10.1.5 Modelo de Implementação

Na figura 10.12 apresenta-se, como exemplo, o diagrama decomponentes para o subsistema Internet.

ControloAcesso.dll

GestaoEncomendas.exe

Men .html

Base de Dados

ít

Encomendas.html

«hyperlink» , K Intemet/i

GestaoProdutos.dll

Catalogo.html

F I G U R A10,12 - D I A G R A M A D EC O M P O N E N T E S

Íf4

175



Fundamental de U M L

10.1.6 Modelo de Instalação

K

Na figura 10.13 apresenta-se o

diaâiUttde

instalação do sistemaPhonePizza.

«processor»

HTTP

7

TCP/IP -

XML

/

s- — ,™

TO

— „

«processor»

TCP/IP - ODBCServidor

Centralf

/

«processor»

|H

Servidor de

Dados

TCP/IP -

XMLJ

TCP/IP - XML

«proces

ServidoEncomc

PizzariETC I

/C

sor»

r

TCP/IP - XML

3

/IP

TCP/IP,.,,.

,

/

J

-.~ À

«processor»Servidor

Centro deChamadas

«device»

Leitor Códigode Barras

«processor»TerminalEncomendasPizzaria

«processor»PC Ecrã Táctil

Mesa

F I G U R A

10.13

D I A G R A M A G E R A L D E

I N S T A L A Ç Ã O

Casos de Estudo

1 0 .2 S I U N I V E R S I T A S ®

rs <

:

Considere que se pretende desenvolver um sistema de informaçãointegrado para a gestão de uma Universidade. Este sistema seráconhecido por SlUniversitas® e procura racionalizar recursos eaumentar a eficiência dos processos de gestão.

Identificam-se seguidamente os principais requisitos recolhidosapós reuniões com os elementos da direcção da Universidade,pessoal administrativo, docentes e representantes de alunos.

O sistema terá como ponto de acesso preferencial a Internet,disponibilizando conteúdos de acesso público e de acesso restrito.Através de um protocolo com uma instituição bancária, todos osfuncionários e alunos terão um cartão magnético de identificação.

O acesso restrito será validado através da introdução do número docartão e respectivo código PEN. A operação de verificação nãopode demorar mais que l segundo. Após 3 tentativas inválidas, ocartão magnético é bloqueado. Esta informação sobre o cartãomagnético é mantida pelo sistema.

Os recursos humanos da Universidade são geridos de acordo com oseu tipo. Assim, os funcionários da Universidade são divididos emDocente e Não Docente. Todos os funcionários possuem umnúmero de identificação interno, nome, morada, número de BI, NIF

e estado civil. Estes registos são mantidos pela Secção de Pessoal,pelo que o sistema deverá permitir a gestão dos funcionários.

Os funcionários não docentes têm que registar diariamente as horasde trabalho efectuadas. Este registo é feito através de uma máquinaPontoMatic situada na entrada principal da Universidade, ondecada funcionário terá que passar o seu cartão magnético à entrada eà saída.Depois da passagem do cartão, a máquina PontoMatic envia um

pedido de registo de entrada/saída para o SlUniversitas®. O sistemaregistará para o dia de trabalho a hora de entrada e saída. Um dia de

176 177



Fundamental deU M L

trabalho poderá ser classificado como Normal, Tolerância dePonto, Ponte. É da responsabilidade da Secção de Pessoalclassificar cada dia.

Os docentes possuem um número de gabinete, número de cacifo epodem ter dedicação exclusiva, parcial ou serem convidados.Possuemum a categoria (Assistente Estagiário, Assistente,Professor Auxiliar, Professor Associado ou Professor Catedrático)e podem leccionar várias disciplinas num determinado semestre deum ano lectivo. Um docente poderá ser o responsável pelacoordenação de várias disciplinas.

Uma disciplina possui um código, um nome, endereço da páginaoficial na Internet e poderá ser teórica, prática ou teórico-prática.Terá também um programa que será constituído pelos objectivos

pedagógicos, tópicos a abordar e bibliografia recomendada. Odocente coordenador da disciplina é responsável por introduzir ealterar o programa. É também responsável por registar os diversoselementos de avaliação dadisciplina

2

. Um elemento de avaliaçãopossui uma data, descrição e pode ser classificado como trabalhode grupo, teste, frequência, avaliação contínua, exame ou exame de2a época.

Para cada elemento de avaliação, o docente publicará uma pautacom os respectivos resultados. Uma pauta possui um código,descrição do elemento de avaliação, turma, estado (não oficial,oficial e lançada) e é constituída pelos diversos resultados. Cadaresultado diz respeito a um aluno e possui uma nota de O a 20.Inicialmente, as pautas são criadas com um estado não oficial,sendo permitido aos docentes efectuar alterações. Passados 10 diasúteis, o sistema altera o estado para oficial, permitindo assim que aSecção Académica proceda ao registo oficial das notas (verprocedimento da inscrição). O docente é avisado da alteraçãoatravés do envio de uma mensagem de correio electrónico.

de

E s

2

Para um semestre de um ano lectivo.1ZS

No decorrer do ano lectivo, o docente terá que introduzir,diariamente, no sistema as aulas que leccionou. Após validar o seuacesso (serviço restrito), o docente introduz o código da disciplinae o código da turma. Em seguida, introduz o número de alunospresentes e o sumário. O sistema calcula automaticamente onúmero da aula.

A Universidade organiza os seus cursos em quatro tipos:Licenciatura, Mestrado, Pós-Graduação e Doutoramento. Um cursoé caracterizado por possuir um código, nome e duração (anoscurriculares). Assim, cada curso terá um ou mais anos curriculares,onde serão leccionadas várias disciplinas no 1° ou 2° Semestre. Umano curricular é caracterizado por possuir um número de ano e tipo(normal, projecto, estágio ou tese). A Universidade utiliza umsistema de créditos por disciplina, cujo valor poderá ser diferentepor curso.

Os alunos são agrupados em turmas, sendo que cada turma terá nomáximo 50 alunos e pertence a um ano curricular Um turma écaracterizada por possuir uma sigla, ano lectivo em que foi formadae o regime horário (diurno ou nocturno). Num ano lectivo o alunosó pode pertencer a uma turma. A cada turma é atribuído umhorário. Um número limitado de turmas é criado no início do anolectivo pela Secção Académica, contudo no decorrer de umainscrição poderá ser necessário a criação de uma nova turma.

O horário é introduzido pelos funcionários da Secção Logística deacordo com o seguinte processo: primeiro selecciona a turma a queo novo horário se destina e modifica a versão de mesmo (a, b, c, d,

s e ... z). Depois introduz os diversos períodos lectivos que compõeml o horário. Cada período lectivo está associado a uma disciplina ei possui um dia de semana (Segunda a Sábado), hora de início, hora^

de fim e sala.

No início de cada ano lectivo, os funcionários da Secção;

Académica registam no sistema as inscrições dos alunos. Caso esta

121

C



seja a primeira inscrição, o procedimento de registo exige a criaçãode uma nova ficha de aluno com os seguintes dados: nome,morada, telefone, sexo, nota de candidatura e número de aluno (onúmero é atribuído automaticamente). Nos dados da inscrição deveconstar o ano lectivo, a época da inscrição (1a Fase, 2a Fase ouEspecial), ano curricular do curso e a

turma

3

.

Um aluno efectua

uma inscrição por ano lectivo, para um curso e num conjunto dedisciplinas (máximo 10), sendo que deve ficar registado para cadadisciplina a classificação obtida (nota e

época

4

).

A ficha de alunopoderá ser consultada e modificada pelo aluno através da Internet

(acesso restrito).

O sistema disponibiliza aos alunos outros serviços de acessorestrito. Assim, o aluno poderá, por exemplo, consultar o resultadoda sua avaliação oficial nas diversas disciplinas ou pedir ocertificado de habilitações. Poderá também inscrever-se nosexames de 2a época, para tal o aluno terá que seleccionar o códigoda disciplina, seguido da indicação se é melhoria ou exame. Porfim será apresentado ao aluno o montante devido,

10€

se ainscrição está dentro do prazo. Caso a inscrição seja fora do prazo,o sistema terá que calcular o montante da multa com base noagravamento de 1% por dia de atraso. Só se aceitam inscrições até15 dias do prazo. O pagamento é efectuado através do débitodirecto no saldo do cartão. Esta operação só é possível através doenvio de uma mensagem para o Sistema Bancário da Universidade.

A Universidade deseja a criação de um serviço de alertas SMS(Short Message Service}.

Este serviço de acesso restrito permite aosalunos definir até 3 alertas. Existem 3 tipos de alertas: Pauta, NotaOficial e Elemento de Avaliação. Todos possuem um estado (activoou inactivo) e para os alertas Pauta e Nota Oficial o sistema enviaráuma mensagem SMS quando uma pauta é publicada por umdocente ou uma nota oficial é lançada pela Secção Académica. Nocaso do alerta Elemento de Avaliação, o aluno tem que definir o

Casos de Estudo

3

É mostrado automaticamente o número de vagas disponíveis na turma.

4

Normal ou 2a época.

ilQ

número de dias de antecedência, da data de avaliação, em quedeseja receber o aviso. O envio de mensagens SMS é efectuadoatravés do sistema GatewaySMS.

De forma a uniformizar a gestão de grupos de trabalho, o sistemagere os grupos de alunos para cada disciplina. Cada grupo possui

um número, data de formação e é constituído no mínimo por 2elementos. Cada elemento corresponde a um aluno, pelo que possuium número de aluno. O registo dos grupos será efectuado pelosalunos (acesso restrito). Antes de registar um grupo, o sistemaverifica se cada elemento já está inscrito. A entrega dos trabalhosao longo do semestre é registada no sistema por um funcionário darecepção (acesso restrito). Ao receber o trabalho, o funcionáriointroduz o número do grupo e efectua o registo da entrega. Umgrupo pode efectuar várias entregas, ficando registado o número daentrega, data e hora. Os docentes podem extrair uma listagem coma constituição dos grupos e também com as entregas efectuadas.

O sistema disponibiliza diversos serviços de acesso público. Estesserviços abrangem a consulta de turmas, pautas, horários eprograma de disciplinas.

10.2.1 Modelo de Use Cases

Actores

Existem os seguintes actores que interagem com o sistema deinformação SlUniversitas

R

:

« Aluno - representa os alunos da Universidade;* Cibernauta - todo aquele que, através da Internet, consulta as

páginas sistema;» Docente - representa um funcionário que lecciona aulas na

Universidade;

« Docente Coordenador - representa um docente que coordenauma disciplina;

181



Funcionário - representa todos os funcionários daUniversidade;

»

Funcionário da Recepção - é o funcionário que efectuaatendimento ao público na recepção da Universidade;

*GatewaySM S

- sistema responsável pelo envio de mensagensSMS;

* PontoMatic - é a máquina que regista diariamente as horas detrabalho dos funcionários não docentes;

* Secção Académica - representa todos os funcionários quepertencem à Secção Académica;

* Secção Logística - representa todos os funcionários quepertencem à Secção Logística;

* Secção Pessoal - representa todos os funcionários quepertencem à Secção Pessoal;

« Sistema Bancário da Universidade - representa o sistema

bancário que controla os débitos no cartão magnético daUniversidade.

Use cases

Tomando como referência cada um dos actores, identificam-se osuse cases em que participam:

Do Aluno:* Consultar F icha

Alterar Ficha* Consultar Avaliação Final

Definir Alerta

»

Pedir Certificado deHabilitações

« Inscrever Exame 2a Época« Registar Grupo« Validar Acesso

Do Cibernauta:

« Consultar Turmas

Consultar Pautas• Consultar Horários

« Consultar Programa deDisciplinas

Do Docente:

»

Publicar Pauta* Listar Constituição de Grupos* Listar Entregas Efectuadas

*

Registar Aula* Aviso Alteração Estado da

Pauta

Do Docente Coordenador:

«

Introduzir Programa

« Alterar Programa

§

Do Funcionário:Valida Acesso

Do Funcionário da Recepção:

Regista Entrega de Trabalhos

Para GatewaySMS:

Enviar Alerta SMSDo PontoMatic:

i

Registar movimento

Diagrama de use cases

Da Secção Académica:5 Inscrever Aluno

Criar Turma* Registar Nota

Da Secção Logística:* Introduzir Horário

Da Secção Pessoal:

«

Gerir Funcionários

Classificar Dia Trabalho

Sistema SlUniversitas (1/3)

Consultar Ficha

/ Alterar Ficha

edir

Certificadode Habilitações

Regista Grupo

Y «' elude»

SistemaBancário

Universidade

FIGURA 10,14 -DIAG, USE SIUNIVERSITAS® (1/3)

182



damentaideJJMJL

Cibernauta

Docente

Funcionário

PontoMatic

Sistema SlUniversitas 2/3)

GatewaySMS

FIGURA 10,15 - DIÂG (2/3)

2

S

Casosidei

gstudo

Sistema SlUniversitas (3/3)

Secção Pessoal

1a Inscrição p.3

Turmasinsuficientes p.5

Secção Académica

Secção Logística

Oegista Entregade Trabalhos

Funcionário Recepção

FIGURA 10.16 - DIAG. USE C A S E S S I U N I V E R S I T A S ® (3/3)

I



5.

j / \ / \ , .; Funcionário Recepção Secçã o Académica Secção Logística Secção Pessoal

í 10,1? -

Descrição dos use cases

Nesta secção são descritos alguns dos use cases que serãoposteriormente detalhados através de diagramas de sequência ou

actividade.

Use Case: Inscrever AlunoPré-Condição: O funcionário validou o seu acesso previamente.

1. Os funcionários da Secção Académica utilizam o sistema

para efectuar a inscrição de alunos.2. Após seleccionar a opção Registar Nova Inscrição ofuncionário terá que introduzir o número de aluno que está ainscrever.

, 3. Caso seja a primeira inscrição do aluno, será criada umanova ficha de aluno, onde será atribuído um número de

aluno.a.Extends Criar Ficha de Aluno.

4. Em seguida, o funcionário indica o ano lectivo, a época dainscrição (1a Fase, 2a Fase ou Especial), ano curricular e a

turma.

Se o número de turmas é insuficiente, o funcionário poderácriar uma nova turma.

Extends Criar Turma.a.6. O funcionário introduz o código do curso e o código das

disciplinas em que é feita a inscrição. Só será possívelintroduzir no máximo 10 disciplinas.

Use Case: Inscrever Exame de 2 a ÉpocaPré-Condição: O aluno validou o seu acesso previamente.

1. Os alunos utilizam o sistema para efectuar a inscrição nosexames de 2a época.

2. Após seleccionar a opção Inscrever Exame 2a Época o1 aluno terá que seleccionar o código da disciplina e indicar

se é para melhoria ou exame.3. O sistema calcula o montante devido pelo aluno, sendo 10€

se a inscrição estiver dentro do prazo. Se a inscrição estiverfora do prazo, será cobrada unia multa.a. Extends Calcular Multa.

4. Só será possível efectuar inscrições se não decorreram 15dias do prazo.

5. E enviada uma instrução de pagamento para o SistemaBancário da Universidade.

Use Case: Validar Acesso1. Para aceder aos serviços de acesso restrito, o funcionário ou

o aluno tem que validar o seu acesso.2. Assim que é seleccionado um serviço com acesso restrito, é

mostrado ao utilizador um ecrã de validação do acesso.3. O funcionário/aluno introduz o número do seu cartão

magnético e respectivo código secreto PIN).

4. O sistema verifica se a informação fornecida está correcta.Esta operação não pode demorar mais que l segundo.

5. O funcionário/aluno dispõe de 3 tentativas. À 3a tentativaf falhada o sistema bloqueia o cartão magnético.

1IZ



m Casos de Estudo

>iagrama

de Classes Conceptual

• /

-

•

í

ipresentamos

nesta secção o diagrama de classes conceptual. Esteiagrama baseia-se nos requisitos identificados previamente.

AnoCurricularVSDisciplinasemestrecréditos

Disciplina

-códigoD-nome-endereçolnternet 1

-tipo

ré

1

fere

Aluno

-número-nome-morada

-telefone -sexo-notaCa

Aluno

ndidatura

1

Grupo

-núms -data-anoL

srourupo

ectivo

l "

^

efectua

Entrega

-númeroEntrega-data-hora

-descrição

\ \

r

. A

D

Eisciplina

no Curricular

lúmeroAnoCipo

-época Curso

Inscrição

-anoLectivo* -época

1

possui l

D.. 50

define

~~l

0.

refere

2..*

i 1

pertence

Dl

-códigoCurso -tipo

ra j -nome

>

-duração perten

Cartão Magnético

-número

-PIN

1l*

Turma

-regime

3---

Alerta

sstado

diasAntecedênciaipo

•

Elemento

-númeroElemento

l1

irmã

;tivo Horário

possui

1Horário

-versão

t

Período Lectivo

scipina

. -diaSemana

-horalnício

-códigoD-nome

1

-endereçolnternet refer-tipo

-horaFim

-semestre-anoLectivo

-tipo-data-descrição

,

Avaliação

-nota

FIGURA

10,18 - DIAG.

CLASSES CONCEPTUAL SIUNIVERSUAS®

l FIGURA 10,19 - DIAG, CLASSES CONCEPTUAL (CONT.)u_

z

° O diagrama de classes conceptual teve que ser dividido em doisg diagramas devido ao espaço disponível. De fornia a manter a

^

coerência entre os diagramas, as classes Aluno, Cartão

189



de

Magnético,

ôram

Turma, Alerta e Disciplina tiveram que ser j

dluplicadas. também identificadas as seguintes restrições:

KRestriçõeslerta.estado={Activo,

Inactivo}

Alerta.tipo={Alerta

Pauta, Alerta Nota Oficial, Alerta Avaliação}

Ano Curricular.tipo={normal, projecto,

tese}

Avaliação.época={Normal, 2-

Época}

Curso.tipo={Licenciatura,

Mestrado, Pós-Graduação,

Doutoramento}

Dia de

Trabalho.tipo={Normal,

Tolerância de Ponto,

Ponte}

Dsciplina.tipo={Teórica,

Prática, Teórico-Prática}ocente.categoria={Assistente

Estagiário, Assistente, Professor Auxiliar,Professor Associado, Professor

Catedrático}

Docente.regime={Dedicação

Exclusiva, Dedicação Parcial,

Convidado}

Elemento de

Avaliação.tipo={trabalho

de grupo, teste, frequência, avaliação contínua,exame, exame 2-

época}

Funcionário.estadoCivil={Solteiro, Casado}

Inscrição 2- Época.tipo={Exame,

Melhoria}

Inscrição.época={1

§

Fase, 2- Fase,

Especial}

Pauta.Estado={Não

Oficial, Oficial,

Lançada}

Turma.regimeHorário={diurno, nocturno}

AO DE

10.2.2 Modelo de Desenho

Diagramas de Sequência

Apresentamos nesta secção os diagramas de sequência dos usecases descritos anteriormente. Estes diagramas possuem umelevado nível de detalhe, muito aproximado de uma possívelimplementação. De forma a simplificar o desenho dos diagramas,foi omitida a representação dos objectos que acedem à base dedados.

- S E Q U Ê N C I A IN S C R E V E R A L U N O ''

lio

- 2a

111

F d t l dCasos de Estydo



Fundamental deUM L

o

:Fundionário

i

dadosAcesso()

\

v1

validarO

v l

s

s ~ ~ ^

verificaAcesso()

\

l

/

^

/

\

{<1

seg.}

t

i

i

i

i

«create»

-^

: Cartão Maanético

cartãoMagnético()

i

x l

_ TJ

verifica() i

N

l

U

[+ 3 tentativas e i

cartão nãobloqueado] '

bloqueiaQ ]V }

k -

'U

T

FIGURA 10,23-DIAG. SEQU ÊNCIA "VERIFICA ACESS O"

Diagrama de Classes de Desenho : » • * « - w ^

O Diagrama de Classes apresentado nesta secção possui um nívelde detalhe elevado, muito aproximado de uma possívelimplementação. Baseia-se principalmente no Diagrama de ClassesConceptual e nos Diagramas de Sequência, e procura realçar as

dependências entre as classes. Por limitações de espaço, o diagramacontém apenas as classes utilizadas nos diagramas de sequências.

Serviços de Interface

Serviços de Negócio

F I G U R A 1 0 , 2 4 - D I A G . D E

152

193



de10.2.3 Modelo de Implementação / •

» ' ; v,

1: tnw í

Na figura 10.25 apresenta-se, como exemplo, um excerto dodiagrama de componentes para o sistema SlUniversitas®. O sistemaserá desenvolvido na linguagem de programação JAVA. O sistemaserá totalmente baseado em páginas dinâmicas através da

tecnologia JSPs (Java Server Pages).

novalnscrição.jsp

Gestorlnscrições.class

lnscriçãoExame2Epoca.class

10.2.4 Modelo de Instalação

O sistema SlUniversitas® seguirá uma arquitectura cliente/servidor,onde os clientes apenas necessitam de um programa que permitaaceder às páginas Internet disponibilizadas pelo servidor. ODiagrama de Instalação apresentado na figura 10.26 ilustra também

a localização dos principais componentes do sistema.

«processor»

Cliente

—

i —

Navegador dei — — páginas Internet

[P/IP

«processor»Servidor Central

Servidor depáginas JSP

SlUniversitas.jar

- DE

F I G U R A 1 0 . 2 5 - D I A G R A M A D E

194115

Documents

casos de uso