Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Figura 2- Dimensões do Modelo de Projeto
Diagramas de classes Pacotes de análise Modelos CRC Diagramas de colaboração Diagramas de fluxo de dados Diagramas de fluxo de controle Narrativas de processamento
Casos de uso - texto Diagramas de casos de uso Diagramas de atividade Diagramas de raias Diagramas de colaboração Diagramas de estados Diagramas de sequência
Projeto técnico da interface Projeto de navegação Projeto da interface gráfica do usuário
Diagramas de classes Pacotes de análise Modelos CRC Diagramas de colaboração Diagramas de fluxo de dados Diagramas de fluxo de controle Narrativas de processamento Diagramas de estados Diagramas de sequência Diagramas de componentes Classes de projeto Diagramas de atividade Diagramas de sequência Realização das classes de
projeto Subsistemas Diagrama de colaboração Refinamentos para: Realizações das classes de projetos
Subsistemas
Diagramas de colaboração Elementros da
arquitetura Elementros da interface Elementros de componentes Elementros de implantação Refinamentos para: Diagramas de componentes Classes de projetos Diagramas de atividades Diagramas de sequência Requisitos: Restrições Interoperabilidade Metas e configurações
Realizações das classes de projeto Subsistemas Diagramas de colaboração Diagramas de componentes Classes de projeto Diagramas de atividade Diagramas de sequência Diagramas de implantação Modelo de análise Dimensão de Processo Alto Baixo Modelo de projeto Fonte: Pressman (2011, p. 221).
Agora, vamos conhecer um pouco de alguns desses elementos que fazem parte do Modelo de Projeto. Aproveite(m) ao máximo cada informação sobre esses projetos. Boa leitura.
PROJETO DA ARQUITETURA DO SOFTWARE
Conforme Pressman (2011, p. 229), o “projeto de arquitetura representa a estru- tura de dados e os componentes de programa necessários para construir um sistema computacional”. Quem realiza essa atividade é o arquiteto de sistemas, ele escolhe os estilos de arquitetura com base na análise de requisitos.
Você deve estar ser perguntando, porque é importante fazer um projeto de arquitetura? Já pensou em construir uma casa sem uma planta dela? Você sabe- ria por onde começar? Mas ao ver a planta de uma casa, você saberia, pois ela mostra a casa de um contexto geral, mais ampla, e com isso você pode imaginar
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
como ela será. O projeto de arquitetura é isso, ele dá uma visão geral do sistema e lhe mostra se você entendeu o contexto do sistema e o que é para desenvolver, ou seja, você pode imaginar como ele será.
O projeto arquitetural antecede a etapa de construção do software, ele deter- mina as partes da implementação e como estas devem interagir e se relacionar. A arquitetura garante a unidade e a consistência entre as partes e a sua repre- sentação serve como guia para o projeto da implementação, teste e implantação do sistema.
A arquitetura de software serve para modelar a estrutura de um sistema, por meio de dados e componentes que se relacionam entre si. Pressman (2011, p. 230) define que quando se considera a arquitetura, por exemplo, de um edifí- cio, pensamos em vários atributos diferentes, desses os mais simples até os mais complexos. Mas a arquitetura envolve mais que isso, são vários componentes inte- grados para formar um todo, que satisfaça as necessidades expressas do cliente. A arquitetura é constituída por decisões, algumas grandes e outras pequenas, e a maioria precisa ser tomada no início do Projeto e podem ter impacto em outras fases do projeto que estão por vir.
Conforme Sommerville (2011, p. 106), a arquitetura de software pode tra- balhar com dois níveis de abstração que são:
1. Arquitetura em pequena escala em que a preocupação é com a maneira como um programa individual é decomposto em componentes.
2. Arquitetura em grande escala em que a preocupação é com a arquitetura de sistemas distribuídos complexos que incluem outros sistemas, progra- mas e componentes.
Projeto da Arquitetura do Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
VISÕES DE ARQUITETURA
A arquitetura de software pode ser representada por visões de arquitetura, em que cada visão aborda um determinado conjunto de questões específicas dos que estão envolvidos no processo de desenvolvimento do sistema, como os usuários finais, os designers do projeto, gerentes de projeto, engenheiros de sistema etc.
As visões de arquitetura são usadas para a tomada das principais decisões de design estrutural, pois mostram como a arquitetura de software é decomposta em componentes. Conforme Pressman (2011, p. 232) “cada visão desenvol- vida como parte da descrição arquitetural trata uma necessidade específica do interessado”. Assim, as decisões que foram tomadas, podem mostrar uma visão sobre a estrutura do sistema e como ele foi adequado às necessidades dos inte- ressados. Sommerville (2011, p. 109) define as principais visões de arquitetura:
Cada um de nós possui uma imagem mental daquilo que a palavra arqui- tetura significa. A implicação é que os diferentes interessados verão uma arquitetura sob diversos pontos de vista orientados por conjuntos de in- teresses distintos. Isso implica que uma descrição de arquitetura é, na ver- dade, um conjunto de artefatos que refletem diferentes visões do sistema. Por exemplo, o arquiteto de um importante conjunto comercial tem de tra- balhar com uma série de interessados diferentes. O principal interesse do proprietário do conjunto comercial (um dos interessados) é garantir que ele seja esteticamente agradável e que forneça espaço e infraestrutura suficien- tes para garantir sua lucratividade. Consequentemente, o arquiteto tem de criar uma descrição usando visões de edifício que atendam os interesses do proprietário. A descrição de arquitetura de um sistema baseado em softwa- re deve apresentar características análogas àquelas citadas para o conjunto comercial.
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
■ Visão de Casos de Uso: mostra os casos de uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes ou ris- cos técnicos. É um subconjunto do modelo de casos de uso.
■ Visão Lógica: mostra as classes de design mais importantes e sua organiza- ção em pacotes e subsistemas, e a organização desses pacotes e subsistemas em camadas. É um subconjunto do modelo de design.
■ Visão de Implementação: mostra uma visão geral do modelo de imple- mentação e sua organização em termos de módulos em pacotes e camadas. É um subconjunto do modelo de implementação.
Além dessas visões, você pode incluir outras adicionais como: visão da interface do usuário, visão de segurança, visão de dados, e assim por diante. Para docu- mentar estas visões de arquitetura, você pode usar o documento de arquitetura de software. O documento de arquitetura de software é usado para fornecer uma visão geral de arquitetura do sistema, podendo usar diversas visões de arquite- tura para descrever diferentes aspectos do sistema. No próximo tópico vamos conhecer os padrões de arquitetura que são mais usados. Boa leitura!
Os modelos de arquitetura de um sistema de software podem ser usados para focar a discussão sobre os requisitos de software ou de projeto. Como alternativa, podem ser usados para documentar um projeto para que este possa ser usado como base para um projeto e uma implementação mais detalhados e para a futura evolução do sistema. É impossível representar todas as informações relevantes sobre a arquitetura de um sistema em um único modelo de arquitetura, pois cada modelo mostra apenas uma visão ou perspectiva do sistema. Pode mostrar como um sistema é decomposto em módulos, como os processos de run-time interagem, ou as diferentes formas como são distribuídos os componentes do sistema através de uma rede. Tudo isso é útil em momentos diferentes. Portanto, para ambos, proje- to e documentação, geralmente você precisa apresentar múltiplas visões da arquitetura de software.
©shutterstock
Projeto da Arquitetura do Software
Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.