Projeto de Sistemas Orientado a Objetos - UNIP - Análise de Sistemas

Prévia do material em texto

UNIP INTERATIVA
Código da Prova: 17503803439
Curso: Sup Tec em Análise e Desenvolvimento de Sistemas
Série ou Período: 4º Bimestre – 3º Semestre
Tipo: Bimestral
Aluno: 1653772 – ANDRÉ LUIZ PINTO DA SILVA
I – Questões objetivas – valendo 5,00 pontos
II – Questões discursivas – valendo 5,00 pontos 
Gerada em: 27/09/2017 15:55:57
Questões de múltipla escolha
Disciplina 308150 – Projeto de Sistemas Orientado a Objetos 
*O processo de desenvolvimento de software - resume-se a um conjunto de atividades executadas em uma determinada sequência. Esse conjunto de
atividades também pode ser chamado de etapas da engenharia de software ou paradigmas da engenharia de software (PRESSMAN, 2006).*
Modelo Cascata ou Waterfall ou ciclo de vida clássico (mais tradicional)- Tem 5 atividades: 
Análise de requisitos,Projeto,Codificação,Testes,Implantação e manutenção./ As atividades são executadas de forma sequencial. Assim, uma atividade não é iniciada até que sua predecessora seja completamente finalizada. / A fase de projeto não se inicia até que todos os requisitos sejam elicitados, documentados e aprovados pelo usuário. / Independentemente do modelo de ciclo de vida que adotarmos, peguemos como exemplo o Modelo Cascata. A fase de projetos encontra-se sempre na fronteira entre a análise de requisitos, o problema e a construção, ou implementação.A fase de projetos sempre se inicia após a fase de requisitos, ou após uma primeira iteração dos requisitos, nos casos em que adotamos um modelo de ciclo de vida iterativo incremental ou qualquer variante dele.
A diferença fundamental entre os modelos clássico, cascata e iterativo - no modelo incremental não é necessário que todos os requisitos estejam mapeados para se iniciar o ciclo de desenvolvimento.
* A fase de projeto dentro do ciclo de vida da engenharia de software é a fronteira entre o domínio do problema e o domínio da solução. Pressman cita, “o modelo de requisitos dá ênfase no o que precisa ser feito, enquanto o modelo de projeto indica o como será feito*
Fases de projeto - Modelos de projeto têm como objetivo representar as diversas visões da solução de um sistema de software./ têm como objetivo representar como os requisitos serão atendidos / Pressman divide o modelo de projetos em quatro fases: (Projeto de componentes./ Projeto de interfaces./Projeto arquitetural./Projeto de dados/classes).
• Projeto de dados/classes: essa fase, que tem como insumo o modelo de requisitos (casos de uso, descrição de casos de uso, modelo de classe conceitual etc.), tem como objetivo a geração do modelo de dados e a transformação de classes e objetos conceituais em classes e objetos equivalentes em projeto.
• Projeto arquitetural: organiza as classes e objetos em componentes do software e define seus relacionamentos.
• Projeto de interfaces: descreve todas as possíveis interfaces de um sistema, que podem ser: interfaces internas (como a comunicação entre os componentes será organizada), interfaces externas (comunicação do sistema com outros sistemas) e interfaces com o usuário.
• Projeto de componentes: a partir do modelo desenhado no projeto de arquitetura, refina-os e detalha-os de tal forma que seja possível a descrição procedimental desses componentes
Modelos - São como guia para a construção e são insumos fundamentais para a validação da qualidade do software.
*Em qualquer modelo de ciclo de vida, antes da fase de projeto, temos a fase de análise, que, dentre outras atividades, compreende a engenharia e análise dos requisitos e dos problemas a serrem resolvidos pelo sistema de software.*
*Abstração e modularidade - são dois dos principais conceitos apresentados por Pressman *
Abstração - O projeto deve, por finalidade, possuir vários níveis de abstração. Nos níveis mais altos de abstração do software nos aproximamos do nível de análise, enquanto nos níveis mais baixos nos aproximamos da solução técnica do software./ Selecionar determinados aspectos do problema e de isolar o que é importante do que não é, para um determinado propósito. Abstração é dar ênfase àquilo que é essencial /No começo do projeto é importante darmos ênfase a soluções macro, e à medida que o projeto for avançando, vamos descendo ao nosso nível de solução, ou de abstração.
Modularidade - O software deve ser dividido em componentes, ou módulos, que trabalham em conjunto para desempenhar uma determinada atividade e atingir um determinado objetivo.O grande desafio da modularidade está em equilibrar as responsabilidades de cada componente, de tal forma que não haja uma superdependência ou a sobrecarga de um único componente. O que se deseja atingir com a modularidade é: baixo acoplamento (Dependencia) e alta coesão (Exclusivo).
Encapsulamento de informações: Os módulos devem ser projetados de uma forma que as informações e sua lógica interna não sejam visíveis por outros módulos, a não ser que seja necessário. Em resumo, é deixar visível apenas o necessário / Encapsulamento é um dos conceitos fundamentais da orientação a objetos, assim como: classe, objeto, abstração, herança e polimorfismo.
Independência funcional: É uma das balizas fundamentais quando estamos querendo atingir acoplamento e coesão. Independência funcional está associada a projetar módulos que tenham funções bem-definidas, minimizando a dependência em relação a outros módulos. Em resumo, é
dizer que um módulo não deve fazer mais nem menos.
Arquiteto – Atividades e habilidades - • Conduz ou coordena o projeto técnico do sistema e tem a responsabilidade pelas decisões técnicas.• Identifica e documenta os aspectos significativos para a arquitetura do sistema como visões que descrevem requisitos, projeto, implementação e implantação. • Justifica as soluções técnicas equilibrando os interesses das várias partes envolvidas, reduzindo os riscos e garantindo que essas soluções sejam comunicadas, validadas e principalmente seguidas pela equipe de construção. • Trabalha junto com gerentes de projeto, recursos humanos e planejamento do projeto; o processo recomenda que a equipe seja organizada em torno da arquitetura. • Trabalha junto com os analistas e desenvolvedores para garantir que o guia da arquitetura seja seguido. • Experiência nos domínios do problema e da engenharia de software. • Habilidade de liderança. • Habilidade de comunicação. • Habilidade de análise crítica, principalmente, para garantir que o desenvolvimento não fuja da arquitetura definida. • Proatividade com ênfase nos objetivos e nos resultados.
Analista – Atividades e habilidades - • Identifica e detalha os requisitos. • Descreve os casos de uso.• Auxilia no desenvolvimento da visão técnica, fornecendo os subsídios necessários. • Experiência na identificação de problemas e soluções. • Capacidade de articular as necessidades que são associadas com o problema-chave a ser resolvido. • Capacidade de colaborar efetivamente com a equipe a partir de sessões colaborativas de trabalho. • Capacidade de comunicação verbal e escrita. • Conhecimento dos domínios de negócios e de tecnologia ou a capacidade de absorver e compreender essas informações rapidamente.
Gerente de projetos - Atividades e habilidades - • Liderança da equipe para um bom resultado e da aceitação do produto por parte do cliente. • É responsável pelo resultado do projeto e da aceitação do produto por parte do cliente. • É responsável pela avaliação dos riscos do projeto e por controlar esses riscos por meio de estratégias de mitigação. • Aplica-se o conhecimento de gestão, habilidades, ferramentas e técnicas para uma ampla gama de tarefas para entregar o resultado desejado para um determinado projeto em tempo hábil. • Capacidades de liderança e formação de equipes. • Experiência completa do ciclo de vida de desenvolvimento de software para treinar, orientar e apoiar outros membros da equipe. • Proficiência em resolução de conflitos e técnicas de resolução de problemas. • Bons conhecimentos em apresentação, facilitação, comunicação e negociação.
*O projeto deve contemplar aimplementação de todos os requisitos explícitos*
*O projeto deve ser um guia para desenvolvedores, testadores e para aqueles de darão suporte ao software.*
* O projeto deve fornecer uma visão completa do software sempre tendo como norte o aspecto implementação *
ISO 25010 (antiga 9126) (ISO, 2011a) - trata da classificação e da definição de requisitos não funcionais, mas que também definem um modelo de qualidade utilizado como referência para a avaliação de qualidade de software.
A norma descreve seis características que definem a qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Essas características, também denominadas atributos de qualidade, são comumente usadas quando trabalhamos com requisitos não funcionais.
Atributos de qualidade segundo a ISO 25010 - Funcionalidade (Está ligado à capacidade do sistema de software de prover funcionalidades que atendam às necessidades explícitas e implícitas quando usado sob as condições especificadas.) Confiabilidade (Está ligado à capacidade do sistema de software de manter um determinado nível de desempenho quando usado sob as condições especificadas.) Usabilidade (Está ligado à capacidade do sistema de software de auxiliar os usuários na realização de suas tarefas, de maneira produtiva). Eficiência (Está ligado à capacidade do sistema de software de prover desempenho apropriado, relativo à quantidade de recursos utilizados.)
Manutenibilidade (Está ligado à capacidade do sistema de software de ser modificado, e essa modificação pode ser uma correção, melhoria ou adaptação.) Portabilidade (Está ligado à capacidade do sistema de software de ser portável entre plataformas de ambientes.)
Os seis atributos de qualidade – funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade – também possuem uma estratificação para outros atributos de qualidade
• Funcionalidade 
— Adequação: é a garantia de que o software possui as funções que foram definidas.
— Acurácia: está relacionada ao grau de precisão dos resultados gerados pelo software. 
— Interoperabilidade: é a capacidade do software de interagir com outros sistemas. 
— Segurança de acesso: está ligada à capacidade do software de prevenir acessos por pessoas ou aplicações não autorizadas. 
— Conformidade: se o software foi desenvolvido seguindo os padrões, convenções ou regras preestabelecidas no projeto.)
• Confiabilidade — Maturidade: está relacionada à baixa frequência de falhas ou defeitos do software em operação. 
— Tolerância a falhas: está relacionada a um determinado nível de desempenho que o software deve atingir, mesmo em momentos de problemas. 
— Facilidade na recuperação: está ligada à capacidade do software de se restabelecer, e de restabelecer seus dados e parâmetros sem que haja necessidade de intervenção, após uma falha.
• Usabilidade
— Inteligibilidade: medida da facilidade do usuário para reconhecer a lógica de funcionamento do software.
— Facilidade no aprendizado: medida da facilidade encontrada pelo usuário para aprender a utilizar o software.
— Operacionalidade: medida da facilidade para operar o produto com segurança e sem falhas.
• Eficiência
— Comportamento em relação ao tempo: está relacionado ao tempo de resposta e de processamento do software em seus serviços.
— Utilização de recursos: está relacionada à quantidade de recursos utilizados (CPU, memória,processador) e ao tempo de resposta e de processamento do software em seus serviços.
• Manutenibilidade
— Facilidade na análise: medida do esforço necessário para diagnosticar falhas e localizar as partes para corrigir os problemas.
— Facilidade na alteração: medida do esforço necessário para corrigir as falhas ou adequar o produto a eventuais mudanças.
— Facilidade na estabilização: medida do esforço necessário em se estabilizar o software após as alterações.
— Facilidade no teste: medida do esforço necessário para testar o produto de software alterado.
• Portabilidade
— Adaptabilidade: está ligada à facilidade em se adaptar o software para funcionar em outros ambientes.
— Capacidade para ser instalado: medida do esforço necessário para instalar o software em um ambiente de operação.
— Coexistência: está relacionado ao nível de conformidade do software a padrões referentes à portabilidade.
— Capacidade para substituir: medida do esforço necessário em substituir um software por outro previamente especificado.
Paradigma - é um conjunto de regras que ajuda-nos a organizar e a coordenar a maneira como olhamos o mundo entre o que é certo
e errado, entre o que é verdadeiro e o que é falso, entre o que se deve fazer e o que não se deve fazer. / O paradigma da orientação a objetos é baseado nos seguintes pilares.
Classes - grupo de objetos com iguais propriedades (atributos), comportamento (operações), relacionamentos e semântica./Uma classe deve possuir responsabilidades bem-definidas, e cada responsabilidade representa um contrato ou obrigações dela. / Semanticamente, dizemos que uma classe é uma especificação de um objeto, pois nela está definido tudo o que o objeto possui (atributos) e tudo aquilo que o objeto pode fazer (métodos).
Objeto - Todo objeto possui uma identidade, representada por um conjunto de informações conferidas aos seus atributos, e ainda que todo objeto possui um estado, definido também pelo conjunto dessas informações em um determinado espaço de tempo.
Encapsulamento - Encapsulamento significa deixar visível, ou deixar acessível a outros objetos, apenas o que é necessário.
Abstração - É fundamental para a modelagem da estrutura de um sistema de software.
A melhor forma de se representar a estrutura estática de um sistema orientado a objetos é utilizando
o modelo de classes. São três os modelos utilizados, segundo Bezerra.
• Modelo de classe de domínio: desenvolvido na fase de análise, o modelo de classe de domínio representa os objetos, ou classes, inerentes ao domínio do problema que queremos resolver, deixando de lado, nesta visão, detalhes tecnológicos da solução do problema.
• Modelo de classe de especificação: construído na fase de projeto, o modelo de classe de especificação adiciona ao modelo de classes de domínio, objetos ou classes específicas para a solução do problema sob o aspecto tecnológico, ou seja, é uma extensão do modelo de classe de domínio.e I
• Modelo de classe de implementação: o modelo de implementação nada mais é que a implementação das classes, especificadas no modelo de especificação, construídas ou codificadas em alguma linguagem de desenvolvimento orientada a objetos, como a linguagem Java ou a linguagem C#.
* Classes de projeto é um nível mais baixo de abstração, ou, podemos dizer, um nível mais refinado das classes de análise, que possuem maiores detalhes de implementação, de infraestrutura que suportarão a concretização das regras de negócio (Pressman)*
5 tipos de classes de projetos que podem ser desenvolvidas na fase de projetos (Pressman):
• Classes de interface do usuário: definem a interação homem-máquina ou IHC (interação homem-computador).
• Classes de domínio de negócio: são refinamentos das classes do modelo de domínio (ou de análise). Possuem atributos e métodos utilizados para implementar elementos do domínio do negócio.
• Classes de processos: têm como objetivo gerir as classes de domínio de negócio.
• Classes persistentes: têm como objetivo a persistência de informações em um repositório de dados, por exemplo, um banco de dados.
• Classes de sistema: têm como objetivo gerir a comunicação do software com o seu ambiente computacional interno e externo.
Coad e Yourdon (1993) têm uma visão semelhante, mas polarizada um pouco mais para a visão arquitetural; enxergando os componentes de um software como uma composição de classes, definem quatro tipos de componentes:
• Componente do domínio do problema: são componentes responsáveis por implementar os requisitos dos usuários.
• Componente de interação humana: são componentes responsáveispor implementar a interação homem-máquina ou IHC (interação homem-computador).
• Componente de gerência de tarefa: são responsáveis por controlar e coordenar tarefas do software.
• Componente de gerência de dados: são responsáveis por controlar a persistência dos objetos em um repositório de dados.
*Um sistema de software pode ser organizado em cinco visões, e cada visão possui um conjunto de diagramas UML,*
Visão de caso de uso - Tem como objetivo capturar as funcionalidades, os requisitos, e seu comportamento sob a ótica do usuário final, ou dos atores. A visão de caso de uso é centralizada, uma vez que o que é produzido nessa visão é a base para as outras visões do sistema.
Visão lógica - Também chamada de visão de projeto ou visão de classe, tem como objetivo representar como as funcionalidades serão implementadas sob o aspecto da solução de projeto. Representa a estrutura estática de um sistema, seus componentes e o relacionamento entre eles e como esses interagem para resolver um determinado problema. Essa interação é capturada pela estrutura dinâmica do sistema.
Visão de processo - Também chamada de visão de concorrência, a visão de processo tem como objetivo capturar aspectos de paralelismo de execução de atividades sob o ponto de vista não funcional de um sistema.
A visão de processo representa uma visão mais técnica do sistema tratada como unidades de processos e processamentos, que podem ocorrer de forma síncrona ou paralela. Essas unidades também podem ser interpretadas como subsistemas.
Visão de implementação - Também chamada de visão de componentes, a visão de implementação tem como objetivo representar aspectos físicos necessários para a construção do sistema e como eles interagem e fazem
interface com o sistema. São exemplos desses aspectos físicos: sistemas de software, programas e rotinas internas, bancos de dados e bibliotecas.
Visão de implantação - Também chamada de visão de organização, tem como objetivo representar a organização física de hardware do sistema, como computadores, servidores e periféricos, e como eles se relacionam com o sistema. Essa visão é utilizada principalmente no processo de implantação, também chamado de instalação ou distribuição do sistema.
Visões da UML x Diagramas Uml
Visão de caso de uso - Diagrama de caso de uso, de processo, de atividade - Estrutura estática:de classe, de objeto - Estrutura dinâmica:
Visão lógica - Diagrama de estado, de sequência, de colaboração, de interação, de atividade.
Visão de processo - São utilizados os mesmos diagramas utilizados na visão lógica, mas com ênfase na linha de execução do sistema.
Visão de implementação - Diagrama de componentes
Visão de implantação - Diagrama de implantação
*Fase de análise - trabalhamos com mais ênfase na visão de caso de uso, desenvolvendo os diagramas de caso de uso, de processo e de atividade, além de trabalhar com os diagramas de classe e sequência sob o aspecto de conhecimento do domínio.*
*Fase de projetos - daremos ênfase à visão lógica, bem como à visão de implementação e à de implantação, que são as visões e, consequentemente, os diagramas que dão suporte à modelagem do aspecto solução dos requisitos elicitados nas demais visões.*
O modelo estrutural dinâmico – É originado do modelo estático. Não existe comportamento dinâmico que não tenha sido representado nos diagramas de classe ou de objeto. Qualquer tipo de alteração no modelo dinâmico acarreta mudança no estático e vice-versa.
As ferramentas CASE (front end e back end)- O objetivo da engenharia de software é apoiar o desenvolvimento de software a partir de técnicas
para especificar, projetar, manter e gerir um sistema de software (SOMMERVILLE, 2010). Ela é baseada em três pilares: métodos, ferramentas e processos. Ferramentas, de qualquer natureza, são utilizadas na engenharia para dar suporte ou auxiliar, na execução de uma ou mais atividades.
CASE é o acrônimo em inglês para Computer-Aided Software Engineering, ou em português: Engenharia de Software Auxiliada por Computador.
Ferramentas CASE são classificadas de acordo com a sua funcionalidade dentro do processo; seguem alguns exemplos.
• Ferramentas para planejamento de projetos.• Ferramentas para gerenciamento de projetos.• Ferramentas para análise e projeto.• Ferramenta para construção (desenvolvimento).• Ferramentas para integração de testes.
Algumas de suas principais características: • Criação de diagramas e manutenção da consistência entre esses diagramas.• Engenharia reversa: geração de código a partir de diagramas e vice-versa.• Gerenciamento de versão.• Gerenciamento de mudança.• Testes automáticos, verificação e relatórios.
O modelo entidade-relacionamento ou E-R, -Tem como base a percepção do mundo real como um conjunto de entidades e do relacionamento entre elas. As entidades são caracterizadas no banco de dados pelos seus atributos. Similar ao E-R, o modelo orientado a objetos tem por base um conjunto de objetos. Cada objeto possui um conjunto de características (atributos) que, ao possuírem um determinado conjunto de valores, passam a constituir uma identidade para o objeto.
A diferença conceitual do modelo orientado a objetos para o E-R está em alguns pontos:
• No modelo orientado a objetos, cada objeto possui um conjunto de códigos que operam sobre este objeto, chamado de método.
• Objetos que possuem o mesmo conjunto de atributos e métodos são denominados classe.
• Cada objeto possui uma identidade única independente dos valores contidos em seus atributos, ou seja, mesmo que um objeto possua os mesmos valores dos atributos de outro objeto no mesmo banco de dados, estes possuem identidades diferentes.
• Adoção de mecanismos de relacionamento: composição, agregação e herança.
São dois os principais padrões para banco de dados orientado a objetos: o padrão Common Object Request Broker Architecture (CORBA) e o padrão Object Request Broker (ORB), ambos definidos pela OMG. O padrão CORBA define uma arquitetura-padrão para comunicação: troca de informações entre objetos independentemente do produto, hardware ou sistema operacional, garantindo a portabilidade e a interoperabilidade. 
Principais bancos de dados orientados a objetos disponíveis atualmente: • Gemstone.• ObjectStore.• Versant.• Objectivity/DB.• Easy/DB.• Ontos/DB.• Jasmine.
Tecnologias de apoio front-end - são subdivididas em duas categorias: ferramentas de modelagem e linguagens de programação OO.
Prerrequisitos para uma linguagem ser considerada orientada a objetos:
• Encapsulamento de dados – garantir a confiabilidade e a capacidade de modificação do sistema de software, expondo apenas o necessário ao restante do sistema, sendo que o estado de um objeto deve estar representado em atributos privados, visíveis apenas no escopo do próprio objeto.
• Abstração de dados – a linguagem deve estar apta a implementar um tipo abstrato de dados, ou seja, um conjunto de métodos utilizados para manipular essas informações. • Coesão dinâmica – a linguagem deve implementar o mecanismo de troca de mensagens no qual existe o objeto chamador, que envia a mensagem e o objeto receptor que recebe a mensagem e executa um método. • Herança – permitir a codificação de classes que sejam especializações de outras classes.
Há três perspectivas do modelo de classes de projeto - Modelo conceitual./ Modelo de projeto./ Modelo de implementação.
Modelo conceitual- Desenvolvido na fase de análise, este modelo representa as classes no domínio do negócio em questão e não leva em consideração restrições inerentes à tecnologia a ser utilizada na solução de um problema.O modelo conceitual representa uma entidade do mundo real que possui:• Identidade: valor de uma característica que o identifica para reconhecimento.• Atributos: qualidades e características.• Comportamento: habilidades de processamento
Modelo de projeto- Também chamado de modelo de especificação, o modelo de projeto é desenvolvido na fase de projeto (design) e é uma evolução do modelo conceitual, no qual são adicionadosdetalhes da solução de software. Representa um objeto do mundo real, dentro de um universo de software que contém: • Identidade: identificador em termos de implementação (em memória). • Atributos: os atributos que definem o objeto passam a ter tipos de dados. • Comportamento: funções ou procedimentos que determinam o comportamento do objeto passam a possuir assinaturas. e é obrigatório que se defina o nível de visibilidade dos métodos.
Modelo de implementação- O modelo de classes de implementação corresponde à implementação das classes em alguma linguagem de programação, por exemplo, C#.
*Os modelos que representam os aspectos dinâmicos de um sistema são: modelo de interações, modelo de estados e modelo de atividades; este último é o menos utilizado*
Uma mensagem pode ter três significados:
• Chamada de função ou procedimento: é o tipo mais utilizado de mensagem. Significa que um objeto está solicitando a execução de um método de outro objeto.• Envio explícito de mensagem: Message Queue (fila de mensagens).• Evento: comunicação entre atores e objetos.
• Mensagens síncronas: são mensagens que implicam um sincronismo rígido entre os estados do objeto que envia a mensagem e os do objeto de destino da mensagem.
• Mensagens assíncronas: não há dependência de estado do objeto chamador e do processamento do objeto chamado. O objeto chamador envia a mensagem e continua o seu processamento
• Autodelegação de mensagens: um objeto pode enviar uma mensagem para ele mesmo, solicitando a execução de um método. Esse movimento é chamado de autodelegação. O método que só pode ser chamado pelo próprio objeto que o contém, conforme vimos, é um método privado, e isso é muito importante levarmos em consideração no momento do projeto, pois isso garante o correto uso do encapsulamento.• Criação e destruição de objetos: no ciclo de vida de um objeto, existem dois métodos, construtores e destrutores, que têm como objetivo criar e remover um objeto da estrutura de memória de um sistema. 
O refinamento dos aspectos estáticos do sistema -tem como objetivo promover a passagem do modelo de classes de domínio para o modelo de classes de projetos.
Associação simples - Se um objeto envia uma mensagem para outro, eles possuem uma ligação,ou seja, uma ligação que acontece apenas em um determinado momento.
3 Tipos de Classes:
Entidade - classe de entidade ou ainda objeto de entidade são objetos mais próximos do domínio do mundo real que o sistema representa.
Classes de fronteira - ou objetos de fronteira, como o próprio nome diz, têm como responsabilidade dividir o ambiente interno do sistema e suas interações externas.
Classes de controle ou orquestração - Objetos que têm como objetivo realizar o sequenciamento da execução de um caso de uso na estrutura de objetos do sistema, bem como fazer a coordenação entre as camadas internas do sistema, representadas pelas classes de entidade, com as camadas externas ao sistema, representadas pelas classes de fronteira. A arquitetura de software - produz modelos e organiza a estrutura de um software de tal forma que sirva como o principal guia para a construção./É o principal meio para o atingimento de qualidade de um sistema como: desempenho, manutenibilidade e segurança. Nenhum índice de qualidade pode ser alcançado sem uma visão arquitetural unificada./está intimamente ligada aos atributos de qualidade, ou requisitos não funcionais.
A importância da arquitetura de software:
• Facilita a comunicação entre os envolvidos no projeto.• Representa, em escala menor e compreensível, a forma pela qual os componentes de um sistema são estruturados e interagem.• Modela e coloca em evidência as decisões de projeto como fator fundamental para o sucesso do sistema de software. Alguns outros benefícios de uma arquitetura bem-definida para um sistema de software:
• Facilita a evolução do software. • Facilita o reúso de componentes, logo promove maior produtividade na construção e na manutenção, pois também facilita a manutenção. • Promove a diminuição do espaço entre as fases de análise e construção e, por consequência, a
diminuição do retrabalho na construção. • Auxilia a gestão do projeto quanto à estimativa de tempo, ao custo e à complexidade do projeto.
• Promove mitigação e diminuição de riscos
Processo de arquitetura de software
A participação de arquitetura de software pode ser dividida em cinco fases, e deve ser iniciada antes mesmo da fase de projetos do ciclo de vida da engenharia de software:
Fases do ciclo de vida daffadsfdfadsfsdfdsfdsaf engenharia de software Fases da
• Pré-projeto: é comum observarmos que a arquitetura de software participa do ciclo de vida de desenvolvimento apenas a partir da fase de projetos
• Análise de domínio: o entendimento dos requisitos funcionais fundamentais é ponto crucial para definição do modelo de domínio que será utilizado como entrada para a fase de projeto.
• Projeto esquemático: criação ou seleção de um modelo de arquitetura. Nessa fase o arquiteto deve criar ou escolher um modelo arquitetural que irá direcionar o processo de modelagem arquitetural e o desenvolvimento.
• Desenvolvimento do projeto: nessa fase ocorre a escolha de elementos tecnológicos, como frameworks ou componentes de desenvolvimento, que deem suporte à implementação.
• Construção: a implementação ou construção é orientada pela arquitetura. Ela irá orientar tecnologias e todo o processo de desenvolvimento no qual os desenvolvedores estarão envolvidos.
• Camadas ou Layers: padrão que promove a divisão em níveis de abstração, em que o critério para essa divisão é a responsabilidade de cada nível, ou camada.
• Pipes and Filters: este padrão promove a divisão de cada atividade da aplicação em um passo a passo de processamento de informações. Cada passo é uma unidade de processamento que recebe, processa e devolve uma informação que serve de entrada para o próximo. 
• Blackboard: São montadas soluções para uma tarefa através do uso da heurística computacional. Essas soluções são chamadas hipóteses e são alimentadas gradualmente através de algoritmos de pequenos componentes do sistema e armazenadas em uma área de memória chamada blackboard. A solução da tarefa é colaborativa, dada pelo conjunto dessas hipóteses, originadas de um conjunto de componentes da aplicação. 
• Broker: promove o encapsulamento de detalhes da infraestrutura de comunicação e a separação desta das funcionalidades da aplicação 
• Microkernel: promove a criação de um componente fechado com todos os serviços fundamentais para a aplicação, esse componente é chamado microkernel
• Model-View-Controller (MVC): propõe a divisão lógica da aplicação em três camadas: model, view e controller. A camada Model ou modelo é responsável por objetos que representem o domínio da aplicação, por exemplo, as regras de negócio; a camada View ou visão representa a interface
com o usuário; e a camada Controller tem como objetivo o gerenciamento do fluxo da aplicação.
• Presentation-Abstraction-Control (PAC): propõe a divisão da aplicação em componentes, em que cada qual tem três divisões lógicas: presentation, abstraction e control.
• Reflection: propõe a separação da aplicação em duas camadas, denominadas metanível e nivel‑base. 
Designer pattern - É a menor estrutura arquitetural proveniente dos subsistemas de um sistema de software e do relacionamento entre eles./ É semelhante aos estilos arquiteturais em todos os pontos, todavia difere pelo nível de abstração.Ao passo que um estilo arquitetural tem ênfase no nível estrutural da solução, o padrão de projeto tem ênfase na estrutura do subsistema da solução.
Visão dinâmica da arquitetura - O objetivo principal é representar a realização dos casos de uso,que fundamentalmente se dá pela troca de mensagens entre os objetos no decorrer do tempo./ O primeiro passo para se determinar como uma tarefa será executada é definir as responsabilidades de cada objeto./ São três as visões arquiteturais:
• Visão modular: representa a visão do sistema em termos de unidadede implementação; essas
unidades podem ser classes, componentes ou módulos.
• Visão componente e conector: representa a forma pela qual os componentes interagem, ou seja,
seus protocolos de comunicação.
• Visão de alocação: representa a forma pela qual esses componentes estão distribuídos em uma infraestrutura.
Diagramas utilizados para documentar a visão dinâmica de uma arquitetura - • Diagrama de sequência.• Diagrama de colaboração.• Diagrama de máquinas de estado.
O diagrama de comunicação – Usado Se você desejar dar ênfase à interação dos objetos no contexto do sistema / Começamos a ler a sequência das mensagens procurando inicialmente a mensagem identificada como 1.0 / Passou a ter esse nome a partir da versão 2.0 da UML; nas versões anteriores, esse diagrama é chamado de diagrama de colaboração / Característica marcante do diagrama de comunicação é a forte semelhança com o diagrama de sequência. As informações modeladas em ambos são, no geral, as mesmas, todavia a representação em cada um dos modelos possui ênfases diferentes./ O diagrama de comunicação é um tipo de diagrama comportamental da UML que representa as interações de dois objetos e suas partes utilizando para isso uma sequência de mensagens representadas de forma livre de formatação./ O diagrama de comunicação é um complemento do diagrama de sequência./ Da ênfase a como os objetos estão interligados e quais mensagens são trocadas entre eles para realizar uma determinada tarefa./ No diagrama de comunicação as mensagens possuem uma numeração, é como se elas fossem etiquetadas com uma numeração em ordem crescente, e é essa sequência numérica que representa a sequência em que as mensagens são trocadas entre os objetos.
O diagrama de sequência - Obedece a uma ordem natural de leitura / Podemos dizer que os diagramas de sequência e de comunicação são isomórficos, ou seja, um pode ser transformado no outro. Isso porque os objetos, atores e mensagens que são representados nesses diagramas são originados nos diagramas de caso de uso e nos diagramas de classes de análise e projeto, e o que é representado no diagrama de sequência; também é representado no diagrama de comunicação / Se o seu objetivo for representar a interação dos objetos no decorrer de uma linha do tempo, então você deverá usar o diagrama de sequência.
O diagrama de comunicação é baseado em alguns componentes:
• Objetos: têm a mesma conotação do objeto que representamos no diagrama de sequência, com uma diferença fundamental, pois no diagrama de comunicação não damos ênfase à linha de tempo de vida do objeto.
• Vínculos: identificam uma ligação entre dois objetos, que é feita a partir da troca de mensagens
entre esses objetos.
• Mensagens: análogas às mensagens do diagrama de sequência, possuem apenas duas diferenças básicas: as mensagens são identificadas numericamente e não existe uma pré-formatação para a representação dessas mensagens, como temos no diagrama de sequência. Na representação
de mensagens, podemos representar todos os tipos de mensagem — síncronas, assíncronas e automensagem.
• Atores: nesse diagrama, bem como no diagrama de sequência, podemos representar o autor. Com o detalhe importante de que esse autor deve necessariamente estar representado também no diagrama de caso de uso.
O diagrama de máquina de estado, ou simplesmente diagrama de estado, tem como objetivo representar o comportamento de um determinado elemento a partir de um conjunto finito de estados.
Evento - é uma ocorrência digna de nota que promove a mudança de estado de algum objeto.
O estado de um objeto pode ser classificado como:
• Simples: quando é autossuficiente, ou seja, não possui a necessidade da composição ou da divisão em estados menores.
• Composto: quando um estado contém internamente dois ou mais estados, chamados subestados,
Quando um objeto entra em um determinado estado, ele executa determinadas atividades, que são:
• Atividade de entrada (entry): é a primeira atividade a ser executada quando um objeto assume um
determinado estado.
• Atividades de fazer (do): são atividades executadas quando um objeto se encontra em um
determinado estado.
• Atividades de saída (exit): são atividades executadas no momento em que um objeto sai de um
determinado estado.
*Existem alguns tipos de transições que não produzem alteração no estado de um objeto, ou seja, ocorrem durante o estado do objeto sem que esse estado seja modificado.*118nidade IV
Essas transições são chamadas de:
• Transições internas: são transições que acontecem enquanto um objeto se encontra em um determinado estado e que não promovem modificação neste estado do objeto. Essas transições executam atividades de fazer (do).
• Autotransições: são transições que executam atividades do tipo sair (exit) de um objeto, executam uma determinada ação e voltam para o estado de que saíram sem que haja alteração desse estado,
Pseudoestado de escolha - que representa um ponto na transição de dois estados em que deve ser tomada uma decisão.
Pseudoestado de história: utilizado para representar o registro do último estado em que um objeto se encontrava quando, por alguma razão, o processo foi interrompido.
Estado de submáquina: quando precisamos representar um estado composto de alta complexidade e que, se utilizarmos apenas a representação de estado composto, dificultará muito o entendimento em apenas um diagrama.
Pseudoestado de junção: Representa a união de múltiplos fluxos em um único ponto.
O projeto de interface pode ser dividido em 3 níveis:
• Interfaces internas entre os componentes do sistema.
• Interfaces externas entre o sistema e outros sistemas de software, dispositivos de hardware ou qualquer entidade que produza ou consuma informação relevante para o sistema de software.
• Interface com o usuário final.
Diagrama de pacotes - Um pacote é utilizado com o propósito de agrupar logicamente objetos, entendendo-se um objeto como qualquer elemento passível de agrupamento no processo de modelagem de um sistema: classes,objetos, componentes e casos de uso./ A função principal é organizar esses objetos, esses elementos de modelagem, que possuem semelhantes características, em agrupamentos maiores que podem ser mais facilmente entendíveis.
Dependência simples é quando um elemento de um pacote possui alguma relação com um elemento de outro pacote.
Dependência com estereótipo de acesso é quando o pacote dependente é incorporado aos elementos públicos do pacote de destino.
Dependência com estereótipo de importação é quando os elementos públicos do pacote de destino são adicionados ao pacote dependente,
Engenharia de usabilidade - é o nome dado ao conjunto de atividades distribuídas na forma estruturada de projeto de sistemas computacionais cujo objetivo é a usabilidade./ O principal objetivo qualquer que seja o modelo adotado, é a diminuição do custo no desenvolvimento de um projeto centrado no usuário através da redução nos tempos de desenvolvimento, treinamento e retrabalho.
Os cinco princípios básicos de um componente - Obrigatoriamente deve possuir uma especificação, implementação, padronização, capacidade de ser empacotado em módulos, capacidade de ser distribuído.
*Componentes e pacotes são semelhantes quanto à função de agrupamento, todavia diferem com relação ao final desse agrupamento:
componentes são agrupamentos físicos de objetos, enquanto pacotes são meramente agrupamentos lógicos*.
*As dependências entre objetos e componentes podem ser classificadas como simples ou estereotipadas.*
Tipos de componentes e estereotipação - ereótipo Tipo de componente
<<executable>> Componente que pode ser executado.<<library>> Biblioteca, que pode ser estática ou dinâmica.<<database>> Banco de dados.<<table>> Tabela de um banco de dados. <<document>> Documento.<<file>> Arquivo, que pode ser desde um arquivo que possuía penas informações a um arquivo com código-fonte
Pacotes - são agrupamentos lógicos de elementos, que podem ser classes ou casos de uso. 
O diagrama de componentes - representauma visão mais física do sistema de software.