Análise Orientada a Objetos

Prévia do material em texto

Análise Orientada a Objetos 
Linguagem de Modelagem Unificada
(Unified Modeling Language - UML)
A UML, cuja sigla em inglês significa Unified Modeling Language, ou Linguagem de Modelagem Unificada, é uma das principais ferramentas de modelagem utilizadas em empresas de desenvolvimento de software. A UML foi evoluindo ao longo dos anos, demonstrando que é uma linguagem sólida, bem estruturada, que teve seu desenvolvimento iniciado por pessoas relevantes na área de desenvolvimento de software orientado a objetos, como podemos ver a seguir:
 1967 – surgimento da linguagem SIMULA, a primeira considerada como orientada a objetos
1979 – surgimento da linguagem ADA, linguagem orientada a objetos do departamento de defesa dos Estados Unidos
1986 – apresentação do trabalho de Grady Booch sobre análise orientada a objetos
1991 – apresentação do método OMT de James Rumbaugh para modelagem de bancos de dados
1996 – chamada do OMG (Object Management Group) para um padrão unificado de modelagem
1997 – envio da primeira versão da UML como resposta à chamada pelos autores Grady Booch, Ivar Jacobson e James Rumbaugh
1997 – UML 1.1
2000 – UML 1.3
2001 – UML 1.4
2003 – UML 1.5
2005 – UML 2.0
2006 – UML 2.1
2007 – UML 2.1.2
2010 – UML 2.3
2011 – UML 2.4.1
2015 – UML 2.5
2017 – UML 2.5.1
A linha do tempo mostra algumas questões importantes sobre o desenvolvimento da modelagem. 
Necessidade de um processo de modelagem
Entre a criação da linguagem SIMULA e o início da preocupação com a modelagem de software passaram-se quase 20 anos de desenvolvimento, tempo necessário para perceber que era necessário utilizar um processo de desenvolvimento de software que incluísse a modelagem. 
Também é importante lembrar que a complexidade dos sistemas neste período também aumentou, prejudicando desenvolvedores que não adotavam um processo definido de desenvolvimento.
Versão mais eficiente
Entre a primeira versão de 1997 e a segunda versão de 2005 são 8 anos de diferença. Este tempo foi necessário para que os desenvolvedores entendessem as necessidades reais da linguagem e pudessem apresentar uma versão mais eficiente e adequada ao desenvolvimento de software atual. 
Ferramenta madura
A partir da versão 2.1.2 o intervalo entre modificações ficou mais longo e a última versão é de 2015. Isso mostra o amadurecimento da ferramenta que não precisou mais ser modificada com tanta frequência por atender aos requisitos dos desenvolvedores.
 
A UML é uma linguagem que apresenta um número muito maior de VANTAGENS do que DESVANTAGENS, porém existem muitos desenvolvedores relutantes em utilizá-la. Os principais motivos para que isso ocorra são:
Falta de conhecimento
A falta de conhecimento sobre a linguagem, que ocorre atualmente apesar de toda a popularidade adquirida e o grande número de meios de comunicação.
Falsa impressão
Impressão de que a linguagem é complexa e que o grande número de diagramas existentes torna o aprendizado demorado. Neste caso é possível dizer que um desenvolvedor pode ir aprendendo os diagramas à medida que houver necessidade de utilizá-los, e que os diagramas mais utilizados são os mais simples de construir.
Falta de estudo
Muitos desenvolvedores julgam a linguagem sem nem mesmo ter estudado ou feito um curso sobre o assunto.
Uso de modelo próprio
Empresas e desenvolvedores muitas vezes criam seus próprios meios de documentação e diagramas para modelagem. Acreditar que o modelo próprio é melhor que a linguagem UML pode ser um erro grave que prejudica o desenvolvimento.
Técnicas de modelagem da UML
Classificação dos diagramas UML 
A UML é uma importante ferramenta para modelagem de sistema que dispõe de uma ampla lista de funcionalidades, neste caso estamos falando dos diagramas, com 14 tipos diferentes.
É importante entender o objetivo principal de cada um para sua utilização, assim, para ficar mais simples encontrar o diagrama necessário para um determinado problema, a linguagem apresenta uma classificação de tipos de diagramas. 
ESTRUTURAL
Os diagramas classificados como estruturais modelam as características referentes a sua estrutura, ou seja, como são organizadas as partes do sistema, como são os módulos, como são as classes.
ESTÁTICO
Os diagramas estáticos serão feitos e não serão modificados, pois as informações utilizadas para criá-los não mudam de acordo com a implementação do sistema.
COMPORTAMENTAL
Os diagramas classificados como comportamentais modelam o comportamento dos objetos e componentes, ou seja, como se comportam em tempo de execução e como se relacionam com os outros componentes do sistema.
DINÂMICO
Os diagramas dinâmicos representam o estado do sistema em um determinado momento, seja de tempo de execução, seja de desenvolvimento. Portanto, ao longo do processo sofrem alterações.
Os diferentes diagramas da linguagem UML informam diversos aspectos de um mesmo projeto, assim devemos considerar a:
Utilização dos diagramas
Sua utilização permite que seja feita uma análise completa do software que está sendo modelado. Porém, nem sempre há tempo para o desenvolvimento de todos os diagramas durante um projeto.
Escolha dos diagramas
É de extrema importância conhecer os diagramas e sua classificação, pois sabendo a informação principal apresentada por cada um deles, é possível fazer uma escolha consciente de qual diagrama utilizar – pois não se pode desenvolver todos eles e também a representação do sistema, para os desenvolvedores, não ser prejudicada.
Ordem dos diagramas
É importante também saber a ordem de desenvolvimento, pois determinados diagramas não são utilizados em todas as fases do projeto. É preciso, então, ficar atento em qual fase o projeto se encontra na hora de determinar quais diagramas serão elaborados.
O processo de desenvolvimento de software com UML
Mecanismos comuns da UML
Existem 14 diagramas disponíveis para serem utilizados na linguagem UML e todos eles apresentam particularidades. Entretanto, há alguns mecanismos que são comuns a todos os diagramas e podem ser utilizados para melhorar a legibilidade, bem como incluir mais informações em determinado diagrama sobre o modelo. 
A seguir, conheça os quatro mecanismos comuns:
ESPECIFICAÇÕES
A UML é uma linguagem gráfica, porém associada a cada elemento dessa linguagem gráfica 
existe uma especificação que descreve exatamente aquele elemento. Por exemplo: 
relacionada a uma classe existe toda a especificação que descreve os atributos, operações e 
comportamentos que a classe incorpora. Visualmente, o elemento da classe mostrará apenas 
parte dessa informação. Basicamente, a parte visual permite um entendimento rápido e global 
de cada parte do sistema, enquanto a especificação permite especificar os detalhes.
ADORNOS
Cada diagrama UML começa com um símbolo e depois os adornos são adicionados ao 
diagrama para compor os elementos da modelagem. Um adorno, portanto, é um elemento do 
diagrama UML que tem uma arte gráfica única e direta, tornando-se uma representação visual 
objetiva daquele elemento, como a classe. Como exemplo, estão os elementos principais da 
classe, ou seja, seu nome, seus atributos e métodos. Nada mais é necessário para o 
entendimento global do diagrama de classes, porém essa representação é um adorno da UML. 
DIVISÕES COMUNS
Os blocos de construção dos diagramas UML apresentam, em quase todos os casos, uma 
dicotomia entre sua interface e implementação. A interface é como um “contrato”, e a 
implementação é uma das possíveis realizações desse contrato responsável por complementar 
a semântica da interface. Essa estrutura é a base do polimorfismo em linguagens orientadas a 
objetos, quando se define uma interface com vários métodos que serão implementados 
apenas nas subclasses.
MECANISMOS DE EXTENSÃO
Foram criados para permitir que sejam feitas modificações na linguagem sem a necessidade de 
mudar toda a linguagem. Os três mecanismos de extensão da UML são:
Estereótipos: é possível, na UML, utilizar o “desenho” de um determinado bloco e modificá-lo 
para um propósito específico, criando umnovo objeto.
Restrições: é possível, também na UML, alterar as restrições na construção de um diagrama. 
Em UML, as restrições são representadas pelas strings que acompanham as ligações entre 
elementos.
Valores predefinidos: é possível predefinir valores específicos em um diagrama para guiar a 
implementação do sistema ou gerenciamento de configurações do sistema.
Consistência entre os diagramas
A consistência entre diagramas UML é um problema e deve ser sempre considerada quando a linguagem é utilizada. Diagramas inconsistentes podem causar problemas graves de desenvolvimento do software gerando erros no produto e retrabalho na parte do desenvolvimento. Apesar de existirem regras para a manutenção da consistência entre os diagramas, elas em si não garantem que a consistência seja alcançada, sendo importante que a construção dos diagramas seja feita em conjunto pela equipe de desenvolvimento. 
Um aspecto relevante nesses casos é que toda a equipe de desenvolvimento deve conhecer a linguagem para poder construir e analisar de forma correta os diagramas. Isso mostra como é importante, em uma empresa, não só a utilização da linguagem em si, como a promoção de constantes treinamentos a respeito da ferramenta, para que os desenvolvedores evoluam seus conhecimentos em conjunto e possam obter resultados de utilização cada vez melhores.
Modelagem de casos de uso
Diagramas UML
A linguagem UML é aplicável a qualquer método de desenvolvimento de software, porém existe uma vertente de desenvolvimento ágil, que diz que não utiliza UML pelo tempo gasto na elaboração dos diagramas. É interessante entender que uma metodologia ágil de desenvolvimento tem como objetivo entregar um produto com alta qualidade em um curto período. 
Sendo assim a utilização de diagramas UML é indicada nesse caso justamente por diminuir o retrabalho durante o desenvolvimento do software por erros gerados no processo e, consequentemente, criar um produto melhor em menor tempo. Portanto, cuidado com as afirmações sobre utilização ou não da linguagem UML, pois, na maioria das vezes, a questão é apenas falta de conhecimento em relação à linguagem.
 Diagrama de casos de uso
