Modelagem UML de um Sistema de Gestão de
Espectáculos e Bilheteira
1. Introdução
1.1. Objectivo e requisitos do sistema
Pretende-se projectar um Sistema de Gestão de Espectáculos e Bilheteira para casas de espectáculos (cinemas, teatros, Casa da Música, etc.), suportando as seguintes
funcionalidades:
• registo de salas, com caracterização de zonas e lugares; uma casa de espectáculos pode ter mais do que uma sala - a cargo do responsável pelas instalações;
• registo de clientes, com nome, nacionalidade, morada, e-mail e telefone - realizado em regime de auto-serviço pelos próprios clientes;
• registo de espectáculos, com indicação do nome do espectáculo, descrição, sala, dia(s) e hora(s), duração, artistas envolvidos, preços dos bilhetes (por zona da sala) - a cargo do responsável pela organização dos espectáculos;
• gestão de campanhas promocionais (descontos por temporada, descontos para clientes de certas empresas, descontos para estudantes, descontos de última hora, ...) - definição e disponibilização de informação sobre as promoções existentes e sua aplicação no cálculo dos preços;
• a descrição de um espectáculo pode ser acompanhada de informação enciclopédica com conteúdos multimédia;
• consulta de informação sobre a programação cultural (espectáculos) - disponível para o público em geral;
• acesso a excertos no momento da consulta;
• reserva de bilhetes online (bilheteira online), com indicação do cliente, espectáculo, número de pessoas (discriminando o número de pessoas que têm direito a cada tipo de redução de preço), zona da sala pretendida, e lugares pretendidos (se o utilizador não escolher, é o sistema que escolhe), competindo ao sistema fornecer um número de reserva a apresentar mais tarde na bilheteira (para pagar e levantar os bilhetes) - realizado em regime de auto-serviço pelos próprios clientes;
• se o bilhete não for pago e levantado na bilheteira até uma hora estipulada, a reserva deixa de ser assegurada;
• aquisição de bilhetes online - semelhante a anterior, mas com pagamento (por cartão de crédito) e impressão do bilhete em casa (com código de barras), deixando de ser necessário levantar o bilhete na bilheteira;
• reserva e aquisição de bilhetes em quiosques multimédia - semelhante a reserva e aquisição online, mas com possibilidade para pagar com cartão multibanco, para além do cartão de crédito;
• reserva e aquisição de bilhetes na bilheteira, com ou sem reserva prévia - a cargo dos empregados da bilheteira;
• reserva de bilhetes por telefone (ligado à bilheteira);
• validação de bilhetes (com leitor de código de barras), por porteiro ou por máquina que controla a entrada;
• reserva e aquisição de bilhetes através de dispositivos móveis (SMS, UMTS, PDA's); o cliente recebe um código de barras (por exemplo mensagem MMS) que deve ser apresentado à entrada, sem chegar a imprimir;
• marketing directo (por SMS);
• subscrição de newsletters;
• captação de opinião e feedback do público e da imprensa;
• consulta de estatísticas sobre a afluência de público, proveniência do público, receitas obtidas, etc. - com interesse para o responsável pela organização dos espectáculos.
1.2. Metodologia e plano de tarefas
1. Análise orientada por diagramas
1.1. Construir um modelo de casos de utilização (diagramas de casos de utilização em UML) relativo ao sistema de informaçoes. Opcionalmente, construir um modelo de casos de utilização relativo ao próprio sistema de negócio.
Sugestão: Começar por construir um diagrama de casos de utilização que mostra as funcionalidades (casos de utilização) e tipos de utilizadores (actores), independentemente do canal ou dispositivo de acesso.
1.2. Modelar o "workflow" do processo de negócio (ou processo organizacional ou caso de utilização do negócio) "assistir a espectáculo", desde a reserva do bilhete até à
comunicação de feedback, através de um diagrama de actividades em UML. Modelar a sequência típica de funcionamento de um caso de utilização à escolha através de um diagrama de sequência em UML, sem detalhar a estrutura interna do sistema. 1.3. Modelar o ciclo de vida de uma reserva através de um diagramas de estados em UML. Os eventos devem corresponder normalmente a casos de utilização.
1.4. Relativamente a um caso de utilização que envolva a passagem por várias páginas, descreva a navegação entre as várias páginas através de um diagrama de estados (diagrama de navegação). Elaborar esboços das páginas.
2. Desenho orientado por diagramas de pacotes
2.1. Modelar a arquitectura do sistema (estrutura de alto nível) através de diagramas de pacotes em UML.
2. Análise orientada por diagramas
A "análise" preocupa-se com a descrição do problema e dos requisitos dos utilizadores, isto é, com "o quê" (que funcionalidades o sistema deve apresentar, que informação deve manipular, etc.) em vez do "como".
A descrição é baseada em diagramas UML, descrições textuais associadas e protótipos da interface com o utilizador. Os diagramas podem ser desenhados Microsoft PowerPoint ou Microsoft Visio ou ferramentas similares.
2.1. Modelo de casos de utilização do sistema
Este modelo apresenta uma visão externa do sistema, na perspectiva dos seus utilizadores. Identifica e descreve com algum detalhe as principais funcionalidades do sistema (casos de utilização) e os tipos de utilizadores que a elas têm acesso (actores).
2.1.1. Visão geral
Figura 1. Diagrama de casos de utilização do sistema.
Notas:
• As setas indicam o sentido da iniciativa da interacção.
2.1.1.2. Encadeamento de casos de utilização
Figura 2. Diagrama de actividades detalhando o caso de utilização do negócio "Assistir a espectáculo", na perspectiva do cliente. Os passos neste diagrama correspondem a casos de utilização do sistema de informação, excepto o passo de assistir ao espectáculo
propriamente dito. Este diagrama é útil para mostrar o encadeamento de casos de utilização do sistema.
2.1.2. Caso de utilização "Vender bilhetes"
Breve descrição
O empregado da bilheteira usa o sistema para vender bilhetes a um cliente para assistir a um espectáculo, sem reserva prévia.
Fluxos de eventos / Sequências de funcionamento
Figura 3. Diagrama de sequência descrevendo o fluxo normal de eventos deste caso de utilização.
Pré-condições
• Espectáculo e preços registados no sistema.
Pós-condições
• Bilhetes impressos e entregues ao cliente.
• Bilhetes pagos pelo cliente.
• Venda registada no sistema (incluindo lugares marcados como já vendidos).
Alta.
Actores
• Empregado da bilheteira - inicia o caso de utilização.
• Cliente - não é um actor no verdadeiro sentido do termo, pois não interage directamente com o sistema, mas apenas com o empregado da bilheteira.
3. Diagrama de Arquitectura do sistema
O desenho (design) preocupa-se com definir uma solução para o problema e para os requisitos dos utilizadores descritos na fase de análise.
3.1. Arquitectura do sistema
No contexto dos sistemas de software e sistemas de informação, entende-se por arquitectura, em sentido estrito, a estrutura de alto nível do sistema. Em sentido lato, entende-se por arquitectura todo o conjunto de decisões significativos acerca da
organização do sistema. Arquitectura é geralmente entendido como sinónimo de desenho de alto nível.
3.1.1 Arquitectura física
A arquitectura física preocupa-se com a infra-estrutura de hardware (essencialmente computadores e redes) sobre a qual corre o sistema de software, com a decomposição do sistema de software em componentes, e com a localização dos componentes nos
computadores.
Por componente de um sistema de software entende-se uma parte que pode ser
desenvolvida, distribuída e substituída independentemente das restantes. Normalmente, os componentes correspondem a ficheiros (executáveis binários, bibliotecas de ligação dinâmica, ficheiros de comandos, ficheiros html, etc.).
Figura 16. Diagrama de distribuição (deployment) do sistema, enriquecido com casas, actores e componentes de software.
3.1.2 Arquitectura lógica
A arquitectura lógica preocupa-se com a decomposição do sistema em partes "lógicas", sem preocupação de alocação dessas partes a componentes de software, máquinas (computadores) e processos (do sistema operativo).
