View
28
Download
0
Category
Preview:
DESCRIPTION
casos de uso
Citation preview
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 2/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 3/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 4/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 5/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 6/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 7/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 8/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 9/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 10/21
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)
^i 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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 11/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 12/21
Fundamental de U M L
10.1.6 Modelo de Instalação
K
Na figura 10.13 apresenta-se o
dia^aiUttde
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 13/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 14/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 15/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 16/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 17/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 18/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 19/21
de
Magnético,
^oram
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 20/21
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
7/21/2019 casos de uso
http://slidepdf.com/reader/full/casos-de-uso-56e169a0d16b5 21/21
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
Recommended