Aulas1_10_AV12

Prévia do material em texto

Aula 1 – Processo UP Iterativo e Incremental Produto RUP
O mundo real e percebido pelos sentidos e suas informacoes sao armazenadas nas nossas estruturas mentais ou em dispositivos que ampliam o nosso conhecimento.
O mundo simbolico de cada pessoa e construido a partir das experiencias vividas e existe na cabeca de cada pessoa. Nele estao os fatos, as regras de inferencia e outra estruturas que permitem tomar decisoes no nosso dia a dia.
Uma empresa tambem precisa ter estruturas, fatos e regras para se tomar decisoes. E o mundo simbolico da empresa. Toda empresa tem o seu assim como cada pessoa tem o seu. O mundo simbolico da empresa pode ser influenciado por pessoas. Sempre temos situacoes diferentes na empresas para um mesmo fato.
Processo de software
Para se produzir alguma coisa, e necessario saber os passo da fabricacao. O mesmo ocorre no software, e o que chamamos de processo de software. Dependendo das caracteristicas do software que pretendemos desenvolver, podemos escolher um dos diversos tipos de processos.
- prototipacao 
- cascata
- espiral
-XP
Sao algumas das propostas pra o processo de software.
Processo de software: e o conjunto de atividades organizadas para o desenvolvimento de um software.
Processo unificado PU e uma forma de processo de software
Processo unificado
Esse processo tem uma abordagem diferente, permitindo que se possa fazer o desenvolvimento aos poucos e que mudemos definicoes de etapas. Podemos desenvolver o projeto de forma estrategica, entregando partes do sistema para o usuario ate o seu termino. Podemos tambem incrementar modificacoes que sao naturais no desenvolvimento de projetos mais demorados e que ocorrem por necessidades da empresa ou do proprio projeto.
O PU implementa o que chamamos de estilo interativo, que consiste em subdividir o projeto em subconjuntos de funcionalidade, preferencialmente as que podem trazer ganhos para o usuario.
O Processo Unificado e iterativo e consiste em subdividir o projeto para sua implementacao por partes. O PU e constituido de atividades divididas em quatro fases
1 – Fase da concepcao: Nesta fase se “imagina” o produto, o que fara.  Seu objetivo e suas principais funcoes.  Pode-se fazer uma estimativa, ainda que “grosseira” de prazos e custo.  Pode-se “imaginar como funcionaria a sua funcao principal”. Nessa fase, decide-se se o produto e viavel ou nao. Pode-se dizer que, nessa fase, definimos o ESCOPO do produto, definindo o que faz e quais as suas limitacoes.
2 – Fase da elaboracao: Nesta fase pegamos cada funcao, segundo o escopo do produto, e lhe damos um tratamento tecnico, definindo como sera feito.  Nessa fase, o que se “imaginou” na fase anterior deve ganhar forma, isto e, deve ser viabilizado.  Inicia-se a identificacao de requisitos funcionais (necessidade do usuario) e nao funcionais (necessidades tecnicas), para implementar as funcoes do produto.  Nessa fase surge o projeto.
3 – Fase da construcao: As definicoes feitas na fase de elaboracao sao construidas.  No caso de software, nesta fase fazemos a programacao, definimos arquivos, testamos o que se “imaginou” virar realidade.
4 – Fase de transicao: Apos o produto pronto, ele precisa ser disponibilizado.  Nessa fase, fazem-se os ajustes necessarios para viabilizar o uso do produto.  No caso de software, fazem-se as implantacoes. Ajustes em programas e arquivos ja existentes.  Testes de integracao e aceitacao.  Essa fase e responsavel por disponibilizar o produto para uso.
Exemplo do planejamento de um desenvolvimento em software
No primeiro momento, identificamos as tarefas mais evidentes nas fases:
1 – Fase da concepcao: Missao do produto: Apoiar o controle de livros da biblioteca.
Funcoes: Registrar o acervo de livros.
Controlar os emprestimos.
2 – Fase da elaboracao: Fazer diagrama de contexto identificando atividades e atores.
Fazer o diagrama de caso e uso para registrar acervo de livros.
Fazer diagrama de caso e uso para controlar emprestimos.
Fazer o prototipo de telas identificadas para cada funcao.
Fazer o diagrama de estados para cada tela.
Fazer analise de risco para cada requisito.
Fazer o plano de desenvolvimento para o projeto.
3 – Fase da construcao: Fazer o desenho do software para a funcao de controlar acervo (1)
- implementar tabelas (1)
- implementar telas (1)
- implementar programas (1)
- testar integracao (1)
Fazer o desenho do software para a funcao de controlar emprestimo (2)
- implementar tabelas (2)
- implementar telas (2)
- implementar programas (2)
- testar integracao (2)
Integrar o sistema
4 – Fase de transicao: Implementar modulo de acervo
Testar com demais sistemas
Treinar o usuario no uso do sistema
Implantar o modulo de emprestimo
Modificar arquivos do modulo de treinar usuario
Testar com os demais sistemas
Treinar o usuario.
Segunda etapa:
Vamos dividir em iteracoes
1 – Concepcao:
Na fase de concepcao, vamos considerar uma única iteracao.  Normalmente, e a regra geral, pois, se entrega o documento que define o escopo do projeto.  Em algumas situacoes podemos ter outras iteracoes como, por exemplo, se tivessemos contratado um estudo de viabilidade.  Nesse caso, teriamos duas iteracoes.
Concepcao (alguns chamam de iniciacao).
2 – Elaboracao:
 A elaboracao e um pouco mais trabalhosa, pois, vamos definir varios artefatos que serao usados na construcao.  Assim, vamos definir, nesse exemplo, tres iteracoes.  Nao esqueca que esperamos terminar cada iteracao no prazo maximo de 20 dias (aproximadamente).
3 – Construcao:
 As iteracoes da construcao devem atender uma estrategia do projeto, tal como implementar uma funcionalidade para o usuario.  Vamos trabalhar no primeiro momento com tres iteracoes.
4 – Transicao:
 A transicao deve garantir que o sistema funcione, para isto deve garantir a implantacao e testes finais, alem do treinamento.
Terceira etapa
Ao trabalhar na fase de transicao, verificou-se que nada foi definido para a identificacao do usuario.  Foi uma falha na modelagem. Nesse caso, vamos voltar na fase de elaboracao e colocarmos as iteracoes necessarias para corrigir o problema.
Uma iteracao pode ser criada durante o desenvolvimento do sistema. E novas iteracoes para completar o sistema ou corrigir um problema podem ser incluidas no projeto.
RUP
IBM RationalUnifiedProcess, ou RUP, e a plataforma de processo de desenvolvimento de software. Configuravel. Esse produto e constituido de um conjunto de templates que devem ser gerados durante o desenvolvimento do software. Nesse produto implementa se o PU. Os templates foram desenvolvidos de forma que o software desenvolvido desta forma possa atender as melhores praticas de gestao e qualidade CMMI
Do conjunto de templates podem se selecionar e implementar apenas os componentes de processo que voce precisa para cada estagio de seu projeto.
Aula 2 – Introducao a linguagem UML Caso de uso levantamento de requisitos
Surgimento do UML
UML foi desenvolvida por GradyBooch, James Rumbaugh e Ivar Jacobson, que sao conhecidos como “os tres amigos”.  UML  e um conjunto de diagramas padronizados e integrados para ajudar na descricao da analise e projeto de um software.  O UML, foi proposto em 1976, com objetivo de padronizar o uso de ferramentas.  Nessa epoca existiam varios autores, propondo solucoes para a modelagem.  O surgimento do UML possibilitou uma padronizacao e apoia o projeto de software, desde seu levantamento de requisitos ate sua implantacao.  O UML , hoje, e controlado pelo OMG.
O UML e um conjunto de diagramas, como mostrado na imagem.
Analise Orientada Por Objetos
A orientacao a objetos tem-se desenvolvido  desde o lancamento da 1ª linguagem orientada a objetos, a SIMULA.  Autores consagrados da engenharia de software, como:  Peter Coad, Edward Yourdon e Roger Pressman, consideram  a analise orientada a objetos como o maior avanco para o desenvolvimentode software.
 
A orientacao a objetos nao e so teoria, mas uma tecnologia de eficiencia e qualidade comprovadas, usadas em inúmeros projetos e para construcao de diferentes tipos de sistemas.
Quando o sistema e desenvolvido com esta tecnologia, tem-se:
- Melhor reaproveitamento de seu codigo no proprio sistema e em outros
- Facilidade de manutencao
- Melhor compreensao do codigo
- Mais seguranca no uso de componentes por parte do programador
Desenvolvimento Diagramas De Caso E Uso
Trabalhando o Levantamento
Apos o primeiro levantamento vamos elaborar os nossos diagramas de caso e uso. Nesta fase vamos dicionarizar todos os casos e usos.
No primeiro caso e uso:
	Nome do caso e uso
	Liberar pagamentos
	Ator
	Secretaria
	Pre condicoes
	Chega uma nota fiscal com carimbo
	Pos condicoes
	Emitir guia de liberacao
	Descricao
	
	Este caso e uso inicia quando o ator recebe uma nota fiscal examina quem carimbou data verifica se o valor e compativel e termina com a emissao da guia de pagamento.
