Arquitetura de Sistemas

Prévia do material em texto

Arquitetura de Sistemas 
Marcio Quirino - 1 
 
SUMÁRIO 
Introdução .............................................................................................................................................. 5 
Componentes de Sistemas .................................................................................................................... 5 
Introdução ........................................................................................................................................... 5 
Fundamentos de componentes.......................................................................................................... 5 
União de dados e funções .......................................................................................................................... 5 
Encapsulamento ......................................................................................................................................... 5 
Identidade .................................................................................................................................................. 5 
O que é um componente afinal? ........................................................................................................ 6 
Arquitetura de sistemas baseada em componentes ................................................................................... 6 
Objetivos de componentes ......................................................................................................................... 6 
Características de componentes ................................................................................................................ 6 
Exemplo de uso de componentes .......................................................................................................... 7 
O que não é um componente? ................................................................................................................... 8 
Definição de arquitetura de sistemas e componentes ...................................................................... 8 
Arquitetura de sistema ............................................................................................................................... 8 
Arquitetura de componentes ...................................................................................................................... 8 
Arquiteturas de sistemas .................................................................................................................... 8 
Camadas da arquitetura de sistemas ......................................................................................................... 9 
Arquitetura de componentes .............................................................................................................. 9 
Relação entre especificação de componentes e interfaces ....................................................................... 9 
Níveis de modelo .............................................................................................................................. 10 
Exercício ........................................................................................................................................... 10 
O processo de desenvolvimento ......................................................................................................... 12 
Introdução ......................................................................................................................................... 12 
Workflow ........................................................................................................................................... 12 
O gerenciamento de processos ....................................................................................................... 13 
Diferenças entre métodos ................................................................................................................ 14 
Objetivos da metodologia de desenvolvimento ............................................................................... 14 
Objetivos da metodologia de gestão................................................................................................ 15 
Interação entre componentes .......................................................................................................... 15 
Especificação de componentes ....................................................................................................... 16 
Atividade ........................................................................................................................................... 16 
Aplicando UML ..................................................................................................................................... 19 
Introdução ......................................................................................................................................... 19 
Porque precisamos de UML na arquitetura de sistemas? .............................................................. 19 
UML e suas generalizações ............................................................................................................. 19 
Como atingir conformidade em requisitos com UML? .................................................................... 20 
Técnicas de modelagem UML ......................................................................................................... 20 
Arquitetura de Sistemas 
Marcio Quirino - 2 
 
Modelo conceitual de negócio.......................................................................................................... 20 
Modelo conceitual de sistemas ........................................................................................................ 21 
Diagrama de casos de uso ....................................................................................................................... 21 
Relação entre objetos .............................................................................................................................. 21 
Descrição de casos de uso ...................................................................................................................... 22 
Diagrama de domínio ....................................................................................................................... 23 
Especificação de interface ............................................................................................................... 23 
Atividade proposta ............................................................................................................................ 23 
Definição de Requisitos ....................................................................................................................... 27 
Introdução ......................................................................................................................................... 27 
Definição de requisitos ..................................................................................................................... 27 
Diferenças no levantamento dos requisitos: ............................................................................................. 27 
Diagrama de Funcionalidades de Interface: ......................................................................................... 27 
Requisitos vistos com muita importância:............................................................................................. 27 
Conceito Intermediário: ........................................................................................................................ 28 
Requisitos de sistemas .................................................................................................................... 28 
Esforço máximo e resultados esperados na etapa de requisitos .............................................................28 
Tipos de requisitos ................................................................................................................................... 28 
Funcionais e Não funcionais ................................................................................................................ 29 
Implícitos e Explícitos ........................................................................................................................... 29 
Framework de conhecimentos em TI como base para requisitos ............................................................ 29 
Reunião de levantamento de requisitos ................................................................................................... 29 
Validação de requisitos ............................................................................................................................ 30 
Pré-Validação de Requisitos: ............................................................................................................... 30 
Prototipação: ........................................................................................................................................ 30 
Mas o que é um conceito de modelo conceitual forte? ................................................................... 30 
E o modelo conceitual fraco? ........................................................................................................... 31 
Como criar para a TI um modelo conceitual forte? ......................................................................... 31 
Modelagem conceitual de negócios e de sistemas a partir dos requisitos validados .................... 31 
Resultados esperados .............................................................................................................................. 32 
Atividade ........................................................................................................................................... 32 
Identificação de Componentes ............................................................................................................ 34 
Introdução ......................................................................................................................................... 34 
Identificação de componentes ......................................................................................................... 34 
Perguntas associadas aos modelos de negócios ........................................................................... 35 
Artefatos e subprocessos de desenvolvimento do modelo de negócios ........................................ 35 
Artefato modelo de negócios .................................................................................................................... 35 
Subprocesso identificação de interfaces de negócio................................................................................ 36 
Artefato interface de negócios .................................................................................................................. 36 
Arquitetura de Sistemas 
Marcio Quirino - 3 
 
Subprocesso identificação de interfaces de sistemas e regras de negócio ................................... 36 
Artefato interface de sistemas .................................................................................................................. 36 
Subprocesso especificação de componentes e arquitetura do sistema ......................................... 37 
Atividade ........................................................................................................................................... 37 
Interação de Componentes – Parte I ................................................................................................... 39 
Introdução ......................................................................................................................................... 39 
Interação de componentes ............................................................................................................... 39 
Definir operações de negócios......................................................................................................... 40 
Refinar interfaces e regras de negócio ............................................................................................ 40 
Refinar definição de componentes e arquitetura ............................................................................. 41 
Atividade ........................................................................................................................................... 42 
Interação de Componentes: Parte II .................................................................................................... 46 
Introdução ......................................................................................................................................... 46 
Complexidade de sistemas .............................................................................................................. 46 
Componentes de uma arquitetura de sistemas ............................................................................... 46 
Divisão estrutural de componentes .................................................................................................. 47 
Camadas como elementos de controle da interação de componentes .......................................... 47 
Exemplo de sistema de gerenciamento de versão.......................................................................... 48 
Vantagens e desvantagens do uso de camadas ............................................................................. 48 
Vantagens: ............................................................................................................................................... 48 
Desvantagens: ......................................................................................................................................... 48 
Elementos da RUP (Rational Unified Process) ............................................................................... 48 
Elementos de implementação que afetam a arquitetura de sistemas ............................................ 49 
Papel do arquiteto de sistemas na interação de componentes ...................................................... 49 
Padrão arquitetura MVC (Model View Controller) ........................................................................... 49 
Interação de componentes com AOS (Arquitetura Orientada a Serviços) ..................................... 50 
Atividade ........................................................................................................................................... 51 
Especificação de componentes ........................................................................................................... 54 
Introdução ......................................................................................................................................... 54 
Definição de especificação de componentes .................................................................................. 54 
Tipos de componentes ..................................................................................................................... 55 
Especificação de componentes a serem desenvolvidos .......................................................................... 55 
Metodologia/padrões ........................................................................................................................ 56 
Empacotamento de componentes ................................................................................................... 56 
Distribuição de componentes ........................................................................................................... 57 
Implementação de componentes .....................................................................................................57 
Atividade ........................................................................................................................................... 58 
Provisionamento e Construção – Parte I ............................................................................................. 61 
Arquitetura de Sistemas 
Marcio Quirino - 4 
 
Introdução ......................................................................................................................................... 61 
Componentes ................................................................................................................................... 61 
Ambiente de componentes ....................................................................................................................... 61 
Framework CCM – CORBA Component Model .............................................................................. 62 
Níveis de componentes do CCM .............................................................................................................. 62 
Cinco tipos de modelos do CCM .............................................................................................................. 62 
Arquivos CIDL .......................................................................................................................................... 63 
Arquivos CIF............................................................................................................................................. 63 
Containers ........................................................................................................................................ 64 
Funcionalidades: ...................................................................................................................................... 64 
Gerenciamento do ciclo de vida ............................................................................................................... 64 
Empacotamentos e distribuição ....................................................................................................... 64 
Atividade ........................................................................................................................................... 65 
Provisionamento e Construção – Parte II ............................................................................................ 67 
Introdução ......................................................................................................................................... 67 
Especificação de Componentes x Construção de Componentes ................................................... 67 
Mapeamento de construção e restrições ......................................................................................... 67 
Heranças de interface e suporte de interfaces ................................................................................ 68 
COM + ...................................................................................................................................................... 68 
EJB ........................................................................................................................................................... 68 
Propriedades de interfaces .............................................................................................................. 68 
Criação de objetos ........................................................................................................................... 69 
Correspondências da arquitetura da aplicação ............................................................................... 69 
Subcomponentes.............................................................................................................................. 70 
Instâncias são criadas por operações específicas ................................................................................... 71 
Interação com sistemas existentes .................................................................................................. 71 
Construção ............................................................................................................................................... 71 
Atividade ........................................................................................................................................... 72 
Arquitetura de Sistemas 
Marcio Quirino - 5 
 
