Oxente Network Rede de blogs oxente.org

9Apr/10Off

Capacitação de Servidores Público pelo TCU (EaD)

Fala, galera.

Uma dica excelente para quem já é servidor público são os cursos de capacitação a distância oferecidos pelo TCU.

Dentre os cursos abertos atualmente estão:

* Introdução à Lei de Responsabilidade Fiscal
* Licitações e Contratos Administrativos (Noções básicas e conceitos introdutórios)
* Prestação de Contas de Convênio

Aproveitem que o período de inscrição começou ontem (08/04/2010). Pena que são apenas para servidores públicos.

Link: http://portal2.tcu.gov.br/portal/page/portal/TCU/gestor_publico

[]s
Manoel Teixeira

Filed under: Concurso Comments Off
21Dec/09Off

Saiu edital – Petrobras

Mais um concurso para área de TI.

São três cargos:
ANALISTA DE SISTEMAS JÚNIOR – ENGENHARIA DE SOFTWARE
ANALISTA DE SISTEMAS JÚNIOR – INFRAESTRUTURA
ANALISTA DE SISTEMAS JÚNIOR – PROCESSOS DE NEGÓCIO

Remuneração: Salário Básico de R$ 3.940,16 com garantia de remuneração mínima de R$ 5.685,07.

Edital: http://www.cesgranrio.org.br/eventos/concursos/petrobras0109/pdf/petrobras0109_edital.pdf

Provas: 28/03/2010

14Nov/09Off

(CESGRANRIO/Petrobras – Analista de Sistemas Jr – 2008) Questão 54 – UML

