quarta-feira, 5 de junho de 2013

Linguagem de Progração C#

O C# (pronuncia-se "C sharp") é uma linguagem de programação criada para o desenvolvimento de uma variedade de aplicações que executam sobre o .NET Framework. C# é uma linguagem simples, poderosa, com tipagem segura e orientada a objetos. As várias inovações no C# permitem o desenvolvimento rápido de aplicações, mantendo a expressividade e a elegância das linguagens C-style.

Feramenta Microsoft Visual C# 2010 Express
Clique na figura para aumentar

Visual C# é uma implementação da linguagem C# pela Microsoft. Visual Studio suporta Visual C# com um editor de código completo, compilador, modelos de projetos, designers, assistentes de código, um depurador poderoso e fácil de usar e outras ferramentas. A biblioteca de classes do .NET Framework fornece acesso a vários serviços do sistema operacional e outras classes úteis e bem estruturadas que aceleram significativamente o ciclo de desenvolvimento.


Feramenta Microsoft Visual C# 2010 Express


Características essenciais do C#: 

Simplicidade: os projetistas de C# costumam dizer que essa linguagem é tão poderosa quanto o C++ e tão simples quanto o Visual Basic;

Completamente orientada a objetos: em C#, qualquer variável tem de fazer parte de uma classe;

Fortemente tipada: isso ajudará a evitar erros por manipulação imprópria de tipos e atribuições incorretas;

Gera código gerenciado: assim como o ambiente .NET é gerenciado, assim também o é C#;

Tudo é um objeto: System.Object é a classe base de todo o sistema de tipos de C#;

Controle de versões: cada assembly gerado, seja como EXE ou DLL, tem informação sobre a versão do código, permitindo a coexistência de dois assemblies homônimos, mas de versões diferentes no mesmo ambiente;

Suporte a código legado: o C# pode interagir com código legado de objetos COM e DLLs escritas em uma linguagem não-gerenciada;

Flexibilidade: se o desenvolvedor precisar usar ponteiros, o C# permite, mas ao custo de desenvolver código não-gerenciado, chamado “unsafe”;

Linguagem gerenciada: os programas desenvolvidos em C# executam num ambiente gerenciado, o que significa que todo o gerenciamento de memória é feito pelo runtime via o GC (Garbage Collector).


domingo, 2 de junho de 2013

Código de Ética para Profissionais de TI

A ética (palavra originada diretamente do latim ethica, e indiretamente do grego ηθική, ethiké), estuda a natureza do que é considerado adequado e moralmente correto. Muito se fala sobre a ética (ou a falta de ética) no Brasil, mas a ética também é muitas vezes violada em TI.

A ACM (Associaction for Computing Machinery ) possui um excelente código de ética para profissionais de engenharia de software, baseado em oito princípios. Para quem não conhece a ACM, ela é a primeira sociedade dedicada a computaçào no mundo e mantém, junto com a IEEE, os principais periódicos, jornais e revistas de computação do mundo.


1. PÚBLICO - Engenheiros de software devem agir de forma coerente com o interesse público.

2. CLIENTE E EMPREGADOR - Engenheiros de software devem agir de uma maneira que é no melhor interesse de seus clientes e empregadores e de acordo com o interesse público.

3. PRODUTO - Engenheiros de software devem assegurar que seus produtos e modificações relacionadas atendam aos mais altos padrões profissionais possíveis.

4. JULGAMENTO - Os engenheiros de software manterão integridade e independência em seu julgamento profissional.

5. GESTÃO - gerentes de engenharia de software e os líderes devem assinar e promover uma abordagem ética para a gestão de desenvolvimento de software e manutenção.

6. PROFISSÃO - Engenheiros de software devem avançar a integridade e reputação da profissão de acordo com o interesse público.

7. COLEGAS - Engenheiros de software devem ser justos e apoiar os seus colegas.

8. SELF - Engenheiros de software devem participar na aprendizagem ao longo da vida em relação à prática de sua profissão e devem promover uma abordagem ética à prática da profissão.

Uma versão mais extensa deste código pode ser encontrada aqui. Um bom passo que profissionais de TI podem fazer para criar um Brasil mais ético é criar uma TI mais ética, onde desenvolvedores busquem incessantemente a qualidade, gerentes sejam mais líderes do que feitores de escravo e que diretores evitem negócios excusos pelo simples prazer do dinheiro pelo dinheiro.