Arquitetura de Sistemas 
Introdução 
Esta disciplina tem por objetivo estudar a teoria que envolve a criação de arquiteturas de sistemas, 
enfatizando modelos, artefatos e linguagens de descrição de arquiteturas. 
Além disso, serão apresentados os conceitos e modelos de arquitetura de sistemas, reuso de 
software, tubos e filtros, camadas, modelo-visão-controle, visões de arquitetura, componentes, linguagens 
de descrição de arquiteturas, arquitetura orientada a serviço e arquiteturas baseadas em componentes. 
Componentes de Sistemas 
Introdução 
O conceito principal do uso de componentes está relacionado ao ditado “dividir para conquistar”. 
Isso significa gerenciar a complexidade, quebrando um grande problema em pedaços menores a 
serem desenvolvidos. Na sequência, integra-se esses pequenos módulos simples para resolver problemas 
complexos. 
Componentes seguem essa definição para sua construção, com a diferença que estão relacionados 
a objetos de negócio, dados, interfaces que combinadas resolvem os problemas apresentados. 
Quando resolvemos criar um sistema de informação, utilizando a abordagem de componentes, será 
necessário primeiro mapear esses componentes em modelos conceituais, depois construi-los 
separadamente e, somente ao final, integrá-los para a solução do problema. 
Bons estudos! 
Fundamentos de componentes 
Componentes, no contexto da arquitetura de sistemas, são unidades de software estruturados de 
acordo com alguns princípios específicos. 
Os princípios fundamentais que regem os componentes estão relacionados ao conceito de objetos, 
conforme descrito a seguir: 
União de dados e funções 
Um objeto de software consiste em dados que podem assumir valores e funções que tratam esses 
dados. Os dados e funções devem ter uma ligação natural entre eles, formando o conceito de classe. 
Encapsulamento 
Conceito de esconder de quem vai usar a classe os detalhes de sua funcionalidade e de dados, 
deixando amostra somente como acionar e o resultado a ser alcançado pelo acionamento. 
Não importa para quem vai usar tal componente, como as coisas acontecem dentro dele, e, sim, se 
o resultado esperado foi alcançado. 
Identidade 
Cada componente encapsulado tem uma identidade única de dados e funções e pode assumir 
estados pré-determinados. 
Arquitetura de Sistemas 
Marcio Quirino - 6 
 
O que é um componente afinal? 
Um componente, então, é um objeto, derivado (instanciado) de uma classe, com uma assinatura 
explícita chamada de interface! 
Podemos, assim, ter mais de uma interface em um mesmo componente. 
Deve existir nos componentes uma relação natural como o que ele representa. Por exemplo, o 
componente "pessoa" está associado à classe "pessoa" no mundo real. 
Arquitetura de sistemas baseada em componentes 
 
 
A arquitetura de sistemas baseada em componentes, então, está relacionada à identificação das 
interfaces possíveis e disponíveis e como elas resolvem os problemas que se apresentam. 
Esse conceito facilita muito o desenvolvimento e reduz o nível de mudança nos sistemas gerados. 
Objetivos de componentes 
A partir de um objeto simples estruturado (componente), é necessário combinar funcionalidade e 
dados para resolver os problemas em sistemas computacionais. 
O grande desafio na abordagem por componentes na arquitetura de sistemas está em conseguirmos 
identificar claramente as interfaces e como elas resolvem os problemas que se apresentam. Isso está 
relacionado às dependências entre componentes. 
Pode até ser uma surpresapara alguns que, quando definem seus objetos, estão pensando somente 
na reutilização e não em como suas interfaces se relacionam em contextos variados. 
Atenção 
Quando pensamos em componentes a partir de suas interfaces, criamos um número maior de possibilidades 
de uso e reduzimos significativamente o número de mudanças futuras. 
Características de componentes 
Existem vários conceitos que podem definir os objetivos de um componente, todos com real validade, 
mas podemos afirmar que um componente contém as características necessárias para resolver problemas 
de forma natural e relacionado ao mundo real. 
Vamos ver algumas delas: 
1. Ser capaz de montar uma aplicação, ligando componentes que devem atender a padrões 
pré-definidos e estarem agrupados por categoria, dentro do conceito de "caixa de 
componentes". Esses componentes devem se encaixar a outros (através de suas 
interfaces), para resolver os problemas; 
Arquitetura de Sistemas 
Marcio Quirino - 7 
 
2. O uso dado aos componentes, então, pode variar, de acordo com a necessidade e 
experiência de cada arquiteto de sistemas; 
3. Quando você, arquiteto de sistemas, for utilizar os componentes para criar suas aplicações, 
é necessário identificar bem as interfaces e como estas se ligam a outros componentes; 
4. Para que isso seja possível é necessário que as interfaces estejam bem especificadas e 
claras; 
5. Se as interfaces dos componentes estiverem bem definidas, será possível trocar 
componentes sem afetar os resultados da aplicação e sem a necessidade de mudanças de 
códigos; 
6. Caso não estejam bem definidas, essas facilidades e funcionalidades podem ser perdidas; 
7. As características de funcionalidade de um determinado componente devem estar claras na 
definição das interfaces (Por exemplo, um componente que atualiza endereço através de 
CEP, somente poderá ser utilizado em uma aplicação que queira funcionar nos EUA se 
também tratar ZIP CODE, que é o equivalente ao CEP para este país). 
Sobre o segundo item, como mostra a imagem para sistemas de automação, componentes 
eletrônicos têm as mesmas características de componentes de sistemas: 
 
 
Fonte: arduino.cc 
Exemplo de uso de componentes 
Imagine que nosso sistema deve gerar um relatório em uma planilha eletrônica para que o usuário 
tenha como trabalhar com as informações e montar seus relatórios e gráficos personalizados. 
É bem razoável que não esteja no escopo do desenvolvimento do sistema a construção de um 
sistema de planilha eletrônica. É muito mais simples e eficaz utilizarmos o Excel ou a Planilha do OpenOffice 
para este fim. 
Para que isso ocorra, precisamos mapear as interfaces de uso dessas planilhas e que elas sejam 
repassadas aos desenvolvedores dos novos componentes de maneira que se liguem ao componente 
“Planilha Eletrônica que se deseja utilizar”. 
Graficamente, teríamos o seguinte: 
 
Arquitetura de Sistemas 
Marcio Quirino - 8 
 
O que não é um componente? 
O fato de termos uma classe ou uma função escrita em uma linguagem de programação, compilada 
e instalada em nosso ambiente, por si só não atribui a esse código a funcionalidade de um componente de 
software. 
É necessário que tenhamos uma interface bem definida e que padrões de interação sejam 
suportados pelo componente. Somente neste caso ele estará apto a ser utilizado e classificado como 
componente. 
Definição de arquitetura de sistemas e componentes 
Arquitetura de sistema 
Usaremos a seguinte definição para arquitetura de sistema: é um conjunto de componentes que 
compõem um software completo instalado na corporação, incluindo as funcionalidades destes componentes, 
a sua interconexão e, possivelmente, até mesmo a tecnologia adequada. 
 
Arquitetura de componentes 
Já para arquitetura de componentes usaremos o seguinte: é um conjunto de componentes de 
software em nível de aplicativo, com sua situação estrutural, relacionamentos e suas dependências 
comportamentais claramente definidas e liberadas para uso. 
 
Arquiteturas de sistemas 
Podemos ter N camadas de arquiteturas distribuídas, ligando bancos de dados corporativos, pacotes 
de automação e sistemas em funcionamento na corporação, interagindo especificamente através dos 
aplicativos de processos de negócios software com as interfaces de usuário baseadas na web. 
 
Arquitetura de Sistemas 
Marcio Quirino - 9 
 