O diagrama de casos de uso é o diagrama responsável por descrever um conjunto de ações que os sistemas devem executar em conjunto com usuários externos ao sistema. Ele que irá modelar todas as possíveis utilizações do sistema de uma forma simples e de fácil entendimento, inclusive é utilizado em reuniões com o cliente para verificação. 
Com um diagrama de casos de uso bem feito, é possível obter êxito no desenvolvimento de vários outros diagramas da linguagem UML.
A seguir veja cada um dos componentes do diagrama de casos de uso.
Ator: é um componente de hardware ou software, externo ao sistema, que interage com ele. Esse componente é chamado de ator por representar um papel de entidade externa ao software que interage com o sistema.
Associação: quando um ator é associado a outro ator ou caso de uso, ou seja, quando estão relacionados.
Caso de uso: representa uma funcionalidade diferente de um sistema, componente, pacote ou classe.
Generalização: quando um ator ou caso de uso herda características de outro e adiciona funcionalidades a ele.
Inclusão: quando um caso de uso inclui outro em sua definição.
Extensão: quando um caso de uso estende a funcionalidade de outro.
Modelagem de classes
Diagrama de classes
O diagrama de classes da UML é um diagrama estrutural, que tem como objetivo principal ilustrar graficamente a estrutura do software, em níveis mais e menos abrangentes. Além disso, o diagrama de classes mostra como se dá a interligação entre os componentes da estrutura do sistema (UML-DIAGRAMS, 2016).
 Diagrama de objetos
O diagrama de objetos foi definido inicialmente na versão 1.4.2 da UML, que atualmente está ultrapassada. Foi incialmente definido como um grafo de instâncias que inclui objetos e valores de dados. Um diagrama estático de objetos é uma instância de um diagrama de classes. Já na UML 2.5 a relação entre diagrama de classes e de objetos não é apresentada. Algumas outras fontes sobre UML classificam os diagramas de componentes e de diagramas de desenvolvimento apenas com instâncias como tipos especiais de diagramas de objetos (UML-DIAGRAMS, 2016). Sendo assim, é possível ver como a evolução da UML pode modificar consideravelmente o papel dos diagramas na modelagem de sistemas. 
O diagrama de objetos é utilizado para representar os objetos instanciados de uma classe. Ele utiliza notação de objetos para a própria construção.
Esse diagrama tem por objetivo representar os objetos e os relacionamentos entre eles e nada mais é do que um grafo de instâncias, incluindo os objetos e os valores de seus atributos (UML-DIAGRAMS, 2016).
A seguir veja a relação entre os diagramas de classe e objetos.
Diagrama de objetos
Diagrama de classes para um sistema de música
 Interfaces: 
- Aparelho de som – com as funções básicas que devem 
estar disponíveis para o sistema, que são tocar, parar, 
pausar e reiniciar a música.
- Gravador de Som – com a função gravar música.
 Classes: Aparelho de DVD e Aparelho de CD implementam a 
interface, cada uma para uma mídia diferente. 
 Herança: Representada entre a classe aparelho de som e 
gravador de som, já que se entende um gravador como um 
aparelho de som que possui a função de gravar.
 Classes que podem ser instanciadas: subclasses derivadas da 
superclasse (classe-mãe) Aparelho de som.
- Aparelho de DVD: atributos – nome, marca e watts.
- Aparelho de CD: atributos – nome, marca e quantidade de 
CDS.
Diagrama de objetos
O diagrama de objetos relacionado ao diagrama de classes irá 
conter vários objetos isolados, cada um com um tipo diferente de 
aparelho sem relacionamentos.
 A1: Aparelho DVD: Nome = SP11, marca – AIQA e watts = 30.
 A2: Aparelho de CD: Nome = Cda, marca SYNY e Quantidade de 
CDS = 30.
É possível perceber a relação entre os diagramas e a existência de 
casos em que a utilização do diagrama de objetos irá apenas 
reforçar o que já existe no diagrama de classes sem apresentar 
relações novas.
Modelagem de atividades
Diagrama de atividades
O diagrama de atividades, basicamente, consiste em um gráfico na forma de fluxo que mostra as características dinâmicas do sistema, podendo ser visualizado o fluxo de ações que serão realizadas em uma determinada atividade relacionada ao sistema que será desenvolvido. 
O diagrama de atividades é importante porque permite que as atividades e os fluxos de controle do sistema sejam representados em um diagrama e, posteriormente, podem auxiliar no desenvolvimento do sistema.
A seguir veja os principais componentes do diagrama de atividades.
A imagem ilustra os componentes do diagrama de atividades com os seguintes elementos:
1. Círculo preenchido: Símbolo de início do fluxo de controle no diagrama de atividades. 
2. Retângulos com cantos arredondados e com texto dentro: Símbolo que representa uma atividade, que é um comportamento parametrizado representado por uma ação.
3. Barra preenchida com uma entrada e mais de uma saída – FORK: símbolo utilizado quando um fluxo gera duas atividades em paralelo. Usado, também, para indicar sincronização da paralelização das atividades. 
4. Barra preenchida com várias entradas e apenas uma saída – JOIN: símbolo utilizado para sincronizar o final de fluxos paralelos que deverão se agrupar novamente em um mesmo fluxo. 
5. Losango: símbolo de decisão que, assim como em fluxogramas, representa a possibilidade de seguir por dois caminhos. Normalmente associado a uma condição, caso a condição seja satisfeita, um dos caminhos é seguido; caso não seja, o outro caminho é seguido.
6. Círculo preenchido com uma borda extra: Símbolo de encerramento de atividade, representa o final da atividade que está representada no diagrama.
Modelagem de estados
Diagrama de máquina de estados
O diagrama de máquina de estados demonstra o comportamento de um elemento por meio de um conjunto de estados relevantes e suas transições de estado.O elemento modelado, muitas vezes, é uma instância de uma classe, o comportamento de um caso de uso ou o comportamento de um sistema completo. É considerado um estado relevante ou importante ao contexto do sistema aquele que implica em ações a serem consistidas durante a execução do sistema. 
Na prática, o diagrama de máquina de estados é recomendado, principalmente, para modelar os estados dos objetos das classes.
A seguir vamos conhecer mais sobre a notação gráfica e os elementos que constituem o diagrama de máquina de estados.
Diagrama de máquina de estados
O diagrama de máquina de estados é uma técnica de modelagem comportamental da Unified Modeling Language (UML) que permite descrever o ciclo de vida de objetos de 
uma classe, os eventos que causam a transição entre os estados e a realização de operações resultantes.
Elementos básicos do diagrama:
 Estado (State) representa uma situação de existência dos objetos de uma classe durante a qual ele satisfaz alguma condição ou realiza alguma atividade.
 Transição (Transition) representa um relacionamento entre dois estados, indicando a mudança de estado, a partir da ocorrência de um evento.
 Estado Inicial (Inicial State) representa o estado de um objeto quando ele é criado, indicando o estado padrão que o objeto assumirá. Só pode haver um estado inicial na máquina de estados.
 Estado Final (Final State) representa o fim do ciclo de vida de um objeto. Este estado é opcional e pode haver mais de um estado final na máquina de estados.
 Escolha (Choice) representa um ponto na transição de estados de um objeto em que deve ser tomada uma decisão. As transições de um estado de escolha devem ser indicadas com uma condição de guarda.