FONTE: http://marcomendes.com/blog/2011/08/codigo-de-etica-para-profissionais-de-ti/
Publicado em 7 de agosto de 2011 por Marco Mendes

sábado, 1 de junho de 2013

PRÁTICA ÉTICA NAS ORGANIZAÇÕES

Ética é um tema fascinante, mas complexo. Fascinante porque em teoria é compreensível e inspirador e complexo porque se dá na prática por meio das pessoas. A Ética é, portanto, um produto das relações humanas. De forma pragmática, a ética se apresenta como o assunto cujo estudo tem tornado possível maximizar a eficácia das relações humanas nas organizações. Em seu sentido mais abrangente, a ética significa o conjunto de valores e da moral que conduzem um indivíduo a tomar decisões, no que se refere principalmente às suas relações com o mundo. Não se pode estudar a ética de forma isolada, mas com foco no ambiente e nas relações humanas ali existentes.

Na busca de facilitar o convívio em sociedade são criadas normas formais, que podem estar escritas ou normas morais, que são simbólicas e se manifestam por comportamentos fortalecidos nas teias sociais ao longo dos anos e é devido a esses atributos que a empresa “Nossa Locadora de Livros” esta no mercado desde 1990. O objetivo das normas é o de se tentar prever, racionalizar e evitar que conflitos éticos ocorram.

A questão ética nas organizações passa pela compreensão da sua cultura organização. Quais os valores e crenças desta organização e como suas questões do cotidiano são resolvidas? Com esse intuito a empresa “Alunos da UNOPAR” patrocinou um seminário a todos os funcionários da empresa “Nossa Locadora de Livros”.

Edgar Schein (1982) define cultura organizacional como sendo um padrão de suposições básicas inventadas, descobertas ou desenvolvidas pelos membros de uma empresa para lidar com problemas de adaptação externa e integração interna.  Estes padrões funcionam com eficácia suficiente para serem considerados válidos e, em seguida, ensinados aos novos membros como a maneira correta de perceber, pensar e sentir esses problemas.

Observa-se que a prática da ética nas organizações, por caminhos formais ou informais, instala-se por referências ideais de comportamentos e procedimentos que servem de guia, modelo e exemplo de ações ou atitudes tidas como aceitas ou recomendadas.

A formalização de um Código de Ética enfrenta um difícil caminho de construção, implementação e manutenção nas organizações.

Na construção, o desafio está em tornar perceptível o que, de fato, se constitui como valor a serviço da visão e da missão da Empresa. A fronteira entre o código de ética de uma empresa e o ideal de comportamento humano pode levar à construção de um produto incompatível com a gestão corporativa. Assim, o produto (código de ética) pode surgir fadado a ser um mero instrumento ilustrativo ou, no máximo, uma ferramenta a serviço da divulgação de imagem da corporação.

Na implementação, o risco consiste em ter um código de ética elaborado, bem redigido, inserido em manuais, mas que não seja do conhecimento das pessoas ou ainda, não seja aceito como padrão efetivo de diretrizes da ação profissional. A implementação de um Código de Ética pressupõe a elaboração de um projeto específico, com ações de treinamento e endomarketing para divulgação e fixação de seu conteúdo como valor para a organização.

Na manutenção de um código de ética é necessário que se tenham os guardiões que, em geral, compõem o Conselho de Ética e têm por objetivo: analisar os casos discrepantes ou não descritos e auxiliar na identificação das necessidades de revisão dos itens existentes, sugerindo acréscimos ou mudanças.

Mesmo quando uma organização não tem um código de ética formal, sempre existe um conjunto de princípios e normas que sustentam as suas práticas.

A maneira como a organização opera, a partir da experiência em diferentes situações, reflete a crença de cada instituição. Essa crença é detalhada no Modelo de Gestão (Fornari, 2004) que tem como ponto de partida a visão e a missão da organização.

Na manutenção, o risco é não manter este código atual e aderente à cultura organizacional da empresa.

Os Valores são afirmações sobre as crenças fundamentais, princípios que podem ser compartilhados, aprendidos e formam a base a partir da qual as ações e decisões organizacionais serão tomadas. O conjunto de valores orienta a definição de políticas e diretrizes, que se consolidam nos hábitos e costumes. Os valores servem de guia para definição de prioridades e de como todos devem se conduzir na busca dos objetivos da organização. Embora tenham caráter permanente, os valores devem ser periodicamente revisitados, para evoluir com a sociedade e com as necessidades da empresa, formando um conjunto vivo de crenças.