Atenção 
Essa é uma típica arquitetura do sistema para os tipos de sistemas que podemos explorar nesta disciplina. 
Compreender esta questão relacionada à arquitetura do sistema é importante porque nos diz a forma geral do sistema 
final e explica como usaremos várias tecnologias para montar o sistema que precisamos. 
Camadas da arquitetura de sistemas 
Queremos usar componentes para fins diferentes e para resolver preocupações diferentes. 
Nossa abordagem global é identificar as camadas diferentes nas quais os componentes podem ser 
utilizados. 
Isso é útil porque nos permite raciocinar sobre a finalidade de cada unidade de software que 
usaremos em nosso sistema. 
 
Arquitetura de componentes 
Componentes podem ser encontrados em qualquer uma das camadas da Arquitetura de sistemas, 
conforme imagem anterior. Porém, o que nos interessa nesta aula são os componentes presentes nas 
camadas de sistemas e de negócio. 
Como vimos, a arquitetura de componentes é um conjunto elementos de software no nível de 
aplicativo que contém comportamentos e dependências em suas relações estruturais. 
Essa é uma definição independentemente do nível de tecnologia em que será implantado. A 
arquitetura de componentes pode ser usada em uma única aplicação ou para um contexto mais amplo, como 
um conjunto de aplicações que servem uma área de processo de negócio em particular. 
Dentro desse contexto, os componentes nos permitem entender como, dependendo do nível de 
integração (forte, moderada ou fraca), nosso sistema vai reagir às modificações e/ou à substituição de 
componentes. 
Relação entre especificação de componentes e interfaces 
A especificação componente define a assinatura do componente e, consequentemente, a forma 
como será construído, utilizado e testado. 
Essa especificação define as formas de uso e delimita sua fronteira de acesso. Já a interface define 
a relação com os outros componentes, informando o que esperar quando se conectar a este componente. 
Arquitetura de Sistemas 
Marcio Quirino - 10 
 
Níveis de modelo 
Um modelo de algo apresenta uma perspectiva ou visão resumida do que é e do que aquilo permite. 
Deve ficar claro que sempre em um modelo algumas coisas serão enfatizadas e outras serão excluídas. 
8. Modelo Conceitual - Independente do tipo de software ou de tecnologia, representam o 
problema a ser resolvido; 
9. Modelo de Especificação - Representa os componentes de software a serem utilizados; 
10. Modelo de Implementação - Informam os detalhes de implementação que devem estar 
presentes dentro dos códigos. 
 
Exercício 
1. De acordo como processo de desenvolvimento baseado em componentes, analise as assertivas 
e assinale a alternativa que aponta a(s) correta(s). 
I - Desenvolvimento de arquiteturas complexas a partir de unidades bem especificadas e testada. 
II - Tem como foco na decomposição da estrutura da funcionalidade individual ou componente lógico 
dele expondo bem definido a interface de comunicação contendo seus métodos, eventos e 
propriedades. 
III - Componentes podem ser objetos, conjunto de objetos, sistemas ou qualquer implementação que 
seja dependente e auto-suficiente. 
I e II são verdadeiras 
2. No contexto de arquitetura de sistemas, os componentes são unidades de software estruturados 
de acordo com alguns princípios. Sendo assim, identifique a qual princípio pertence a descrição 
abaixo: 
O usuário de um componente de software é isolado de como os dados desse componente de software 
é armazenado ou como suas funções são executadas. O cliente depende da especificaçãodo 
componente, mas não da sua implementação. 
Arquitetura de Sistemas 
Marcio Quirino - 11 
 
Encapsulamento 
3. São características principais encontradas na Arquitetura em Camadas: 
Cada camada depende exclusivamente dos serviços providos pela camada inferior 
No modelo em camadas, a lógica de apresentação esta separada em sua própria camada lógica e 
física. A separação em camadas lógicas torna os sistemas mais flexíveis, permitindo que as partes 
possam ser alteradas de forma independente. As funcionalidades da camada de negócio podem ser 
divididas em classes e essas classes podem ser agrupadas em pacotes ou componentes, reduzindo as 
dependências entre as classes e pacotes; podem ser reutilizadas por diferentes partes do aplicativo e até 
por aplicativos diferentes. O modelo de 3 camadas tornou-se a arquitetura padrão para sistemas 
corporativos com base na Web. 
4. Sobre a Arquitetura de Sistemas, as questões abaixo são verdadeiras, EXCETO: 
É tarefa da arquitetura a construção do projeto detalhado dos componentes individuais que 
formam o sistema. 
5. Em relação aos níveis de modelo, descubra qual modelo que é independente do tipo de software 
ou de tecnologia, e representa o problema a ser resolvido. 
Modelo Conceitual 
 
Arquitetura de Sistemas 
Marcio Quirino - 12 
 
O processo de desenvolvimento 
Introdução 
Sempre que iniciamos alguma atividade, é muito importante ter um conjunto de informações iniciais, 
fornecidas por quem já tem experiência nessas atividades, para que o nosso resultado seja positivo desde 
a primeira vez. 
Essas informações são chamadas de “processos” que, em conjunto, assumem a forma de 
“metodologia”. O uso de metodologias nos garante aumento na maturidade na condução dos projetos, 
mesmo quando os profissionais envolvidos não têm muita experiência. Isso se deve ao fato de as 
metodologias servirem de referência e de guia na condução dos trabalhos e nelas estarem contidas toda a 
boa prática da área de referência. 
Nesta aula, faremos contato com metodologias de gestão e metodologias de desenvolvimento e 
realizaremos a correlação entre as duas, seus usos e resultados a serem alcançados. Dessa maneira ficará 
evidente sua importância e sua aplicação no contexto da arquitetura de sistemas. 
Workflow 
Workflow representa a metodologia de desenvolvimento de sistemas baseada na metodologia RUP. 
RUP 
É uma sigla que significa Rational Unified Process, que traduzindo para o português, quer dizer Processo 
Unificado da Rational. 
Esse termo é um processo que foi criado pela empresa de engenharia de software, a Rational Software 
Corporation, com o intuito de orientar o desenvolvimento de um programa. Em 2003, a companhia foi adquirida pela 
IBM. 
O RUP é uma metodologia com práticas ágeis, assim como Scrum e o Extreme Programming (XP). Esses 
métodos possuem em comum a utilização de boas práticas que auxiliam na obtenção de uma rotina e técnicas 
produtivas. 
Na metodologia RUP, a organização é feita em quatro fases: concepção, elaboração, construção e transição. 
Cada etapa tem um objetivo próprio e serve como auxílio para os especialistas, entre os quais estão os Analistas de 
Sistema, Projetistas etc. 
Parte-se da ideia do sistema, em seguida efetua-se a coleta de requisitos que, após validados, são 
encaminhados para a análise. 
Depois que os modelos conceituais de negócio são desenvolvidos, o processo é encaminhado para 
a especificação das funcionalidades e interfaces de sistemas. 
Ao final desse processo, as especificações são encaminhadas para codificação pela equipe de 
desenvolvimento, para, em seguida, serem efetuados os testes integrados e por último a implantação do 
novo sistema. 
Arquitetura de Sistemas 
Marcio Quirino - 13 
 
 
O gerenciamento de processos 
Refere-se ao conjunto de conhecimentos que serão utilizados para guiar a condução do projeto de 
desenvolvimento de software. 
Esses conjuntos de processos garantem que o resultado dos projetos será um sucesso, baseado 
nos grupos de processos que contém ações, distribuídas em 10 áreas do conhecimento da Gestão de 
Projetos, segundo o PMI®: 
1. Iniciação; 
2. Planejamento; 
3. Execução; 
4. Monitoramento e Controle; 
5. Encerramento da Gestão. 
Cada um dos grupos de processos se integra às áreas de conhecimento em uma sequência lógica 
que, quando seguida, viabiliza a execução do desenvolvimento com muito mais assertividade. 
 
Fonte: PMBoK - 5ª Edição 
Arquitetura de Sistemas 
Marcio Quirino - 14 
 