Ações de estado
Uma representação mais detalhada dos estados dos objetos com consiste na indicação das atividades internas, também denominadas de ações de estado, e ainda apresentar as transições internas dos estados. As ações de estado são representadas pelas cláusulas predefinidas “entry, exit e do” no interior do retângulo do estado, sendo: 
 Do: representa uma atividade realizada durante o tempo em que o objeto se encontra no estado.
 Entry: representa as ações realizadas no momento em que o objeto assume o novo estado.
 Exit: representa as ações executadas quando o objeto está mudando de estado.
Uma atividade interna está sempre associada ao estado que o objeto assumiu, ou seja, corresponde aos métodos executados pelo objeto, porém não causa alteração na situação do estado.
Na elaboração do diagrama de máquina de estados, é fundamental identificar as regras de negócio aplicadas ao contexto dos objetos, a fim de auxiliar na definição dos seus estados e das suas transições. Para definir as transições entre os estados, deve-se identificar os eventos internos e externos aos objetos da classe e analisar se há algum fator que condicione a transição de estado, nesse caso, deve-se representar por meio da indicação de condições de guarda.
Modelagem de interações
Diagramas de interação
Os diagramas de interação mostram como os objetos do sistema agem internamente para apoiarem a realização das funcionalidades representadas pelos casos de uso, consolidando, assim, o entendimento dos aspectos dinâmicos do sistema. Uma das formas mais utilizadas para especificar a interação entre os objetos é a ênfase à ordenação temporal das mensagens, representando a sequência lógica da troca de mensagens formada por um conjunto de objetos e seus relacionamentos a partir da adoção do diagrama de sequência.
 Diagrama de sequência
O diagrama de sequência representa a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos na execução de um processo. 
O diagrama de sequência baseia-se no diagrama de casos de uso e elabora normalmente um diagrama de sequência para cada caso de uso, apoiando-se no diagrama de classes para determinar os objetos das classes que realizam o caso de uso, com a indicação das mensagens trocadas entre os objetos que são, na maioria das vezes, as operações das classes.
A seguir veja a interação entre os elementos do diagrama de sequência com os tipos de mensagens possíveis, a notação gráfica dos estereótipos das classes e utilização de fragmentos de interação e fragmentos combinados que possibilitam o alinhamento de interações, sendo que cada fragmento representa uma interação independente, formando uma fronteira entre os elementos do diagrama. 
Diagrama de sequência
O diagrama de sequência tem o objetivo de representar a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos na execução de um processo, que foi especificado como um caso de uso. Graficamente, é uma tabela que mostra objetos distribuídos no eixo X e mensagens, em ordem crescente no tempo, no eixo Y.  
Elementos básicos
Ator: representa os mesmos atores já criados no diagrama de casos de uso; são apoiados por uma linha de vida e enviam mensagens para os objetos como uma forma de interação para solicitarem a execução de uma operação ou simplesmente o envio de informações. No diagrama sempre representa o ator primário responsável por enviar a mensagem inicial, que começa a interação entre os objetos.
Objeto: representa os objetos que participam da realização do caso de uso; são também apoiados por uma linha de vida, que juntamente com os atores, formam um cabeçalho para o diagrama. Um objeto pode existir desde o início da interação ou ser criado ao longo da dela. Um objeto é representado por um retângulo com um nome único, conforme o padrão da notação de objeto.
Linha da vida: representa os objetos que participam da realização do caso de uso; são também apoiados por uma linha de vida, que juntamente com os atores, formam um cabeçalho para o diagrama. Um objeto pode existir desde o início da interação ou ser criado ao longo da dela. Um objeto é representado por um retângulo com um nome único, conforme o padrão da notação de objeto.
Mensagem: representa os objetos que participam da realização do caso de uso; são também apoiados por uma linha de vida, que juntamente com os atores, formam um cabeçalho para o diagrama. Um objeto pode existir desde o início da interação ou ser criado ao longo da dela. Um objeto é representado por um retângulo com um nome único, conforme o padrão da notação de objeto.
Foco de controle: representa os objetos que participam da realização do caso de uso; são também apoiados por uma linha de vida, que juntamente com os atores, formam um cabeçalho para o diagrama. Um objeto pode existir desde o início da interação ou ser criado ao longo da dela. Um objeto é representado por um retângulo com um nome único, conforme o padrão da notação de objeto.
Esteriótipos das classes
<<boundary>>: denominado de classe de fronteira, é aquele que representa a interface do sistema, indicando a comunicação entre o ator primário e os demais objetos das classes que participam da interação. O estereótipo do tipo <>, denominado de classe de fronteira, é aquele que representa a interface do sistema, indicando a comunicação entre o ator primário e os demais objetos das classes que participam da interação.
<<control>>: denominado de classe de controle, serve de intermediário entre as classes definidas como <> e <> para tratar as regras de negócio e o fluxo da aplicação.
<<entity>>: denominado de classe de entidade, é aquele que mostra que as classes do sistema também são entidades, seja persistente ou transiente durante a execução do sistema.
Fragmentos
Fragmentos de interação: na notação gráfica do quadro de interação, identifica-se o rótulo com a expressão “ref” e, no centro do quadro, descreve-se o nome do diagrama de sequência referenciado. 
Fragmentos combinados: Um fragmento combinado é utilizado para definir o fluxo de controle da interação, correspondendo a uma sequência de mensagens encapsuladas em um fragmento, compondo um procedimento que pode ser reutilizado em demais diagramas de sequência. Os fragmentos combinados são representados pelo elemento quadro de interação com uma identificação norótulo, que descreve o tipo de operador de interação, que pode ser (BEZERRA, 2014): 
"alt": abreviatura de Alternative (Alternativa): modela a construção procedimental do tipo se-então-senão, ou seja, uma escolha entre duas ou mais ações, sendo que o quadro de interação é dividido em partes por uma linha tracejada, representando cada operador com uma condição de guarda (texto entre colchetes que estabelece uma condição ou uma regra). Apenas um operador do quadro é executado. 
"opt": abreviatura de Option (Opção): modela a construção procedimental do tipo se...então, sendo que o operador opt representa uma escolha de comportamento que será ou não executado a partir de uma condição de guarda.
"loop": abreviatura de Looping (Laço): representa que uma interação deve ser realizada zero ou mais vezes conforme indicação da expressão com os limites mínimo e máximo, definindo a quantidade de repetições.
Modelagem dos demais diagramas de interação
Diagramas de interação
A seguir, veremos as principais características a modelagem dos demais diagramas de interação da UML, o diagrama de comunicação, o diagrama de visão geral de interação e o diagrama de tempo.
Diagrama de comunicação
O diagrama de comunicação representa o relacionamento entre os objetos envolvidos na realização de um caso de uso, enfatizando o sentido da troca de mensagens entre os objetos que participam de uma interação. O diagrama de comunicação não demostra a temporalidade da realização de um processo. 
A leitura do diagrama de comunicação deve ser conduzida pela ordem de envio de mensagens entre os objetos, acompanhando o rótulo das mensagens, que descreve uma expressão de sequência obrigatória, incluindo a numeração da mensagem, as informações enviadas e também um elemento de controle, como uma condição de guarda, se necessário. O sentido da mensagem é indicado por uma seta posicionada próxima ao rótulo da mensagem, apontando para o objeto receptor da mensagem.
A ênfase do diagrama de comunicação está em demonstrar exatamente a ligação entre os objetos representados pela lifeline, que participam da realização de um caso de uso. 
Diagrama de visão geral de interação
O diagrama de visão geral de interação é um novo diagrama da UML 2.0. É uma variação do diagrama de atividades que integra os diagramas de interação, principalmente o diagrama de sequência, demonstrando um processo geral. Com o diagrama de visão geral de interação é possível ter uma visão de alto nível das interações de vários processos ou de um único processo correspondente à realização de um caso de uso. 
A notação gráfica do diagrama de visão geral de interação consiste na representação de dois tipos de quadros:
Quadros de interação
Contêm a representação completa dos diagramas de interação do tipo diagrama de sequência ou diagrama de comunicação. 
Quadros de ocorrência de interação
Fazem referência a um diagrama de interação especificamente separado por um diagrama de sequência, contudo não apresentam detalhamento.
Desta forma, pode-se utilizar ocorrências de interação para fatorar interações comuns a vários diagramas de visão geral de interação e reutilizar esse quadro diversas vezes.
Na elaboração do diagrama de visão geral de interação, além da representação dos quadros de interação e/ou quadros de ocorrência de interação, unem-se os quadros com os mesmos elementos do diagrama de atividades (nó inicial, nó final, nó de decisão, nó de bifurcação e nó de união).  
Diagrama de tempo
O diagrama de tempo também é um diagrama novo que foi introduzido a partir da UML 2.0. Ele representa, de forma concisa e simples, a mudança pontual nos estados de um objeto, relevantes para contexto da execução de um processo que envolve várias atividades, ou especificamente de um caso de uso, em resposta aos eventos disparados durante uma interação.
A notação gráfica do diagrama de tempo consiste em um único retângulo (quadro) com a indicação do nome em um rótulo, indicado no canto superior à esquerda do quadro. 
O diagrama de tempo concentra-se nas condições que mudam dentro e entre linhas de vida ao longo de um eixo de tempo linear. O diagrama descreve o comportamento dos classificadores individuais e as interações dos classificadores, concentrando a atenção no tempo dos eventos que causam mudanças nas condições modeladas das linhas de vida.
Considerando a evolução das versões da UML, os dois diagramas de interação – diagrama de visão geral de interações e o diagrama de tempo – foram introduzidos na UML 2.0 e, na última versão da UML, lançada em dezembro de 2017, a versão 2.5.1, foi introduzido um diagrama estrutural chamado de diagrama de perfil, que visa demostrar a criação de uma extensão da notação da UML, a ser complementada com estereótipos específicos e aplicados a domínios com características particulares. 
Segundo Guedes (2018), o diagrama de perfil é um diagrama abstrato que permite adaptar a notação da UML a uma nova plataforma com características, tecnologias ou domínio específicos a partir da criação de perfis que representam a extensão da linguagem para criação de novas metaclasses e estereótipos, permitindo, assim, a modelagem desses novos domínios.
Modelagem inicial da atividade de Análise
DOCUMENTAÇÃO DOS CASOS DE USO
ESTUDO DE CASO 
Modelagem do sistema ilustrando a documentação dos seus principais diagramas estruturais e comportamentais da Unified Modeling Language (UML)
ATIVIDADE 
ANÁLISE E PROJETO
Em um processo de desenvolvimento iterativo a atividade de Análise precede o da atividade de Projeto, entretanto, a modelagem da análise e o projeto podem acontecer simultaneamente.
MODELO DE CASOS DE USO
Antes de iniciar a especificação dos casos de uso, é importante listar todos os casos de uso identificados, para assim tomar a decisão de agrupá-los ou não por categoria ou assunto e, com isso, desenhar o Diagrama de Pacotes e o Diagrama de Casos de Uso correspondentes a cada pacote, compondo o Modelo de Casos de Uso. 
Especificação do Modelo de Casos de Uso
Na atividade de Análise, inicia-se a modelagem com a definição dos casos de uso, a partir dos requisitos funcionais identificados na atividade de Requisitos, especificando o Modelo de Casos de Uso.
DIAGRAMAS DE CLASSE
A partir da abstração dos casos de uso inicia-se a identificação das classes de objetos e a elaboração do Diagrama de Classes, que é considerada a principal técnica de modelagem estrutural da UML, representando a modelagem da parte estática do sistema e simbolizando um conjunto de classes com seus atributos, operações e relacionamentos.
 Especificação do Modelo de Classes
