Design da arquitetura do sistema e particionamento

Este conjunto de atividades representa a ponte entre especificação e implementação, concentrando-se no sistema-solução, ou imagem do problema, e o acionador do mecanismo incremental/evolutivo de desenvolvimento. A partir do levantamento de um repertório tecnológico e técnico aplicável ao sistema-solução, definem-se o conjunto de tecnologias (subconjunto do repertório) e as premissas e regras/requisitos associados à arquitetura empregada no sistema-solução, especificando a infraestrutura da arquitetura proposta, suas características e

constraints, e as interfaces entre as diferentes tecnologias. Por fim cada macro-

função é aportada na arquitetura, em uma ou mais tecnologias disponíveis, e verifica-se sua interoperabilidade com as macro-funções adjacentes.

Figura 5.7 - Arquitetura: Design da arquitetura e Particionamento

A4.1 Identificar e catalogar tecnologias aplicáveis ao sistema-solução: Esta atividade inicia o subprocesso de design no nível de sistema (system level design), que tem por objetivo implementar/transladar a especificação do sistema numa arquitetura alvo, refinando esta especificação em um conjunto de especificações particulares das tecnologias e arquitetura definidas. Desta forma a criação do repertório tecnológico é dependente da estratégia de design adotada na pesquisa.

Considerando as três principais abordagens para o design no nível de sistema (CAI, 2004) – síntese de sistema (ou co-design de hardware e software),

design baseado em plataformas e design basedo em componentes – entende-se:

• Síntese de sistema (CHOI, 2012): Pode-se definir esta abordagem como o

design cooperativo de hardware (componentes físicos) e software para

atingir os objetivos do sistema (requisitos funcionais e não-funcionais), explorando a sinergia entre estes. Esta é uma estratégia top-down que adiciona gradualmente detalhes de arquitetura e design sobre as especificações e comportamentos do sistema. De forma semelhante deve- se construir o repertório tecnológico, identificando e catalogando a cada adição as premissas de arquitetura e as tecnologias aplicáveis, suas características e decisões relacionadas.

• Design baseado em plataformas (KEUTZER et al., 2000): Em vez de gerar a arquitetura através de um processo top-down de refinamentos e adições como no co-design de hardware e software, o design baseado em plataformas mapeia os requisitos e comportamentos do sistema para uma arquitetura predefinida, ou plataforma, numa abordagem meet-in-the-middle. Desta forma o repertório tecnológico deve abranger a tecnologia presente na plataforma em si e possíveis modificações, atualizações ou adições à esta. • Design baseado em componentes (MAHMOOD et al., 2007): Nascida na

engenharia de software, o design baseado em componentes é uma estratégia bottom-up. Nesta abordagem a arquitetura surge do encadeamento e agrupamento de componentes heterogêneos existentes, através da inserção de invólucros entre e estes componentes. O repertório

tecnológico é então o conjunto das características e tecnologias de cada componente e dos invólucros criados.

A4.2 Realizar levantamento e análise de constraints, impactos e riscos associados à tecnologia: Nesta atividade deve-se ponderar sobre os riscos, impactos e constraints adicionados por uma tecnologia ou técnica particular no atendimento aos requisitos do sistema e, consequentemente, aos objetivos e propósito da pesquisa e do programa. Sendo assim, esta análise deve considerar não só os impactos que uma dada tecnologia ou premissa de arquitetura tem sobre o desenvolvimento e implementação do sistema, mas também sobre os possíveis desdobramentos deste sistema dentro do programa de pesquisa no qual está inserido.

A4.3 Definir arquitetura do sistema-solução: Do ponto de vista do processo ARES, a arquitetura do sistema-solução é a infraestrutura que permite sua realização associada a uma filosofia de design, um conjunto de regras/requisitos que restringem e guiam o design e implementação desse sistema. Deste entendimento, o objetivo desta atividade é definir, a partir do repertório tecnológico, o conjunto de tecnologias que comporá o sistema-solução, as regras de associação e de interfaces dessas tecnologias, a infraestrutura aportada no sistema e em cada tecnologia e os requisitos para o design e implementação, ou requisitos de arquitetura.

