Consultoria e treinamento em TI

Descrição: teclawindows

Tecla Windows. Ela nunca foi tão útil quanto nessa
nova versão do sistema operacional. Nas versões
anteriores, algumas combinações já eram possíveis,
mas agora, ela ganhou outras funções que facilitam
o manuseio e fazem com que o usuário ganhe tempo.
Quer ver?

Experimente a combinação Windows + seta para a
direita. A janela que estava em primeiro plano
vai, automaticamente, para a metade direita da
tela. Selecione outra janela e, dessa vez, aperte
Windows + seta para a esquerda. Veja só. A tela
ficou dividida ao meio, com cada janela para um
lado. Isso é ideal para quem gosta de utilizar
duas aplicações ao mesmo tempo. A combinação
Windows + seta pra cima maximiza a janela, e
Windows + seta pra baixo minimiza o que estava em
primeiro plano.

Se o botão Windows for apertado junto com a tecla
de espaço, todas as janelas somem da tela e a área
de trabalho é mostrada. Isso é muito útil caso
você queira ver algo que esteja no desktop, sem
precisar minimizar uma por uma. O mesmo efeito
pode ser conseguido ao repousar o mouse aqui, no
cantinho direito. Agora, experimente clicar em
alguma janela e chacoalhar o mouse. Olha só. Tudo
é minimizado, menos o programa selecionado. Legal,
né? Isso também pode ser feito via teclado,
apertando simultaneamente os botões Windows e
Home.

Agora, com o Windows 7, cada item na barra de
tarefas é associado a um número. O mais perto do
botão iniciar é o 1. O item logo em seguida é o 2,
e assim sucessivamente. Se você apertar a tecla
Windows + algum número, aquele programa vai para o
primeiro plano. Já a combinação Windows + Shift +
algum número vai executar uma nova janela daquela
aplicação. Windows + T e você percorre pelos itens
da barra de tarefas. E se você tem problemas com
letras pequenininhas, experimente Windows e a
tecla +. O zoom digital aproxima a região onde o
mouse estiver repousado. Para voltar ao zoom
original, é só apertar Windows e a tecla -.

Veja logo abaixo uma lista com outras dicas de
como utilizar a tecla Windows:

Win+Home: Deixa aberta apenas a janela ativa
Win+Space: Todas as janelas ficam transparentes, e
o usuário consegue enxergar o desktop
Win+Seta para cima: Maximiza a janela atual
Shift+Win+Seta para cima: Maximiza a janela atual
na posição vertical
Win+Seta para baixo: Minimiza a janela / volta ao
tamanho original se maximizada
Win+seta esquerda / direita: leva a janela para
cada metade da tela
Shift+Win+seta direita / esquerda: Leva a janela
para o monitor da direita ou da esquerda (em caso
de monitor duplo)
Arrastar a janela para o topo: maximiza
Arrastar a janela para a esquerda ou direita: faz
com que ela ocupe metade direita / esquerda da
tela
Chacoalhar a janela com o mouse: minimiza tudo,
menos a janela selecionada
No Windows 7, se você usar a tecla Windows com
algum número, é possível interagir com as
aplicações da taskbar. Por ex: Win + 4 vai abrir o
4. programa, contado da esquerda para a direita.
Windows + Alt + 4 mostra o jumplist do mesmo
aplicativo.
Shift+Win+número (1-9): Abre uma nova janela
daquele aplicativo
Ctrl+Win+número (1-9): Alterna entre as janelas já
abertas daquele aplicativo
Alt+Win+número (1-9): Abre a jumplist daquele
aplicativo
Win+T: Passeia pelos ítens da taskbar
Win+B: mostra os aplicativos da direita da taskbar
Ctrl+Shift+N: Cria uma nova pasta no Windows
Explorer
Alt+Up: Sobe um nível de pastas no Windows
Explorer
Win+(+/-): Zoom in/out
Win+G: Alterna entre os gadgets da sua tela