Considerando que o Modelo de Casos de Uso está pronto, a próxima etapa é analisar cada caso de uso e iniciar a identificação das classes de objetos, compreendendo qual classe ou quais classes participam da realização de um caso de uso e como o sistema será estruturado internamente, especificando o Modelo de Classes geralmente em várias perspectivas de visão.
DOCUMENTAÇÃO DOS CASOS DE USO
Não existe um formato específico de documentação para os casos de uso definido pela UML. O formato de documentação de um caso de uso é flexível, permitindo que se documente o caso de uso da forma que se considerar melhor, até mesmo com o uso de pseudocódigo ou de código de uma linguagem de programação. Outra opção é utilizar a prototipação da interface gráfica para facilitar a compreensão da execução do caso de uso.
Documentação descritiva de cada caso de uso
A partir da primeira versão do Modelo de Classes é mais fácil complementar a modelagem dos casos de uso com a documentação descritiva de cada caso de uso, pois nesse momento já se identificou os objetos que colaboram e devem participar da execução de cada caso de uso.
Modelagem complementar da atividade de Análise
ESTUDO DE CASO
LOCADORA DE VEÍCULOS
Modelagem complementar do sistema a partir da especificação dos Diagramas de Estrutura Composta, dos Diagramas de Atividades, dos Diagramas de Máquina de Estados e dos Diagramas de Sequência.
DIAGRAMAS DE ESTRUTURA COMPOSTA
O Diagrama de EstruturaComposta é um novo diagrama estrutural da UML 2.0, que visa identificar a arquitetura do conjunto de elementos que interagem entre si durante a execução do sistema, formando uma colaboração entre esses elementos que se comunicam, contudo não especifica o comportamento da colaboração, que é o objetivo dos diagramas comportamentais da UML.
DIAGRAMAS DE ATIVIDADES
Os elementos de um Diagrama de Atividades podem ser divididos para demonstrar fluxos de controle paralelos, também denominados simultâneos, ou fluxos de controle sequenciais, também chamados de simples.  Para facilitar a elaboração do Diagrama de Atividades ou de outro diagrama comportamental, recomenda-se a descrição do cenário de execução do caso de uso, utilizando um dos formatos de documentação do caso de uso. 
DIAGRAMAS DE MÁQUINA DE ESTADOS
Diante do contexto e de algumas regras de negócio já definidas na descrição do estudo de caso, as classes de objetos identificadas com estados relevantes no Diagrama de Classes especificado são “Reserva”, “Carro” e “Pessoa”. Entretanto, para melhor controle e agilidade das consultas e relatórios, também foi definida a classe “AluguelDevolucao”, com estados relevantes. 
Lembre-se!
Lembre-se de que na elaboração do Diagrama de Máquina de Estados é fundamental identificar as regras de negócio aplicadas ao contexto dos objetos com estados relevantes, definindo consistentemente os estados e suas transições de estados, que são os elementos básicos do diagrama.
DIAGRAMAS DE SEQUÊNCIA 
Na modelagem da atividade de análise, recomenda-se utilizar o Diagrama de Sequência para descrever a realização dos casos de uso, representando os objetos que colaboram entre si a partir da troca de mensagens entre eles.
Transição da atividade de Análise para Projeto
ESTUDO DE CASO 
LOCADORA DE VEÍCULOS
Refinamento referente aos aspectos estáticos e estruturais da atividade de projeto, tomando-se por base a modelagem da atividade de análise. Persistência de objetos, considerando o mapeamento das classes para tabelas de banco de dados relacional.
REFINAMENTO DOS ASPECTOS 
ESTÁTICOS E ESTRUTURAIS
Como refinamento dos aspectos estáticos e estruturais das técnicas de modelagem da UML, para a atividade de projeto o foco concentra-se na principal técnica de modelagem estrutural, o Diagrama de Classes. 
É recomendado:
· Refinar as classes, definindo as classes de projeto ou novas classes, ou seja, uma classe de análise pode resultar em mais de uma classe de projeto.
· Definir o estereótipo das classes, que são classes de fronteira (<<boundary>>), de controle (<<control>>) ou de entidade (<<entity>>).
· Estabelecer o tipo de dados de cada atributo, correspondente à linguagem de programação que será adotada na implementação. 
·  Detalhar as operações, listando todas as operações identificadas nos diagramas comportamentais e de interação.
· Revisar a visibilidade das classes e operações, definindo o nível de acessibilidade de um atributo ou operação por outros objetos, sendo a visibilidade do tipo privada, pública, protegida ou de pacote.
· Rever os tipos de relacionamentos estabelecidos entre as classes, que são do tipo associação (podendo ser associação do tipo reflexiva, binária, ternária, classe associativa e agregação), generalização, dependência ou realização; além de indicar a navegabilidade de cada associação.
· Definir as classes abstratas, as interfaces, padrões de projeto (design patterns), componentes de softwares reutilizáveis, frameworks e demais detalhes pertinentes às tecnologias de desenvolvimento a serem utilizadas durante a implementação, definindo, assim, a arquitetura de um sistema orientado a objetos.
PERSISTÊNCIA DE OBJETO PARA O
MODELO RELACIONAL
Para especificar o mapeamento de classes para tabelas do modelo de dados relacional, é usual adotar técnicas de modelagem de dados e/ou definir o uso de frameworks de mapeamento objeto relacional, como estratégia de armazenamento persistente. Assim, como parte da documentação que envolve o projeto de banco de dados, deve-se apresentar no mínimo a construção do esquema do banco de dados.
Considerando que foi definido o uso de SGBDR como mecanismo de armazenamento dos objetos, é necessário fazer o mapeamento dos valores de atributos de objetos das classes persistentes para as tabelas de banco de dados relacional, com base no Modelo de Classes.
Relacionamento entre os objetos das classes
Na representação do Diagrama de Classes da atividade de projeto, é importante revisar o relacionamento estabelecido entre as classes de objetos. Os relacionamentos usuais estabelecidos no Diagrama de Classes de análise são do tipo associação e generalização, no entanto, na versão do diagrama de projeto é comum inserir componentes de softwares, bem como aplicar padrões de projeto (design patterns). Assim, podem surgir os relacionamentos do tipo realização e dependência. 
Estereótipos das Classes
Ainda faz parte da definição das classes de projeto definir o estereótipo das classes. Uma classe indicada com um estereótipo representa uma classificação do elemento. Alguns tipos de estereótipos de classe adotados no Diagrama de Classes de projeto são: 
· Estereótipo de fronteira (<<boundary>>):  identifica uma classe que serve de comunicação entre os atores externos e o sistema. Muitas vezes uma classe de fronteira é associada à própria interface do sistema. A utilização de classes de fronteira é importante quando é preciso definir a existência de uma interface para o sistema, sendo desnecessária em sistemas muito simples cujas interfaces não apresentam nenhuma característica especial.
· Estereótipo de controle (<<control>>):  identifica classes que servem de intermédio entre as classes de fronteira e as outras classes do sistema. Os objetos de controle são responsáveis por interpretar os eventos ocorridos sobre os objetos de fronteira, como os movimentos do mouse ou o pressionamento de um botão, e retransmiti-lo para os objetos das classes de entidade que compõem o sistema. 
· Estereótipo de entidade (<<entity>>): classes de entidade também são chamadas de classes do negócio, e são aquelas que representam os conceitos do domínio do sistema, ou seja, a classe contém informações recebidas ou geradas por meio do sistema. É com base nas classes de entidade que se define quais delas geram objetos que devem ser persistentes, no qual o mecanismo de armazenamento geralmente é um sistema de gerenciamento de banco de dados.
Parte do Diagrama de de Classes (Projeto) - md_Locacao_dc
Recorte do Diagrama de Classes de projeto do sistema “Locação de Veículos” referente à classe “Reserva”, correspondente à visão de classes participantes do caso de uso “Reservar Carro”. 
Identificação dos objetos das classes
Primeiramente, deve-se identificar se os objetos das classes são objetos transientes ou objetos persistentes. Normalmente os objetos de entidade são os objetos persistentes, os quais devem ser armazenados em meio físico durante a execução do sistema para serem manipulados. Os objetos transientes existem somente durante uma sessão de uso do sistema e geralmente são os objetos de fronteira e de controle. 
Análise das classes e seus relacionamentos
Na sequência, são analisadas as classes persistentes e seus relacionamentos e aplicadas as alternativas de mapeamento apresentadas a seguir, considerando a notação indicada para manter uma padronização da representação das tabelas e, assim, constituir o esquema do Banco de Dados Relacional (BDR):
Nome da Tabela (coluna 1, coluna 2, coluna 3, coluna 4,… coluna n)
· Cada coluna representa um atributo da classe mapeada, no entanto, atenção aos atributos derivados, pois eles não são mapeados para uma coluna.
· Destaca-se a coluna que representa a chave primária com sublinhado simples e as colunas que representam chaves estrangeiras com sublinhado tracejado. 
· Representa-se em cada tabela derivada de classe, no geral, uma coluna que indica o identificador (Id) para a chave primária. Essa estratégia de notação dos “Ids” define a identidade independente dos objetos,conforme os princípios da orientação a objetos. 
Mapeamento de Classes para Tabelas
Segundo Rumbaugh (1997), as principais alternativas de mapeamento de classes para tabelas são:
· Mapeamento de associação binária: para as classes relacionadas com associação binária, com multiplicidade um-para-muitos, mapeia-se cada classe em uma tabela. Para associação binária com multiplicidade um-para-um, pode-se mapear as classes cada uma em uma tabela ou unir os atributos das duas classes em uma única tabela. 
· Mapeamento de classe associativa: para as classes relacionadas com associação de classe associativa, mapeia-se cada classe em uma tabela. Para classes relacionadas com multiplicidade muitos-para-muitos, cria-se a terceira tabela com apenas a chave primária composta. 
· Mapeamento de agregação: para classes relacionadas com associação do tipo agregação, mapeia-se a classe “Todo” e “Parte” para tabelas individuais. O identificador da classe “Todo” é indicado como chave estrangeira na tabela que representa a classe “Parte”. 
· Mapeamento de composição: para classes relacionadas com associação do tipo composição (tipo especial de agregação), mapeia-se a classe “Todo” e “Parte” para tabelas individuais. O identificador da classe “Todo” torna-se parte da chave primária na tabela que representa a classe “Parte”. 
· Mapeamento de generalização: existem três abordagens para o mapeamento do relacionamento do tipo generalização em tabelas. A abordagem normal define que a superclasse e as subclasses são mapeadas cada uma em uma tabela com a utilização de um “Id” compartilhado e a criação de um atributo tipo na tabela que representa a superclasse, para identificar os tipos de objetos representados pelos objetos das subclasses. A segunda e terceira abordagens são consideradas alternativas de mapeamento de generalização. A segunda abordagem define a eliminação da tabela correspondente à superclasse e mapeia-se uma tabela correspondente à cada subclasse, reproduzindo todos os atributos da superclasse em cada tabela da superclasse. A terceira abordagem define a criação de uma única tabela correspondente à superclasse, unindo todos os atributos das subclasses ao nível da superclasse. 
1)
Basicamente, processos descrevem quem é o responsável por fazer um determinado artefato (o que), como serão executadas as tarefas e quando. Uma forma de escrever tais processos é por meio do chamado de UP (do inglês, Unified Process), ou Processo Unificado (PU) criado pelos fundadores da uml. Uma evolução do UP é o RUP (do inglês, Rational Unified Process). O RUP é um refinamento do PU desenvolvido pela Rational Corporation (daí a origem do nome) que não só melhorou o processo como desenvolveu ferramentas para sua utilização.
JACOBSON, I., BOOCH, G., RUMBAUGH, J. The Unified Software Development Process. Addison-Wesley, Massachusetts, EUA, 1999.
 