Diferenças entre métodos 
Em alguns métodos de desenvolvimento, prega-se que os requisitos devam ser levantados até ser 
alcançada sua totalidade, independentemente do tempo que isso demore, com o objetivo de reduzir 
mudanças futuras. 
Outros métodos pregam que os requisitos mínimos devam ser levantados para iniciar ondas de 
desenvolvimento, e, com o passar do tempo, chegam a situação ideal sem perder muito tempo com 
requisitos. A justificativa seria: já que os requisitos vão mudar mesmo, então não se deve perder tempo com 
isso. 
Atenção 
Aqui nesta aula, nós faremos uma abordagem intermediária, onde se gasta no máximo 5% do esforço total do 
projeto com levantamento de requisitos e, ao mesmo tempo, garante-se que eles tenham sido bem definidos e 
validados. 
Isso somente é possível com a prototipação para validar requisitos em tempo de modelagem conceitual. 
Fica claro que vão existir trabalhos de gestão e trabalhos de desenvolvimento. 
Os dois tipos de trabalhos vão coexistir em workflows diferentes, que interagem e se integram para 
gerar um sistema muito mais assertivo do ponto de vista de funcionalidade e em conformidade com escopo, 
tempo, custo, riscos e qualidade. 
 
Objetivos da metodologia de desenvolvimento 
A metodologia de desenvolvimento tem como objetivo guiar o processo de produção de software, de 
forma que os componentes gerados tenham alta qualidade e sejam produzidos mais rapidamente, 
garantindo sua efetividade. 
Lembre-se que é objetivo de uma metodologia definir, de forma clara: 
1. Quem? 
2. O que? 
3. Quando? 
4. Como? 
5. Onde? 
Arquitetura de Sistemas 
Marcio Quirino - 15 
 
Outro ponto importante em uma metodologia é o conjunto de padrões a serem seguidos para garantir 
o uso de boas práticas e que as funcionalidades sejam construídas conforme seus requisitos. 
Objetivos da metodologia de gestão 
A metodologia de gestão deve contemplar quantas fases forem necessárias para conseguir que todas 
as áreas de conhecimento sejam abordadas de forma a garantir que escopo, tempo, custos e qualidade 
atinjam os níveis definidos pelas corporações como sendo os ideais. 
As fases da metodologia devem seguir um modelo interativo e incremental. Nele, cada fase é dividida 
em uma ou mais iterações que visam uma entrega ao final. 
Veja a segui um exemplo das fases de um processo de desenvolvimento, testes e manutenções dos 
softwares. 
 
Fonte: Adaptado de Hi Solution. Disponível em: //www.hisolution.com.br/software.php 
Atenção 
Cada entrega de cada fase deve garantir que o resultado esteja com o grau de maturidade necessário naquele 
momento do projeto. 
Interação entre componentes 
A interação de componentes define como cada uma das operações do sistema será alcançada, 
utilizando a arquitetura de componentes. 
Usa-se a interação entre os modelos para descobrir as operações nas interfaces de negócios. Quanto 
mais interações são consideradas, operações e padrões de uso comuns são conseguidos e passam a poder 
ser reutilizados. 
Dessa maneira, as escolhas e possibilidades se tornam mais claras e as operações são movidas de 
uma interface para outra, quando necessário. 
Grupos alternativos de interface para os componentes podem ser utilizados e este é o momento de 
pensar as integrações referenciais entre componentes para que os problemas sejam minimizados e as 
integridade sejam respeitadas. Assim, a interação de componentes é o momentoem que todos os fatores 
do sistema são levantados, com uma clara compreensão das dependências entre eles, chegando-se até o 
nível mais detalhado de operações. 
Arquitetura de Sistemas 
Marcio Quirino - 16 
 
Especificação de componentes 
É na fase final da especificação que ocorre o detalhamento das operações e as suas restrições. 
Para uma dada interface, deve-se definir os potenciais estados dos componentes e suas assinaturas 
e, em seguida, especificar as condições prévias e posteriores para as operações. Aqui são levantadas ainda 
as regras de negócios e restrições. 
As condições prévias e posteriores e outras restrições fazem referência aos tipos das informações 
de modelo de interface que, em conjunto com os tipos dos parâmetros, formam a assinatura da interface. 
Saiba mais 
Além desses detalhes na especificação da interface, esta etapa também apresenta a especificação de 
restrições, que são específicas para um componente e determinam como as definições de tipo de interfaces individuais 
vão corresponder a cada elemento no contexto desse componente. 
A arquitetura não deve ser efetivamente alterada nesta fase. Essa tarefa de especificação detalhada 
somente deve ser realizada quando a definição da arquitetura estiver estável e todas as operações das 
interfaces forem identificadas. 
O ato de escrever as regras detalhadas para cada operação pode ajudar você a descobrir parâmetros 
que estejam faltando ou informações que precisem ser complementadas, mas a ênfase está em identificar 
cada detalhe em uma arquitetura estável. 
Atividade 
1. Quais são as três características de um projeto de desenvolvimento de software? 
Temporário, Gera um resultado único e Elaborado Progressivamente 
2. Qual das respostas abaixo melhor define o conceito de ciclo de vida de projeto de 
desenvolvimento de software? 
As etapas que compõe o desenvolvimento de um projeto. 
3. O processo de decomposição para definição do escopo de um projeto de desenvolvimento de 
software é uma técnica utilizada para construir um(a): 
Estrutura Analítica do Projeto (EAP) 
4. A metodologia de gestão deve contemplar quantas fases forem necessárias para conseguir que 
todas as áreas de conhecimento sejam abordadas de forma a garantir que escopo, tempo, custos 
e qualidade atinjam os níveis definidos pelas corporações como sendo os ideais. Qual o modelo 
de desenvolvimento, estas fases da metodologia devem seguir? 
Iterativo e incremental 
Explicação: No modelo Iterativo e Incremental, cada fase é dividida em uma ou mais iterações que 
visam uma entrega ao final. 
5. São características que levaram à especificação do Modelo de Componentes CORBA, EXCETO: 
Necessidade da existência de um mecanismo único de implementação 
Verdadeiras: 
• Falta de flexibilidade para estender as funcionalidades dos objetos 
• Dificuldade de configurar e utilizar aplicações em padrões anteriores 
• Necessidade da especialização das interfaces (conexões) entre os objetos 
Arquitetura de Sistemas 
Marcio Quirino - 17 
 
• Requisitos não funcionais eram usualmente especificados junto com o métodos do negócio 
(funcionais) 
Explicação: 
CORBA (abreviado de Common Object Request Broker Architecture) é a arquitetura padrão criada 
pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas 
distribuídos heterogêneos. Em face da diversidade de hardware e software que encontramos 
atualmente, a CORBA atua de modo que os objetos (componentes dos softwares) possam se 
comunicar de forma transparente ao usuário, mesmo que para isso seja necessário interoperar com 
outro software, em outro sistema operacional e em outra ferramenta de desenvolvimento. CORBA é 
um dos modelos mais populares de objetos distribuídos, juntamente com o DCOM, formato proprietário 
da Microsoft. 
6. Workflow representa a metodologia de desenvolvimento de sistemas baseada na metodologia 
RUP. Assinale a alternativa que representa a sequência do processo de desenvolvimento. 
Coleta de Requisitos - Análise - Especificação - Codificação - Testes - Implantação 
Explicação: 
• Especificação refere-se a especificação das funcionalidades e interfaces do sistemas. Sendo 
assim, não pode vir antes de Análise. 
• Devemos realizar todos os testes antes da implantação do sistema. 
• A Especificação refere-se a especificação das funcionalidades e interfaces do sistemas. Sendo 
assim, não pode vir antes da coleta de requisitos. 
• A Especificação refere-se a especificação das funcionalidades e interfaces do sistemas. Sendo 
assim, não pode vir antes da coleta de requisitos. Outra questão é que devemos realizar todos 
os testes antes da implantação do sistema. 
 
7. Uma estratégia tradicional para a construção do projeto arquitetural envolve a análise do fluxo 
(workflow) do sistema. Sobre essa estratégia é correto afirmar: 
Nessa estratégia, as operações são usualmente representadas através de componentes, 
ordenados de acordo com a sequência dessas operações 
Explicação: 
Um sistema de gerenciamento de Workflow - WfMS (Workflow Management Systems) é um sistema 
que define, gerencia e executa workflows com o suporte de um software e cuja ordem de atividades é 
guiada por uma representação lógico e ordenada de um fluxo de no computador. 
8. O gerenciamento de processos refere-se ao conjunto de conhecimentos que serão utilizados para 
guiar a condução do projeto de desenvolvimento de software. A atividade de desenvolver o termo 
de abertura do projeto pertence ao gerenciamento de qual grupo de processos? 
Iniciação 
Explicação: 
Tudo começa com a abertura do termo do projeto, por isso corresponde a primeira etapa que é 
Iniciação. Na etapa de Planejamento trabalhamos com o desenvolvimento de gerenciamento do 
projeto. A etapa de execução tem como foco orientar e gerenciar o trabalho do projeto. A etapa de 
Monitoramento e Controle tem como objetivo realizar o controle integrado de mudanças e monitorar e 
controlar o trabalho do projeto. E a etapa de Encerramento visa encerrar o projeto ou fase. 
 
