Documento de Arquitetura
| Data | Versão | Descrição | Autores |
|---|---|---|---|
| 05/09/2018 | 0.0.1 | Criação do documento | Mariana Mendes |
| 07/09/2018 | 0.0.2 | Adição de tópicos iniciais | João Sconetto e Mariana Mendes |
| 13/09/2018 | 0.0.3 | Tópico visão geral: Diagrama de pacotes | João Sconetto e Mariana Mendes |
| 14/09/2018 | 0.0.4 | Adição do diagrama de classes | Adrianne Alves, Andrew Lucas, Maria Luiza e Natália |
| 15/09/2018 | 0.0.5 | Adição do diagrama NFR | Diego Barbosa e João Pereira |
| 18/09/2018 | 0.0.6 | Adição do tópico 4 | Mariana de Souza Mendes |
| 18/09/2018 | 0.0.7 | Descrição do diagrama de classes | Adrianne Alves |
| 19/09/2018 | 0.0.8 | Descrição do NFR Framework | João Pereira |
| 25/09/2018 | 0.0.9 | Introdução da representação arquitetural e adição do tópico 2.1 | Natália Rodrigues |
| 25/09/2018 | 0.1.0 | Introdução da representação arquitetural e adição do tópico 2.2 | Maria Luiza |
| 15/11/2018 | 0.2.0 | Evolução do Diagrama de Pacotes | João Pedro Sconetto |
| 22/11/2018 | 0.3.0 | Adição do diagrama lógico do banco e descrição das tabelas da versão 1, além da linkagem | Adrianne Alves |
| 22/11/2018 | 0.4.0 | Adição do diagramas de sequências | Andrew Lucas, Maria Luiza e Adrianne Alves |
| 22/11/2018 | 0.5.0 | Adição dos estilos arquiteturais e adicionando versão 2 do NFR | Maria Luiza e Adrianne Alves |
| 22/11/2018 | 0.6.0 | Correção das classes na descrição do diagrama | Mariana Mendes |
| 23/11/2018 | 0.7.0 | Correção das classes na descrição do diagrama | João Pereira |
| 23/11/2018 | 1.0.0 | Correções para entrega da primeira versão | João Pedro Sconetto |
- 1 Introdução
- 1.1 Finalidade
- 1.2 Escopo
- 1.3 Metodologia
- 1.4 Definições, acrônimos e abreviações
- 2 Representação Arquiteturals
- 3 Padrões de Projeto
- 4 Requisitos e Restrições Arquiteturais
- 4.1 TicketFlix
- 5 Visão Lógica
- 6 Referências
Este documento tem como finalidade apresentar uma visão geral da arquitetura que será usada no desenvolvimento do projeto e permitir um maior entendimento do sistema Ticketflix e de como ele irá se comportar e se comunicar com as outras aplicações que compõem o projeto. Com o maior detalhamento da arquitetura, espera-se deixar explícitas as decisões arquiteturais feitas pela equipe.
Ticketflix será uma ferramenta desenvolvida voltada para empresas que fornecem serviços de shows, espetáculos, apresentações, filmes e etc, onde será possível gerenciar a venda, reserva e demais serviços correlacionados a ingressos para tais espetáculos. Será levantado, também, a construção de um subsistema de gerenciamento de bomboniere/lanchonete para vendas de item de consumação para clientes. Este documento apresentará toda a parte arquitetural para a confecção do software Ticketflix, a fim de tornar claras as características arquiteturais do projeto.
Para a elaboração desse arquivo, houve a divisão por artefato necessário para descrição da arquitetura do projeto. A primeira coisa feita foi a definição dos tópicos a serem descritos no documento, essa atividade foi realizada pelo João Sconetto e Mariana.
| Tópico | Autores |
|---|---|
| Diagrama de pacotes | João Sconetto e Mariana |
| Diagrama de classes | Adrianne Alves, Andrew Lucas, Maria Luiza e Natália |
| NFR inicial | Diego Barbosa e João Pereira |
| Representação arquitetural | Natália Rodrigues e Maria Luiza |
| Diagrama lógico do banco | Adrianne Alves |
| Diagrama de sequência | Andrew Lucas, Maria Luiza e Adrianne Alves |
| Estilos arquiteturais | Maria Luiza e Adrianne Alves |
| Diagrama NFR versão 2 | Maria Luiza e Adrianne Alves |
É preciso salientar que a versão do documento conta com a revisão de todos os membros da equipe.
| Abreviação | Definição |
|---|---|
| UnB | Universidade de Brasília |
| DSW | Desenho de Software |
A arquitetura utilizada no projeto será, essencialmente, a arquitetura providenciada pelo framework de desenvolvimento web Django, construído em torno do conceito de MVC (Model View Controller).
Com o advento da Internet, o conceito citado vem crescendo exponencialmente, isso porque tem sido visto como a melhor maneira de desenhar aplicações do tipo cliente-servidor. A grande maioria dos frameworks de desenvolvimento web da atualidade é baseada nele.
O Django utiliza o conceito de MVC fazendo uma adaptação do mesmo e criando o que é chamado de MTV (Model Template View). Tais conceitos serão apresentados nas seguintes seções.
O funcionamento do MVC está representado na figura a seguir:
-
Model (M): É o modelo de representação dos dados. Em outras palavras, é a maneira como os dados serão armazenados no banco. A Model é a camada responsável pela persistência de dados, na qual todas as entidades (classes) participantes do domínio da aplicação serão especificadas.
-
View (V): É a camada de apresentação, onde os dados são exibidos aos usuários finais. Nela, uma interface de interação é providenciada ao usuário, para que ele possa interagir e fazer requisições à aplicação.
-
Controller (C): É a camada intermediária, que controla o fluxo de informações entre a View e a Model. É nela que as requisições de usuários são recebidas e tratadas para que a comunicação entre as duas camadas presentes na extremidades da aplicação seja feita de maneira correta.
O Django utiliza o padrão MVC, no entanto ele usa sua própria lógica de implementação denominada o padrão MTV (Model - Template -View), que é descrito a seguir:
- Model (M): Assim como no MVC, a Model é a camada de acesso a dados. Essa camada contém tudo e qualquer coisa sobre os dados: como acessá-lo, como validá-lo, quais comportamentos ele possui e as relações entre os dados.
- Template (T): No MVC, a camada Template é representada como a View, que é a camada de apresentação. Essa camada contém questões relacionadas à apresentação: como algo deve ser exibido em uma página da Web ou outro tipo de documento.
- View (V): No MVC, a camada View é a Controller, que controla o fluxo das informações. Essa camada contém a lógica que representa o intermédio entre a Model e a camada Template.
Estilo arquiteturais são princípios aplicados ao padrão arquitetural, a fim de dar um grau de uniformidade à arquitetura. Tendo em vista esse conceito, foi aplicado os seguintes estilos arquiteturais ao projeto.
A aplicação é independente e não depende de terceiros que fornecem dados ou serviços para a aplicação. Portanto, este estilo arquitetural faz-se presente na representação da arquitetura deste projeto.
A aplicação é dividida em um conjunto de camadas, cada uma especializada em um tipo de serviço específico. Este é um estilo muito comum em padrões arquiteturais que utilizam MVC ou MTV, o qual está sendo usado neste projeto. Portanto, a aplicação é formada por 3 camadas, sendo Model, Template e View.
Os Padrões de Projeto e os GRASPS podem ser acessados aqui
| Requisito | Ferramenta/Solução |
|---|---|
| Linguagem | Python 3.6.4 |
| Framework | Django 2.0.3 |
| Plataforma | Web - Navegadores Chrome, Safari e Firefox |
| Segurança | O sistema terá informações pessoais dos pacientes que só poderão ser vistas pelo mesmo ou pelo(s) seu(s) respectivo(s) médico(s). Outros dados pessoais só poderão ser vistos pelo próprio usuário. |
| Internacionalização (i18n) | A aplicação terá suporte aos idiomas: Inglês e Português do Brasil (sendo esta a linguagem padrão). |
O framework Django organiza os projetos em apps, que são pastas que contêm uma funcionalidade independente do restante da aplicação. Além disso, existem arquivos de configuração e arquivos estáticos globais. A figura a seguir mostra a organização de pastas de um app.
-
apps: cada app tem uma pasta com as suas models, views, formulários, testes, templates e arquivos estáticos. Além disso, também há um arquivo URLs que será incluso no URLs global.
-
migrations : pasta com as migrações para o banco de dados.
-
static : pasta com arquivos CSS, JavaScript e imagens.
-
tests : arquivos de testes refente ao app.
-
templates : arquivos html do app.
-
locale : traduções referentes ao app.
-
models : arquivos de models do app.
-
views : arquivos de views do app.
-
forms : arquivos de formulários do app.
-
admin : arquivo de conexão do app com o admin.
-
urls.py : arquivo que mapeia as as views com templates de cada app
-
_init_ : arquivo que transforma o app em um pacote python.
-
apps : mapeia a pasta que o contém como um app.
-
utils : arquivos de validação dos apps.
-
-
config : pasta com as configurações do projeto Django.
-
urls.py : inclui todos os URLs.py dos apps.
-
_init_ : arquivo que transforma as configurações em um pacote python.
-
settings : arquivos com as configurações básicas da aplicação.
-
wsgi : especificação para uma interface simples e universal entre servidores web e aplicações web.
-
-
manage.py : arquivo criado automaticamente pelo Django para gerênciamento de comandos.
-
docs : documentação da aplicação.
-
compose : pasta com arquivos do docker.
-
utility : arquivos para o auxílio na instalação do software.
-
requirements : organiza todos os pacotes/componentes que a aplicação utiliza em arquivos.
Segue abaixo a primeira versão do diagrama lógico da aplicação TicketFlix.
-
Tabelas do banco: Até o momento existem um total de 22 tabelas na base de dados TicketFlix, a partir da qual são persistidos os dados para dar suporte à funcionalidades essenciais do sistema, como por exemplo, o usuário poder selecionar um assento para um ticket a ser adquirido na aplicação.
-
**django_content_type, django_admin_log, auth_permission, users_user_user_permission, user_user, auth_group_permission, auth_group,user_user_groups ** : Bases relativas à lógica de usuário do sistema.
-
account_emailconfirmation, account_emailaddress: Tabelas referentes à emails
-
spetacle_play : Tabela para persistência peça.
-
spetacle_movie : Tabela para persistência de filme.
-
spetacle_spetacle: Tabela para persistência da classe pai espetáculo
-
spetacle_show: Tabela para persistência dos dados de show
-
establishment_establishment: Tabela para persistência dos dados de estabelecimento
-
ticket_ticket: Tabela para persistência dos dados de ticket
-
session_session: Tabela para persistência de sessão
-
O diagrama de classes tem como principal propósito relacionar os tipos modelados no sistema. Geralmente, inclui classe, interface, tipo de dado, restrição de acesso e dependências. Dessa forma, consiste em um importante artefato da UML (Unified Modeling Language) para documentação das classes codificadas ou que serão codificadas em uma aplicação.
O diagrama abaixo representa a arquitetura geral do Ticketflix :
-
Classes
-
Establishment: Classe destinada aos estabelecimentos. Possui endereço, nome, cep e telefone.
-
Play: Classe destinada às peças. É parte de uma especialização total de espetáculo. Contém como atributos a Sinopse, diretor e elenco.
-
Show: Especialização de espetáculo, contém atributo específico de show, a banda.
-
Movie: Especialização de espetáculo, contém atributos específicos ao filme.
-
Spectacle: Classe que define o espetáculo. Movie, Show e Play são especializações de Espetáculo.
-
Administrator: Classe que define o administrador. É uma especialização de usuário que possui um atributo de permissão booleano que registra a sua permissão para tarefas de administrador.
-
Customer: Classe definida para o cliente, que contém como atributo a lista de compras já feitas no site. É uma especialização de usuário.
-
Purchase: Classe definida para a compra, possui um cliente, o preço total da compra, um carrinho e um status para definir a sua situação.
-
Authentication: Interface que padroniza o processo de autenticação para os cliente e gerente.
-
Cart: Classe destinada ao carrinho mantido por um cliente. Possui os atributos preço parcial, lista de tickets e lista de atributos da bomboniere.
-
bomboniereProduct: Classe para os produtos de bomboniere dos estabelecimentos. Possui o preço do produto, o tipo, descrição e a que estabelecimento pertence.
-
Ticket: Classe definida para o ticket de uma espetáculo. Possui atributos básicos como sessão a que esse ticket pertence, o tipo de ticket, correspondente à inteira ou meia entrada e o preço do mesmo. Essa classe compõe a classe Card.
-
Session: Classe que define as sessões de uma espetáculo. Possui atributos como a que espetáculo pertence, a data , o tempo de execução, a localização e o número de entradas disponíveis. É composta por tickets e compõe uma sessão.
-
User: Classe que determina o usuário do sistema, com atributos como nome, login, senha e email. É especializada em administrador e cliente.
-
PaymentStrategy: Classe destinada ao pagamento que tem como principal atributo o preço total da compra. É especializada em cartão de crédito e boleto. Compõe uma compra.
-
CreditCard: Classe que define um cartão de crédito. Possui atributos como nome do proprietário, número do cartão, código de segurança. É uma especialização de pagamento.
-
BankTicket: Classe definida para boleto, contendo como atributos o nome do proprietário, seu cpf, data de vencimento e cnpj da empresa. É uma das especializações de pagamento.
-
-
Relações
-
Establishment promotes Attraction. Determina que um estabelecimento pode promover várias espetáculos e cada espetáculo pode ser promovida por mais que um estabelecimento.
-
Administrator register Attraction. Determina que um administrador pode registrar várias espetáculos, mas cada espetáculo só pode ser registrada por um administrador.
-
Customer makes Purchase: Define que um cliente pode realizar várias compras no site e uma compra só pode pertencer à um cliente.
-
Purchase é composta por Cart: Relação de dependência entre a compra e o carrinho.
-
BomboniereProduct agrega Cart: É uma agregação ao carrinho, tal que um carrinho pode ter vários produtos da bomboniere, mas um produto da bomboniere só pode fazer parte de um carrinho.
-
Cart é composto por Ticket: Define que não há um carrinho sem ticket, e ainda que cada carrinho pode ter um ou vários tickets, mas um ticket só pode pertencer a um carrinho.
-
Sessão é composta por Ticket: Define que não há sessão se não houverem tickets. Além disso, uma sessão pode conter vários tickets, mas um ticket só pode pertencer à uma sessão.
-
Attraction é composta por Session: Define que não há espetáculo se não houver sessão. Além disso, cada espetáculo pode ter várias sessões, mas uma sessão só pode ser de uma espetáculo.
-
Purchase é composta por Payment: Para cada compra deve existir um pagamento.
-
- acessar e adquirir conhecimento sobre:
- o domínio particular e sobre o sistema a ser desenvolvido;
- requisitos funcionais sobre o sistema em particular; e
- tipos particulares de requisitos não-funcionais e técnicas de desenvolvimento associadas;
- identificar os requisitos não-funcionais do domínio;
- decompor os requisitos não-funcionais;
- identificar as "operacionalizações" (possíveis alternativas de desenho para viabilizar os requisitos não-funcionais no sistema desejado);
- lidar com:
- ambiguidades;
- trocas e prioridades; e
- interdependências entre requisitos não-funcionais e operacionalizações;
- selecionar operacionalizações;
- apoiar as decisões com o Design Rationale; e
- avaliar os impactos das decisões.
O diagrama de interdependência abaixo representa os requisitos não-funcionais do Ticketflix:
Versão 1
Versão 2
Para melhor compreensão das interações entre os objetos, foi elaborado dois diagramas de sequência um para a sequência do processo realizado pelo usuário, ao realizar o fluxo de compra. E outro, o fluxo do administrador, ambos seguem abaixo:
Esse fluxo representa a sequência realizada pelo usuário no processo de compra. O fluxo inicia com o usuário selecionando uma Espetáculo, depois uma das sessões desse espetáculo. Após a escolha da sessão o usuário deve escolher a quantidade de ingressos, e depois escolher os assentos. O próximo passo é selecionar os itens de bomboniere e então finalizar o pedido de compra. O usuário então, irá visualizar o resumo do pedido, confirmar a compra, e realizar o pagamento. Após a aprovação do pagamento, os ingressos serão enviados ao usuário.
O fluxo de criação dos objetos, é realizado pelo administrador. Ele inicia cadastrando espetáculos, salas e itens de bomboniere. Por fim ele cadastra uma sessão definindo em qual sala ela ocorrerá e a qual espetáculo ela pertence.
CHUNG, Lawrence et al. Non-functional requirements in software engineering. Springer Science & Business Media, 2012.
SERRANO, Milene. Arquitetura e Desenho de Software - Aula 02. 2018. 45 slides. Material apresentado na disciplina de Arquitetura e Desenho de Software no curso de Engenharia de Software da UnB, FGA.