Sobre as 4 fases do processo unificado, análise as afirmativas a seguir:
 
I - A fase concepção pode-se criar uma proposta de arquitetura rudimentar com base no escopo do projeto, apresenta um estado inicial provisório do sistema e seus subsistemas.
II - A fase de elaboração expande-se os casos de uso elaborado na fase concepção, além de apresentar os riscos relacionados ao projeto.
III - A fase construção é a fase que realiza o desenvolvimento do sistema bem como os testes com usuários finais do sistema.
IV. A fase transição é uma fase que o produto é transferido ao cliente, não permitindo nenhum tipo de erros no sistema. Nessa fase não são permitidos testes.
É correto o que se afirma em:
Alternativas:
· a)
I, apenas.
· b)
II, apenas.
· c)
II e IV, apenas.
· d)
I e II, apenas.
Alternativa assinalada
· e)
I, II, III e IV.
2)
O processo unificado é uma tentativa de “unificar” o melhor de todos os modelos convencionais (por isso o nome Processo Unificado) de forma que possam se adequar ao Desenvolvimento Ágil de software. Como os outros métodos não possuíam uma maneira satisfatória para lidar com o paradigma de Orientação a Objetos, o UP introduziu a UML, uma notação gráfica para especificação de objetos capaz de demonstrar visualmente as funcionalidades e os fluxos de um software.
 