Uso De Estereotipo
Voce verificou que usamos um palavra entre <<        >>.  Isto eh, para indicar o que chamamos de estereotipos.  Um estereotipo eh uma serie de caracteristicas que servem para classificar alguma coisa.  No diagrama, o estereotipo indica que devemos dar o mesmo tratamento de analise e construcao, quando formos construir o sistema.  Assim, o <<include>> indica que devemos tratar todos os arcos da mesma forma (sugiro o tratamento por funcao ou modulo).  E 
comum, tambem, se usar << use >>, com as mesmas caracteristicas.
O << EXTENDED>> indica o tratamento comum.  Se eu fosse o desenvolvedor, sempre trataria os elementos gerados a partir destas elipses como especiais e os separaria dos demais.  Existem, ainda, o << INTERFACE>>, que e o arco entre o ator e o comando de utilizacao, nesse caso se informa que o tratamento de chamada deve ser feito do mesmo modo, por exemplo: com telas de entrada. Voce pode criar o seu proprio estereotipos, por exemplo: <<ORACLE>> pode indicar que voce deseja que os elementos da elipse marcadas com este estereotipos deverao ser implementadas no ORACLE.   O importante e que se apresente o dicionario de estereotipos.
Erros Comuns
Muitas pessoas mal informadas consideram o diagrama de caso e uso como se fosse um DFD.  Isto e um erro grave.  O diagrama representa conjunto de atividades.  Os arcos nao indicam fluxos de dados.  Sao chamadas a grupos de atividades.
Assim, e comum vermos diagramas de caso e uso mal feitos, representando programas, como o mostrado abaixo:
Aula 3 – Diagrama de classe Modelo de dominio
Diagrama de classes
O diagrama de classes eh o principal dos diagramas do UML.  O diagrama e como uma fotografia dos elementos usados pela aplicacao.  E uma representacao estatica e nao deve ser usado para representar dinamicas da aplicacao, embora tambem as retrate, como veremos.  Existem varios niveis de diagrama de classes, eles sao usados no nivel de dominio – conceitual – e em nivel de projeto.  Nesta aula vamos abordar o diagrama de classes a partir da observacao do mundo real para um determinado contexto, vamos construir o diagrama, em nivel de dominio.  Isto e, nao se devem representar estruturas de projeto (chaves, arquivos, campos...).  O foco da analise e o negocio.  Imagine que voce esta no seculo 15 e que nao tem computador – quando estiver fazendo esse modelo.
Identificando classes
Uma classe e uma forma de representarmos no mundo simbolico um conjunto do mundo real.  Ao observar um conjunto sobre o qual temos alguns interesses  dizemos que temos uma classe.  As propriedades que desejo observar  sao chamado de atributos.
Representando uma classe
Existem varias formas graficas para se representar uma classe, mas em UML, quando temos interesse em um conjunto do mundo real, desenhamos:
Queremos observar um conjunto de pessoas, e as informacoes sobre as quais temos interesse sao: nome, endereco, telefone, CPF
Ao definir a classe de dominio, definimos um modelo de representacao dos elementos do conjunto:
Assim, os elementos
(Manoel, Rua do Bispo-3, 32116734, 371622571)
(Jose, Rua Ava-34, 3226216, 37162225881)
Fica representado:
Observe que colocamos os valores que os atributos assumem nas representacoes.  Nesse caso, dizemos que a classe foi INSTANCIADA, ou seja, recebeu valores.  Cada um dos elementos no mundo das representacoes e chamado de um objeto da classe.  Entao, uma classe representa um conjunto e os elementos do conjunto – objetos – sao representados segundo a definicao da classe.
Uma classe e a descricao de um tipo de objeto do mundo real.
Usam-se classes para classificar os objetos que identificamos no mundo real.
As classes devem ser retiradas do dominio do problema.
Uma classe completa,  no UML, e  representada por um  retangulo dividido em tres compartimentos: o compartimento de nome, que contera apenas o nome da classe modelada, o de atributos, que possuira a relacao de atributos que a classe possui e o compartimento de operacoes chamadas de  metodos. Nos veremos o que e metodo e sua modelagem em aulas futuras
Foi instanciado o objeto Pablo Barros, da classe cliente.  E as operacoes que se pode fazer com ele sao: criar() e destruir().  Vamos aprender como identificar os metodos, ainda em aulas futuras
Relacionamentos
Outro elemento importante, para a modelagem de classes, e o relacionamento.  Aqui, o relacionamento tem o mesmo conceito matematico estabelecido em teoria dos conjuntos.  Tem-se um relacionamento, quando estabelecemos alguma “ligacao”, do nosso conhecimento, entre os conjuntos.  VIU... Nao e uma ligacao fisica... e uma ligacao do nosso conhecimento – ou do dominio da aplicacao- por isto, nao tem como se constatar fisicamente.  E um elemento conceitual. Reflete o conhecimento a respeito de alguma coisa.  So existe no mundo simbolico.
Voce tem o conjunto dos homens e o conjunto das mulheres.
Um relacionamento e um estabelecimento conceitual entre elementos de um conjunto com outro que depende de que aspecto do mundo real estamos analisando.
Multiplicidade dos relacionamentos
Uma informacao importante, quando trabalhamos com os relacionamentos e de como os elementos do conjunto se comportam em relacao ao outro.  Quando eu tenho um conjunto  A e um conjunto B, na matematica um relacionamento representa um par (a,b) onde a pertence ao conjunto A e b pertence ao conjunto B.
Pode ser que todos os elementos de A tenham o par (a, b), neste caso se fala PARA TODO a pertencente ao conjunto A temos uma imagem b no conjunto B.   Observe que nao INTERESSA como chega ou para quem chega ao conjunto B.
Existem quatro possibilidades de multiplicidade do conjunto A em relacao ao conjunto B:
Primeira situacao
Todo Veiculo pertence a UM aluno.
Analisando A verificamos que de todo elemento do conjunto A sai uma flecha:
Neste caso representamos esta informacao junto ao relacionamento no sentido da leitura
Segunda situacao
Existem alunos que TEM  ZERO ou UM pai vivo
Observe que da situacao anterior UM elemento do conjunto A nao tem correspondente no conjunto B. Se existir um elemento (basta um) nao ter correspondente que caracterizamos esta situacao.
Representamos assim:
Terceira situacao
Lemos do seguinte modo: Um aluno cursa uma ou mais de uma disciplina.
De todo elemento de A estabelecemos um relacionamento, mas existem ( no minimo um) elementos que tem mais de um correspondente no conjunto B
Quarta situacao
Importante:
Na multiplicidade  0..N ou 1..N, estamos representando o minimo e o Maximo de relacionamento de um elemento, na forma min..max, assim, pode se representar 3..10, indica que existem elementos no conjunto a com um minimo de 3 correspondentes em B e no maximo 10 correspondentes no conjunto B.
Pode-se ainda substituir o N por *
No minimo, um elemento pertencente ao conjunto a nao tem correspondenteem b e existem elementos no conjunto A com mais de uma imagem.
Representa-se:
Analise dos relacionamentos
Quando fazemos a analise dos relacionamentos,  estabelecemos duas informacoes:  Relacionamento do conjunto A para o conjunto B; e do conjunto B para o conjunto A.  Assim, vamos completar os exemplos anteriores:
Primeira situacao
Lemos:  um veiculo pertence a um aluno,
E um aluno possui 0 ou mais veiculos  (ha alunos que nao tem veiculo e alunos que tem mais de um)
Segunda situacao
Lemos um aluno tem 1 ou Zero PAI VIVO, e 
Um PAI VIVO mantem Zero ou mais alunos
Terceira situacao
Lemos:
Um aluno cursa 1 ou mais disciplinas; e Uma disciplina tem O ou mais de um aluno
Quarta situacao
Lemos: Um aluno possui zero ou mais veiculos; e Um veiculo pertence a um aluno
De forma resumida para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estao  relacionados.  O intervalo pode ser de zero para um (0..1), zero para varios (0..* ou apenas *), um para varios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. E tambem 
possivel expressar uma serie de números como (1, 4, 6..12). 
Se nao for descrita nenhuma multiplicidade, entao e considerado o padrao de um para um (1..1 ou apenas 1).
Classes dependentes
Existem alguns conjuntos que, no processo de modelagem, desejamos condiciona-los a existencia de outros conjuntos. Sao chamados de conjuntos dependentes.  A dependencia de conjuntos e uma ferramenta da modelagem.  Nesse caso, o modelador deseja que a identificacao do conjunto dependente seja feita a partir do conjunto a.  A representacao da dependencia e por uma linha tracejada.
O diagrama significa que o familiar deve ser identificado a partir da identificacao do empregado.  Na realidade, um objeto dependente so pode ser dependente de um único objeto, por isto e desnecessario a indicacao da multiplicidade 1.
Associacoes
Outro recurso importante e a associacao.  Uma associacao e um conjunto criado com objetivo de ligar outros dois (ou mais) conjuntos existentes.
As classes associadoras sao representadas por linhas cheias e a classe que as associa e ligada a esta linha cheia por uma linha pontilhada.
Toda vez que tivermos um relacionamento de multiplicidade ( 0..*) para os dois lados do relacionamento, deve-se usar a classe associativa.  O modelo de classes de objetos e determinista, isto e, devemos saber quem se relaciona com quem, portanto  a multiplicidade 1 e obrigatoria nos relacionamentos fora da estrutura associativa.
Uma empresa trabalha com projetos.  Todo empregado trabalha em um projeto, cada projeto e coordenado por um orgao.  O departamento de pessoal precisa saber que dia e hora o empregado entrou e saiu de cada projeto. Faca um modelo de classes que permita fornecer esta informacao:
Primeiro passo : O modelador iniciaria identificando os conjuntos existentes:
Aula 4 – Pratica e particularidades do UML diagrama caso de uso e classe
Diagrama de classes
O UML especifica uma serie de informacoes complementares aos conjuntos identificados do mundo real e seus respectivos relacionamentos.  Essas informacoes tem o objetivo da implementacao.  Sim, porque nao devemos esquecer que o objetivo e definir um sistema de informacoes. Alguns dos instrumentos apresentados sao para outros diagramas e vamos aprender a usar estas  ferramentas em outros diagramas.
Completando as associacoes
Uma associacao e um conceito que liga dois conjuntos, matematicamente  e um par (a,b) onde: a pertence a um conjunto e b pertence ao outro conjunto.
Quando apresentamos a associacao, mostramos que existem duas informacoes  - do conjunto A para o conjunto B e do Conjunto B para o conjunto A – e representamos estas informacoes.  Estavamos NOMEANDO OS  relacionamentos mas,  na pratica, nao ha necessidade de se qualificar estes relacionamentos, pois, o nosso principal objetivo e a multiplicidade.
O que o UML  define para se representar em um relacionamento:
multiplicidade
generalizacao
nomeacao
ordenacao
qualificador
navegabilidade
agregacao
composicao
especificador de interface
mutabilidade
visibilidade
ordenacao:
Considere a modelagem  abaixo, observe que os relacionamentos estao nomeados e, no caso do relacionamento de multiplicidade (0..N), se deseja informar que os veiculos devem ser ordenados de forma crescente por ano.
Nesse caso, indicamos junto ao conjunto.
Indica que o conjunto de veiculos e ordenado; a representacao nao indica a forma de ordenacao.
qualificador:
Quando necessitamos qualificar uma associacao, com objetivo de reduzir a multiplicidade, e representada no relacionamento com um retangulo menor, onde se faz a qualificacao.  O Retangulo do qualificador e parte do cominho e nao faz parte da classe.
No desenho, o qualificador indica que cada item de NF, na nota fiscal, refere-se a um produto.  Essa representacao evita de se representar a classe de produto.  A qualificacao e uma informacao para a implementacao – e um conceito voltado para a programacao – indica que, na implementacao da nota fiscal, deve haver um objeto do tipo produto para cada objeto de item de nota fiscal.  Isto indica que nao devem existir dois itens de nota fiscal para um mesmo produto.
Tambem,  pode ser visto como um tipo de chave para separar todos os objetos no relacionamento de multiplicidade n.
navegabilidade:
Quando for implementado (codigo de programacao) um objeto, podem-se chamar operacoes de outros objetos.  Diz-se que de uma classe instanciada podem-se acessar instancias de outras classes que tem relacionamentos com a primeira classe.  Para indicar o sentido da NAVEGACAO, ou seja, como podemos percorrer (chamando funcoes – veremos na proxima aula), usamos uma flecha no final do relacionamento.  Assim:
A navegacao e de aluno, que e chamada de classe fonte; para veiculo e chamada de classe alvo.  Isso indica que da classe aluno podem-se identificar os veiculos de um aluno.  Mas, nao e possivel identificar o aluno dono de um veiculo.
As classes, normalmente, se relacionam de forma de bidirecional; por definicao, a navegacao pode ocorrer nos dois sentidos do relacionamento, exceto quando dito ao contrario.
agregacao:
Quando desejamos que um conjunto fosse tratado de forma incorporada com outro conjunto. Uma agregacao e uma representacao que indica que o objeto e composto com outros objetos, por exemplo: uma nota fiscal e composta por seus itens de nota fiscal.   A nota fiscal, neste caso e chamada de objeto TODO e o item de nota fiscal e chamado de objeto PARTE.  A estrutura constituida dessa forma e chamada de TODO-PARTE.  E a agregacao tem como caracteristica propria: os objetos parte sao criados pelo objeto todo, ao qual estao agregados; portanto  o objeto todo ja deve ter sido  criado. 
Tambem e chamada de  de agregacao por referencia.
 Representa-se por um losango vazado, no relacionamento:
