INICIO

Contents

• Architecture Background
  • Problem Background
    • System Overview
    • Context
    • Driving Requirements
      • Functional requirements
    • DIAGRAMA DE CENÁRIOS
      • Quality attributes
        • Funcionalidade
        • Usabilidade
        • Confiabilidade (Reliability)
        • Desempenho (Performance)
        • Suportabilidade
        • Design constraints
        • Implementation constraints
        • Interface constraints
        • Physical constraints
  • Solution Background
    • Architectural Approaches
    • Analysis Results
    • Mapping Requirements to Architecture
      • Acesso aos Requisitos Funcionais: CASOS DE USO
      • MODELO DE DOMÍNIO

Architecture Background

Architecture Background provides information about the software architecture, by:

• describing the background and rationale for the software architecture;
• explaining the constraints and influences that led to the current architecture;
• describing the major architectural approaches that have been utilized in the architecture.

Problem Background

The sub-parts of this section explain the constraints that provided the significant influence over the architecture.

System Overview

This section describes the general function and purpose for the system or subsystem whose architecture is described in this SAD.

A Graphs4Social pretende um sistema de rede social que detém um jogo onde o objetivo principal é que um utilizador se ligue a outros e cada uma dessas ligações dá pontos que serão apresentados numa leaderboard, o que tiver mais é o vencedor.

Context

This section describes the goals and major contextual factors for the software architecture. The section includes a description of the role software architecture plays in the life cycle, the relationship to system engineering results and artifacts, and any other relevant factors.

A Graphs4Social, S.A. é uma startup1 com sede no Porto (Portugal) cuja missão é fornecer aplicações de manipulação e visualização de grafos de redes sociais. A empresa decidiu recentemente expandir o sue portfolio de produtos entrando na área de jogos, mas mantendo o foco nos grafos de redes sociais. A empresa decidiu recorrer à subcontratação de serviços de desenvolvimento uma vez que não possui capacidade livre de momento.

NB: Contudo, o sistema aqui pedido é uma simplificação daquilo que é uma rede social, pelo que são assumidas simplificações para tornar o projeto exequível neste âmbito (i.e. 5º semestre da LEI).

Este SAD serve de base para debate sobre o sistema a construir (a implementar, testar e implantar), e pretende-se que esteja alinhado com o sistema construído. Para além do óbvio na descrição duma arquitetura de software, deve identificar alternativas de design e ponto de variação.

Driving Requirements

This section lists the functional requirements, quality attributes and design constraints. It may point to a separate requirements document.

Functional requirements

1. Como utilizador, quero poder editar relacionamento com tags e força de ligação.
2. Como utilizador, quero poder editar o meu próprio perfil.
3. Como utilizador, quero poder atualizar o meu estado de humor.
4. Como utilizador, quero consultar a rede a partir da minha perspetiva.
5. Como utilizador(não-autenticado), quero conseguir registar-me como utilizador no sistema.
6. Como utilizador, quero escolher quais utilizadores objetivo sugeridos pelo sistema, enquanto recém registado, gostaria de ter na minha rede.
7. Como utilizador, quero poder pesquisar utilizadores que conheça na rede, e pedir ligação de utilizador.
8. Como utilizador, quero poder pedir introdução ao utilizador objetivo.
9. Como utilizador, quero aprovar/desaprovar um pedido de introdução.
10. Como utilizador, quero aceitar ou rejeitar um pedido de introdução.
11. Como utilizador, quero obter a lista de pedidos de ligação pendentes.

-------------Tasks-------------

12. Planear o esqueleto da aplicação. Identificar que módulos e interfaces (detalhadas) de cada módulo. Identificar diferenças de terminologia, se existirem, entre o vários dominios.
13. Setup dos projetos e repositórios Git (Bitbucket).
14. Design arquitetural: o Nível 1: vista lógica e de cenários, Nível 2: vista lógica, de processo, de implementação e física, Nível 3 (Master Data Rede): vista lógica, de processo e de implementação, Adoção de estilos/padrões: cliente-servidor, SOA, DDD, Onion (inclui DI, IoC), DTO.
15. Tecnologia: .Net C#, SGBD relacional (e.g. MS SQL Server), ORM (e.g. Entity Framework).
16. Testes unitários e de integração (com isolamento via mocks).
17. Implantação na cloud (e.g. Heroku, MongoDB Atlas).
18. Pipelines (Bitbucket Pipelines).

DIAGRAMA DE CENÁRIOS

Quality attributes

Os atributos de qualidade são categorizados e sistematizados segundo o modelo FURPS+.

FURPS é um acrónimo que representa um modelo para classificação de atributos de qualidade de software (requisitos funcionais e não-funcionais) distribuído da seguinte forma:

Funcionalidade

1. Um utilizador deve conseguir registar-se com as suas credenciais e aceder à sua conta.
2. Deve ser auditada e verificada a integridade da informação a que os sistemas acedem.
3. Com vista à necessidade de saber e necessidade de conhecer, toda a informação deve estar protegida de acessos indevidos. Ou seja, o princípio de minimização de acesso ao que é essencial para cada utilizador/aplicação, criação de túneis para transferência de informação, avaliação da integridade de dados e aplicações, e encriptação/minimização dos dados.

Usabilidade

4. A SPA deve permitir acesso a todos os módulos do sistema: master data, planeamento e visualização, bem como RGPD.

5. No âmbito do projeto atual, a administração de utilizadores pode ser efetuada diretamente na base de dados não sendo necessário um módulo de gestão de utilizadores.

Confiabilidade (Reliability)

6. A base de dados está normalizada segundo as normas. Assim, a duplicidade de dados é mínima e a confiabilidade da base de dados é elevada.