Arquitetura de Sistemas 
Marcio Quirino - 18 
 
9. Sobre os Componentes de um Sistema, as questões abaixo são verdadeiras, EXCETO: 
Seguindo o princípio da alta coesão, cada componente deve ter no máximo 3 interfaces 
Explicação: 
Acoplamento e Coesão talvez sejam as características mais importantes de qualquer sistema. 
Muitos sistemas são como um Castelo de Cartas. 
Assim como o baixo acoplamento, a alta coesão é um dos princípios que devem ser levados em 
consideração ao se construir um projeto. 
Da mesma maneira que o baixo acoplamento, a alta coesão também é dividida em tipos: 
Coesão coincidental: o pior tipo de coesão, há nenhuma ou pouca relação construtiva entre os 
elementos de um módulo, em outras palavras é uma classe inchada, com um punhado de métodos, 
todos executando tarefas diferentes, sem nenhuma relação com a classe que os implementa. 
Coesão lógica: melhor do que a coincidental, mas não menos pior em um projeto, semelhante ao 
acoplamento de controle, onde um módulo faz um conjunto de funções relacionadas e uma das quais 
é escolhida através de um parâmetro para controlá-lo. 
Coesão temporal: os elementos estão agrupados no mesmo módulo simplesmente porque são 
processados no mesmo intervalo de tempo, semelhante aos arquivos .ini do windows xp, ao iniciar o 
xp esses arquivos são carregados para iniciar serviços ou aplicativos. 
Coesão procedural: o módulo só tem sentido sobre a aplicação associada, sem ela, há dificuldade 
em entendê-lo, basicamente é a coesão relacionada aos procedimentos executados pelos elementos 
do módulo. 
Coesão de comunicação: um módulo tem coesão de comunicação se os seus elementos usam a 
mesma entrada ou a mesma saída. 
Coesão sequencial: a saída de um elemento é a entrada de outro e a solução é decompor em 
módulos menores, isso nós já vimos em tópicos passados, chamado também de acoplamento de 
dados. 
Coesãofuncional: Um módulo funcionalmente coeso contém todos os elementos e apenas aqueles 
necessários para realizar uma única tarefa bem definida. 
 
Arquitetura de Sistemas 
Marcio Quirino - 19 
 
Aplicando UML 
Introdução 
Uma metodologia de desenvolvimento de sistemas gera um conjunto de entregas que começam em 
modelos conceituais de negócio e vão evoluindo para modelos de sistemas até chegarem à implementação 
e construção do sistema. Seguir esse conjunto de etapas ajuda muito para que os sistemas sejam mais 
eficazes e eficientes. 
Como visto na aula anterior, o uso de metodologias nos garante o aumento na maturidade na 
condução dos projetos, mesmo quando os profissionais envolvidos não têm muita experiência. Isso se deve 
ao fato de as metodologias servirem de referência e de guia na condução dos trabalhos e nelas estarem 
contidas toda a boa prática da área de referência. 
Nesta aula, faremos contato com a metodologia Unified Modeling Language (UML) para 
desenvolvimento de sistemas e veremos como seus modelos podem ser extremamente úteis no contexto 
da arquitetura de sistemas. 
Porque precisamos de UML na arquitetura de sistemas? 
UML foi concebida para modelagem de projeto de sistemas orientado a objetos. 
Esse conceito tem uma relação direta com o desenvolvimento orientado a componentes, do conceito 
de arquitetura de sistemas. 
Atenção 
Mas lembre-se que o foco desta disciplina está nos aspectos externos de componentes de sistemas e não no 
desenvolvimento dos módulos internos, mesmo que eles também possam ser modelados utilizando UML. 
Neste contexto, um dos itens que usaremos em nossa disciplina é a modelagem de pacotes de 
interface, em que os componentes são modelados sem a preocupação com a codificação, mas, sim, com a 
junção dos elementos do sistema para definir sua lógica de funcionamento. 
Veremos nesta aula que UML pode nos ajudar a definir e projetar a arquitetura do sistema, servindo 
como ferramenta de suporte à técnica de modelagem por componentes da arquitetura de sistemas. 
Não vamos aqui definir ou indicar uma ferramenta de modelagem UML específica, já que todas as 
ferramentas que se propõe a isso atendem aos objetivos propostos nesta disciplina. 
UML e suas generalizações 
Na UML, temos muitos mecanismos de derivação de classes. Porém, com certeza, o mais utilizado 
na criação e implementação dos componentes é a generalização. 
Qualquer classe UML pode sofrer generalização para implementar novas funcionalidades e/ou novos 
componentes. 
Em um conceito mais amplo, sempre que você generalizar uma classe utilizando UML, pode também 
criar restrições específicas para essa generalização, independente da classe da qual este novo conceito foi 
estendido. 
 
Arquitetura de Sistemas 
Marcio Quirino - 20 
 
Como atingir conformidade em requisitos com UML? 
1. Ao definirmos nossos componentes, é necessário que sejam geradas as suas 
especificações de comportamento. 
2. É através desses componentes que vamos garantir que as funcionalidades levantadas 
estejam implementadas e em conformidade com os requisitos validados pelas partes 
interessadas. 
3. Ao definirmos o comportamento deles, estamos sendo mais precisos, em relação à 
integração do modelo, e completos, em relação à sua funcionalidade. 
4. Ao efetuarmos os testes de comportamento, durante a homologação, estamos garantindo 
que a aplicação esteja em conformidade com os requisitos. 
Técnicas de modelagem UML 
Veremos aqui como usar UML para modelar os vários artefatos necessários na modelagem de 
sistemas por componentes. 
Esses artefatos nos servirão neste contexto para modelar o negócio e o sistema, na forma dos 
componentes que formam a arquitetura do sistema. 
Os diagramas que vamos utilizar usam os mesmos nomes da UML, mas são aqui apresentados com 
uma funcionalidade específica. 
Exemplo 
Para modelarmos os conceitos de negócios, usaremos o diagrama de classes, pois ele descreve o modelo de 
conceito do negócio. 
Outro exemplo é o diagrama de especificação de interface que apresenta a especificação das interfaces. Nesse 
mesmo caminho temos os seguintes modelos: 
• diagrama de modelo de negócio, 
• diagrama de componentes e diagrama de implantação. 
 
Temos também as seguintes variações: 
1. Diagrama de Funcionalidades de Interface: 
a. Descreve o modelo de negócio, suas interfaces e as regras de funcionalidades para 
essas interfaces. 
2. Diagrama de Interação de Componentes: 
a. É um diagrama de colaboração utilizado para interação entre componentes. 
Veremos mais detalhadamente cada um deles nos próximos elementos desta aula. 
Modelo conceitual de negócio 
O modelo conceitual de negócio não é um modelo de software, mas sim um modelo de informação 
que define o domínio do problema. 
Sua principal finalidade é identificar e definir as relações existentes dentro do negócio. 
Usaremos o diagrama de classe UML para representá-lo, mas é importante ficar claro que a 
ferramenta é independente do modelo, ou seja, poderemos generalizar cada classe do modelo e amarrá-las 
Arquitetura de Sistemas 
Marcio Quirino - 21 
 
do ponto de vista de restrições. Depois, quando formos definir os pacotes, poderemos separar o negócio do 
sistema. 
Os modelos conceituais de negócio, normalmente, definem classes conceituais e suas associações 
e, como previsto nesse modelo, as associações terão suas multiplicidades. 
O modelo pode conter atributos, caso isso seja significativo para explicar o negócio, mas seu uso 
não é obrigatório. A ênfase desse modelo é definir o domínio e não normalizar suas relações. 
Modelo conceitual de sistemas 
Diagrama de casos de uso 
O diagrama de casos de uso é modelo que define a funcionalidade do sistema a ser desenvolvido e 
contém os seguintes elementos: 
1. Atores: 
a. Representados por um boneco e um rótulo com o nome do ator. 
b. Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro 
sistema computacional. 
2. Objetos: 
a. São representados por uma elipse e um rótulo com o nome do objeto. 
b. Um objeto define uma grande função do sistema. A implicação é que uma função 
pode ser estruturada em outras funções e, portanto, um objeto pode ser explodido 
em níveis mais baixos ou detalhados. 
3. Relacionamentos: 
a. Podem ser associações entre atores e objetos, generalização entre atores ou 
generalizações (extends e includes) entre os objetos. 
b. Os relacionamentos ajudam a representar o negócio dentro do diagrama de casos 
de uso. 
c. O primeiro tipo de relacionamento que veremos é a associação, que representa a 
que objeto(s) os atores se relacionam ou, ainda, como um segundo ator se relaciona 
com os mesmos objetos do primeiro, a que está relacionado. 
 
