Derivação da Arquitetura Lógica e Modelos de Domínio da Solução

Reunida a informação sobre as necessidades específicas do domínio, pode-se agora avançar

para a conceção de uma arquitetura lógica de nível de processo alinhada com as necessidades do domínio. Esta secção inicia com a apresentação da forma como foi derivada a arquitetura lógica de nível de processo do sistema pretendido (subsecção 4.3.1) e como esta foi validada

(subsecção 4.3.2).

4.3.1 Derivação da Arquitetura Lógica

De modo a assegurar o alinhamento da arquitetura lógica de nível de processo com as necessidades específicas de domínio ou com os modelos de casos de uso, o modelo V sugere a

execução do método 4SRS.

Tradicionalmente, o método 4SRS é aplicado numa perspetiva de nível de produto, contudo

recentemente surgiu um método adaptado e estendido do 4SRS que permite a aplicação numa perspetiva de nível de processo (Ferreira et al. 2012).

Nesta perspetiva de nível de processo, o 4SRS utiliza como

input

as representações (e correspondentes descrições textuais) dos casos de uso para transformar (recorrendo a transformações tabulares) as necessidades dos utilizadores (os casos de uso) em elementos

arquiteturais (AEs) de forma a criar uma representação da arquitetura lógica do sistema.

A sua aplicação difere da tradicional pela definição de um conjunto de regras que devem ser consideradas quando se raciocina sobre a execução dos passos do método e pela existência de

novos micro-passos. É também de destacar que a natureza do termo elemento arquitetural pode variar, mas no contexto específico de arquiteturas lógicas este refere-se às partes a partir do qual

a arquitetura lógica final pode ser construída (Ferreira et al. 2012).

Uma vez que a descrição da aplicação do método 4SRS, numa perspetiva de nível de processo,

é completamente realizada na literatura (Ferreira et al. 2012), e pode ser usado como descrito nessa obra, por razões de inteligibilidade, de seguida é apresentado apenas uma breve explicação da estrutura do método e da aplicação.

De forma a transformar os casos de uso em AEs, o método 4SRS está organizado em quatro passos que podem ser suportados por representações tabulares, onde cada coluna tem seu

primeiro passo (criação de elementos arquiteturais) cria automaticamente três tipos de AEs para

cada caso de uso: um do tipo i (interface), um do tipo c (controlo) e um do tipo d (dados). O segundo passo (eliminação de elementos arquiteturais) remove automaticamente a redundância

dos requisitos herdados pelos casos de uso, e promove a descoberta de novos requisitos. O terceiro passo (agregação de elementos arquiteturais) agrupa semanticamente elementos arquiteturais em

packages

e permite representar agregações. Por fim, o passo 4 (associação de elementos arquiteturais) tem como objetivo representar as associações entre os elementos arquiteturais que “sobreviveram” aos passos anteriores.

Figura 26 – Transformações tabulares do método 4SRS (adaptado de (Ferreira, Santos, Machado, et al. 2013)).

Para o caso prático deste trabalho, como

input

para o método 4SRS, foram utilizados os casos de uso correspondentes aos “folha” da estrutura em árvore do processo de decomposição (i.e.

os casos de uso a cinzento na Figura 25), uma vez que representam a informação mais detalhada e completa alcançada do processo de identificação das necessidades de negócio.

Step 1: Architectural element creation

2i – User case classification

Step 2: Architectural element elimination 2ii – Local elimination

2iii – Architectural element naming

2iv – Architectural element description

2v – Architectural element representation 2vi – Global elimination

2vii – Architectural element naming

2vii – Architectural element specification

Step 3: Packaging & aggregation

2i – Direct associations

Step 4: Architectural element association 2ii – UC associations

Como resultado deste trabalho, foi criado um diagrama lógico que representa as funcionalidades

da arquitetura lógica de nível processo da SLT Solution.

Após terminada a execução completa do 4SRS, algumas informações estatísticas sobre os AEs

mantidos e eliminados foram possíveis de extrair das transformações tabulares. Conforme apresenta a Figura 27, os dados estatísticos revelam que os 39 casos de uso utilizados como

input

deram origem a 142 elementos arquiteturais, dos quais mantiveram-se 66 até o final das

transformações tabulares. Estes dados que foram criados representam quase 40% de elementos arquiteturais a mais do que os casos de uso iniciais, ou seja, a execução do 4SRS permitiu uma

representação mais detalhada e expressiva do sistema em estudo, ao mesmo tempo diminui a redundância e valida o diagrama de arquitetura lógica derivada.

Figura 27 – Dados estatísticos da execução do 4SRS.