7. Os protocolos http já estão implementados na framework do .NET pelo que só têm de ser personalizados.

Desempenho (Performance)

n/a

Suportabilidade

8. Embora não esteja no âmbito atual do projeto, deve ser levado em conta na arquitetura da solução, a extensão futura para aplicações móveis.

Design constraints

9. O sistema deve ser composto por uma aplicação web do tipo Single Page Application (SPA) que permite aos utilizadores autorizados acederem aos diferentes módulos da aplicação, bem como por um conjunto de serviços que implementem as componentes de regras de negócio necessárias para o funcionamento da aplicação web.

De um modo geral, as principais funcionalidades de cada módulo são as seguintes:

• Master data Rede Social – permite a gestão da informação relacionada com a rede: relações, missões, posts, pedidos de ligação, pedidos de introdução.
• Visualizador 3D – permite a visualização 2D e 3D da rede, a navegação pela cena e a consulta gráfica de informação sobre as viagens. Consome a informação gerida no módulo Master Data Rede Social e no módulo de inteligência artificial.
• Inteligência Artificial - permite os cálculos de sugestões para utilizadores objetivo, entre outras funcionalidades de algoritmia avançada. Consome informação dos utilizadores do módulo Master Data Rede Social e do módulo de Visualização.

10. No âmbito do projeto atual, a administração de utilizadores pode ser efetuada diretamente na base de dados não sendo necessário um módulo de gestão de utilizadores.

11. Embora não esteja no âmbito atual do projeto, deve ser levado em conta na arquitetura da solução, a extensão futura para aplicações móveis.

Implementation constraints

12. Todos os módulos devem fazer parte do código fonte da mesma SPA e serem disponibilizados como um único artefacto.

Interface constraints

13. A SPA deve permitir acesso a todos os módulos do sistema: master data rede social (SITE), inteligência artificial ( AI) e visualização (GRAFICO), bem como RGPD.
14. O módulo master data rede social consome dados de utilizadores da rede vindos do módulo de visualização e pode reencaminhar pra este ou para o módulo de inteligência artifical.
15. O módulo de visualização envia/recebe dados de utilizadores para o módulo master data rede social ou para o módulo de inteligência artificial.
16. O módulo de inteligência artifical envia/calcula/recebe dados de utilizadores para os módulos master data rede social e para o módulo de inteligência artifical.

Physical constraints

17. Existem dois servidores em load balancing, onde estão instaladas as aplicações, serviços e as bases de dados e que se encarregam do armazenamento da informação.

Solution Background

The sub-parts of this section provide a description of why the architecture is the way that it is, and a convincing argument that the architecture is the right one to satisfy the behavioral and quality attribute goals levied upon it.

Architectural Approaches

This section provides a rationale for the major design decisions embodied by the software architecture. It describes any design approaches applied to the software architecture, including the use of architectural styles or design patterns, when the scope of those approaches transcends any single architectural view. The section also provides a rationale for the selection of those approaches. It also describes any significant alternatives that were seriously considered and why they were ultimately rejected. The section describes any relevant COTS issues, including any associated trade studies.

Baseado nos requisitos não funcionais e restrições de design, serão adotadas as seguintes abordagens/padrões/estilos:

• Client-Server, porque cada um dos "módulos" MDRS, IA, GRÁFICO são aplicações servidoras de outras aplicações clientes;
• Web Application, em que o frontend é desempenhado por uma SPA (Single Page Application), e que o backend é desempenhado pelos módulos IA e Master Data Rede Social;
• SOA, porque os servidores (cf. anterior) deverão disponibilizar API, e particularmemte API para serem usadas na web, disponibilizados serviços para os clientes respetivos. Serão adotados os nível 0, 1 e 2 do Modelo de Maturidade de Richardson aplicado a REST;
• Layered architecture, mais especificamente Onion Architecture, por razões académicas;
• Padrões GRASP, SOLID e GoF.

Outras abordagens/estilos/padrões, como e.g. interligação entre aplicações baseado em mensagens-eventos foram desconsideradas para não violar os requisitos e restrições definidos, mas também por questões académicas.

Analysis Results

This section describes the results of any quantitative or qualitative analyses that have been performed that provide evidence that the software architecture is fit for purpose. If an Architecture Tradeoff Analysis Method evaluation has been performed, it is included in the analysis sections of its final report. This section refers to the results of any other relevant trade studies, quantitative modeling, or other analysis results.

Não existem por agora resultados de análise ou avaliação. Estudos qualitativos acerca dos estilos/padrões adotados ( nomeadamente Onion em MDRS, mas também Dependency Injection na UI), permitem empiricamente advogar que a manutenibilidade, evolutabilidade e testabilidade do software são elevadas, ao mesmo tempo que permitem atingir as funcionalidades desejadas.

Mapping Requirements to Architecture

This section describes the requirements (original or derived) addressed by the software architecture, with a short statement about where in the architecture each requirement is addressed.

Acesso aos Requisitos Funcionais: CASOS DE USO

UC	LINK
3	ACEDER
4	ACEDER
5	ACEDER
6	ACEDER
7	ACEDER
8	ACEDER
9	ACEDER
10	ACEDER
11	ACEDER
12	ACEDER
13	ACEDER
14	ACEDER
16	ACEDER
17	ACEDER
18	ACEDER
19	ACEDER
20	ACEDER
21	ACEDER
22a	ACEDER
22b	ACEDER
24	ACEDER
25	ACEDER
26	ACEDER
27	ACEDER
28	ACEDER
33	ACEDER
35	ACEDER

MODELO DE DOMÍNIO