Relação entre objetos 
Quando estamos falando da relação entre objetos, temos o include, que informa que o objeto A é 
parte do objeto B, caso exista entre eles uma relação do tipo include partindo de A. 
Arquitetura de Sistemas 
Marcio Quirino - 22 
 
Outro tipo de relação entre objetos é o extends. Esse tipo de relação representa que o objeto D é 
uma extensão do objeto A, compartilhando suas funcionalidades e implementando algumas novas, que 
existem somente para ele. 
 
Descrição de casos de uso 
Descrevem, geralmente na forma textual, as funcionalidades existentes no diagrama de casos de 
uso, no que diz respeito a como seus atores interagem com os objetos do sistema. 
Descrevem também como os objetos se relacionam entre si e, por último, a funcionalidade dos 
objetos. 
 
Arquitetura de Sistemas 
Marcio Quirino - 23 
 
Diagrama de domínio 
O diagrama de domínio é uma variação do diagrama de classes e utiliza quase a mesma notação. 
Representa o domínio de dados a serem tratados e armazenados pelo sistema, ou seja, os elementos 
DAO do sistema. 
Garante uma visão sistêmica entre os componentes de interface e os componentes de dados do 
sistema. 
Especificação de interface 
A especificaçãode interfaces de componentes é a forma de descrever como os elementos que 
quiserem utilizar esses componentes: 
1. Devem acessá-lo (sua assinatura, com os parâmetros e retornos oferecidos); 
2. Quais os atributos que ele manipula; 
3. Quais as funções disponíveis para uso. 
Os componentes podem ser agrupados em pacotes, que reúnem componentes com funcionalidades 
e atributos complementares, dentro do conceito de família de componentes. 
Esses pacotes vão apresentar as informações necessárias para que possam ser utilizados no 
conceito de arquitetura de componentes, através de suas funcionalidades e operações. 
Atividade proposta 
Os modelos conceituais utilizados na UML garantem que os elementos de negócio, referentes ao 
sistema que está sendo desenvolvido, sejam completamente mapeados. Garantem também que haja uma 
migração consistente dos modelos conceituais de negócio para os modelos conceituais de sistemas. 
Dessa maneira, conseguimos que nossos sistemas atendam a seus objetivos e sejam desenvolvidos, 
segundo o melhor conjunto de boas práticas. 
Você acha que podemos fazer um paralelo entre esse conceito e a construção de um equipamento, 
atendendo às normas da ABNT e definições do INMETRO? 
1. Questão: 
I. UML é uma linguagem de modelagem de uso geral que pode ser usada com os principais 
métodos de objetos e de componentes, podendo ainda ser aplicada a todos os domínios de 
aplicação e plataformas de implementação; 
II. Um relacionamento estendido entre casos de uso significa que o caso de uso base incorpora 
implicitamente, sob alguma condição, o comportamento de outro caso de uso. 
III. Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora 
explicitamente o comportamento de outro caso de uso. 
IV. Relacionamentos de inclusão e extensão são representados pela mesma notação do 
relacionamento de dependência, com a seta apontada para o caso de uso base. 
A alternativa completamente CORRETA é: 
I – II – III 
2. Questão: 
I. Diagramas de casos de uso são compostos por atores, casos de uso e seus relacionamentos; 
II. Diagramas de classes são compostos por classes e seus relacionamentos; 
III. Diagramas de sequência são compostos por objetos e suas trocas de mensagens, ou seja, 
chamadas de métodos para outros objetos; 
Arquitetura de Sistemas 
Marcio Quirino - 24 
 
Considerando as sentenças acima, marque a opção correta: 
As afirmativas I, II e III são verdadeiras 
3. O diagrama UML, que apresenta um conjunto de objetos envolvidos em um cenário e a 
especificação das mensagens trocadas entre esses objetos ao longo de uma linha de tempo, é 
chamado de: 
Diagrama de sequência 
4. Em UML, são exemplos de diagramas responsáveis por representar o aspecto estrutural de um 
software: 
Diagrama de classes e diagrama de pacotes 
5. A atividade de análise de requisitos procura descobrir o que os stakeholders de um projeto de 
sistema de software querem que o sistema faça. Para ajudar na comunicação com os usuários e 
clientes vários diagramas da UML podem ser utilizados. 
Com relação à utilização dos diagramas da UML na atividade de análise de requisitos, analise se 
as sentenças a seguir são falsas ou verdadeiras e depois assinale a opção correta: 
 
( ) Diagrama de classes desenhado a partir da perspectiva conceitual é uma boa maneira de construir 
um vocabulário rigoroso do domínio. 
( ) Um diagrama de atividades é recomendo para exibir o fluxo de trabalho da organização, mostrando 
como o software e as atividades humanas interagem. 
( ) Um diagrama de objetos é indicado para representar um conceito que tenha um ciclo de vida com 
vários estados e os eventos que mudam esses estados. 
V, V e F 
6. A UML é uma famosa linguagem usada para análise e projeto orientado a objetos. O seu diagrama 
de sequência tem como características, EXCETO: 
Dá ênfase ao fluxo de controle de uma atividade para outra. 
7. Qual modelo abaixo, sugere uma abordagem sequencial e sistemática para o desenvolvimento 
de software nos casos em que os requisitos de um problema são bem compreendidos e quando 
o trabalho flui de forma relativamente linear? 
Modelo em cascata 
Explicação: 
O Modelo em Cascata é um modelo de desenvolvimento de software sequencial no qual o processo é 
visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos, 
projeto, implementação, testes (validação), integração, e manutenção de software. 
8. Qual o diagrama que permite que o Arquiteto de um sistema modele a estrutura de arquivos de 
uma aplicação e seus relacionamentos? 
Diagrama de Componentes 
Explicação: 
Arquitetura de Sistemas 
Marcio Quirino - 25 
 
Na UML, os diagramas de componentes mostram a estrutura do sistema de software, que descreve os 
componentes do software, suas interfaces e suas dependências. É possível utilizar diagramas de 
componentes para modelar sistemas de software em um alto nível ou para mostrar componentes em 
um nível de pacote mais baixo. 
Esse tipo de diagrama suporta o desenvolvimento com base em componentes no qual um sistema de 
software é dividido em componentes e interfaces que são reutilizáveis e substituíveis. 
Os diagramas de componentes são úteis pelos seguintes motivos: 
• Definir os aspectos executáveis e reutilizáveis de um sistema de software 
• Revelar problemas de configuração de software através de relacionamentos de dependência 
• Mostrar uma representação precisa de um aplicativo de software antes de fazer alterações ou 
aprimoramentos 
Também é possível utilizar os diagramas de componentes para descrever as seguintes peças físicas 
de um sistema de software: 
• Os arquivos de código fonte desenvolvidos em um ambiente de desenvolvimento integrado 
• Os arquivos executáveis necessários para fornecer um sistema em execução 
• Bancos de dados físicos que armazenam informações nas tabelas de um banco de dados 
relacional ou nas páginas de um banco de dados orientado a objetos 
• Sistemas adaptáveis que possuem componentes que migram para equilíbrio de carga e 
recuperação de defeitos 
 
9. Um Analista pretende desenvolver um projeto utilizando UML, e em seus propósitos, verificou a 
possibilidade de uso de alguns diagramas. Um deles é o Diagrama de Caso de Uso, cujo objetivo 
é: 
Definir as funcionalidades do sistema a ser desenvolvido 
Explicação: 
O diagrama de funcionalidades de interface que descreve o modelo de negócio, suas interfaces e as 
regras de funcionalidades para essas interfaces. 
 O diagrama de interação de componentes é um diagrama de colaboração utilizado para interação 