A agregacao indica que uma das classes do relacionamento e uma parte, ou esta contida em outra classe. As palavras chaves usadas para identificar uma agregacao sao: “consiste em”, “contem”, “e parte de”.
Exemplo de uma agregacao entre duas classes Existem tipos especiais de agregacao que sao as agregacoes compartilhadas e as compostas.
composicao:
A composicao e outra forma de tratarmos a estrutura toda-parte. Uma composicao e uma representacao que indica que o objeto e composto com outros objetos, tal qual na agregacao; em uma agregacao, apos serem estabelecidas as relacoes, elas sao inalteraveis; eles nao poderao ser modificados. Na composicao, o objeto todo contem os objetos parte.  Assim ao se instanciar o objeto todo, os partes tambem sao instanciadas; tambem e chamada de agregacao por valor.  Representa-se  o losango de forma cheia.
especificador de interface:
Um classificador indica um comportamento esperado de um objeto, que esta sendo relacionado.  Define o comportamentoexigido para se estabelecer o relacionamento.
  Tem a seguinte sintaxe.
nome-do-classificador
Quando o especificador e omitido, e por que se tem acesso a todos os elementos da classe.
Exemplo:
Indica que o relacionamento e feito, quando a media (um dos atributos de aluno aprovado) e maior que sete.
mutabilidade:
Indica se os relacionamentos estabelecidos sao mutaveis (podem ser agregados, apagados).  Quando nada e dito, indica que nenhum indicador e necessario. A propriedade {congelado} indica que apos ser criado, nenhum vinculo pode ser feito.  A propriedade {somarSomente} indica que os vinculos podem ser somados.
visibilidade:
A visibilidade e especificada para os atributos de uma classe e tambem entre classes.   Os indicadores de visibilidade para atributos sao:
Ou a palavra publico: Indica que qualquer funcao metodos de outras classes pode ter acesso e usar estes atributos;
Ou a palavra privado: indica que apenas as funcoes metodos escritas dentro da classe podem ter acesso e usar esses atributos
Ou a palavra protegido: indica qua as funcoes especificadas dentro de uma estruturagen-esp podem ter acesso e usar estes atributos
A visibilidade entre classes sao especificadas junto aos relacionamentos (veremos nas proximas aulas)
Relacionamentos Recursivos Ou Autorelacionamento.
Imagine que voce tem um conjunto de equipamentos de hardware.  Nesse conjunto temos equipamentos como teclados, videos, mouses,  que sao únicos, ou seja, tem um identificador e um único fabricante.  Existem tambem computadores (equipamentos compostos) que sao compostos por equipamentos únicos.  Para representar isto temos:
Ou seja, estamos criando relacionamento entre os elementos do proprio conjunto.
E possivel conectar uma classe a ela mesma, atraves de uma associacao e que ainda representa, semanticamente, a conexao entre dois objetos; mas os objetos conectados sao da mesma classe. Uma associacao deste tipo e chamada de associacao recursiva.
Relacionamentos Recursivos ou Autorelacionamentos
Apesar de o UML definir o autorelacionamento, no meu entender, nao ha necessidade de se usar este tipo de recursos, pois, fica pouco claro como ocorre o relacionamento e nao se define que objetos estao associados.  Voce ja tem o recurso do subconjunto, portanto, basta modelar os subconjuntos e estabelecer o relacionamento entre eles.
Assim, no exemplo, temos dois tipos de equipamentos: Simples e Compostos – podemos definir dois subconjuntos e depois associar os componentes.
Sempre que possivel, desenvolva a analise, identifique que objeto se relaciona com que objeto.  Isso evitara problemas, na fase de implementacao do sistema.
Associacao Exclusiva
Uma associacao exclusiva e uma restricao em duas ou mais associacoes. Ela especifica que objetos de uma classe podem participar de, no maximo, uma das associacoes, em um dado momento.
 Uma associacao exclusiva e representada por uma linha tracejada entre as associacoes, que sao partes da associacao exclusiva, com a especificacao “{ou}” sobre a linha tracejada.