Disponível em: https://medium.com/contexto-delimitado/o-processo-unificado-d102b1fc9d00 . Acesso em: 30 jul. 2020.
 
Com relação ao processo unificado, complete as lacunas da sentença a seguir.
 
Basicamente no Processo Unificado, os processos descrevem ________________é o responsável por fazer um determinado artefato (______________), como serão executadas as tarefas e ________________.
Assinale a alternativa que completa as lacunas corretamente.
Alternativas:
· a)
quando, (quem), o quê
· b)
quando, (o quê), quem
· c)
quem, (quando), o quê
· d)
quem, (o quê), quando
Alternativa assinalada
· e)
o quê, (quem), quando
3)
Um modelo captura aspectos importantes e de alguma forma modifica ou omite o restante das informações. A forma como o modelo é apresentado e desenvolvido deve ser escolhida para facilitar tanto sua construção quanto sua interpretação e utilização. O modelo de softwares e sistemas computacionais é normalmente feito em uma linguagem de modelagem e, atualmente em sua maioria, utilizando UML.
Sobre a linguagem UML assinale a alternativa correta.
Alternativas:
· a)
A linguagem UML é um método de desenvolvimento que envolve a criação de diagramas do sistema para auxiliar em cada uma das etapas.
· b)
A linguagem UML é uma linguagem de programação que gera diagramas a partir de um código-fonte.
· c)
A linguagem UML é uma linguagem visual de modelagem que apresenta diferentes perspectivas de um software utilizando diagramas.
Alternativa assinalada
· d)
A linguagem UML é capaz de gerar diagramas do software que está sendo desenvolvido independente da linguagem.
· e)
Existem diversas versões da linguagem UML e todas devem ser consideradas no momento de geração dos diagramas.
4)
Um diagrama de atividades apresenta visualmente uma série de ações ou fluxo de controle em um sistema semelhante a um fluxograma ou diagrama de fluxo de dados. Os diagramas de atividades são frequentemente usados na modelagem de processos de negócios. Eles também podem descrever as etapas em um diagrama de casos de uso. As atividades modeladas podem ser sequenciais e simultâneas. Nos dois casos, um diagrama de atividades terá um começo (um estado inicial) e um fim (um estado final).
Além de ações, atividades, eventos e objetos, os diagramas de atividade da UML 2.5 admitem um conjunto de nós de controle do processo, tais como os das figuras abaixo:
 
 
A alternativa que apresenta o significado correto de cada um dos símbolos respectivamente é:
Alternativas:
· a)
1. bifurcação ou junção, 2. desvio temporário, 3. início de atividade.
· b)
1. final de atividade, 2. decisão ou merge, 3. bifurcação ou junção.
Alternativa assinalada
· c)
1. repetição, 2. retorno, 3. conclusão.
· d)
1. repetição, 2. decisão ou merge, 3. bifurcação ou junção.
· e)
1. início de atividade, 2. desvio condicional, 3. conclusão.
5)
Os diagramas da UML se dividem em dois grandes grupos: diagramas estruturais e diagramas comportamentais. Diagramas estruturais devem ser utilizados para especificar detalhes da estrutura do sistema, diagramas comportamentais devem ser utilizados para especificar detalhes do comportamento do sistema (parte dinâmica), por exemplo: como as funcionalidades devem funcionar, como um processo de negócio deve ser tratado pelo sistema, como componentes estruturais trocam mensagens e como respondem às chamadas.
Disponível em: https://www.ateomomento.com.br/diagramas-uml/ . Acesso em: 20 ago. 2020.
 
 
De acordo com as informações apresentadas na tabela a seguir, faça a associação dos tipos de diagramas na Coluna A com seus respectivos diagramas, apresentados na Coluna B.
 
	COLUNA A
	COLUNA B
	 
	I. Casos de uso.
	1. Comportamental
	II. Sequência
	2. Estrutural
	III. Atividade
	 
	IV. Classe.
Assinale a alternativa que apresenta a associação CORRETA entre as colunas.
Alternativas:
· a)
1 - III  /  2 - I  /  2 - II  /  2 - IV.
· b)
1- I  /  1 - II   /  1 - III  /  2 - IV.
Alternativa assinalada
· c)
1 - I  / 2 - II  /  2 - III  /  2 - IV.
· d)
1 - IV  /  2 - I  /  2 - II  /  2 - III.
· e)
1 - II  /  2 - I  /  2 - III  /  2 - IV.
1)A ênfase do Diagrama de Comunicação está em demonstrar exatamente a ligação entre os objetos representados pela Lifeline, que participam da realização de um caso de uso. Segundo Guedes (2018), o Diagrama de Comunicação complementa o Diagrama de Sequência, concentrando-se na representação de como os elementos do diagrama estão vinculados e a ocorrência das mensagens que esses elementos trocam entre si durante a execução de um processo, normalmente baseado em um caso de uso, não se preocupando com a temporalidade do processo.
A figura a seguir ilustra um recorte de um Diagrama de Comunicação, correspondente ao caso de uso “Realizar Pedido” de um sistema de vendas.
 
Sobre os elementos representados no Diagrama de Comunicação, assinale a alternativa correta que condiz com a representação.
Alternativas:
· a)
A mensagem “9:cadasstrarItem( )” representa uma mensagem construtora para o objeto “item:ItemPedido”
· b)
 O elemento “produto:Produto” representa uma Linha de Vida (Lifeline), indicando uma coleção de instâncias da classe “Pedido”.
· c)
O elemento “item:ItemPedido” representa um Multiobjeto, ou seja, uma coleção de objetos de uma mesma classe, participando da interação.
Alternativa assinalada
· d)
 O elemento “FormPedido” representa uma Linha de Vida (Lifeline), indicando uma coleção de objetos do tipo interface do sistema. 
· e)
 O elemento “pedido:Pedido” representa uma Linha de Vida (Lifeline), indicando uma coleção de instâncias da classe “Pedido”. 
2)
Uma das formas mais utilizadas de especificar a interação entre os objetos é enfatizando à ordenação temporal das mensagens, representando a sequência lógica da troca de mensagens formada por um conjunto de objetos e seus relacionamentos, a partir da adoção do Diagrama de Sequência, o qual é uma forma de representar a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos na execução de um processo, ou seja, na realização de um caso de uso.
 
Sobre as possíveis trocas de mensagens que podem acontecer entre os elementos do Diagrama de sequência, julgue as afirmativas a seguir:
 I. Ator e Ator: indica uma comunicação entre os atores envolvidos na realização de um caso de uso.
 II. Ator e Objeto: geralmente o ator provoca um evento, enviando uma mensagem que dispara uma operação, contudo o ator pode simplesmente transmitir uma informação sem disparar uma operação.