entre componentes. 
O diagrama de sequência representa a troca de mensagens entre os objetos. 
O diagrama de domínio representa o domínio de dados a serem tratados e armazenados pelo sistema 
10. Considerando as seguintes afirmativas sobre processos de desenvolvimento de software 
conhecidos como Engenharia de Software Baseada em Componentes (ESBC): 
I. O ESBC tem ênfase no paralelismo entre tarefas. 
II. A atividade da Engenharia de Domínio produz uma lista de componentes que podem ser 
reutilizados. 
III. O modelo de troca de dados é um dos ingredientes arquiteturais necessários para a atividade de 
composição de componentes. 
As afirmativas verdadeiras são: 
I, II e III 
 
Arquitetura de Sistemas 
Marcio Quirino - 26 
 
11. Uma empresa realizou um levantamento de requisitos de um Estacionamento, onde num primeiro 
momento destacou duas funcionalidades principais: 
I. Atendente registra a entrada e saída do veículo, mas é importante frisar que quando o cliente 
estaciona o veículo ele recebe o ticket onde contém a data e hora de entrada, placa, a cor do 
veículo e o modelo do carro. 
II. Quando o cliente retira o veículo do estacionamento ele recebe o comprovante de pagamento 
(fatura). 
É correto afirmar que: 
Existe um relacionamento do tipo include do caso de uso Registrar Entrada para o casode 
uso Gerar ticket impresso, onde este é essencial para o comportamento do caso de uso Registrar 
Entrada. 
Explicação: 
O relacionamento é do tipo include, uma vez que é obrigatório executar o caso de uso gerar ticket 
impresso, e este é chamado pelo caso de uso registrar entrada. 
 
Arquitetura de Sistemas 
Marcio Quirino - 27 
 
Definição de Requisitos 
Introdução 
Como vimos na aula 2, algumas metodologias tratam requisitos de forma menor, entendendo que, 
como mudarão até o fim do projeto, não vale a pena perder muito tempo neste trabalho. Outras 
metodologias, ao contrário, entendem que os requisitos devem ser levantados completamente até a 
exaustão, independentemente do tempo necessário para isso. 
Nesta aula, veremos um conjunto de ações intermediárias desses dois conceitos. Nos dedicaremos, 
portanto, à apresentação do conceito que prega que levantar muito bem os requisitos é muito importante, e 
que eles devem ser validados através do conceito de prototipação e, ao mesmo tempo, não devem durar 
mais que 5% do tempo total do projeto. 
Assim, apresentaremos uma nova maneira de se lidar com requisitos e sua relação com os resultados 
a serem alcançados, mostrando sua importância e aplicação no contexto da arquitetura de sistemas. 
Definição de requisitos 
Podemos definir requisitos como condição ou exigência indispensável para um fim, uma ocupação 
e/ou uma realização. 
Para começarmos é importante definirmos como as metodologias tratam requisitos e como essa 
disciplina fará a abordagem do tema, quais as diferenças encontradas no processo de levantamento de 
requisitos, no esforço gasto e em seus resultados, além de tratar da importância de requisitos para o 
resultado do sistema. 
Diferenças no levantamento dos requisitos: 
Diagrama de Funcionalidades de Interface: 
Como dito na introdução desta aula, algumas metodologias tratam requisitos de forma menor, pois 
entendem que, como mudarão até o fim do projeto, não vale a pena perder muito tempo com eles, nem 
dedicar muito esforço nesse trabalho. 
Nesses casos, os usuários e a equipe de desenvolvimento são chamados para novas definições e 
validações em cada parte do sistema que fica pronta. 
Lembrando que para essas metodologias, os modelos conceituais de negócios e de sistemas são 
suficientes para que todos os envolvidos possam, cada um dentro de sua área de conhecimento, validar o 
que foi feito até ali. 
Isso não é uma verdade absoluta, pois dificilmente um usuário leigo vai conseguir validar requisitos 
frente a modelos conceituais (negócio e sistemas) feitos para os iniciados em arquitetura de sistemas. 
Requisitos vistos com muita importância: 
Outras metodologias, ao contrário, entendem que os requisitos devem ser levantados completamente 
até a exaustão, independentemente do tempo necessário para isso. 
Nesse caso, o processo se torna moroso, caro e muito frustrante para os usuários, já que eles têm 
de participar de intermináveis reuniões de definição, sem que os resultados sejam visíveis aos seus olhos. 
O mesmo ocorre com a equipe de desenvolvimento, que acaba por gastar muita energia e foco em 
algo que demora a ficar consistente. 
No caso dessas metodologias, a validação de requisitos é feita através de textos longos e cansativos 
que, dificilmente, levarão os usuários a um correto entendimento de seus sistemas e a uma correta e 
consistente validação dos requisitos. 
Arquitetura de Sistemas 
Marcio Quirino - 28 
 
Conceito Intermediário: 
Como dissemos, nesta disciplina, usaremos um conceito intermediário, em que o esforço total no 
processo de requisitos não pode ultrapassar os 5% do esforço total do projeto. 
Além disso, os requisitos devem ser validados com um mecanismo que seja eficiente e eficaz para 
esse fim. 
Essas definições de esforço e dos mecanismos veremos mais detalhadamente nos itens a seguir. 
Requisitos de sistemas 
 
Os requisitos de sistemas fazem parte da família de requisitos e compartilham sua definição básica. 
Porém, estão associados a funcionalidades e tipos que veremos mais detalhadamente ainda nesta aula. 
O conhecimento adquirido aqui servirá para que nossas partes interessadas e nossas equipes de 
desenvolvimento não enfrentem o problema apresentado no quadrinho. 
Esforço máximo e resultados esperados na etapa de requisitos 
É de se supor que gastar somente 5% do esforço do projeto em levantamento e validação de 
requisitos, como estamos propondo aqui nesta disciplina, nos leve a estar mais próximos das metodologias 
que dão pouca importância aos requisitos. Mas podemos garantir que isso está longe de ser verdade. 
A delimitação de esforço máximo está associada a direcionar os trabalhos ao que realmente é 
importante para o levantamento, a validação de requisitos e também para o uso de ferramentas e técnicas 
baseadas em boas práticas de gestão e de desenvolvimento. 
Tipos de requisitos 
 
 
Arquitetura de Sistemas 
Marcio Quirino - 29 
 
Funcionais e Não funcionais 
Podemos separar os requisitos em duas categorias: 
1. Requisitos funcionais, que são aqueles que tratam do que o sistema deve fazer, de sua 
funcionalidade; 
2. Requisitos não funcionais, que tratam dos critérios que suportam os requisitos funcionais. 
a. Como, por exemplo, qualidade para o software, os requisitos de performance, 
usabilidade, confiabilidade, robustez etc. Ou, então, os critérios relativos à qualidade 
para o processo de software ou uso de metodologias. 
Implícitos e Explícitos 
Para os dois tipos de requisitos devemos, ainda, separá-los em: 
1. Requisitos explícitos, que são aqueles que o usuário vai conseguir externar e repassar à 
equipe de desenvolvimento; 
2. Requisitos implícitos, que são aqueles que o usuário não vai conseguir repassar, ou por 
falta de conhecimento ou por entender ser óbvio e julgar que não vale a pena falar. 
Saiba Mais 
Para complementar as informações faltantes (requisitos implícitos), é necessário que a equipe de 
desenvolvimento tenha um framework de conhecimentos bem vasto. Dessa maneira, é capaz de preencher as lacunas, 
tanto para requisitos funcionais como para requisitos não funcionais. 
Framework de conhecimentos em TI como base para requisitos 
O framework de conhecimentos em TI tratado aqui refere-se aos conhecimentos que vão além dos 
requisitos, como, por exemplo: 
 