No diagrama, um contrato nao pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento e exclusivo a somente uma das duas classes. Novamente, lembro que podemos destacar como subconjuntos e mostrarmos a disjuncao.
Aula 5 – Identificacao de metodos e mensagens
Diagrama de sequencia
Os casos e uso devem ser implementados, deve-se definir como devem ser implementados. Os diagramas de interacao, que mostram como as classes interagem, sao o diagrama de sequencia e o diagrama de colaboracao. Nesta aula vamos estudar os principais aspectos do diagrama de sequencia. No diagrama de sequencia estamos definindo que funcoes devem ser implementadas, se definir como e o codigo, para que o caso e uso possa ser realizado. O objetivo e identificar funcoes, que sao as unidades para definir novas funcoes.
Comparando com fatoracao de números, no diagrama de sequencia “fatoramos” os caso e uso. Nao confunda – Um diagrama de sequencia mostra a sequencia de execucao de funcoes, portanto, nao mostra troca de informacao. Um diagrama de sequencia e uma especie de algoritmo de alto nivel em que se destaca a chamada das funcoes.
Os casos e uso devem ser implementados, deve-se definir como devem ser implementados. Os diagramas de interacao, que mostram como as classes interagem, sao o diagrama de sequencia e o diagrama de colaboracao. Nesta aula vamos estudar os principais aspectos do diagrama de sequencia. No diagrama de sequencia estamos definindo que funcoes devem ser implementadas, se definir como e o codigo, para que o caso e uso possa ser realizado. O objetivo e identificar funcoes, que sao as unidades para definir novas funcoes. Comparando com fatoracao de números, no diagrama de sequencia “fatoramos” os caso e uso. Nao confunda – Um diagrama de sequencia mostra a sequencia de execucao de funcoes, portanto, nao mostra troca de informacao. Um diagrama de sequencia e uma especie de algoritmo de alto nivel em que se destaca a chamada das funcoes.
Metodos
Um metodo e uma funcao que colocamos dentro da classe, isto quer dizer que a funcao esta encapsulada e so pode ser
executada a partir da classe.
Nao e uma boa pratica de modelagem colocar metodos nas classes sem o desenvolvimento de um dos diagramas de interacao.
Mensagem
Os objetos precisam trabalhar de forma coordenada, e por isto devem se comunicar atraves de seus metodos. Um objeto pode chamara a execucao de um metodo de outro objeto. A chamada do metodo de outra mensagem e o que chamamos de mensagem.
Quando desejamos definir como e quais mensagens sao transmitidas, podemos fazer um diagrama de sequencia ou um diagrama de colaboracao sao chamados de diagramas interativos.
Para cada caso e uso desenhamos que classes e que mensagens sao necessarias para se implementar o caso e uso.
Diagrama de sequencia
Mostra a sequencia de chamada de metodos (MENSAGENS) ao longo do tempo.
Para isto devemos estanciar os objetos que irao ser utilizados.
Para se representar um objeto instanciado, por exemplo, para a classe aluno, temos:
: aluno representa que um objeto qualquer da classe aluno foi instanciado – Joao
: aluno representa que o objeto nomeado como Joao, da classe aluno, foi instanciado.
Um objeto instanciado tem um tempo de existencia.  A existencia do objeto e representado por um retangulo, desenhado em  um traco na horizontal, chamado linha da vida (representacao no tempo) .
Na figura, o inicio do retangulo indica o momento que o objeto e criado.  Uma classe tem, no minimo, dois metodos obrigatorios. O metodo construtor() e o metodo destrutor().  O metodo construtor e disponibilizado automaticamente e tem, como objetivo, criar todas as estruturas de dados, mecanismos de software e controles necessarios a existencia do objeto.  Assim, o inicio do retangulo indica que foi executada o metodo construtor da classe.  O metodo destrutor  e responsavel por liberar aereas de trabalho e estruturas que foram estabelecidas pelo construtor  Assim, o destrutor libera espaco na memoria e dispensa a CPU de executar atividades desnecessarias.  Quando nao se deseja mais o objeto instanciado deve-se passar a funcao destrutora, normalmente indica-se isto pela palavra DESTROY, ou KILL, ou FREE.  Quando nao se indica a chamada da funcao destrutora, assume-se que ela ocorre no final da execucao do caso e uso.
um metodo (ou funcao encapsulada) e da forma:
<tipo:retorno> nome (<paramentrotipo:nome>);
int:matricula ID_ALUNO (string:CPF);
Indica uma funcao chamada ID_ALUNO que retorna um número inteiro chamado matricula e que ao ser chamada para executar recebe uma string chamada CPF.
Uma boa pratica de desenvolvimento e se numerar a sequencia das chamadas de metodos.  Embora o UML especifique como se deve representar um metodo, algumas pessoas nao representam os tipos junto ao retorno e aos parametros.  Alguns metodos nao precisamde parametros  Os retornos das funcoes pode ser representados por linhas pontilhadas.  So tem sentido se colocar retornos quando a informacao voltada sera usada no processamento de um metodo.
Autodelegacao
Um metodo pode ser chamado por outro metodo dentro de uma classe. Nesse caso, o objeto esta enviando uma mensagem para ele mesmo. È o chamamos de autodelegacao e representa-se:
Na pratica, as linguagens de programacao, ao executarem um metodo, guardam o endereco desta execucao em uma variavel especial chamada THIS. Quando se faz a auto delegacao, busca-se, para execucao do metodo, o endereco armazenado nessa variavel.
Podemos indicar a execucao da forma:
THIS.mesagem();
Uma mensagem e uma chamada a esse metodo. Pode-se indicar o acesso a um atribulo, ou metodo de um objeto, indicando o nome do objeto. 
Assim para a classe:
Podemos chamar a funcao construtora, que vai criar o objeto.  Suponha que desejamos o objeto  Joao.
As linguagens, geralmente, fazem isso por um metodo com o mesmo nome da funcao ou pelo operador new.
 Aluno Joao:  /aluno e um novo tipo e foi criado o objeto Joao.
Joao = new aluno; / Joao e um objeto que foi criado da classe aluno.
Podem-se acessar os atributos da classe, indicando o objeto e a estrutura que desejamos de dentro da classe.
     Nome   --> indica que estamos acessando a variavel nome do objeto Joao
     Joao.Telefone = “23657854”.  --> indica que o telefone 23657854 foi atribuido a variavel telefone no objeto Joao.
     Joao.transferir(); --> indica que foi ativada (executar) a funcao transferir, a partir do objeto Joao e com as caracteristicas existentes no objeto, na hora da chamada.
Vamos construir alguns diagramas de sequencia para explicitar alguns conceitos:
Considere  o caso e uso: Matricular um aluno em uma universidade.
   Com uma única classe´.
Para incluir um objeto aluno, temos o seguinte diagrama de sequencia:
Inicialmente, registramos os objetos que serao usados com a representacao de sua existencia na linha da vida.
Depois, comecamos a desenhar cada metodo com as respectivas mensagens.
Observe que o nome do caso e uso e o metodo inicial no diagrama.  E esse metodo estabelece uma serie de mensagens.  Todas as mensagens sao feitas no proprio objeto.  A primeira mensagem chama o metodo mostrar_tela(); este metodo e responsavel por criar uma tela para ser preenchida com os dados do aluno e, tambem, faz a critica desses dados (eu estou definindo isto), ao se clicar OK (eu estou imaginando um botao de OK na tela) os dados (nome, matricula e telefone), correspondente aos atributos  da classe, serao conhecidos e devem ser incluidos no conjunto (arquivos ou banco de dados, nao e momento de definir isto agora), para isto vou estipular outro metodo com o nome de incluir_aluno(); e vou passar estes dados como parametros.
Observacao:
Observe que a chamada de metodos (mensagens) so pode ser feita para metodos definidos na classe, por isto vamos colocando os metodos identificados por cada classe.
Se analisarmos a estrutura do caso e uso do exercicio, verificamos que a forma que foi projetado nao e adequada, pois, permitira que se inclua duplicatas de alunos.  O ideal e que verificassemos se o aluno ja existe no conjunto.  Nesse caso, deveriamos colocar um metodo para verificar isso, poderiamos, por exemplo, criar um metodo que retorne a string “sim”, se ele ja existe ou nao, se ele nao existe.  So vamos incluir se voltar nao.
Se tivermos uma linguagem de programacao orientada a objetos, teriamos de definir nossa classe assim:
      Classe Aluno
   {  atributos:
          String Nome;
          Stringend;
          Int matricula;
       Metodos:
          Voidmatricular();
          Voidmostrar_tela();
          StringValidar();
         Voidincluir­_aluno();
   }
O diagrama corresponde a um algoritmo que incida metodos usados:
Vamos mostrar, com uma pseudolinguagem, como ficaria o metodo matricular();
Aluno::void matricular()
                    { string variavel; // para receber a volta da validacao
                        .....
 // nome, end, matricula sao variaveis da classe e sao  
 //acessadas pelos metodos
This.mostrar_tela();
  // esta funcao le e armazena dados nos atributos;
  Variavel= this.validar(); //retorna sim ou nao para a variavel
  Se (variavel==”nao”)
           This.incluir_aluno() 
      Senao
           Imprimir “aluno ja existe”
retornar
                     }