III. Objeto e Ator: indica o retorno de uma mensagem com a resposta que transmite uma mensagem reflexiva para o Ator.
 IV. Objeto e Objeto: indica o envio de uma mensagem, disparando uma operação, sendo que um objeto pode enviar uma mensagem para si mesmo, denominada de mensagem reflexiva.
É correto o que se afirma em
Alternativas:
· a)
I e II, apenas.
· b)
III e IV, apenas.
· c)
I, II e IV, apenas.
Alternativa assinalada
· d)
II, III e IV, apenas.
· e)
I, II, III e IV.
3)
Todo objeto do mundo real ou do mundo computacional assumem diferentes estados durante a sua existência, ou seja, durante seu ciclo de vida. Durante a execução de uma funcionalidade do sistema, um objeto muda de estado quando acontece algum evento interno ou externo ao sistema, provocando uma transição entre os estados do objeto e com isso, o objeto realiza determinadas ações responsáveis pela consistência e integridade dos dados do sistema. Para modelar os estados de um objeto usa-se o Diagrama de Máquina de Estados.
 
Sobre a notação dos principais elementos do Diagrama de Máquina de Estados, julgue as afirmativas a seguir:
 I. O elemento “Estado Inicial” representa o estado de um objeto quando ele é criado. Pode haver vários estados iniciais em um diagrama de máquina de estados.
 II. O elemento “Estado Final” representa o fim do ciclo de vida de um objeto. Este estado é opcional e pode haver mais de um estado final em um diagrama de máquina de estados.
III. O elemento “Estado” representa uma situação na vida de um objeto durante a qual ele satisfaz alguma condição ou realiza alguma atividade.
 IV. O elemento “Transição de Estado” representa uma associação entre os estados, com uma seta apontando para um dos estados.
