Atividade:
| |||||||||||||||||||||||||||||
Finalidade
|
|
Passos
|
|
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Uma vez por iteração, com a maior parte do trabalho ocorrendo nas iterações iniciais; as iterações posteriores inspecionam a atividade principalmente para validar e ajustar os aspectos analíticos da arquitetura. | |
| Papel: Arquiteto de Software | |
| Conceitos: | |
| Detalhamentos do Fluxo de Trabalho: |
A análise arquitetural concentra-se em definir uma sugestão de arquitetura e restringir as técnicas de arquitetura a serem utilizadas no sistema. Ela conta com a experiência obtida com sistemas ou domínios de problema semelhantes para restringir e enfocar a arquitetura de modo que o esforço não seja desperdiçado na 'redescoberta arquitetural'. Em sistemas nos quais já existe uma arquitetura bem-definida, é possível omitir a análise arquitetural, que é vantajosa principalmente quando se está desenvolvendo sistemas novos e inéditos.
Finalidade
|
A visão geral da arquitetura é criada no início do ciclo de vida de um projeto, possivelmente já na fase de iniciação (em Detalhamento do Fluxo de Trabalho: Realizar Síntese Arquitetural). Ela reflete as hipóteses de trabalho e decisões iniciais sobre a implementação da Visão, bem como as decisões relativas à arquitetura física e lógica e aos requisitos não-funcionais do sistema. Ela é elaborada pelo arquiteto de software, geralmente em colaboração com o patrocinador do projeto. Tem o formato de uma encenação informal rica em imagens ou de um gráfico icônico. Conceitualmente, ela ilustra a natureza essencial da solução proposta, transmitindo as idéias dominantes e incluindo os principais componentes. O nível de formalidade da visão geral da arquitetura depende do projeto. Por exemplo, em um projeto grande e com alto grau de formalidade, talvez seja necessário capturar a visão geral da arquitetura nas seções apropriadas do Documento de Arquitetura de Software para que ele possa ser formalmente revisado.
Nesse ponto, a visão geral da arquitetura é uma condição inicial provisória. Nenhuma confirmação deve ser baseada no diagrama de visão geral da arquitetura até que sejam desenvolvidos e validados o Modelo de Implantação e o Modelo de Implementação de nível superior.
Considere a possibilidade de basear a arquitetura em uma arquitetura de referência, em outros padrões de arquitetura ou em outros recursos arquiteturais.
Aperfeiçoe o diagrama de visão geral da arquitetura para maximizar sua eficácia como veículo de comunicação.
Muitos sistemas ficam restritos a serem desenvolvidos e implantados em um ambiente existente de hardware e software; nesses casos, o arquiteto de software coleta informações sobre o ambiente atual e o captura no Modelo de Implantação. Por exemplo, no projeto de desenvolvimento de um sistema de comércio eletrônico, as seguintes informações são pertinentes:
|
Finalidade
|
Conheça os requisitos do ambiente para o qual os recursos estão sendo considerados. Conheça o escopo do sistema e a funcionalidade geral necessária. Pesquise as bases de recursos organizacionais e a literatura do setor para identificar recursos ou projetos semelhantes. Existem diversos tipos de recursos a serem considerados, incluindo, entre outros, modelos da indústria, frameworks, classes e experiência. Avalie se os recursos disponíveis podem contribuir para responder aos principais desafios do projeto atual e se eles são compatíveis com as restrições correspondentes.
Analise a extensão dos ajustes entre os recursos e as necessidades do cliente. Considere se algum requisito é negociável (para permitir o uso do recurso).
Analise se o recurso pode ser modificado ou estendido para atender aos requisitos. Avalie as vantagens e desvantagens de custo, risco e funcionalidade implicadas na adoção do recurso.
Decida, em princípio, utilizar ou não um ou mais recursos e documente os fundamentos da decisão.
Finalidade
|
| Diretrizes: Divisão em Camadas |
Este passo é omitido no desempenho da Análise Arquitetural (esta atividade) como parte do Detalhamento do Fluxo de Trabalho: Realizar Síntese Arquitetural durante a iniciação.
O modelo de design normalmente é organizado em camadas - um padrão de arquitetura comum para sistemas de médio a grande porte. O número de camadas não é fixo, mas varia de acordo com a situação.
Durante a análise arquitetural, o enfoque normalmente é colocado nas duas camadas de nível superior, ou seja, as camadas de aplicativo e específicas do negócio; é isso o que quer dizer a "organização de nível superior de subsistemas." As outras camadas de nível inferior são consideradas na Atividade: Incorporar Elementos de Design Existentes. Se outros padrões de arquitetura estiverem sendo usados, os subsistemas serão definidos com base no template arquitetural.
Finalidade
|
| Mentor de Ferramentas: Documentação das classes de análise no Rational Rose |
Este passo não é omitido no desempenho da Análise Arquitetural (esta atividade) como parte do Detalhamento do Fluxo de Trabalho: Realizar Síntese Arquitetural durante a iniciação, mas somente é executado até o limite necessário para orientar o arquiteto de software na seleção dos recursos para a construção do Artefato: Prova de Conceito Arquitetural e possibilitar a construção de interações estereotipadas.
As atividades Requisitos e Modelagem de Negócios normalmente revelam conceitos-chave que devem ser tratados pelo sistema; esses conceitos manifestam-se como abstrações-chave de design. Devido ao trabalho já realizado, não é necessário repetir o trabalho de identificação durante a Atividade: Análise de Caso de Uso. Para nos beneficiarmos do conhecimento existente, identificamos as classes de análise de entidades preliminares que representam essas abstrações-chave com base no conhecimento geral do sistema, como, por exemplo, os Requisitos, o Glossário e, particularmente, o Modelo de Domínio ou o Modelo de Objetos de Negócios, caso você tenha um. Enquanto define as abstrações-chave, defina também quaisquer relacionamentos existentes entre as classes de entidade. Apresente as abstrações-chave em um ou em vários diagramas de classes e descreva-as brevemente. Dependendo do domínio e da inovação do sistema, é provável que já existam padrões de análise, que capturam muitas das abstrações-chave necessárias para modelar o sistema. O uso de tais padrões (que já devem ter sido implantados corretamente no domínio) diminuirá bastante a responsabilidade intelectual de identificar os conceitos importantes que devem ser representados. [FOW97a] apresenta alguns padrões de análise que são bastante úteis para modelar sistemas de negócios, mas que podem ser aplicáveis em outros contextos. Outro exemplo é o Object Management Group (OMG(tm)), que também está tentando definir interfaces e protocolos para muitos domínios mediante o trabalho do Domain Technology Committee (comitê de tecnologia de domínios) e forças-tarefa associadas. Inevitavelmente esse trabalho leva à identificação de importantes abstrações no domínio.
As classes de análise identificadas neste ponto provavelmente mudarão e se expandirão no decorrer do projeto. A finalidade deste passo não é identificar um conjunto de classes que permanecerão no design, mas sim identificar os conceitos-chave a serem tratados pelo sistema. Não passe muito tempo descrevendo minuciosamente as classes de entidade nessa fase inicial, pois você corre o risco de identificar classes e relacionamentos que efetivamente não são necessários para os casos de uso. Lembre-se de que você encontrará mais classes de entidade e relacionamentos ao analisar os casos de uso.
|
Finalidade
|
Utilizando a visão geral da arquitetura desenvolvida anteriormente, agora é possível desenvolver um modelo de implantação de nível superior.
Os principais impulsionadores de negócios do modelo de implantação são os seguintes:
O modelo de implantação deve poder suportar os usuários nos locais que estão realizando casos de uso e que acessam componentes, que, por sua vez, acessam dados, ao mesmo tempo em que deve atender a restrições e requisitos não-funcionais. Os componentes são temporariamente colocados em nós. Confirme se os nós e as conexões são adequados para permitir as interações entre os componentes nos diferentes nós e entre os componentes e os respectivos dados armazenados.
Se os relacionamentos entre os principais impulsionadores forem complexos, talvez seja válido identificar unidades de implantação e criar matrizes de unidades de implantação neste ponto (e não posteriormente).
São utilizados recursos, se os recursos apropriados estiverem disponíveis.
A especificação detalhada de nós e conexões é protelada, exceto quando eles forem importantes para a análise de estimativas ou viabilidade.
Embora este seja o primeiro modelo de implantação criado no projeto, observando-se que foi desenvolvido rapidamente e com um alto nível, ele pode identificar os reais produtos de hardware e software caso sejam conhecidos ou se é importante tomar essas decisões de seleção neste momento.
Finalidade
|
Este passo é omitido no desempenho da Análise Arquitetural (esta atividade) como parte do Detalhamento do Fluxo de Trabalho: Realizar Síntese Arquitetural durante a iniciação.
É possível identificar mecanismos de análise 'de cima para baixo' (conhecimento a priori) ou 'de baixo para cima' (descobertos no decorrer no processo). No modo 'de cima para baixo', a experiência orienta o arquiteto de software a reconhecer determinados problemas no domínio que exigirão determinadas soluções. Exemplos de problemas de arquitetura comuns que podem ser expressos como mecanismos durante a análise: mecanismos de persistência, gerenciamento de transações, gerenciamento de falhas, mensagens e inferência. O aspecto comum a todos esses mecanismos é que cada um deles representa uma capacidade geral de uma ampla classe de sistemas e oferece a funcionalidade que interage com ou oferece suporte à funcionalidade básica do aplicativo. Os 'mecanismos de análise' oferecem suporte a recursos contidos nos requisitos funcionais básicos do sistema, independentemente da plataforma em que são implantados ou da linguagem de implementação. Os mecanismos de análise normalmente também podem ser projetados e implementados de várias formas; geralmente haverá mais de um mecanismo de design correspondente a cada mecanismo de análise e talvez mais de uma forma de implementar cada mecanismo de design.
A abordagem 'de baixo para cima' é aquela em que os mecanismos de análise são originados: eles são criados de acordo com a visão do arquiteto de software, talvez inicialmente vaga, o que costuma ocorrer devido à existência de várias soluções para diversos problemas: é necessário permitir de alguma forma que os elementos dos diferentes threads sincronizem seus relógios, é necessário existir um modo comum de alocar recursos. A partir desses padrões se desenvolvem os mecanismos de análise que simplificam a linguagem de análise.
A identificação de um mecanismo de análise consiste em reconhecer a existência de um subproblema comum e talvez implícito (no sentido daquilo que é implicado pelos requisitos do sistema) e nomeá-lo. Inicialmente, esse nome pode ser qualquer nome já existente; por exemplo, o arquiteto de software reconhece que o sistema exigirá um 'mecanismo de persistência'. Por fim, esse mecanismo será implementado através da colaboração de uma 'sociedade de classes' (consulte [BOO98]). Algumas delas não oferecem diretamente funcionalidade de aplicativo, mas existem somente para respaldá-la. Freqüentemente, essas 'classes de suporte' ficam nas camadas intermediária ou inferior de uma arquitetura em camadas, fornecendo a todas as classes de aplicativo um serviço de suporte comum.
Se o sub-problema identificado for comum o suficiente, talvez exista um padrão a partir do qual o mecanismo possa ser instanciado, vinculando as classes existentes e implementando novas classes conforme exigido pelo padrão. Um mecanismo de análise produzido dessa forma será abstrato e exigirá posteriormente um refinamento por meio do design e da implementação.
Para obter mais informações, consulte Conceitos: Mecanismos de Análise
Finalidade
|
| Diretrizes: |
| Mentor de Ferramentas: Criação de Realizações de Casos de Uso Usando o Rational Rose |
Este passo é omitido no desempenho da Análise Arquitetural (esta atividade) como parte do Detalhamento do Fluxo de Trabalho: Realizar Síntese Arquitetural durante a iniciação.
Os Casos de Uso são o foco central de grande parte do trabalho inicial de análise e design. Para possibilitar a transição entre atividades centradas em Requisitos e atividades centradas em Design, o Artefato: Realização de Casos de Uso serve como uma ponte, permitindo reconstituir o comportamento do Modelo de Design no Modelo de Casos de Uso e organizando colaborações no Modelo de Design com base no conceito de Caso de Uso.
Crie uma Realização de Casos de Uso no Modelo de Design para cada Caso de Uso significativo do ponto de vista da arquitetura (identificado em Atividade: Priorizar Casos de Uso). O nome da Realização de Casos de Uso deve ser igual ao do Caso de Uso associado e um relacionamento de "realização" deve ser estabelecido da realização de casos de uso para o caso de uso associado.
Este passo é incluído somente no desempenho da Análise Arquitetural (esta atividade) como parte do Detalhamento do Fluxo de Trabalho: Realizar Síntese Arquitetural durante a iniciação.
A finalidade deste passo é identificar aquelas interações entre as abstrações-chave no sistema que caracterizam (ou seja, são representativas de) tipos significativos de atividades no sistema. Essas interações são capturadas como Realizações de Casos de Uso.
Finalidade
|
| Pontos de Verificação: Considerações sobre a Análise Arquitetural |
Quando a Análise Arquitetural for concluída, revise os mecanismos de arquitetura, subsistemas, pacotes e classes que foram identificados para se certificar de que estão completos e são consistentes. Como os resultados da Análise Arquitetural são preliminares e relativamente informais, as revisões devem ser igualmente informais. Cenários de casos de uso importantes devem ser utilizados para validar as opções de arquitetura feitas em diversos níveis, desde a perspectiva do negócio até as interações específicas que ocorrem.
|
Rational Unified Process
|