Considere que o analista de requisitos nos enviou o seguinte:
Os Objetos envolvidos para se realizar o metodo sao: :matricula, :aluno e :curso  Esses objetos precisam estar na memoria  (pelo menos achamos isto inicialmente) para podermos executar as funcoes (que vamos identificar) e acessar os valores dos atributos.
Observe, no meu diagrama, que comecei  pelo objeto matricula, voce pode contestar isso.  Para fazermos a matricula, no diagrama de classes vemos que precisamos, de alguma forma, buscar o codigo do aluno e o codigo da disciplina, entao mandamos mensagens para esses objetos retornarem esses codigos.  Com o conhecimento dos codigos, podemos incluir no conjunto associativo.
1 - Classe curso
{atributo:
       String nome;
       Intcod_curso;
Metodos:
      IntID_curso();
2 - Classe curso
{atributo:
       String nome;
       Intcod_curso;
Metodos:
      IntID_curso();
3 - Classe curso
{atributo:
       String nome;
       Intcod_curso;
Metodos:
      IntID_curso();
A titulo de exemplo, teriamos o algoritmo em pseudocodigo correspondente ao diagrama de classes, par ao metodo mat():
Matricula::voidmat()
                {  int valor1, valor2 // duas variaveis para receber o retorno   
                                            // dos metodos
                   AL = new aluno; // criou o objeto aluno
                   CUR = new curso; // criou o objeto curso
                   // nao precisa criar o objeto matricula, pois, ele esta na   
                    //variavel THIS – o metodo deve ser chamada pelo objeto
                   // matricula 
                  ..
                   Valor1=AL.ID_al();
                   Valor2=cur.Id_cur();
                  ...
                   This.incluir();
                  ....
                   retorna    
                 }
Existem situacoes que o diagrama de sequencia tem um a condicional.  Isto e representado representando-se por letra e com a condicao.
Vamos considerar o caso e uso e o respectivo diagrama de classe:
Vamos projetar o diagrama de sequencia para o caso e uso, e verificamos que apos se verificar o tipo de usuario (professor ou aluno) deve-se abrir ativar a tela de professor ou de usuario.
Assim considerando os objetos envolvidos temos:
Observe a numeracao dos metodos .  O metodo logar e 1. E ele e constituidos por chamadas a outros metodos 1.1 (auto metodo) e 1.2.a que e uma alternativa e 1.2.b outra alternativa.
Observe que as alternativas sao representadas de um mesmo ponto.  O caminho de a cada alternativa e indicada pelo valor da condicao,  por exemplo,  1.2.1[tipo=aluno] indica que sera executado o metodo ativar() da sub classe aluno.
No desenvolvimento de um metodo o ponto onde se define uma chamada pode corresponder a um comando Se... entao, ou a um comando switch case.  Veja a representacao abaixo:
A representacao numerica indicando niveis, exemplo 1.2, significa o metodo dois dentro do metodo um, facilita o desenvolvimento, pois podemos resolver um nivel de cada vez, sem nos preocuparmos no nivel inferior.
O metodo 1.2.2b.1 que e um metodo chamado na opcao b de metodo 1.2.2b, que foi selecionado no metodo 1.2 que e o segundo metodo a ser executado quando se executa o metodo 1.
Existem situacoes que precisa-se usar a repeticao de chamada de metodos.  
Suponha o diagramade caso e com o respectivo diagrama de classes:
Para se fazer o diagrama de sequencia deve-se saber que a nota fiscal, deve ter o nome do cliente, endereco.  Deve ter o número da nota e listar todos os itens que compoem a nota.  Cada item de nota tem a descricao e o preco unitario do produto .
Mas enquanto houver itens de nota fiscal deve-se busca-los e para cada item buscar as informacoes do produto; Veja o diagrama abaixo.  O quadrado pontilhado mostra o que deve ser repetido para cada item:
A condicao assinalada no canto do quadrado delimitador pode ser da forma: 
Condicao booleana: [ x<30 ]
Indicacao de variacoes de uma variavel: 
[ i=1,3,5,7,9,12]
Indicacao de uma condicao [enquanto houver elementos].
Mensagens etiquetadas
Ja vimos nos itens anteriores  o que UML classifica como uma mensagem etiquetada.   Uma mensagem etiqueta e quando se estabelece uma serie de condicoes que devem ser cumpridas para se enviar a mensagem
De acordo com a UML a sintaxe da etiqueta e:
<Predecessor><condicao><expressao><retorno> := <mensagem> (<parametros>);
 
<predecessor> e uma lista de números separada por virgulas terminando por uma “/”
          Exemplo:  1.1, 1.2, 1.2.1, 1.2.2, 1.2.2.3/
<CONDICAO>
<EXPRESSAO> E uma lista de termos de sequencia separados por .seguida por dois pontos.
Exemplo 1:   3.1    [x<y]  :  variavel:= funcao (valor1,valor2);
 
Exemplo 2:  1.1b ,1.1 c  [x<10] : variavel := funcao (valor1,valor2);
           - Indica que serao executas as mensagens consecutivamente
  <Retorno> uma lista de nomes separados por virgula que sao retornados pela funcao.
Exemplo3:    3.1 * [x=1..n]  : nome,endereco,matricula:= id_aluno();
         Obs: * indica repeticao  - para valores de x de 1 ate n.
Exemplo4:   3.1 * [x=1;x<100,x++]  : nome,end := id_al ();
          Obs: pode-se usar estruturas de sintaxe de linguagens de programacao.
Exemplo5 : 3.1 *|| [x=1; x<100,x ++] : nome,endid_al();
          Obs: o simbolo *|| indica que as mensagens podem executar em paralelo, isto e, nao existe sincronismo na execucao.
<Mensagem> e o nome da funcao.
<parametros> e o conjunto de parametros passados na funcao pode-se   usar sintazxe de alguma linguagem como por exemplos passar simplesmente o nome dos parametros:
                       1.2 :int nome:= Id_aluno (matricula, curso)
Ou passar o tipo junto ao parametro:
                  1.2 :int nome:= id_aluno (string:matricula, int:curso);
Casos especiais de representacao
Tempo Real:Um sistema em tempo real, em principio, tem o tempo como o principal fator para sua execucao.  O sistema precisa responder conforme projetado, permitindo a execucao simultanea  de processos em paralelo.  Precisa-se definir tempo de resposta, comportamento, comunicacao entre processos.  
Embedded System: Um sistema de tempo real, normalmente, tem os processos muito integrados a dispositivos de hardware.  Este tipo de sistema e chamado de Embedded System.
Classe ativa: Normalmente os objetos (de uma classe passiva) so sao instanciandos quando recebem mensagens – as classes que vimos nos exemplos anteriores-.  Uma objeto de uma classe ativa pode tomar iniciativa para executar acoes sem enviar mensagens.  Para isto deve-se representar os metodos com a preocupacao de definir a forma de comunicacao entre os objetos ativos e sua sincronizacao.  Na UML uma classe ativa e representado com a indicacao do estereotipos<<classe ativa>>.
A UML indica a forma de sincronismo durante a transferencia das mensagens, por variacoes na ponta da flecha:
Ponta de flecha solida:  Indica que a chamada do procedimento e sincrono. Indica que a sequencia aninhada (niveis) e toda completada antes da sequencia acionadora.  
Isto indica que metodos no mesmo nivel devem esperar.  O remetente da mensagem esperara pelo destinatario esperara a conclusao do metodo 
antes de continuar o seu processamento.
Ponta de flecha fina: Fluxo de  controle assincrono. Mostra que o controle e passado sem haver preocupacao com a comunicacao., tambem se indica o retorno com a flecha do voltando do objeto solicitado para o solicitante.
Meia Ponta:Indica que o remetente envia a mensagem e continua imediatamente o seu processamento sem esperar pelo destinatario.
Mensagem de intervalo: Indica que o remetente esperara pelo destinatario por um periodo fixo de tempo antes de interromper o processo de transmissao da mensagem e continuar o seu processamento.
Metodocriar():
Um diagrama de sequencia, usando todas as representacoes da UML, da para o implementador uma serie de informacoes importantes.
Quando o diagrama de sequencia envolve varios objetos, pode-se ter dificuldadade de visualizar o metodo que se esta desenhando.  Para resolver isto temos um outro tipo de diagrama chamado diagrama de colaboracao.  O diagrama de colaboracao tem o mesmo objetivo do diagrama de sequencia, mas permite uma melhor visualizacao, pois so se representa as classes envolvidas no metodo.
Dica:
 Seja simples:
 1 - Nao queira iniciar usando todas as representacoes apresentadas nesta aula. Use as basicas e a medida que for ganhando experiencia va introduzindo novas representacoes 
2 – O diagrama de sequencia e para ser simples.  Por isto desenhe apenas o desenvolvimento de um metodo ou caso e uso completo por diagrama.  Nao resolva varios caso-uso ou metodo no mesmo diagrama
3 – pratique, este e o segredo.  Lembre-se que ao desenhar um diagrama de sequencia voce esta definindo codigo.
Aula6
DIAGRAMAS DE COLABORACAO
O diagrama de colaboracao mostra como as classes se colaboram. O diagrama de colaboracao expressa, de forma diferente, as mesmas informacoes do diagrama de sequencia. O diagrama de colaboracao mostra uma interacao organizada em torno de um conjunto limitado de objetos, por isto e, normalmente, preferido pelos programadores. “ Para se decidir qual dos diagramas deve ser utilizado para estudar uma interacao, uma regra e escolher o diagrama de colaboracao, quando o objeto e seus vinculos facilitam a compreensao da iteracao e escolher o diagrama de sequencia apenas se a sequencia precisa ser evidenciada. (Furlan )
Arquitetura de camadas
No projeto, o projetista precisa organizar o codigo, de modo a atender as classes de dominio. Alem disso, deve ter outras preocupacoes de projeto, como facilitar a manutencao futura, garantir estabilidade do codigo, garantir reutilizacao e outras caracteristicas. Assim, aparece uma nova preocupacao que organizar o codigo para facilitar a sua existencia fisica, de acordo com padroes de engenharia. Assim, surge outro nivel de abstracao, que e a de camada. Neste estudo, vamos desenvolver o nosso projeto, considerando uma camada de software, cuja preocupacao e a apresentacao (telas, relatorios...), outra e a camada onde se encontra o codigo que faz controle do aplicativo e o codigo que trata as regras de negocio e uma camada onde se encontra o codigo relativo ao acesso e armazenamento de objetos. Assim, aparecera um conjunto de novas classes que irao conter metodos com objetivos, segundo a camada que se encontra.
Essa proposta cria tres niveis de abstracao para se organizar o codigo que ira ser desenhado.
1 – As classes, definidas para apresentacao, poderao ser marcadas com o estereotipos de apresentacao ou “view”; ecomum se representar estas classes na forma:
:Tela_aluno indica que foi instanciado um objeto que contem metodos de apresentacao (metodos como ativar(); apresentar(); ...) e que estao definidos na classe tela_aluno.
2 – As classes definidas como “controles” contem o codigo que permite controlar a instanciacao de novas classes ou mesmo ordenar como sera executado um metodo. Entre um objeto de apresentacao e um objeto de negocios sempre devera existir um objeto de controle, isto dara mais reutilizacao ao codigo.
: ctr_aluno e um objeto da classe que tem os metodos de Controle do sistema.
3 – As classes de negocio,que sao originarias da analise e onde se tem as regras de negocio:
Para se tratar um objeto de dominio como aluno temos:
rosa
PADROES DE PROJETO
O diagrama de colaboracao serve para desenhar alguns padroes de projeto. Um padrao de projeto e uma solucao ja estabelecida para um determinado problema. Existe uma categoria de problema para a qual ja foi dada uma solucao, por desenvolvedores experientes e esta deve ser adaptada para uma situacao semelhante. Isso e que chamamos de padrao.
Normalmente, o padrao tem uma sintaxe da forma:
Nome do padrao:
Problema que resolve:
Solucao:
Nesta aula, veremos de forma resumida os padroes GRASP, mas quem desejar aprofundar estes conhecimentos deve buscar a bibliografia citada acima.
Os padroes GRASP definem principios gerais para a atribuicao de responsabilidades as classe usa se tambem nos diagramas de sequencia.
Existem cinco padroes GRASP:
1 – Especialista na informacao InformationExpert :Problema que resolve:
Durante o projeto orientado a objetos, ao se definirem as interacoes entre objetos, precisamos definir onde os metodos serao colocados. Uma boa escolha torna os sistemas mais faceis de entender e manter, alem de favorecerem a reutilizacao.
Solucao:
Atribuir a responsabilidade do metodo a classe que tem a informacao, isto e, onde existe o atributo.
2 – Creator: Quem deve ser responsavel pela criacao de uma nova instancia de um objeto?
Atribuir a uma classe B a responsabilidade de criar uma instancia de A em uma das condicoes:
B agrega objetos de A.
B contem objetos de A
B contem dados para inicializacao na criacao do objeto A
B registra instancias de objetos de A.
O metodo CriarLinha(quantidade) deve ficar em venda, pois ela e responsavel de criar inicializando os objetos de itemdeVenda.
3 – Coesao Alta:Como manter a complexidade de um projeto sob controle?
A coesao e um conceito que define o quanto elementos devem permanecer juntos. Uma classe de coesao baixa normalmente sao dificeis de compreender, dificeis de manter e de se reutilizarem.
Solucao:
Manter o acoplamento fraco entre classes e manter uma alta coesao nas classes deve ser o objetivo de um projeto
 
A coesao e o acoplamento devem ser avaliados de forma conjunta. O ideal e termos altas coesoes com baixos acoplamentos.
4 – Acoplamento Fraco: Como se ter pequenos impactos na manutencao do codigo e favorecer a reutilizacao?
O acoplamento mede o quanto um elemento(codigo) esta conectado ao outro, ou precisa dos outros para funcionar. Um acoplamento forte exige que se tenha outros elementos para o funcionamento correto. Tal situacao, normalmente, e indesejavel, pois, nao favorece a reutilizacao, alem de provocar um volume alto de manutencao em casos de modificacao no codigo. 
Uma classe que tem acoplamentos fortes e dificel de ser compreendida isoladamente. Sao dificeis de serem reutilizadas pois exigem a presenca de outras classes.
Solucao:
Atribuir responsabilidades de modo que a dependencia entre elementos fique o mais baixa possivel.
5 – Controlador:Quem deve ser responsavel por tratar um evento de um sistema? 
Que operacoes e metodos devem ser executados? 
Em que sequencia?
Solucao:
Criar uma classe responsavel por tratar o evento.
Aula7
DIAGRAMAS DE COMPONENTES E IMPLANTACAO
DIAGRAMAS DE COMPONENTES
Um componente pode ser tanto um codigo em linguagem de programacao como um codigo executavel ja compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java ou .class e um componente do sistema, e sera mostrado no diagrama de componentes que os utiliza.
Um componente se representa graficamente na forma:
Um diagrama de componentes mostra as dependencias entre os elementos de um software.
A dependencia entre componentes e mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para o seu funcionamento. O diagrama de componentes visualiza que modulos de software (arquivos .dll , .exe, .com, .bat, .htm e outros executaveis) sao necessarios para executar a aplicacao. 
Exemplo de diagrama:
O diagrama de componente mostrao sistema pelo seu lado funcional, mostrando a organizacao de seus modulos e como se dara a sua execucao. 
Portanto, representa o desenho da estrutura do codigo gerado. Um componente e definido a partir de condicoes fisicas, definicoes de projeto nas implementacoes de classes e metodos definidos nos diagramas de sequencia (ou colaboracao). Eles sao tipicamente os arquivos implementados no ambiente de desenvolvimento.
DEFINICAO DE COMPONENTES
Para se definir um componente, deve–se levar em consideracao as condicoes fisicas que o sistema ira executar, por exemplo, tamanho de memoria, tempo de execucao, modulos mais utilizados, tamanho dos modulos.  Alem do criterio do reaproveitamento do codigo.  O ideal e criar componentes que possam ser utilizados em varios softwares.
Suponha, por exemplo, o modulo de logon em um software.  Suponha que o modulo para efetuar o login e de 5Mbytes e que o software compilado tem 60 Mbytes.
O modulo de login deve ser compilado juntamente com o restante do software gerando um único componente executavel?
Nao, pois o modulo de login ira executar uma única vez, e ira ocupar a memoria com 5Mbytes de codigo que nao sera mais executado.  Alem disto, se este modulo for projetado devidamente, podera ser reutilizado em outros produtos, de forma que o ideal e termos um único componente de software para tratar o login e outro componente que chamaremos de principal, que chamarao componente login, que, apos executado, nao mais sera chamado.  Temos o seguinte diagrama de componentes:
Quando definimos componentes a partir dos diagramas de colaboracao, pode-se ter situacoes em que um componente tenha parte da execucao de um metodo ou contenha mais de um metodo.  Assim, ao ser chamado, precisa que se indique que metodo sera executado ao entrar o componente, e as caracteristicas necessarias ao metodo (assinatura da funcao).  Neste caso, o componente tera varias formas de entrada e deve-se indicar a forma de chamada do componente.  Cada forma de entrada e chamada de interface do componente.  No diagrama de componentes, deve-se indicar que interface esta sendo chamada.  A representacao da interface de um componente e feita na forma:
Um componente podera ter varias interfaces.
Na definicao de um componente, para garantir o seu funcionamento correto, podemos escrever um modulo, a ser compilado dentro do componente, que verifique as suas condicoes de execucao.  Ou seja, verifica se existem os outros componentes necessarios para o seu trabalho, ou faz o controle dos metodos ou interfaces que estao sendo usados.  Este modulo e um controle e e chamado de controle do componente.
A figura ao lado mostra um componente com todos os seus elementos: interface e controle.  Se o componente for muito simples, pode nao ter estes elementos
Exemplo de diagrama de componente
Exemplo de diagrama de componente, em que o projetista estruturou a compilacao dos modulos levando em consideracao os tipos de elementos:
DIAGRAMAS DE IMPLANTACAO
O diagrama de implantacao, tambem chamado por alguns autores de diagrama de execucao, mostra a organizacao do hardware e a ligacao do software aos dispositivos fisicos.
O diagrama e constituido de nos conectados:
NO 1 – Na UML, um no representa um dispositivo fisico com memoria ou capacidade de processamento.  Podemos ser contidas instancias de componentes indicando que os itens residem nas instancias d do tipo de no (sublinhar o nome do no).
Sintaxe:
Um tipo de no: <tipo do no>
Para uma instancia: <nome do no> “: “ <tipo do no>
PENTIUM 300 MHZ – E um tipo de no.
COMPUTADOR DE PEDRO: PENTIUM 300MHZ -E uma instancia do tipo de no Pentium 300Mhz.
ASPECTOS PARA SE ALOCAR COMPONENTES EM UM NO
SEGURANCA:Estabelecer direitos de acesso e protecao de dados em localizacoes geograficasdiferentes.
ACESSO A DISPOSITIVOS:Avaliar as necessidades individuais de dispositivos em um no, incluindo conexao de impressoras e demais perifericos.
LOCALIZACAO GEOGRAFICA:Determinar que funcionalidades necessitam estar disponibilizadas localmente para o melhor desempenho.
UTILIZACAO DE RECURSOS:Distribuir componentes de forma a obter desempenho maximo do hardware utilizado.
EXEMPLOS DE DIAGRAMA
Foram colocados simbolos de multiplicidade para indicar  o número de dispositivos necessarios para a operacao.
O diagrama de implantacao/execucao mostra a arquitetura fisica do hardware e do software no sistema. Pode mostrar os atuais computadores e perifericos junto com as conexoes que eles estabelecem entre si.  
O diagrama de execucao demonstra a arquitetura rotim de processadores, componentes fisicos (devices), e de software que rodam no ambiente onde o sistema sera utilizado. E a última descricao fisica da topologia do sistema, descrevendo as estruturas de hardware e software que executam em cada unidade. 
 
O diagrama de execucao mostra instancias de nos que significam objetos fisicos que fazem parte do sistema, podendo ser uma maquina cliente numa LAN, uma maquina servidora, uma impressora, um roteador, etc., e conexoes entre estes nos e componentes que juntos compoem toda a arquitetura fisica do sistema.
O diagrama de implantacao/execucao define aspectos fisicos do sistema.
Aula8
DIAGRAMAS DE ESTADO
DIAGRAMAS DE TRANSICAO DE ESTADOS
1 –O diagrama de estados e uma ferramenta desenvolvida em estudos de maquinas finitas, na matematica, e tem sido adaptado a varias aplicacoes na informatica.  Na analise essencial existe uma variacao destes diagramas que sao chamados de diagramas de transicao de estados (DTE).  Em todas essas variacoes, usam-se os mesmos conceitos com representacoes diferentes.
Nesse diagrama, representamos os eventos, que podem ser para um caso e uso ou para tratamento de uma classe e tambem se modelam processos, por isto, e comum alguns “processos” serem analisados e documentados com diagramas de estado.
2 –ESTADO - Um estado e um conjunto de condicoes que estao ocorrendo em um momento no tempo, por isto, obrigatoriamente, um estado e indicado pelo verbo no gerúndio. Normalmente, dois estados nao sao representados no gerúndio o estado inicial (inicio) e o estado final (fim), os demais, obrigatoriamente, estarao no gerúndio, como por exemplo, apresentando tela – indica que uma tela esta sendo apresentada em um determinado instante de tempo para determinadas condicoes-. Normalmente, representados dentro de uma elipse.
3 –Aguardando aula
O inicio e representado por um ponto, na forma
O Fim e representado por:
A representacao do fim e chamada de olho de boi, por isto, muitos desenvolvedores chamam o diagrama de estados como diagrama de olho de boi.
4 –EVENTO – E uma ocorrencia significativa que pode alterar um estado, provocando uma mudanca; pode ser uma entrada de dados, um acionamento de um comando, ou mesmo um elemento temporal (exemplo: sao seis horas).
TRANSICOES OU MUDANCA DE ESTADO
Os eventos devem ser registrados junto ao estado onde provocam a mudanca.
A transposicao de um estado para outro e indicado por um arco entre o antigo e o novo estado.
O evento que provou a mudanca deve ser indicado no arco junto ao estado que provocou a mudanca.
DIAGRAMAS DE ESTADOS
Ilustram-se os estados, eventos e as mudancas provocadas por estes eventos.  Exemplo:
Um diagrama de estados pode, por exemplo, mostrar o ciclo de vida de um objeto
Mostrando detalhes simples ou complexos de acordo com o que estamos analisando.
Exemplo:
Um aluno da classe aluno, de uma faculdade, tem o seguinte ciclo de vida:
Podem-se estudar os eventos externos do sistema para tratar um caso e uso
Vamos, por exemplo, modelar o Caso e Uso Processar venda.  Nesse caso, devemos conhecer a descricao do caso e uso. Suponha que ao processarmos vendas nao se pode fazer pagamento com cartao de credito ate o evento terminar venda ocorra.
NOTACAO PARA ESTADO SEGUNDO O UML
O UML padroniza que um estado seja indicado em um retangulo com cantos arredondados com tres compartimentos como mostrado abaixo:
	Nome_do_Estado
	<- Compartimento de nome do estado
	Variavel 1 ...
Variavel n
	<- Compatimento de variaveis de estado
	No compartimento das variaveis de estado, sao colocadas as variaveis que sao consideradas neste estado.
	Evento 1 /acao
...
Evento n /acao
	<- Compartimento de atividade interna
	No compartimento de atividade interna, apresenta-se a lista de acoes internas ou atividades executadas, quando o objeto esta no estado.  As seguintes acoes representam palavras reservadas e nao podem ser utilizados como nome de eventos:
 - “entrar” “/” expressao de acao
- “fazer” “/” expressao de acao
-“ sair” “/” expressao de acao
Uma acao interna “fazer” e um processo continuo executando, enquanto o objeto esta em um determinado estado em um tempo finito nao instantaneo.  A acao nao precisa ser atomica e e interrompida por eventos externos.
Os atributos sublinhados indicam a chave primaria de cada relacao, enquanto que os assinalados em vermelho constituem chaves estrangeiras.
A imagem abaixo mostrao ciclo de vida de um objeto pedido, em um sistema de vendas:
Observe que o diagrama de estados pode ter mais de um inicio e mais de um fim.
SUBESTADO E SUPERESTADO
Um estado em um diagrama de estado pode ser decomposto em outro diagrama de estados, a abertura do estado e chamado de subestado.
Considere o diagrama de estados para se definir um software para tratar os cadastros de Aluno, Professor ou Coordenador.
Para manter a complexidade e a facilidade de entendimento, vamos usar fazer o
desenvolvimento em niveis:
O estado tratando tela esta detalhado, mas os estados de tratando aluno, tratando professor e
tratando coordenador sao estados que precisam ser tratados. Vamos tratar o estado, tratando
aluno, os demais sao similares
Quando os estados podem ser abertos em novos diagramas de estado, dizemos que o atual
estado e um subestado e, quando se pode considerar que os atuais estados sao estados que 
foram abertos, o estado que deu origem a abertura e um super estado.
Essa estrutura de tratar o diagrama de estados, dizemos que os estados sao aninhados e
permitem que se apresentem diagramas que facilitem o entendimento.
SUBESTADOS SIMULTANEO E SUBESTADOS SEQUENCIAL
Um subestado pode ser simultaneo ou sequencial.
SIMULTANEO
Quando um subestado pode ocorrer simultaneamente com outro.
preparando despacho de mercadoria
SEQUENCIAL
Nova venda iniciada e pagamento feito sao eventos externos ao sistema.
Conclusao
O diagrama de estados e uma ferramenta que deve ser usada na analise, devido a sua simplicidade  e clareza.  A sua utilizacao facilita a modelagem de processos em tempo real.  Na pratica, muitos desenvolvedores colocam informacoes de codigo, como comentarios, informacoes condicionais.  
Aula9
DIAGRAMAS DE ATIVIDADES
O diagrama de atividades, para alguns autores, e um caso especial do diagrama de transicao de estados, quando a maioria das transicoes e comandada por termino de acoes nos seus estados precedentes.
Diagramas de atividade capturam acoes e seus resultados de casos e usos. O seu objetivo e o de capturar acoes e seus resultados em termos das mudancas de estados dos objetos.
Um diagrama de atividade pode ser usado com diferentes propositos inclusive:
Para capturar os trabalhos que serao executados quando uma operacao e disparada (acoes). Este e o uso mais comum para o diagrama de atividade.
Para capturar o trabalho interno em um objeto.
Para mostrar como um grupo de acoes relacionadas pode ser executado, e como elas vao afetar os objetos em torno delas.
Para mostrar como uma instancia pode ser executada em termos de acoes e objetos.
Para mostrar como um negociofunciona em termos de trabalhadores (atores), fluxos de trabalho, organizacao, e objetos (fatores fisicos e intelectuais usados no negocio).
ELEMENTOS USADOS NO UML
Elementos usados no UML para representar diagramas de atividades:
Atividade: Representa o desempenho de alguns componentes no fluxo de atividades. Pode ser ou nao atomica. Normalmente o nome da atividade e constituido de um verbo no infinitivo e um complemento.
Transicao: Sao usadas para mostrar a passagem do controle do fluxo de execucao entre as atividades. 
Normalmente sao disparadas pela complementacao das atividades.
Decisao: Ao se estabelecer o fluxo de trabalho entre as atividades, existem pontos onde se deve decidir que fluxo se deve seguir. Sao os pontos de decisao. 
Neles encontram-se as condicoes de guarda que permitem que se estabeleca o fluxo de acordo com a condicao encontrada.
Barra de sincronizacao: Em um fluxo de trabalho existem atividades que podem ser desenvolvidas em paralelo.  a barra de sincronizacao permite especificar fluxos de trabalho que podem ser feitos ao mesmo tempo (em paralelo).  
Tambem mostram quando o conjunto de fluxos de trabalho (atividades) deve ser completado para iniciar outro fluxo (ou atividade).
Inicio: O Inicio indica o inicio do fluxo de trabalho.
Pode-se ter mais de um inicio (pouco comum) em um diagrama de atividades
Fim: Determinar o fim do fluxo de trabalho.  Pode-se ter mais de um fim (comum) em um diagrama de atividades
CONSTRUCAO DE UM DIAGRAMA DE ATIVIDADES PARA UM CASO E USO
Um diagrama de atividade e uma maneira alternativa de se mostrar interacoes, que ocorrem em um caso e uso com a possibilidade de expressar que acoes sao executadas.
Exemplo: Para o caso e uso  devidamente dicionarizado (nao apresentamos o dicionario no exemplo abaixo),
CONTRUCAO DE UM DIAGRAMA DE ATIVIDADES PARA UM PROCESSO
O diagrama de atividades tambem e útil para o desenvolvimento de um processo.  Vamos supor que desejamos estabelecer uma serie de procedimentos para criar um curso e abrir matriculas para um conjunto de cursos catalogados.
1 – Vamos criar uma ementa.
2 – Colocar o novo curso no catalogo.
3 – Vamos atribuir os professores para cada curso do catalogo.
4 – O catalogo devera ser divulgado em varios meios para posteriormente abrirem-se as inscricoes.
SWINLINES
No diagrama de atividades podemos informar quem ou onde as atividades sao feitas, para isto, usamos “raias” (faixas), como em uma piscina, para indicar onde (ou quem) as atividades sao feitas.  Estas linhas sao chamadas de “swinlanes”:
Considere o nosso exemplo anterior e vamos considerar que as atividades sao desenvolvidas  pelo coordenador, gerente de produto, departamento de divulgacao e a departamento de captacao
Vamos redefinir o nosso diagrama de atividades com as swinlines mostrando quem desenvolve cada atividade:
O diagrama de atividades tambem pode ser usado para definicao de metodos como mostrado no exemplo abaixo e tambem pode conter especificacoes de mensagens enviadas e recebidas como partes de acoes executadas.
SERVIDOR DE IMPRESSAO
O diagrama de atividades e um diagrama que deve ser usado na especificacao de projetos administrativos do sistema, ou na complementacao, do estudo das interacoes com o sistema.  Como mostrado tambem serve para definir metodos.
Aula10
TOPICOS ESPECIAIS
VISIBILIDADE
Agora que aprendemos na aula anterior - diagrama de sequencia – o que um metodo, o que uma mensagem podemos falar sobre uma caracteristica importante em orientacao a objetos que e a visibilidade das classes.
VISIBILIDADE DE ATRIBUTOS
Uma classe e encapsulada para proteger seus dados e metodos. Assim quando se especifica um metodo ou uma classe eles devem ser protegidos quanto ao acesso, mas muitas vezes precisamos acessar estes dados ou metodos de fora da classe. Assim neste topico vamos analisar como isto e tratado.
PRIVADO PRIVATE
E a condicao de criacao de um metodo ou atributo significa que so podem ser usados dentro da classe onde estao especificados. Os metodos podem utilizar diretamente as variaveis ou outros metodos internos a classe, sao considerados como globais no escopo da classe. Quando nao se especifica o tipo de atributo assume-se como privado.
PUBLICO PUBLIC
Quando explicitamente se deseja liberar o acesso feito de forma externa a classe. Nao e uma situacao desejavel, pois e contra o conceito de implementacao de uma classe, que e de proteger de forma encapsulada seus metodos e atributos. Deve-se usado com muito cuidado, estes metodos, na pratica, quando colocados nas classes nao devem acessar diretamente os atributos da classe, isto deve ser feito com ajuda de metodos privados por uma questao de seguranca.
PROTEGIDO PROTECT
So deve ser usado quando temos uma estrutura gen-esp. Quando um metodo ou atributo e especificado como protected ele e visivel por todas as classes que estao na estrutura GEN-ESP.
Podem-se abrir os metodos de uma classe A para uma classe B declarando que a Classe B e amiga de A. Neste caso voce pode considerar que os metodos e atributos privados A sao totalmente visiveis para B. Isto e implementado em algumas linguagens de programacao da seguinte forma:
	Classe A friend classe B;
	Da se acesso a metodos e atributo de classe A para os metodos da classe B.
Algumas linguagens limitam este recurso e nao permite o acesso a toda a classe, permitindo acesso apenas para algumas funcoes da classe. Neste caso se desejamos que a classe B tenha acesso a alguns metodos da classe B isto deve ser especificado junto aos metodos atributos na classe A. Usa-se a clausula Friend classe B;
A representacao de classe no UML ja considera que estamos definindo a visibilidade de atributos e funcoes e usa a seguinte notacao na frente do atributo ou metodo:
+ significa que o metodo ou atributo e público (public)
- significa que o metodo ou atributo e privado (private)
# significa que o metodo ou atributo e protegido (protected)
VISIBILIDADE DE OBJETOS
Visibilidade e a capacidade de um objeto fazer referencia e utilizar metodos e valores de outro objeto.
DIAGRAMAS DE PACOTES
Um pacote e um recurso para definicao de grupamentos. Seu uso mais comum e o grupamento de classes, embora possa se fazer grupamentos para tipos de elementos no UML. E um recurso que pode ser usado para organizar o sistema seja pelo aspecto tecnologico ou administrativo.
Um pacote e representado na forma:
Os pacotes podem ser membros de outros pacotes. Pode-se definir uma hierarquia de pacotes. Um pacote pode conter um ou mais pacotes e assim sucessivamente.
Observe na representacao que se o conteúdo do pacote e exibido deve-se colocar o nome na aba, senao for pode-se colocar o nome no meio do meio do retangulo. Se for necessario, ainda, pode-se usar o recurso de estereotipo usando a indicacao “<<” e “>>” com o nome dado.
As classes tem escopo dentro de pacotes onde sao definidas. Uma classe X definida dentro de um pacote em a seguinte sintaxe:
 
 NomeDoPacote :: NomeDaClassse
 
Se for necessario uma classe pode incluir um caminho completo de pacote no qual esta presente. Se forem pacotes encadeados deve-se grupar os nomes dos pacotes separados por:
Nomedopaacote1::NomeDo Pacote2::NomeDoPacote3::NomeDaClasse
 
Um pacote nao pode modificar atributos ou metodos de uma classe. E deve manter a navegabilidade de associacoes dentro do pacote. Um pacote deve ter sua visibilidade indicada para os outros pacotes (como podem acessa-lo).
VISIBILIDADE DE PACOTES
A visibilidade de um pacote pode ser:
PRIVADA: Somente o pacote que possui o elemento pode usa-lo.
PROTEGIDA: Alem dos elementos do pacote e possivel que pacotes que participem de generalizacao acessem.
PUBLICA: Todos os elementos podem acessar o conteúdo do pacote. E o default quando nada e indicado.
IMPLEMENTACAO: Similar a visibilidade privada, mas os elementosde modelos que tem uma dependencia com um pacote nao podem usar os elementos dentro daquele pacote.
Dentro e um pacote s classes sao públicas ou privadas. Se uma classe de um pacote precisa ser usada por outra classe de um outro pacote estabelece-se uma dependencia entre os pacotes.
Os pacotes tambem podem ser definidos contendo casos e usos. Aplica-se as mesmas regras
Um pacote possui varios modelos de elementos, e isto significa que estes nao podem ser incluidos em outros pacotes.
Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes nao possuam semanticas definidas para suas instancias. Os relacionamentos permitidos entre pacotes sao de dependencia, refinamento e generalizacao (heranca).
Se um pacote for destruido, todo o seu conteúdo tambem sera.
Teste1
1.Marque a afirmativa totalmente correta:
1) No Mundo real e mundo simbolico se confundem e sempres se repetem. 
2) Sistemas existem no mundo real, detro de computadores, assim o processamento e do mundo real. Nao existe mundo simbolico quando se processa com sistemas de informacoes informatizados. 
3) O mundo das representacoes e igual em varias empresas, assim como o conhecimento que cada pessoa tem.
->4) Cada empresa tem o seu mundo de representacoes que depende da lei, da cultura e das pessoas que compoem a empresa. 
5) A analise de sistemas trabalha no mundo real, assim precisamos observar as coisas do mundo real e nao como as pessoas usam o conhecimento. 
2. Abaixo temos a carteira de identidade de Luiz da Silvausa ribeiro
Sobre ela veja a afirmativa correta.
1) A carteira de identidade e do mundo real. E usada por todos nao serve para processamento. 
->2) A carteira de identidade e uma imagem que representa uma pessoa para processamentos no mundo simbolico do Ministerio de Justica 
3) A carteira de identidade e a representacao da pessoa, portanto, toda empresa obrigatoriamente incorpora a carteira de identidade 
4) O simbolico da empresa nao pode criar as suas proprias representacoes por isto usa a carteira de identidade. 
5) A carteira de identidade e diferente do CPF com relacao a repesentacao dos processamentos de informacoes nos respectivos mundos simbolicos 
3. Sobre o processo do software pode-se afirmar que:
1) E uma burocracia desnecessaria, um programador com experiencia nao precisa disto. 
2) e sempre igual para todo e qualquer produto de software 
3) e uma forma de se controlar o projeto e gera muito mais trabalho 
4) O programador incia o desnvolvimento do codigo, e nao precisa de processo. E muito mais rapido 
->5) E uma forma de se assegurar que o projeto sera feito de forma correta, com metodo, com qualidade, e pode ser gerneciado
4. Sobre o processo unificado escolha a alternativa totalmente correta.
1) O processo unificado nao permite modificacoes no projeto. 
2) Na fase de concepcao ou iniciacao deve-se definir detalhes do que sera construido. 
->3) Na fase de elaboracao deve-se detalhar os requisitos funcionais do sistema 
4) Na fase de construcao nada mais pode-se acrescentar, msmo que se identifique falha. 
5) A programacao e definicao de arquivos devem ser feitas na fase de concepcao. 
5. Sobre o RUP podemos afirmar com certeza.
1) e uma forma de se implementar o processo de cascatas com “templates” – gabaritos. 
2) e um produto que e constituido de gabaritos escritos em HTLM geram os programas automaticamente. 
3) Nao permite implementar iteracoes nas fases de concepcao. 
->4) Permite definir uma iteracao sempre que necessario 
5) E um novo processo de desenvolvimento e analise de sistemas, portanto nao e um produto.
Teste2
1. Considere a A.O.O para verificar a afirmativa correta abaixo:
1) Trata-se de um modismo que serve para colocar novas linguagens no mercado, sem ganho para o desenvolvimento. 
->2) Permite que se desenvolva de forma organizada e economica, pois, permite o reaproveitamento de codigo. 
3) E constituida de diagramas padronizados para evitar a confusao no desnvolvimento. 
4) E uma foram de se programar, mas devem-se buscar maneiras que gerem menos codigo, para no caso de reutilizacao ficar mais facil gerar o mesmo codigo. 
5) Trata-se de uma forma moderna de se desenvolver software, desde que se usem apenas novas linguagens. 
2. Considere o UML:
1) Trata-se de uma linguagem que permite programar um sistema, de forma rapida, inclusive com geracao de codigo. 
2) E um banco de dados composto por dados e diagaramas. 
->3) Produz um desenvolvimento com o uso de diagramas integrados e padronizados. 
4) E uma forma de se poder desenvolver o sistema com diagramas integrados, porem despadronizados. 
5) No uso de diagramas do UML, so pode usar um tipo de diagrama por projeto. 
3. Sobre o ator, pode-se afirmar, com certeza:
->1) E um personagem que interage com o sistema. 
2) E um orgao ou pessoa responsavel pelo sistema. 
3) Representa um conjunto de pessoas que trabalham no sistema. 
4) Repesenta um conjunto de pessoas que desenvolvem o sistema. 
5) Repesenta um conjunto de pessoas interessados no sistema.
Teste3
1. Responda, falso ou verdadeiro:
No UML, a representacao de uma classe e formada em tres compartimentos, sendo: o primeiro, para identificar o nome da classe, abaixo vem o compartimento com os objetos relativos a classe e, por último, o compartimento dos atributos.
->1) FALSO 
2) VERDADEIRO 
2. Dadas as seguintes afirmacoes, marque a opcao falsa, em relacao a generalizacao:
1) Todas as instancias de uma classe filha sao tambem instancias da classe mae. 
2) E uma associacao ‘e um tipo de’. 
->3) Todas as instancias da classe mae sao tambem instancias das classes filhas. 
4) Uma classe pode ter varias ou nenhuma classe mae. 
5) Uma classe pode ter nenhuma ou varias classes filhas. 
3. Quais dos relacionamentos abaixo podem haver entre classes?
I – Include (inclusao) . II – Extends (extensao).
III – Agregacao. IV – Generalizacao.
V – Composicao. VI – Associacao.
1) Todos 
2) Nenhum 
3) II, III, IV, VI 
->4) III, IV, V, VI 
5) I, II, IV 
4. Dadas as seguintes afirmacoes, marque a opcao falsa, em relacao a heranca:
1) A heranca e um mecanismo que deriva novas classes, a partir de uma classe ja existente, atraves de um processo de refinamento. 
2) Uma classe derivada herda atributos e operacoes da classe base. 
->3) A classe derivada nao pode adicionar novos atributos ou operacoes as ja existentes. 
4) Quando uma classe herda de mais de uma classe, temos a heranca múltipla. 
5) A classe derivada pode redefinir a implementacao de operacoes existentes na classe base.
Teste4
1. Indique que grupo de informacoes pode ser representado junto ao relacionamento:
1) Agregacao, multiplicidade, navegacao, atributo. 
2) Composicao, ordenacao, atributo, navegacao. 
->3) Ordenacao, composicao, qualificacao, navegacao. 
4) Objeto, composicao, classificacao, restricao. 
5) Generalizacao, nomeacao, classe, ordenacao. 
10. Considere as seguintes classes e associacoes e escolha a alternativa correta
->1) Classe B compoe a Classe A, Classe D e uma Classe C, Classe F tem visibilidade para Classe E
2) Classe B e uma classe A; Classe D compoe a Classe A; Classe F tem visibilidade para Classe E 
3) Classe B tem visibilidade para Classe A; Classe D e uma Classe C; Classe F compoes a Classe E 
4) Classe A compoe a Classe B; Classe C e uma Classe D; Classe E tem visibilidade para Classe F 
5) Classe A compoe a Classe B; Classe D tem visibilidade para Classe C; Classe F e uma Classe E 
2. Uma agregacao indica que:
1) a classe que agrega deve colocar todos os itens em ordem. 
2) a classe que agrega