Em torno dos valores, as pessoas, constroem modelos de referência para atuar de forma independente e delegada, respeitando seus interesses, crenças e as variações culturais.

Além da declaração de valores, outros artefatos culturais contribuem para disseminar os princípios éticos de uma organização (exemplo dos líderes; código de ética e o conselho de ética).

A ética numa organização, seja ela empresarial ou governamental, deve ser pautada pelos mesmos princípios. Qualquer ação ou decisão, coletiva ou pessoal, não pode prescindir de um comportamento ético, já que os códigos de conduta devem ser uma ferramenta de gestão para estabelecer e articular os valores corporativos, as responsabilidades sociais, e as obrigações da organização que, em última análise, vão definir a forma como atua para atingir os fins coletivos a que se propõe.

Diagramas de Classe para a Fase de Projeto

    projbaixo.gif (9424 bytes)

Introdução

  • Ao completar os diagramas de interação, pode-se completar o diagrama de classes.
  • Na realidade, o diagrama de classes é criado em paralelo com os diagramas de interação.
    • No final, falta incluir alguns detalhes finais.

Exemplo de um Diagrama de Classes

21-1.gif (4031 bytes)

Diagrama de classes na fase de projeto

  • Deve especificar as classes de software e as interfaces da aplicação
    • Não somente das entidades conceituais.
  • Informação tipicamente incluída:
    • Classes, associações e atributos
    • Interfaces, incluindo métodos e constantes
    • Métodos
    • Informação de tipo de atributos
    • Navegabilidade
    • Dependências

Como construir um diagrama de classes

  1. Identificar todas as classes que participam da solução em software.
    • Isso é feito pela análise dos diagramas de interação
  2. Inclui-las num diagrama de classes.
  3. Duplicar os atributos, a partir das entidades associadas no modelo conceitual.
  4. Adicionar nomes de métodos descobertos nos diagramas de interação.
  5. Adicionar informação de tipo aos atributos e métodos.
  6. Adicionar as associações necessárias para a visibilidade de atributos.
  7. Adicionar setas às associações para indicar a diração da visibilidade de atributos.
  8. Adicionar linhas de relações de dependência para indicar a visibilidade que não seja de atributo.

Modelo conceitual versus diagrama de classes da fase de projeto

  • Para ambos, UML usa o diagrama de classes.
  • No modelo conceitual, uma entidade não representa uma classe de software mas um conceito do domínio do problema.
  • No diagrama de classes da fase de projeto, as classes são de software.
21-2.gif (5939 bytes)

Criação dos diagramas de classe do estudo de caso

Identificar as classes de software

  • Verificar todos os diagramas de interação para identificar classes.
  • Adicioná-las ao diagrama de classes, junto com os atributos.
  • Não precisa incluir classes que não participam da iteração atual.
21-3.gif (4699 bytes)

Adicionar nomes de métodos

  • Analisar os diagramas de interação para descobrir os métodos de cada classe.
  • Alguns detalhes sobre métodos.
    • O método create() de UML não aparece em muitas linguagens, pois é uma chamada a um construtor.
    • Muitas vezes, não se incluem os métodos acessores (getAtributo() e setAtributo()).
    • Se classes de bibliotecas (ex. Vector em Java) são mostrados no diagrama, não se precisa mencionar seus métodos.
  • Pode-se usar a sintaxe da linguagem de programação final, se desejado.
21-4.gif (2784 bytes)
  • Diagrama até agora:
21-5.gif (5366 bytes)

Adição de informação de tipo

  • Este passo é opcional
    • Se o diagrama de classes está sendo criado numa ferramenta CASE (ex. Rational Rose), e a ferramenta será usada para gerar código, todos os detalhes de tipos devem ser dados.
    • Se o diagrama for preparado apenas para leitura por desenvolvedores, o nível de detalhamento pode ser menor.
  • O seguinte diagrama contém toda a informação de tipo.
21-7.gif (8333 bytes)