É correto o que se afirma em:
Alternativas:
· a)
I e II, apenas.
· b)
III e IV, apenas.
· c)
I, II e IV, apenas.
· d)
II, III e IV, apenas.
Alternativa assinalada
· e)
I, II, III e IV.
4)
A empresa Lógica Soluções em TI está revisando a sua metodologia de desenvolvimento de sistemas de softwares e decidiu adotar o modelo de processo denominado - Processo Unificado Ágil (AUP - Agile Unified Process) que adota as atividades em fases clássicas do Processo Unificado – Concepção, Elaboração, Construção e Transição, fornecendo uma camada serial, ou seja, uma sequência linear de atividades de engenharia de software que permite a` equipe visualizar o fluxo do processo geral de um projeto de software. Decidiu-se também adotar algumas técnicas de modelagem da Unified Modeling Language (UML) para modelagem dos sistemas, entre elas, um diagrama de interação que demonstra a sequência de eventos que ocorrem em um determinado processo, identificando quais métodos devem ser disparados entre os atores e objetos envolvidos, representando a troca de mensagens sequenciais entre os objetos das classes.
Considerando o contexto descrito, assinale a alternativa correta que indica o diagrama da UML que deve ser adotado para esse objetivo.
Alternativas:
· a)
Diagrama de Pacotes.
· b)
Diagrama de Atividades.
· c)
Diagrama de Máquina de Estados.
· d)
Diagrama de Sequência.
Alternativa assinalada
· e)
Diagrama de Visão Geral de Interação.
5)
Na modelagem da atividade de Análise ou da atividade de Projeto, a melhor indicação de uso do Diagrama de Máquina de Estados é para modelar o comportamento dos objetos das classes que possuem estados relevantes, o qual o comportamento das classes de objetos é afetado e modificado pelos diferentes estados, consequentes dos eventos disparados durante a execução dos casos de uso do sistema.
Assinale a alternativa correta que indica os elementos básicos de um Diagrama de Máquina de Estados.
Alternativas:
· a)
Estados, Transições de Estados, Estado Inicial e Estado Final.
Alternativa assinalada
· b)
Estados, Objeto, Classe, Atributo e Operação.
· c)
Objeto, Classe, Atributo, Operação e Mensagem.
· d)
Estados, Transições de Estados, Atividade e Ação.
· e)
Estado Inicial, Estado Final, Classe, Atributo e Operação.
Questão 1
O Diagrama de Classes é um diagrama que representa um conjunto de classes com seus atributos, operações e relacionamentos. A Figura a seguir ilustra um recorte de um Diagrama de Classes, com a representação suprimida dos atributos e operações.
Considerando o Diagrama de Classes, analise as sentenças que descrevem os relacionamentos estabelecidos entre as classes:
I. Um cliente realiza um ou mais orçamentos.
II. Cada orçamento refere-se a um cliente.
III. Um orçamento é composto por um ou mais itens de orçamento.
IV. Cada item de orçamento faz parte de um orçamento.
V. Cada item de orçamento refere-se a nenhum ou mais produtos.
Os itens corretos são exatamente:  
A)
 
I, II, IV e V.
B)
 
I e II.
C)
 
I, III e IV.
D)
 
II, III e IV.
E)
 
III, IV e V.
Questão 2
O Processo Unificado (PU) consiste em um processo de desenvolvimento de software iterativo e incremental, ou seja, a cada nova iteração são introduzidos incrementos de novas características à arquitetura do sistema. No PU, as fases de Concepção, Elaboração, Construção e Transição ocorrem em ciclos iterativos, a partir do conjunto de atividades que são executadas para a transformação dos requisitos de usuário em um sistema de software.
Assinale a alternativa que indica as atividades que são concentradas na fase de "Concepção".
A)
 
Projeto e Testes.
B)
 
Implementação e Testes.
C)
 
Análise e Implementação.
D)
 
Análise e Projeto.
E)
 
Requisitos e Testes.
Questão 3
Na empresa de desenvolvimentode software, Master Software, a metodologia para desenvolver sistemas orientados a objetos inclui algumas técnicas de modelagem da Unified Modeling Language (UML). Utiliza-se o Diagrama de Máquina de Estados para descrever o ciclo de vida de objetos de uma classe.
Considerando a notação gráfica do Diagrama de Máquina de Estados, assinale a alternativa correta que indica os elementos básicos do diagrama.
A)
 
Estado Inicial; Estados; Transições de Estados; Estado Final.
B)
 
Nó de Ação; Nó de Objeto; Fluxo de Controle; Estados.
C)
 
Estado Inicial; Estado Final; Atributos; Operações.
D)
 
Nó de Estado; Nó de Decisão; Estado de Escolha; Transição de Estado.
E)
 
Estados; Atividades Internas; Transições Internas; Operações. 
Questão 4
O Diagrama de Classes serve de base para todo o desenvolvimento do software, pois representa a estrutura do sistema como um todo, em diferentes perspectivas de detalhamento. O Diagrama de Classes representa um conjunto de classes com seus atributos, operações e relacionamentos. O objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas pelo sistema e como estas se relacionam.
Assinale a alternativa correta que descreve a notação do Diagrama de Classes.
A)
 
O nome de um atributo é declarado por um verbo, tipicamente, em letra minúscula e para palavras compostas usa-se concatená-las, sendo que a partir da segunda palavra inicia-se com letra maiúscula, por exemplo, "validarCnpj".
B)
 
Uma classe é representada por um retângulo com, no máximo, três partes. Na primeira parte (de cima para baixo) é exibido o nome da classe no plural. Na segunda parte, são declaradas as operações e, na terceira parte, são declarados os atributos.
C)
 
O relacionamento do tipo "Associação" de uma classe é representado por um losango, ligando as classes envolvidas. Pode-se indicar um nome na associação e a navegabilidade na extremidade das associações que indicará o sentido em que as informações são transmitidas entre os objetos das classes associadas.
D)
 
O nome de uma operação é declarado por um substantivo, tipicamente, em letra minúscula e para palavras compostas usa-se concatená-las, sendo que a partir da segunda palavra inicia-se com letra maiúscula, por exemplo, "razaoSociall".
E)
 
Uma classe é representada por um retângulo com, no máximo, três partes. Na primeira parte (de cima para baixo) é exibido o nome da classe. Por convenção, o nome é apresentado no singular e com as palavras compostas começando por letra maiúscula. Na segunda parte, são declarados os atributos e, na terceira parte, são declaradas as operações.
Questão 5
Para o desenvolvimento de um sistema de software, se não há um entendimento real do domínio do problema, a solução dificilmente é satisfatória. Por muitos anos, o desenvolvimento de software era feito sem seguir um padrão, sem a utilização de técnicas ou ferramentas. Ao longo dos anos, com uma maior exigência e necessidade de resolução de problemas mais complexos, surgiu maior demanda por sistemas mais complexos e assim, os modelos de processo de software evoluíram e muitos métodos de desenvolvimento de software surgiram.
Assinale a alternativa correta que indica o modelo de processo que foi criado para apoiar a Unified Modeling Language (UML).
A)
 
Modelo Espiral.
B)
 
Modelo Clássico.
C)
 
Modelo Linear.
D)
 
Processo Unificado.
E)
 
Processo Ágil.
Questão 6
Conforme o modelo de processo de desenvolvimento de software – Processo Unificado, o qual preconiza-se a iteração, as atividades de Análise e Projeto integram-se como uma atividade conjunta executada ao longo das fases do processo denominadas de __________, __________, __________, __________. Na atividade de Análise evolui-se a modelagem especificada na atividade de análise de requisitos, concentrando-se na solução do problema, a partir da abstração, identificação, definição e documentação do que o sistema deve fazer, considerando a visão lógica do negócio, independente das tecnologias que serão adotadas para implementação do sistema. Posteriormente, a Análise especificada vai se transformando em Projeto, com novos detalhes e refinamentos que definem os aspectos físicos do sistema e aplicados as tecnologias que serão adotadas na implementação do sistema. 
Assinale a alternativa correta que indica os termos que preenchem as lacunas acima:
A)
 
Elaboração, Construção, Avaliação e Transição.
B)
 
Concepção, Elaboração, Projeto e Implantação.
C)
 
Planejamento, Requisitos, Análise, Projeto e Testes..
D)
 
Concepção, Elaboração, Construção e Transição.
E)
 
Requisitos, Análise, Projeto e Implementação.
Questão 7
As técnicas de modelagem da Unified Modeling Language (UML) 2.0 são classificadas em estruturais, comportamentais e de interação, sendo que os diagramas de interação representam um Diagrama de Classes é a principal técnica de modelagem estrutural. A partir desses diferentes grupos de diagramas podemos ter a visão do sistema em diferentes perspectivas.
Assinale a alternativa correta que apresenta os diagramas de interação.
A)
 
Diagrama de Perfil, Diagrama de Objetos, Diagrama de Classes e Diagrama de Pacotes.
B)
 
Diagrama de Perfil, Diagrama de Tempo, Diagrama de Objetos e Diagrama de Pacotes.
C)
 
Diagrama de Objetos, Diagrama de Atividades, Diagrama de Tempo e Diagrama de Visão Geral de Interação.
D)
 
Diagrama de Atividades, Diagrama de Colaboração, Diagrama de Pacotes e Diagrama de Sequência.
E)
 
Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Tempo e Diagrama de Visão Geral de Interação.
Questão 8
O Diagrama de Classes da atividade de Projeto complementa os elementos do Diagrama de Classes da atividade de Análise, permitindo enriquecer os detalhes físicos do diagrama, obtendo um modelo suficientemente completo, aproximando-o com o que será implementado. No Diagrama de Classes de Projeto, recomenda-se indicar a restrição ou também denominado de classificador do relacionamento de generalização. Os classificadores da generalização são utilizados para definir melhor a semântica das classes _____________ derivadas da classe _____________.
Assinale a alternativa correta que indica o termo que preenche a lacuna acima.
A)
 
especializadas; genérica.
B)
 
especializadas; global.
C)
 
dependentes; central.
D)
 
individualizadas; genérica.
E)
 
individualizadas; central.
Questão 9
A modelagem de um sistema de software consiste na representação de diferentes modelos. O ______________ é um diagrama estrutural da UML, que visa identificar a arquitetura do conjunto de elementos que interagem entre si durante a execução do sistema, formando uma colaboração entre esses elementos que se comunicam, ou seja, a estrutura refere-se a uma composição de elementos interconectados por vínculos de comunicação que colaboram entre si para atingir um objetivo. Já para modelagem dos objetos que possuem estados relevantes, deve utilizar o ______________ que representa um comportamento que, especifica as sequências de estados pelos quais um objeto passa durante seu tempo de vida, em resposta aos eventos disparados que provocam as transições entre os estados.
Assinale a alternativa que indica o preenchimento correto das lacunas acima:
A)
 
Diagrama de Casos de Uso; Diagrama de Perfil.
B)
 
Diagrama de Estrutura Composta; Diagrama de Objetos.
C)
 
Diagrama de Estrutura Composta; Diagrama de Classes.
D)
 
Diagrama de Estrutura Composta; Diagrama de Máquina de Estados.
E)
 
Diagrama de Fluxo de Dados; Diagrama de Colaboração.
Questão 10
Em um nível alto de abstração, a modelagem de um software consiste na especificação de diferentes diagramas que são construídos no início do processo de desenvolvimento, nas atividades de requisitos e análise. O ___________________ representa a modelagem da parte estática do sistema, representando um conjunto de classes com seus atributos, operações e relacionamentos. Já, o ___________________ é utilizado para visualizar o comportamento de um sistema, demostrando todas as funcionalidades do sistema.
Assinale a alternativa correta que preenche as lacunas acima:
A)Diagrama de Classes, Diagrama de Use Cases (Casos de Uso).
B)
 
Diagrama de Sequência, Diagrama de Objetos.
C)
 
Diagrama de Use Cases (Casos de Uso), Diagrama de Máquina de Estados.
D)
 
Diagrama de Sequência, Diagrama de Classes.
E)
 
Diagrama de Máquina de Estados, Diagrama de Objetos.
Questão 11
Entre os elementos do Diagrama de Casos de Uso, o elemento associação representa um relacionamento de comunicação entre ator e os casos de uso, indicando uma interação com o sistema. Os relacionamentos de extensão e inclusão são específicos do Diagrama de Casos de Uso.
Assinale a alternativa correta que indica entre quais elementos do Diagrama de Casos de Uso pode ser estabelecido os relacionamentos de inclusão e extensão.
A)
 
Entre Ator e Casos de Uso.
B)
 
Entre Ator e Ator.
C)
 
Entre Ator e Pacote. 
D)
 
Entre Casos de Uso e Classes. 
E)
 
Entre Casos de Uso e Casos de Uso.
Questão 12
Seguindo as boas práticas da Engenharia de Software, uma empresa de desenvolvimento de software define a sua metodologia de desenvolvimento de sistemas, a partir da escolha do modelo de processo de software, método de desenvolvimento com suas técnicas de modelagem ideais ao domínio e complexidade do sistema, ferramentas etc,. O Processo Unificado foi criado para apoiar o desenvolvimento orientado a objetos com a Linguagem de Modelagem Unificada (UML), sendo dirigido por casos de uso (use cases), centrado em arquitetura, e é iterativo e incremental.
Considerando as fases do Processo Unificado, indique "V" para os itens verdadeiros e "F" para os itens falsos.
(  ) Na fase de Transição o sistema é entregue aos usuários treinados e inicia-se o processo de acompanhamento e manutenção do sistema.
(  ) Na fase de Concepção define-se a ideia geral do negócio do sistema e a delimitação do escopo do projeto, para obter um desenvolvimento bem fundamentado nos requisitos do usuário.
(  ) Na fase de Elaboração define-se como o sistema será construído a partir da definição dos requisitos do sistema, estabelecendo a arquitetura e mecanismos para especificar o sistema.
(  ) Na fase de Construção concentra-se na implementação e testes das funcionalidades, através do desenvolvimento iterativo e incremental do sistema.
Assinale a alternativa que indica a sequência correta dos itens. 
A)
 
F – F – F – F.
B)
 
V – F – V – F.
C)
 
F – V – F – V.
D)
 
F – V – V – F.
E)
 
V – V – V – V
.
image6.png
image7.png
image8.png
image9.png
image10.png
image11.png
image12.png
image13.jpeg
image14.png
image1.png
image2.png
image3.png
image4.png
image5.png