Read Users' Comments (0)

            A técnica de modelagem de estudo de caso é usada para descrever o que um sistema novo deveria fazer ou qual a função de um sistema já existente. O modelo de estudo de caso é construído através de um processo interativo de discussão entre os desenvolvedores do sistema, e os clientes (e/ou) usuários em busca de uma solução pela qual todos estejam satisfeitos.
            O estudo de caso foi criado por Ivar Jacobson, em 1994, baseado em suas experiências em desenvolvimento do sistema AXE na Ericsson, mais especificamente o OOSE e método Objectory (Veja Histórico). O estudo de casos têm recebido bastante atenção pela comunidade de orientação a objetos, e têm, da mesma forma,  afetado os métodos usados na orientação a objetos.
            Os componentes primários do modelo de estudo de caso  são: os casos, os atores, e os sistemas moldados. O limites do sistema são definidos pela funcionalidade proposta ao sistema. A funcionalidade é representada por um número de estudo de casos, e cada estudo de caso especifica uma funcionalidade completa.quando a funcionalidade está completa, o estudo de caso deve manobrar a função inteira, desde o início, feito por um ator externo, até que ele tenha alcançado a funcionalidade desejada no início. Um estudo de caso deve sempre retornar um valor para o ator, de acordo com o que este ator definiu para o sistema.
            O ator é qualquer entidade externa ao sistema que tenha interação com o sistema. Normalmente, é uma pessoa, um usuário do sistema, mas pode ser, também, outro sistema, ou algum tipo de artifício de um hardware na necessidade de interagir com o sistema.
            Na modelagem de estudo de caso, o sistema é visto como uma "caixa preta" que supre o estudo de caso. Como o sistema faz isso, como os estudo de caso são implementados, ou como eles trabalham internamente, não é o mais importante. Na verdade, quando uma modelagem de estudo de caso é feita no início do projeto, os desenvolvedores não tem idéia de como os casos de uso são implementados.
            Tópicos:    
            Objetivos
            Diagramas de estudo de caso
            Sistemas
            Atores
           Estudo de Caso
                               
   
            Portanto, o importante é saber quais são os propósitos iniciais para o estudo de caso:

•         Decidir e descrever as funcionalidades exigidas pelo sistema, resultado de um acordo entre o cliente (e/ou usuários finais) e os desenvolvedores de software que estão trabalhando no projeto;
•         Dar uma visão clara e consistente do que o sistema deve fazer, para tanto o caso de uso é utilizado durante todo o processo para comunicar todos os desenvolvedores os objetivos principais exigidos pelo sistema, e para suprir as bases de uma modelagem gráfica futura do sistema, de acordo com esses objetivos;
•        Garantir uma base para que testes de verificação do sistema sejam feitos. Certificar que os objetivo iniciais ainda sejam o foco principal do desenvolvimento do sistema.
•        Providenciar uma habilidade para traçar a funcionalidade requeridas dentro das classes e das operações do sistema. Simplificar mudanças, extensões para o sistema (manutenção), e então, traçar o estudo de caso alterado na interface gráfica e na implementação.

            Todo este trabalho de criação de modelos de estudo de casos envolve a especificação do sistema, conhecimento dos atores e dos usos de casos, descrevendo os usos de caso, e definido o relacionamento entre os casos, e por fim, a validação do modelo.
            O modelo de estudo de casos consiste de diagramas mostrando os atores, os casos e os relacionamentos. Esses diagramas dão uma visão geral do modelo. Mas as principais descrições são tipicamente textuais. Modelos visuais não podem suprir toda a informação necessária para um modelo de estudo de caso, dessa forma, ambos, diagramas e textos são usados.
            O cliente, e o usuário devem estar interessados porque o estudo de caso especifica a funcionalidade do sistema e descreve como o sistema poderá ser usado. É de grande utilidade quando o consumidor participa ativamente do processo de criação de estudo de caso, porque o modelo acaba por se adaptar em detalhes aos desejos, e necessidades do usuário. 
            O modelo de estudo de caso representa a visão do caso de uso do sistema. Esta visão é muito importante, pois influencia todas as outras visões do sistema. Tanto a arquitetura lógica quanto a física são afetadas pelo estudo de caso, pois as funções especificadas no estudo de caso são implementadas nessas arquiteturas.
            A modelagem de estudo de caso não apenas captura as necessidades de um novo sistema, mas também é usada para a geração de novos sistemas a serem desenvolvidos. Quando uma nova geração (versão) do sistema é desenvolvida, uma nova funcionalidade é acrescentada para a extensão do modelo do caso de uso basta adicionar novos atores ou casos, ou modificando as especificações de casos já existentes. No entando, deve se tomar cuidado quando se modifica um caso de uso para uma extensão para que a funcionalidade inicial não seja prejudicada.


             Um modelo de estudo de caso é descrito em UMl como um diagrama de caso de uso, e este modelo pode ser dividido em vários diagramas de estudo de casos. Um diagrama desses deve conter elementos do modelo para o sistema, os atores, e os estudo de casos, e mostrar diferentes relacionamentos como generalização, associação e dependência entre os elementos.
            A descrição real de diagrama de estudo de caso normalmente contem m texto completo. Em UML, a descrição é tratada como um documentação própria dos elementos de estudo de caso. Essa descrição contém informações vitais para a definição nas necessidades reais da funcionalidade. Como uma alternativa para descrever o estudo de caso em forma de texto, pode-se desenhar o diagrama. Contudo, é importante lembrar que o estudo de caso deve ser facilmente compreendido pelo usuário final, e uma estrutura mais formal como um diagrama ativo, pode intimidar as pessoas a interpretá-lo.
        Veja a Figura


        Como parte da modelagem do estudo de caso, os limites do sistema desenvolvido são definidos. (É importante que se tenha em mente que um sistema não é necessariamente um sistema de software, pode ser uma máquina, ou um negócio). Definir os limites e a todas as responsabilidades do sistema não é sempre fácil, pois não é sempre óbvio quais questões são melhores automatizadas por um sistema que pode ser executado manualmente, ou  por outros sistemas.
        Um sistema em um diagrama de caso de uso é descrito em uma caixa, o nome deve aparecer acima, ou dentro da caixa.

        Um ator é alguém ou algo que interage com o sistema, é quem o que usa o sistema. Por "interagir com o sistema" queremos dizer que o ator manda e recebe mensagens para e do sistema, ou seja, troca informações. Em suma, atores executam os casos de uso.
        Um ator é um tipo (uma classe), e não uma instância. Ele representa um papel, não um usuário individual do sistema. Essa troca de mensagens com o sistema é bastante similar à programação orientação a objetos, apesar de não serem tão formalmente especificados em um caso de uso. Um caso de uso é sempre inicializado por uma mensagem enviada por um ator, o que chamamos de estímulo. Quando um caso de uso é executado, espera-se que ele envie mensagens para um ou mais atores.
        Atores também podem ser definidos como ativos ou passivos. Um ator ativo é aquele inicializa o estudo de caso, enquanto que o passivo nunca inicia um estudo de caso, mas apenas participa de outros usos de caso. Quando se identifica um ator, está se estabelecendo uma entidade interessada em usar e interagir com o sistema.
       Um ator deve possuir a mesma associação com um ou mais casos de uso. Apesar do ator não ter inicializado o caso de uso, o ator irá em algum momento se comunicar com um. O ator recebe um nome que reflita seu papel no sistema.
        Atores em UML
        Tendo em mente que em UML existem classes com tipos <>, e que o nome da classe é o nome do ator (como dito acima, refletindo seu papel), uma classe ator, como outra qualquer, possui atributos e métodos, bem como documentação própria descrevendo o ator. Uma classe ator possui padrão de  representação que é o "homem palitinho", como o nome do ator abaixo da figura.
           Veja a Figura
       Relacionamento entre Atores
       Como atores são classes, eles tem os mesmos relacionamentos de uma classe normal. No diagrama de caso de uso, apenas relacionamentos de generalização são usados para descrever o comportamento normal entre atores. (Veja Gereneralização)
            Veja a Figura



       Um caso de uso representa uma funcionalidade completa, como percebida pelo ator. Um caso de uso em UML é definido como um série de ações em seqüência que um sistema executa que produzem um resultado de valor notável para o ator. As ações podem envolver comunicação com vários atores (usuários ou sistemas), bem como performar cálculos e trabalhos internos no sistema.
        As características de um estudo de caso são:

•        Um estudo de caso é sempre iniciado por um ator: é sempre executado em parte por um ator. O ator deve direta ou indiretamente ordenar que o sistema utilize um estudo de caso.
•        Um estudo de caso devolve um valor ao ator: Um estudo de caso deve enviar algum tipo de valor tangível ao usuário.
•        Um estudo de caso é completo: um estudo de caso deve possuir uma descrição completa. Um erro comum seria dividir o caso em casos menores que acabam não completando um ao outro. Um caso de uso não está completo até que se acabe o processamento do valor, mesmo que várias comunicações (como o uso de diálogos) sejam necessários ao longo do processo.

        estudo de casos está ligados aos atores através de associações, que são as vezes chamadas de associações de comunicações. As associações mostram qual ator está se comunicando, incluindo o ator que iniciou a execução de caso de uso. A associação é normalmente de um-pra-um, e sem direção. Isso significa que uma instância de ator se comunica com outra instância de estudo de caso, e que isso ocorre nas duas direções. Um estudo de caso recebe o nome de que caso performa.
        Um caso de uso é uma classe, não uma instância. Ele descreve a funcionalidade como um todo, incluindo possibilidades alternativas, erros e exceções que podem ocorrer durante o processo do estudo de caso. Um instanciamento do estudo de caso é chamado de scenario (em português cenário), e ele representa o uso real do sistema (uma execução específica através do sistema)
           Veja a Figura
    
       Um estudo de caso é representado em UML como ema elipse contendo o seu nome dentro ou abaixo dela. Um caso de uso é geralmente alocado dentro dos limites do sistema, e pode estar ligado a um ator com uma associação ou  uma associação de comunicação que mostra como usar o caso e como o ator interage com ele.
            Veja Figura
        
        Relacionamentos entre Casos de Usos
         Existem 3 tipos de relacionamentos entre casos.

•         Relacionamento por extensão:  é um tipo de herança, onde um caso de use é uma extensão de outro através da adição de ações do caso geral. O usa da extensão pode incluir o comportamento da classe que está sendo herdada, dependendo das condições de extensão;
•         Uso de Relacionamento: é outro relacionamento de generalização onde um caso de uso, porém outro estudo de caso indicando que como parte especializada do caso de uso, o comportamento do caso de uso geral (classe mãe), também será incluído;
•         Agrupamento: quando um número de casos de uso apresentam funcionalidades semelhantes, ou de alguma forma relacionadas, eles podem ser colocados juntos num pacote UML. Um grupo de pacotes relaciona um modelo de elementos, e pode ser expandido ou quebrado, permitindo ao desenvolvedor visualizar um pacote de cada vez. O pacote não possui nenhum outro significado semântico.

        Descrevendo estudo de casos
        Como já foi mencionado  várias vezes, a descrição do estudo de casos é normalmente fetita através de uma descrição textual. Esta é uma forma simples e consistente de especificação de como os atores e os usos de casos (sistemas) interagem. Isso contrasta com o comportamento externo do sistema. A terminologia da linguagem usada na descrição é a mesma da usada por consumidores/usuários do sistema:
        O texto de descrição inclui:

•             Objetivos para o caso de uso: Quais são os objetivos finais do caso de uso?! O que se quer alcançar?! O estudo de caso é orientado a objetivos, e os os objetivos de cada caso de uso devem aparecer.
•             Como o estudo de caso é inicilaizado: Que ator inicializa a execução do estudo de caso. E em quais situações.
•             A fluência das mensagens entre os atores e os casos de uso. Que mensagens ou acontecimentos, o ator do caso de uso troca: atualizada, ou não, e ajuda em outras decisões.
•             A fluência alternativa no caso de uso: um caso de uso pode ter execuções alternativas dependendo das condições ou exceções. É importante mencionar isso, mas é preciso também ser cauteloso para não descrever em muitos detalhes, já que eles devem escondem a fluência principal da ação no caso geral.
•             Como um caso de uso termina com um valor para um ator: descrever quando um caso de uso é considerado terminado e que tipo de valor ele retorna ao ator.

         Lembrar-se que a descrição identifica o que é feito de relevante pelo ator externo, e não como as coisas são feitas dentro do sistema. O texto precisa ser claro e consistente para que o consumidor possa entender e validá-lo. Evitar sentenças complicadas que dificultem a interpretação.
         Um caso de uso pode também ser descrito através de um diagrama mostrando a seqüência de atividades, suas ordens e as decisões opcionais que são feitas para indicar que atividade será executada em seguida. 
        Como complemento para o caso de uso descrito, que contém uma completa e geral descrição, um número real de cenários são usados para ilustrar o que acontece, com ambos, os atores e os casos em suas respectivas instâncias definidas. É importante não esquecer que o scenario é apenas um complemento e não um substituto para a descrição do caso.
        Depois que os casos de uso são descritos, uma atividade específica revela se os relacionamentos previamente estabelecidos descritos estão identificados. Os desenvolvedores não tem conhecimento completo para identificar os relacionamentos cabíveis, até que todas as classes estejam descritas, além de ser arriscado o fazer sem essas informações.

Read Users' Comments (0)