Adicionar Associações e Navegabilidade

  • A navegabilidade implica visibilidade da fonte para o destino.
    • Normalmente navegabilidade de atributo, incluída na implementação.
  • As associações devem ser apenas aquelas necessárias para a visibilidade de objetos.
    • Isso é diferente das associações no modelo conceitual, as quais podem ser incluídas para melhorar o entendimento.
  • Os diagramas de interação são usados para descobrir a visibilidade, associações e navegabilidade.
  • Situações comuns que levam a associações:
    • A envia uma mensagem a B.
    • A cria uma instância de B.
    • A deve manter conhecimento de B.
  • Exemplo:
21-8.gif (5718 bytes)
  • Diagrama de classes até agora:
21-10.gif (8627 bytes)

Adição de relações de dependência

  • Quando uma classe conhece outra (tem visibilidade), mas a visibilidade não é de atributo, usa-se uma linha tracejada.
  • Exemplo: TPDV recebe um objeto da classe EspecificaçãoDeProduto como retorno do método especificação da classe TPDV.
  • Diagrama de classes com dependências:
21-11.gif (10169 bytes)

Incluindo detalhes de membros de classes

  • UML possui sintaxe para especificar:
    • Visibilidade.
    • Valores iniciais.
    • etc.
  • Exemplo:
21-12.gif (2915 bytes)

quinta-feira, 30 de maio de 2013

DIAGRAMA DE CLASSE

O diagrama de classes elaborado na ferramenta astah community, é uma representação da estrutura e relações das classes que servem de modelo para objetos. O diagrama de classes é uma modelagem muito útil para o sistema, define todas as classes que o sistema necessita/possui e é a base para a construção dos diagramas de comunicação, sequência e estados.

Seus conceitos básicos são:

Classe: Elemento abstrato que representa um conjunto de objetos. A classe contém a especificação do objeto; suas características: atributos e métodos.

Atributo: Define características da classe.

Métodos: São ações que os objetos de uma classe podem realizar.

O Diagrama de Classe abaixo foi criado baseado em uma empresa de "Locação de Livros”, somente com as classes Livro, Editora e Autor, conforme informações abaixo.


quarta-feira, 29 de maio de 2013

Modelo Entidade Relacionamento (MER)

Segundo Martins (2007), em março de 1976, Peter P. Chen publicou um trabalho intitulado “The Entity-Relationship Model” no qual definia uma possível abordagem para o processo de modelagem dos dados, esse trabalho, após sua divulgação e ampla aceitação, passou a ser considerado como um referencial definitivo para o processo de modelagem de dados evoluído com o passar dos anos para uma abordagem mais próxima do ambiente de orientação de objeto, abordagem esse que torna a técnica mais rica, e portanto aplicável a novas finalidades.

O modelo relacional estabeleceu-se como o primeiro modelo de dados para aplicações comerciais desenvolvido para facilitar o projeto de banco de dados relacionais permitindo a representação de todas as estruturas dos mesmos e um melhor dialogo entre os profissionais envolvidos no projeto, umas das suas maiores vantagens são: flexibilidade, adaptabilidade, simplicidade e objetividade.

Segundo Martins (2007), com a criação de mais de um tipo de SGBD´s, houve uma grande preocupação com o estabelecimento de padrões que pudessem regrar este novo ambiente, assim surgiu o conceito de Schema, que é o conjunto de parâmetros e especificações para mapeamento das estruturas de dados, incluindo aspectos conceituais, lógicos e físicos.

Estes aspectos são abordados em diferentes níveis do Schema conforme Figura 29, com o objetivo de tornar possível a implementação física do banco de dados em qualquer SGBD, isso possibilita que um mesmo modelo lógico de dados, seja implementado em qualquer banco de dados, sem exigir transformações no modelo de dados original que durante essa implementação passara por níveis distintos, cada qual com suas características e particularidades.


Modelo Conceitual

Modelo que representa fielmente o negocio em questão, demonstrando características fieis ao ambiente observado ou imaginado independente de qualquer limitação imposta por tecnologia, técnica de implementação ou dispositivo físico.

Deve ser utilizada na fase de analise, nunca na fase de projeto, em nível de conversação, representação do negocio, validação de conceitos etc. Um grande diferencial do modelo conceitual é sua estabilidade, pois permanece sem mudanças independente da escolha futura de implementação, em um SGBD relacional ou um hierárquico, por exemplo. Outro aspecto positivo do modelo conceitual é que como o mesmo não respeita regras e limitações imposta pela tecnologia, as pessoas que estarão desenvolvendo o modelo irão concentrar todo seu esforço no aspecto conceitual, obtendo, desta forma, maior detalhamento do conceito nessa fase.