No final da execução do 4SRS foi também construído uma representação das funcionalidades da arquitetura lógica de nível processo da SLT Solution. A arquitetura lógica derivada é composta

pelos elementos da arquitetura que sobreviveram após a execução do passo 2. Os

packages

que resultaram da execução do passo 3 permitem a identificação dos principais processos. E as

associações identificadas no passo 4 são representadas no diagrama pelas ligações entre os elementos da arquitetura.

Analisando a arquitetura lógica derivada (diagrama lógico da Figura 28), é possível concluir que

existe uma interdependência visível entre os

macro-packages

da arquitetura lógica. Para além disso, é também verificada a existência de processos que apresentam uma dependência

temporal ({P1} Schedule Planning, {P2} Operation Order Execution, {P3.2} Task Monitoring, {P4} Incident Communication e {P5} Assistances) e outros que são transversais a todo sistema ({P6} Configurations e {P3.1} Data Monitoring). Por um lado, a execução do processo transversal, {P6}

Configurations, influência o comportamento de todos os outros processos do sistema. Por outro, um processo de dependência temporal, como o {P2} Operation Order Execution, é apenas uma

parte integrante de um processo que também estimulará o início de outros processos de

dependência temporal, como o {P3.2} Task Monitoring e {P4.2} Detect Incidents.

Para os processos {P1} Schedule Planning, {P2} Operation Order Execution, {P3} Activity

Monitoring, {P4} Incident Communication e {P5} Assistances a execução típica inicia com um

input

a partir de elementos arquiteturais referentes a decisões humanas, de seguida o fluxo de

informação é tratado a partir dos elementos arquiteturais de decisões de sistema e finaliza com

um

output

através de elementos arquiteturais de interfaces. Apenas, para o processo {P6}

Configurations, a execução começa a partir das decisões humanas e vai diretamente para

camada de apresentação, porque não há necessidade de qualquer decisão do SLT Solution numa perspetiva de nível de processo.

4.3.2 Diagramas de Sequência do Tipo B

Nesta fase final do modelo V procede-se à definição dos processos relativos à arquitetura lógica derivada na secção 4.3.1. Na presente subsecção elucida-se então, o modo como foram

abordados e definidos esses processos, e apresenta-se ainda o conjunto alcançado dos mesmos.

De modo a assegurar uma correta definição dos processos relativos à arquitetura lógica derivada, o modelo V sugere a realização de uma atividade de testes através da modelação de

diagramas de sequência do tipo B.

Estes representam a troca de informações entre atores e elementos arquiteturais da arquitetura

lógica e admitem duas distintas validações, nomeadamente: a validação da arquitetura lógica derivada e a validação das sequências, sendo estas últimas representadas pelos diagramas de sequência do tipo A. Estas validações compreendem, respetivamente, a deteção da falta de

elementos arquiteturais e/ou associações para executar um determinado processo dentro de arquitetura lógica derivada (subsecção 4.3.1); e a verificação de uma relação conforme entre os

fluxos de sequência associados aos casos de uso dos diagramas do tipo A e os fluxos de sequência associados aos elementos arquiteturais dos diagramas do tipo B.

Assim, durante o processo de modelação de diagramas do tipo B, devem-se considerar pelo

menos três aspetos. Assinalam-se portanto as necessidades de assegurar que as sequências do processo modeladas para os diagramas do tipo B exponham os mesmos fluxos que as

sequências de processo modeladas para os diagramas do tipo A; garantir a conformidade dos diagramas do tipo B com os elementos arquiteturais,

packages

e associações definidos na arquitetura lógica de nível de processo derivada; e por último, ter em conta o número de

diagramas do tipo B a modelar, asseverando que todos os elementos arquiteturais são utilizados.

No âmbito do caso prático desta dissertação, foi modelado um conjunto de diagramas de

sequência do tipo B com a intenção de representar as principais execuções de processos possíveis em relação à arquitetura lógica do SLT Solution (consultar secção B.4 em anexo). Estes

diagramas de sequência foram modelados de forma estereotipada, utilizando os elementos arquiteturais, os atores e

packages

(i.e. diferem dos tradicionais).

A predileção pelos processos representados deriva dos cenários de execução previamente

definidos, na secção 4.2.2, como críticos para a realização de negócio. Como exemplo, na Figura 29 são apresentadas as mesmas atividades (do diagrama de sequência do tipo A

disponibilidade de um nó para a execução de ordens de operação, todavia num nível inferior de

abstração.

Figura 29 – Diagrama de sequência do tipo B, parking.

Com a conclusão desta fase, pululou a primeira versão do contexto para a conceção do sistema

de software pretendido.

No documento Computação em nuvem em sistemas logísticos de transportes: análise de um caso prático (páginas 87-92)