Atenção 
Note que é normal que as lacunas existam, pois os usuários não conhecem e nem precisam conhecer 
elementos acima. Esse é um papel que obrigatoriamente deve ser desempenhado pela equipe de desenvolvimento, 
dentro do contexto previsto na arquitetura de sistemas. 
Reunião de levantamento de requisitos 
Os trabalhos de levantamento e validação de requisitos deve conter uma reunião de levantamento 
de requisitos, com as seguintes características: 
Arquitetura de Sistemas 
Marcio Quirino - 30 
 
 
Validação de requisitos 
A validação de requisitos deve ser feita em duas etapas, chamadas de pré-validação e validação 
de requisitos. 
Pré-Validação de Requisitos: 
• Convoque uma reunião de 2h com todas as partes interessadas do seu projeto; 
• Separe as partes interessadas do projeto em grupos de 4 integrantes; 
• Gere uma cópia do documento de requisitos para cada um dos grupos; 
• Cada grupo deve revisar o documento por no máximo 15 minutos, com as observações que 
acharem pertinentes; 
• Fazer com que todos os grupos revisem todas as cópias dos documentos. 
Ao final desses passos, você terá seus requisitos validados por todas as partes interessadas no 
projeto. Além disso, conseguirá o apoio e o patrocínio necessário, pois todos são responsáveis pelo 
documento gerado e não somente a equipe de desenvolvimento. 
Saiba Mais 
A nomenclatura técnica desta técnica é “Técnica de Delphi”. 
A segunda etapa é desenvolvida dentro da prototipação que veremos detalhadamente agora: 
Prototipação: 
A prototipação é a melhor maneira de se validar requisitos. 
Com essa técnica, conseguimos criarum modelo conceituai forte para ser validado pelas partes 
interessadas. 
Mas o que é um conceito de modelo conceitual forte? 
A melhor maneira de responder isso é fazer um comparativo entre modelos conceituais de outras 
áreas de conhecimento que tenha modelos conceituais fortes, como os modelos conceituais de negócio e 
de sistemas. A partir dessa comparação, fica mais fácil entender o conceito proposto. 
Por exemplo, se usarmos como base para exemplificar um modelo conceitual forte, podemos partir 
da arquitetura e de uma planta de casa: 
Não precisamos ser arquitetos para conseguir entender o conceito proposto a partir da planta 
(modelo). Isso representa a definição de um modelo conceitual forte. 
Arquitetura de Sistemas 
Marcio Quirino - 31 
 
E o modelo conceitual fraco? 
 
Quando olhamos para os diagramas de casos de uso, ou de classes, de objetos ou de componentes, 
verificamos que é necessário ser iniciado na arquitetura de sistemas para entender e validar se estão em 
conformidade com as necessidades do sistema a ser desenvolvidos (requisitos). 
Isso representa um modelo conceitual fraco, ou seja, precisa de explicação externa para ser 
entendido. 
Como criar para a TI um modelo conceitual forte? 
Como, então, criar para área de TI um modelo conceitual forte, que seja facilmente entendido pelas 
partes interessadas e, ao mesmo tempo, esteja em adequação às boas práticas da arquitetura de sistemas? 
A resposta está na prototipação de sistemas! 
É com o protótipo que as partes interessadas vão conseguir facilmente verificar se seus requisitos 
estão presentes na definição do que será feito. 
Atenção 
É importante deixar claro às partes interessadas leigas que o protótipo é somente a casca e serve para validar 
funcionalidade e que ainda existe muito trabalho a ser feito para que o sistema fique pronto. 
Modelagem conceitual de negócios e de sistemas a partir dos 
requisitos validados 
Agora que temos todos os requisitos levantados e validados de forma consistente e confiável pelas 
partes interessadas, podemos iniciar os trabalhos de modelagem conceitual de negócios e de sistemas. 
Essa modelagem será feita de acordo com os elementos estudados na aula anterior. 
Arquitetura de Sistemas 
Marcio Quirino - 32 
 
 
Resultados esperados 
Como resultado desse conjunto de processos, espera-se que todas as necessidades das partes 
interessadas estejam presentes nos sistemas desenvolvidos, na forma de funcionalidades, restrições e uso 
de tecnologias, atendendo plenamente a tudo o que se espera do novo sistema. 
É de responsabilidade da equipe de desenvolvimento o atingimento dos resultados esperados. 
Atividade 
1. A gestão de requisitos é uma etapa importante do projeto por ser um conjunto de atividades que 
tem como principal objetivo ajudar a equipe de projeto a: 
Identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à 
medida que o projeto prossegue. 
2. Os requisitos não funcionais normalmente surgem por meio das necessidades dos usuários, 
podem ser restrições de orçamento, políticas organizacionais ou mesmo por fatores externos, 
como regulamentos de segurança e legislações de privacidade. Juntamente com a classificação 
dos requisitos não funcionais estão os requisitos de produto, os quais: 
Especificam ou restringem o comportamento do software, incluindo requisitos de 
desempenho, especificações de rapidez de execução e requisitos de confiabilidade que estabelecem, 
por exemplo, a taxa aceitável de falhas. 
3. A Prototipação é um paradigma da Engenharia de Software que faz uso de protótipos durante o 
processo de desenvolvimento de software. Não representa uma afirmação verdadeira acerca da 
Prototipação: 
Os protótipos podem apontar funcionalidades que não foram contempladas. 
 
 
Arquitetura de Sistemas 
Marcio Quirino - 33 
 
Explicação: 
A arquitetura de um protótipo descartável favorece a evolução do protótipo para o produto final. O que 
não é verdade é que a arquitetura de um protótipo descartável favorece a evolução do protótipo para o 
produto final. 
4. Na especificação dos componentes, as Interfaces identificam como os elementos podem utilizar 
esses componentes. Entre os elementos que compõem essa identificação estão corretamente 
identificadas as afirmativas: 
I. A assinatura, que identifica a forma de acesso à Interface e o retorno esperado 
II. A manipulação dos atributos para a realização do serviço oferecido 
III. A descrição do serviço que deve compor unicamente a Interface 
I, II e III estão corretas. 
5. No desenvolvimento de um software, um técnico se deparou com uma lista de requisitos, na qual 
identificou corretamente como requisito funcional: 
O sistema deve gerar diariamente, a lista de processos cadastrados naquele dia. 
6. Visando obter os requisitos de forma consistente e sem gastar tempo em excesso, o trabalho de 
levantamento de requisitos deve conter como característica: 
Serão realizadas várias reuniões, e para um melhor aproveitamento separar as reuniões por 
camada de desenvolvimento. 
Explicação: 
No trabalho de levantamento de requisitos devemos levar em consideração as seguintes características: 
Duração máxima de 2 horas, No máximo 3 reuniões com cada grupo, Separar as reuniões por camada 
de desenvolvimento, conforme previsto no conceito de arquitetura de sistemas e Convocação de 
usuários que consigam responder sobre cada uma das camadas. 
7. Com relação aos Requisitos de Software, avalie se as afirmativas a seguir são falsas (F) ou 
verdadeiras (V): 
( ) Requisitos funcionais são as declarações de serviços que o sistema fornecer, como o sistema 
deve reagir a entradas específicas e como o sistema deve se comportar em determinadas 
situações. 
( ) Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo 
sistema, incluindo restrições de timing, sobre o processamento de desenvolvimento e padrões, 
aplicam-se frequentemente ao sistema como um todo. 
( ) Requisitos funcionais são aqueles não diretamente relacionados às funções fornecidas pelo 
sistema, enquanto que os não funcionais descrevem a função do sistema detalhadamente, 
incluindo as entradas e saídas. 
As afirmativas são respectivamente: 
V, V e F. 
Explicação: 
Requisitos funcionais descrevem a função do sistema detalhadamente, incluindo as entradas e saídas. 
Já os Requisitos não funcionais são aqueles não diretamente relacionados às funções fornecidas pelo 
sistema. 
8. São requisitos funcionais, exceto 
Fechamento da compra do cliente deve ter processamento inferior a 10 segundo. 
Arquitetura de Sistemas 
Marcio Quirino - 34 
 
Identificação de Componentes 
Introdução 
Identificar componentes é o primeiro processo da metodologia apresentada por esta disciplina. Seu 
objetivo é fazer com que o arquiteto de sistemas tenha um processo formal em que vai avaliar todas as 
estruturas, componentes e módulos disponíveis para a construção do modelo do sistema a ser desenvolvido. 
Nesta aula, portanto, você verá, dentro desse processo, qual o passo a passo para que seja feita 
uma identificação completa e abrangente, seguindo as boas práticas de arquitetura de sistemas. 
Além disso, analisará como o arquiteto de sistemas deve lidar com a identificação de componentes 
e a sua relação com os resultados a serem alcançados. Dessa forma, ficará evidente a importância de sua 
aplicação no contexto da arquitetura de sistemas. 
Identificação de componentes 
A identificação de componentes é o primeiro processo da metodologia apresentada por esta 
disciplina, que está baseada nas boas práticas da arquitetura de sistemas. 
Seu objetivo é criar uma visualização inicial de todos os elementos envolvidos (modelos, métodos, 
objetos, componentes etc.) e como eles são integrados. 
Na figura, você vê graficamente a origem dessas informações e suas ligações: 
 
Os artefatos gerados a partir desse primeiro