Segue meu post no blog do Walter ( http://waltercunha.com/blog/ ).

Olá, pessoal.

Esta será minha primeira participação aqui no blog do Walter. Pretendo comentar sobre questões de Engenharia de Software, assunto como UML, Padrões de Projeto, Processos de software, Rup, Desenvolvimento OO…

Pois então, começarei por uma questão que envolve UML e Padrões e que achei muito bem elaborada , apesar do criador ter dado uma ajudinha nas alternativas. Uma pequena modificação, e mantida a idéia, ela poderia ser tornar uma questão de nível um pouco elevado.

Estou falando da questão 54 da prova da Petrobras – Analista de Sistemas Júnior – Engenharia de Software – CESGRANRIO – 2008.

Segue:

questao54petroanalistauml

(CESGRANRIO/Petrobras – Analista de Sistemas Jr – 2008) Questão 54 – UML – A figura acima mostra um diagrama de classes UML desenvolvido para um projeto em que ainda não se sabe em que linguagem será realizada a implementação. Sobre o diagrama, assinale a afirmação correta.

(A) Há um erro na cardinalidade da associação entre ClasseA e ClasseB, pois se trata de uma composição e, como tal, um objeto da ClasseB só pode estar associado a um objeto da ClasseA

(B) Há uma dependência cíclica entre ClasseB, ClasseC e ClasseE, o que não é permitido pela UML.

(C) O fato de que ClasseD generaliza ClasseA e ClasseB se traduz em herança múltipla, o que não é permitido pela UML.

(D) Retirando a ClasseA, o diagrama resultante corresponde ao padrão de projeto composite

(E) Invertendo o sentido de todas as generalizações, o diagrama resultante corresponde ao padrão de projeto chain of responsability.
Comentário:

Então o que nos parece a primeira vista é uma questão simples de UML [1], que mostra um diagrama e elabora algumas assertivas, e é isso mesmo que ela é. Apesar do diagrama assustar um pouco, pois utiliza Agregação, Composição, Generalização (herança composta), Navegação numa Agregação e dentre as assertivas cobrar do candidato entendimento da estrutura de dois Padrões de Projeto, na verdade a questão se resume ao entendimento do relacionamento de Agregação Composta (ou Composição).

Vejamos, na alternativa (B) é questionado o fato de haver uma dependência cíclica entre as classes B,C e E e que isso não seria permitido na UML. O que não é verdade, o que não é permitido na UML é o que foge da sua semântica e sintaxe, pois lembremos que UML é uma linguagem de modelagem. Ainda, essa pode ser extendida ( o que pode ser um terror para certas questões ). Logo, a UML em sua semântica e sintaxe não impede a existência da dependência cíclica, pois essa não se preocupa com problemas da arquitetura do sistema ou da solução, seria similar afirmar que a UML não permite uma baixa coesão e alto acoplamento. ( Lembre que buscamos, na medida do possível, alta coesão e baixo acoplamento).

O mesmo pode ser comentado na alternativa (C), só que aqui temos outro porém, não existe problemas na herança múltipla se você estiver usando C++, por exemplo. Já se o seu projeto definiu Java como linguagem não será a UML que impedirá você de modelar uma herança múltipla.

Agora vem a parte interessante da questão. Na alternativa D e E, é cobrado certo conhecimento da estrutura dos Padrões Composite e Chain of Responsability, o que não é muito comum. Mas, vamos relembrar:

Composite: Compor objetos em estruturas de árvore para representarem hierarquias partes-todo. [2]

Estrutura do Composite: 600px-composite-dpcd

Notem que retirando a ClasseA não iremos chegar à estrutura do Composite. Em sua estrutura o Composite é composto por Components e é um filho deste através da herança. Na questão não temos essa composição e herança ao mesmo tempo. Aqui vai uma observação importante sobre o livro do GOF, ele não utiliza a UML para representar a estrutura! Utiliza a Object Modeling Technique (OMT), que é bem parecida com a UML.

Chan of Responsability: Evitar o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar a solicitação. Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate.

Estrutura do Chain of Responsability: jw-0829-designpatterns2Para quem conhece o padrão Chain of Responsability sabe que ele é comportamental e portanto a idéia central reside mais em sua interação/colaboração. A estrutura do padrão é bem simples, e como podemos ver temos um auto-relacionamento, o que de imediato descartar a alternativa E.

Para o mais ligado em UML, bastaria ler a alternativa A e saber que está é a alternativa correta, conferrindo apenas com uma leitura rápidas nas outras, e mesmo que ficasse em dúvida sobre as estruturas dos Padrões, saberia a alternativa correta. Nessa alternativa é levantado um ponto importante entre a diferença de Agregação e Composição. Vejamos:

“A agregação simples é inteiramente conceitual e nada faz além de diferenciar o ‘todo’ da ‘parte’…. nem vincula o tempo de vida do todo e suas partes.”

“A composição é uma forma de agregação, com propriedade bem-definida e tempo de vida coincidente como parte do todo. … Isso significa que, em uma agregação composta (negrito por mim), um objeto poderá ser uma parte de somente uma composição em determinado momento.” Ou seja, na composição só teremos a multiplicidade do relacionamento 1 para muitos partindo do todo para a parte, pois a parte só se relaciona com uma composição em determinado momento. Por isso, a alternativa A é a correta, pois no diagrama da questão temos uma agregação composta com multiplicidade de relacionamento muitos para muitos.

Bom pessoal, acho que prolonguei demais. Mas é justamente por isso que escolhi essa questão, ela envolve dois assuntos interessantes da Engenharia de Software, que são os Padrões (Reúso) e a modelagem UML.

Nos vemos na próxima questão. []s

[1]: Booch, G.; Rumbaugh, J.; Jacobson, I. UML Guia do Usuário, 2ª edição. Ed. Campus.
[2]:Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Padrões de Projeto, Soluções reutilizáveis de software orientado a objetos. Bookman.

Manoel Teixeira de Abreu (http://manoel.oxente.org/blog)

25Sep/09Off

#1 – Questões Polêmicas. INFRAERO – 2009 – FCC – Redes e Suporte

Vou começar diferente, decidi mudar, ia começar com uma questão do TCU 2009, mas vou começar com essa da FCC. Achei bem absurda por conta da referência, e nem tanto pelo gabarito.

Segue:

58. O design lógico do banco de dados, inclusive as tabelas e as relações entre elas, é a parte fundamental de um banco de dados relacional otimizado. A normalização do design lógico de um banco de dados envolve o uso de métodos formais para separar os dados em várias tabelas relacionadas. Nesse sentido,

(A) valores nulos em uma tabela não requerem tratamento especial, já que não aumentam a complexidade das operações de dados.

(B) várias tabelas largas com mais colunas são características de um banco de dados normalizado.

(C) várias tabelas estreitas com menos colunas são características de um banco de dados normalizado.

(D) a quantidade e a largura das colunas de uma tabela não interferem na caracterização de um banco de dados normalizado.

(E) a quantidade de índices por tabela não é fator irrelevante no desempenho das instruções INSERT, UPDATE e DELETE.

Comentários:

Bom, o primeiro comentário é o mais óbvio, sobre o gabarito, que para esta questão é a letra C. Para mim, quando fiz esta questão, marquei a letra D. Então gera uma certa confusão na interpretação da questão, a diferença entre “tendência” e “características”. É fato que quando normalizamos uma modelo a tendência dele é aumentar o número de tabelas e dimunuir o número de colunas. Notem que o enunciado já diz isso! Porém, será que é característica de um banco normalizado ter várias tabelas com menos colunas?

Tudo bem, é uma dúvida que até podemos argumentar: Não quer dizer que por ele não ser característico não será normalizado. Característico tem significado similar a tendêncioso, e não impede de ser diferente. Eu contínuo podendo ter um banco normalizado com várias tabelas e várias colunas, ele apenas não é característico.

Mas então eu fui procurar em referências consagradas, não encontrei no Navathe nem no Silberschatz… Apelei pelo google e vejam o que eu achei: http://msdn.microsoft.com/pt-br/library/ms191178.aspx . Reparem que esta questão foi um CTRL+C e CTRL+V deste documento da Microsoft. Aí fica a questão, será mesmo que a Microsoft é referência para se utilizar no conceito de normalização?

Outra polêmica… Observem a letra E. Vejam o trecho: “não é fator irrelevante”. Nega-se a irrelevância, logo ele é relevante! E reparem nessa linha do mesmo documento supracitado: “Menos índices por tabela. Isto melhora o desempenho das instruções INSERT, UPDATE e DELETE.” Então, a alternativa E está correta.

Então fica a dúvida, até onde escolher o material certo para estudar e até onde acreditar no gabarito.

Se alguém encontrar em outra referência (DATE, por exemplo) algo sobre número de colunas e normalização, por favor, envia aqui nos comentários.

Valeu, até a próxima.

16Sep/09Off

Questões Polêmicas de Concursos de TI

Hoje inicio uma nova categoria aqui no Blog. Esta categoria será sobre questões polêmicas de concursos de TI, ou seja, questões com gabarito errado após análise de recursos ou então questões ambíguas que não nos permite deduzir sobre o que está sendo pedido.

Já tenho algumas questões na manga, mas se alguém tiver alguma pode repassar que irei comentar sobre a questão.

[]s

10Sep/09Off

Por que concurso público para Tecnologia da Informação (TI)?

Depois de encarar a maratona de quatros anos ou mais de estudos na universidade, vem a questão: O que fazer agora? Pois é, uma pergunta que muitos devem se fazer.

Pretendo aqui expor[t] minha opinião sobre este tema, ou melhor, responder à pergunta do título. Vai ficar um pouco evidente a minha tendência para uma linha de pensamento, que hoje eu acho a mais vantajosa em curto, médio e longo prazo. Entre outros fatores, como restrições de oportunidades no mercado Alagoano.

Pois bem, começemos justamente por ela, oportunidades no mercado de TI em Maceió. É… tem? Não vamos mentir, ter tem, o problema são as vantagens. Dou-lhe um exemplo, certa entidade da esfera pública, meses atrás (Julho/Agosto 2009),  contratava desenvolvedor Web com inúmeras exigências, entre essas, diploma de ensino superior em Informática. Ah, detalhe: 40h semanais. Aí eu pergunto: Sabe quanto era o salário? R$1800. Você até pode argumentar:

  • Mas rapaz, R$1800 para começar, está bom. Não? E eu respondo: Não! E explico já.
  • Num país onde o salário mínimo é menos que R$500, está bom. Não? E eu respondo: Não!
  • Mas é Maceió! E eu respondo: Aí é que tá…

Beleza, vai ver era porque a entidade na verdade era pública e não necessáriamente do mercado, ok. E o mercado, quanto está pagando? Na mesma faixa salarial, ou seja, muito pouco.

Mas então eu posso optar por me mudar para algum estado do Brasil em busca de um emprego que pague bem. Pode, mas se você não já tiver uma base, como familiares ou algo do gênero, o líquido do seu salário vai ser comparável ao que você conseguiria em Maceió com certas vantagens familiares (partindo do principío que você tem essas vantagens). Salvo os casos em que estamos tratando de algum cara com sérias habilidades em determinada ferramenta ou linguagem, alguém realmente bom! Ou então, já é um especialista em SAP/ERP. O salário daria um pulo de R$15000.

Então posso assumir alguns compromissos como tentar uma especialização ou mestrado para aumentar meu salário em Maceió. Acorda!!! Seu salário simplesmente não vai mudar se você tiver doutorado!! Opa, aqui cabe uma ressalva.

E a ressalva é a de se tornar professor universitário das universidades particulares com título de mestre. Bom, é uma boa, mas será que o salário vai passar dos R$2500 por mês? Até que é razoável, não é mesmo?

Uma observação, cabe aqui deixar claro que não entrei no mérito do empreendedorismo, que é outro ponto a se falar sobre oportunidades em Maceió, restritas mas possíveis. Quem sabe outro post.

O que eu quero agora é colocar em Cheque toda a minha argumentação anterior. Como? Basta olhar para o edital do concurso do TRT-CE. Sabe qual o salário de um cargo para ensino médio para informática? R$4400. E para superior? R$6600. Meu caro, se você souber uma forma de ganhar este salário respondendo 60 questões (20 de português e 40 de TI), me avise. Fora os concursos como TCU e BACEN, que já exigem disciplinas a mais como Direito Administrativo, Constitucional e Controle Externo aquele, e Direito Adm., Const. e Economia este. Onde os salários giram em torno de R$13000.

E o que eu quero lhe dizer com isso? Nada. Só mostrar uma coisa que para mim parece evidente. Ok, alguns irão criticar o funcionalismo público, mas será que os críticos conhecem realmente o trabalho dos cargos que cito acima?

Espero comentários de pensamentos diferentes, eu pretendo escrever mais sobre esse tema, que é o que mais ocupa minha cabeça hoje. Como a decisão de fazer ou não doutorado…

Valeu.

[]s

   
Oxente.org