A4.4 Definir particionamento das macro-funções (Co-arquitetura): Da definição da arquitetura, ou de uma arquitetura candidata, define-se o particionamento das macro-funções. O processo de particionamento tem por base as capacidades de uma ou mais disciplinas (eletrônica analógica, eletrônica digital, software e firmware, mecânica, etc.) no cumprimento das premissas e requisitos de arquitetura no aporte de uma macro-função.

Cabe ressaltar que, nesta atividade, deve-se considerar as macro-funções como elementos integrantes do sistema e interdependentes entre si, deve-se considerar suas interações com as demais macro-funções e como estas interações serão resolvidas dentro da arquitetura proposta. Deve-se considerar ainda o impacto que esta proposta de arquitetura e as tecnologias empregas no

particionamento de uma macro-função exercem sobre ela e o impacto que esta exerce sobre as tecnologias e arquitetura. Desta forma não se exclui, nesta atividade, a adição de elementos ao sistema a fim de estabelecer o “casamento de impedância” entre as macro-funções e as tecnologias.

A4.5 Aportar macro-funções nas tecnologias designadas: Com o particionamento e distribuição das macro-funções nas tecnologias e arquitetura propostas para o sistema-solução, cada macro-função é modela segundo as premissas e requisitos de arquitetura para as tecnologias nas quais será aportada e implementada. Noutras palavras, tem-se um conjunto de modelos, ou mesmo um modelo único, que representa o sistema-solução sobre uma abstração da arquitetura proposta.

A4.6 Verificar interoperabilidade da estratégia de arquitetura: Verificar a estratégia de arquitetura é verificar as interações entre as macro-funções aportadas nesta arquitetura confrontando-as com a interoperabilidade do modelo em “caixa branca” do sistema-solução. Destarte, para cada macro-função presente num cenário de interoperabilidade específico: substitui-se essa macro-função por seu símile no modelo de arquitetura; executa-se, em ambiente simulável, o cenário de interoperabilidade correspondente, e; confrontam-se os resultados dessa simulação com as métricas e critérios presentes no workbench de verificação e interoperabilidade.

A4.7 Definir plano de design e implementação: Cada disciplina envolvida no desenvolvimento do sistema possui seu próprio ciclo de desenvolvimento, por exemplo, as etapas e atividades e os recursos destinados à elaboração e implementação de uma interface homem-máquina diferem completamente daqueles empregados no design, fabricação e montagem de placas de circuitos impressos. Como consequência, o design e implementação do sistema deve considerar as características particulares de cada disciplina e do sistema-solução, bem como da equipe envolvida e da infraestrutura disponível para o desenvolvimento, terceiros e demais envolvidos, segmentando o desenvolvimento em etapas, alocando os recursos necessários e determinando o prazo e a sequência para a execução de cada uma dessas.

Este planejamento é similar àquele proposto no processo FDD (PALMER; FELSING, 2002), entretanto a segmentação do desenvolvimento não se dá por funcionalidades, mas pela agregação de macro-funções e disciplinas. Sendo assim, para cada grupo de desenvolvedores numa disciplina, atribui-se um conjunto de macro-funções – numa sequência de desenvolvimento específica – aportadas nas tecnologias de domínio dessa disciplina ou grupo particular, considerando o tamanho da equipe, o tempo e os recursos disponíveis para o desenvolvimento. A4.8 Revisar e atualizar plano de desenvolvimento: Revisar, modificar e atualizar o plano de desenvolvimento, transição e validação com as decisões e comuns- acordos estabelecidos, acrescentando ou alterando informações quanto a realização da pesquisa e refinando as estimativas feitas.