Modelo Lógico

Ao contrário dos modelos conceituais, os modelos lógicos são os modelos em que os objetos, suas características e relacionamentos têm sua representação de acordo com as regras de implementação e limitantes impostos por alguma tecnologia, modelo esse utilizado já na fase de projeto, mais independente de dispositivo físico, implementando conceitos como chave primaria, normalização, integridade referencial, chaves compostas e outros.

Segundo Martins (2007), esse modelo será criado através do modelo conceitual já construído, teoria essa que alguns autores têm uma visão diferenciada, definindo que o método para obtenção do modelo lógico é o próprio processo criativo, sem haver a necessidade de um modelo conceitual.


Modelo Físico

Elaborado a partir do Modelo lógico levando em consideração limites impostos por dispositivo físico e pelos seus requisitos não funcionais dos programas que acessam os dados, cada dispositivo físico (SGBD) diferente poderá definir um modo diferente de implementação física das características e recursos necessários para o armazenamento e manipulação das estruturas de dados.

Segundo Pressman (2006), o modelo de dados consiste em três peças de informação inter-relacionadas: o objeto de dados, os atributos que descrevem o objeto de dados e as relações que conectam os objetos de dados uns aos outros.




Referência Bibliográficas
Pressman, Reger S. Engenharia de Software, 2006
Martins, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software – 2ª e 4ª edições, 2007.


FONTE: Leia mais em: Modelo Entidade Relacionamento (MER) http://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821#ixzz2Uhihudc9

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS


Esse tecnólogo desenvolve, analisa, projeta implementa e atualiza sistemas de informação para diversos setores de atividade. Tem noções de gerenciamento, mas sua especialidade é a criação de sistemas informatizados. Ele programa computadores e desenvolve softwares que permitem o melhor aproveitamento das máquinas, a ampliação da capacidade de armazenamento de dados e maior velocidade no processamento das informações. Pode dedicarse à implantação e ao desenvolvimento de banco de dados para sistemas de computação e para a internet e intranet, criando estruturas de programas compatíveis com as necessidades de uma empresa. Para isso, ele deve conhecer a estrutura física dos equipamentos e periféricos, softwares, bancos de dados, bem como os negócios da companhia em que vai trabalhar. Tem de manterse atualizado também sobre as linguagens de programação e os ambientes operacionais que servem de suporte aos aplicativos. Pode atuar, ainda, como consultor na área de sistemas de informação.

Mercado de Trabalho

A demanda por profissionais no mercado de informática está sempre em alta. "Há funções em todas as esferas do poder público que requerem formação nessa área", diz Léony Luis Lopes Negrão, coordenador do curso da Uepa. "E, no setor privado, qualquer empresa precisa manter sistemas informatizados para controle de gastos, preparação da folha de pagamento e emissão de notas fiscais, entre outras operações." Empresas como IBM, HP, Totvs e DataSul, bem como companhias de telecomunicações e telefonia móvel, são algumas das que costumam contratar o profissional. Também há mercado para quem quer atuar como autônomo. As cidades de São Paulo, Campinas e Rio de Janeiro e as capitais da Região Sul concentram a maior parte das vagas. Os estados das regiões Nordeste, CentroOeste e Norte apresentam boas perspectivas de trabalho em razão da carência de mão de obra especializada.

Salário inicial: R$ 1.082,00 (fonte: Sindicato dos Trabalhadores em Processamento de Dados e Tecnologia da Informação do Estado de São Paulo).

Curso

Os cursos nessa área recebem grande variedade de nomes. Porém, há fundamentalmente dois tipos: um mais generalista e outro mais específico para banco de dados. Mas o currículo de ambos mantém quase as mesmas disciplinas básicas, como cálculo e linguagens de computação. Em aulas práticas, o estudante faz análise e programação de sistemas e administra redes de computadores. Os cursos de Banco de Dados aprofundamse no desenvolvimento, na implantação e na administração de banco de dados. Fazem parte do currículo, neste caso, matérias como aplicações em comércio eletrônico e internet. Algumas escolas exigem estágio de um semestre e um trabalho de conclusão de curso. 

Duração média: de dois a três anos.