UML

Origem: Wikipédia, a enciclopédia livre.

Ir para: navegação, pesquisa

Nota: Para Engenharia de software, veja UML (desambiguação).

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de

terceira geração. A UML não é uma metodologia de desenvolvimento, o que significa que ela
não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe
auxilia a visualizar seu desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em

diagramas padronizados. Junto com uma notação gráfica, a UML também especifica
significados, isto é, semântica. É uma notação independente de processos, embora o RUP
(Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML.

É importante distinguir entre um modelo UML e um diagrama[1] (ou conjunto de diagramas) de

UML. O último é uma representação gráfica da informação do primeiro, mas o primeiro pode
existir independentemente. O XMI (XML Metadata Interchange) na sua versão corrente
disponibiliza troca de modelos mas não de diagramas.

[editar] Objetivos da UML

Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e

maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é
um modo de padronizar as formas de modelagem.

[editar] O Futuro da UML

Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros
aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em
técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a
linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser
definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua
estrutura interna.

A UML será a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual,
simulações e ambientes de desenvolvimento. Em breve, ferramentas de integração e padrões de
implementação baseados em UML estarão disponíveis para qualquer um.
A UML integrou muitas ideias adversas, e esta integração acelera o uso do desenvolvimento de
softwares orientados a objetos.

[editar] História

A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter
sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT
(Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e
largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelar
sistemas concorrentes e distribuídos.

A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os
auspícios do Object Management Group (OMG). O OMG pediu informação acerca de
metodologias orientadas a objetos que pudessem criar uma linguagem rigorosa de modelagem de
software. Muitos líderes da indústria responderam na esperança de ajudar a criar o padrão.

Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se
juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um
ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process -
Processo Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational
e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em
junho de 1996, a versão 0.9 da UML.

Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management
Group), um consórcio internacional de empresas que define e ratifica padrões na área de
Orientação a Objetos.
 editar
Diagramas da UML 2.0

Diagramas Estruturais

• Diagrama de classes
• Diagrama de objetos
[editar] • Diagrama de componentes
Visão • Diagrama de instalação
Geral • Diagrama de pacotes
da UML •Diagrama de estrutura
[editar] Diagramas Comportamentais

• Diagrama de Caso de Uso

• Diagrama de Estados

• Diagrama de atividade
Diagramas de Interação (Todos também são
diagramas comportamentais)

• Diagrama de sequência
• Diagrama de Interatividade
• Diagrama de colaboração ou comunicação

• Diagrama de tempo
Elementos

• De estrutura:
o Classe
o Objetos
o Interface
o Componente
o Colaboração
o Nó

• De comportamento:
o Casos de uso
o Iteração
o Máquina de estados

• De agrupamento:
o Pacote
o Modelo
o Subsistema
o Framework

• De anotação:
o Notas
Hierarquia dos diagramas UML

[editar] Relacionamentos

• Associação (bidirecional ou unidirecional)

• Generalização
• Composição
• Agregação

A criação da UML iniciou-se a partir de outubro de 1994.[2]

[editar] Conceitos de UML

UML Ator
Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de Ator (UML))

Chama-se UML Ator ao estereótipo standard do UML usado para definir o papel que um
utilizador representa relativamente ao sistema informático modelado. Um ator representa um
conjunto coerente de papéis que os usuários de casos de uso desempenham quando interagem
com esses casos de uso. Tipicamente, um ator representa um papel que um ser humano, um
dispositivo de hardware ou até outro sistema desempenha com o sistema. De notar que um
utilizador pode ser uma das seguintes entidades:

• Pessoa;
• Outro sistema informático;
• Equipamento hardware especializado;
• Passagem de tempo

Por omissão o seu ícone representa a figura de um individuo.

Uma entidade pode ser representada por vários actores, já que pode estar a assumir diferentes
papéis.

Diagrama de atividade
Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de Atividade (UML))

O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem

Unificada (UML), e representa os fluxos conduzidos por processamentos. É •
essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade •
para outra. Comumente isso envolve a modelagem das etapas seqüenciais em um processo
computacional.

Os diagramas de atividade não são importantes somente para a modelagem de aspectos

dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas
executáveis por meio de engenharia de produção reversa.

[editar] Conceitos

• Atividades: Comportamento a ser realizado.

• Sub-atividade: Execução de uma sequência não atómica de atividades.
• Transição: Fluxo de uma atividade para outra.
• Ação: Transformação.
• Decisão: Dependendo de uma condição, mostra as diferentes transições.
• Raia: Diferenciação de unidades organizacionais.
• Bifurcação (Fork): Separa uma transição em várias transições executadas ao
mesmo tempo.
• Sincronização (Join): Concatenação de transições vindas do Fork.
• Objecto: O objecto da atividade.
• Envio de sinal: Transição pra um meio externo, por exemplo, um hardware.
• Recepção de sinal: Recepção do envio.
• Região: Agrupamento de uma ou mais atividades.
• Excepção: Atividades que ocorrerem em decorrência de uma excepção.

[editar] Composição

Os diagramas de atividade costumam conter:

• Estado de atividade e estado de ação.

• Transições
 • Objectos

[editar] Estado de atividade e estado de ação

No fluxo de controle modelado por um diagrama de atividade é onde as atividades acontecem. É

possível calcular uma expressão que defina um conjunto de valor de um atributo ou que retorne
algum valor. Alternativamente, você poderá chamar uma operação num objeto, enviar um sinal a
um objeto ou até criar ou destruir um objeto. Estas computações atómicas executáveis são
chamados estado de ação.

Os estados de ação não podem ser decompostos. Além disso, os estados de ação são atómicos,
significando que os eventos poderão ocorrer, mas o trabalho de estado de acção não é
interrompido. O trabalho de estado de ação é geralmente considerado como ocupando um tempo
de execução insignificante.

Em contraste, os estados de atividade podem ser decompostos, suas atividades sendo

representadas por outros diagramas de atividades. Além disso, os estados de atividade são não-
atómicos, significando que poderão ser interrompidos e, em geral, são considerados como
tomando algum tempo para serem completados

Interface
Origem: Wikipédia, a enciclopédia livre.

Ir para: navegação, pesquisa

O Wikcionário possui o verbete Interface

O conceito de Interface é amplo, pode se expressar pela presença de uma ou mais ferramentas
para o uso e movimentação de qualquer sistema de informações, seja ele material, seja ele
virtual. O dicionário define interface como o conjunto de meios planejadamente dispostos sejam
eles físicos ou lógicos com vista a fazer a adaptação entre dois sistemas [1] para se obter um certo
fim cujo resultado possui partes comuns aos dois sistemas, ou seja, o objeto final possui
características dos dois sistemas.
Índice
[esconder]

• 1 Multisignificação de Interface
• 2 Interface na Ciência da
computação
o 2.1 Interface Visual
• 3 Aplicação
• 4 Analogias e Curiosidades
• 5 Referências

• 6 Ver também

[editar] Multisignificação de Interface

Pode ter o significado, na ciência da computação, de um circuito eletrônico que controla a

interligação entre dois dispositivos hardwares e os ajuda a trocar dados de maneira confiável.

Pode ter o significado, na Informática, de interconexão entre dois equipamentos que possuem
diferentes funções e que não se poderiam conectar diretamente, como, p. ex., o modem.[1]

Pode ter o significado, na Comunicação, como o meio capaz de promover a comunicação ou

interação entre dois ou mais grupos.[1]

Pode ter o significado, na Física, de superfície que separa duas fases de um sistema.[1]

Pode ter o significado, na Ecologia, de área de fronteira entre regiões adjacentes, e que constitui
ponto em que interagem sistemas independentes de diversos grupos. [1]

[editar] Interface na Ciência da computação

O ponto em que há controle entre dois dispositivos hardwares, entre um usuário e um programa
ou sistema operacional, ou entre duas aplicações. No hardware, a interface descreve as conexões
lógicas e físicas utilizadas, como no RS-232-C, sendo considerado em geral sinônimo de porta.
A interface com o usuário se compõe dos meios pelos quais um programa se comunica com o
usuário, incluindo uma linha de comandos, menus, caixas de diálogos, sistema de ajuda on line,
etc. As interfaces com os usuários podem ser classificadas com baseadas em caracteres ( texto ),
baseados em menus ou baseadas em elementos visuais. As interfaces de software são APIs
( Application Program Interfaces ou Interfaces de Programas Aplicativos) e consistem em
códigos e mensagens utilizadas pelos programas para se comunicarem de forma transparente
para o usuário.
[editar] Interface Visual

Uma interface com usuário que recorre ao mouse e imagens de mapa de bits para simplificar
grandemente as operações básicas do computador para os usuários iniciantes. Os recursos típicos
da interface visual são os quadros de advertência, clipboard ou áreas de transferência, os
acessórios, de mesa, a metáfora do desktop, os quadros de dialogo, as setas de paginação, a
possibilidade de utilização de diversas fontes na tela, a equivalência entre conteúdo da tela e a
página impressa e a abertura de várias janelas na tela.

[editar] Aplicação

Na ciência da computação, o termo interface é utilizado em diversas áreas:

• Interface do utilizador
• Interface gráfica do utilizador
• Interface, em programação de computadores, é uma definição que
estabelece a fronteira de comunicação entre dois componentes de software.
• Interface de rede

[editar] Analogias e Curiosidades

Partindo da definição de que Interface é um conjunto de meios físicos ou lógicos planejadamente

dispostos... (vide início do artigo) Para exemplicar o conceito de Interface: Tem-se um relógio,
que é um sistema cujo fim é contar um tempo, e uma dinamite, que é um sistema cujo fim é
causar uma explosão. Para se criar uma bomba relógio é necessário que haja uma interface entre
estes dois elementos ou sistemas. Após a adaptação dos sistemas, ou após interfaceados, o
usuário obterá um sistema conjugado cujo fim é causar uma explosão num tempo determinado.

Curiosamente, se no exemplo acima os dois sistemas interfaceados pudessem repetir seu fim
(causar explosão em tempo determinado) várias vezes e existisse um usuário à distância capaz de
reconhecer o padrão temporal das explosões mas desconhecendo a interface dos sistemas, estes
usuário reconheceria os dois sistemas como um só sistema isolado, isto é, sem interface, ou seja,
o usuário reconheceria como um único sistema que é capaz de explodir num determinado tempo
padronizado. Subtende-se disso tudo que o conceito de interface também adentra o campo da
Relatividade visto que depende do observador.

A existência da Relatividade no conceito de Interface é evidente quando vemos, por exemplo,

um programador dizendo: “o usuário não precisa ver estes subsistemas” Esta frase poderiam
muito bem ser escrita assim: “neste ponto não há necessidade de existir uma interface com o
usuário”. Todavia, apesar do software final se feito de inúmeros subprogramas, o usuário final
somente o enxerga como um único programa (sistema isolado).

Este exemplo é muito útil para se reconhecer a importância do entendimento do conceito de

Interface e a primordialidade de se identificar as interfaces nos sistemas em geral, inclusive os
naturais, para que não se cometa equívoco do usuário à distância do exemplo acima. Saliente-se
que já se cometeu esse nobre equívoco no passado quando a Ciência acreditou que as ligações
químicas (fim), eram feitas entre partículas elementares que somente se agrupavam (não há
interface entre os sistemas) visto que eram pequenas esferas indivisíveis. Contudo isto foi
desmistificado posteriormente quando se identificou que para haver as ligações químicas era
necessário que os átomos doassem, recebessem ou compartilhassem elétrons, ou seja, o elétron
seria a Interface das ligações químicas.

Referências

1. ↑ a b c d e Buarque de Holanda Ferreira, Aurélio. Novo Dicionário Aurélio da

Língua Portuguesa, Revista e atualizada do Aurélio Século XXI. 3ª Edição.
Brasil: Editora Positivo. 2004

2. Pacote de software
3. Origem: Wikipédia, a enciclopédia livre.
4. (Redirecionado de Package)
5. Ir para: navegação, pesquisa
6. Um pacote de software é o software empacotado num formato de arquivo para ser
instalado por um sistema gestor de pacotes ou por um instalador autônomo. Em contextos
específicos, um pacote de software também pode ser considerado um conjunto de classes
e interfaces relacionadas.
7. Distribuições Linux geralmente são segmentadas em pacotes, de forma que cada pacote
contém uma aplicação ou um serviço específico.

Classe (programação)
Origem: Wikipédia, a enciclopédia livre.

Ir para: navegação, pesquisa

Esta página ou secção não cita nenhuma fonte ou

referência, o que compromete sua credibilidade.
(desde julho de 2010).
Por favor, melhore este artigo providenciando fontes
 fiáveis e independentes, inserindo-as no corpo do texto
por meio de notas de rodapé. Encontre fontes: Google —
notícias, livros, acadêmico — Scirus

Orientação a objetos

Objeto

Classe

• Instância
Abstração

Métodos

Atributo
Em orientação a objetos, uma classe é uma estrutura que abstrai
Encapsulamento
um conjunto de objetos com características similares. Uma classe
define o comportamento de seus objetos através de métodos e os Herança
estados possíveis destes objetos através de atributos. Em outros
termos, uma classe descreve os serviços providos por seus objetos
• Herança múltipla
e quais informações eles podem armazenar.
Polimorfismo
Classes não são diretamente suportadas em todas as linguagens, e Outras referências
são necessárias para que uma linguagem seja orientada a objetos.
Classes são os elementos primordiais de um diagrama de classes. Padrões de projeto

UML

Engenharia OO
Índice
[esconder]

• 1 Estrutura da classe
• 2 Encapsulamento
• 3 Herança
• 4 Polimorfismo
• 5 Associação
o 5.1 Agregação
o 5.2 Composição
• 6 Classes abstratas e
concretas

• 7 Ver também

[editar] Estrutura da classe

Uma classe define estado e comportamento de um Objeto geralmente implementando métodos e

atributos (nomes utilizados na maioria das linguagens modernas). Os atributos, também
chamados de campos (do inglês fields), indicam as possíveis informações armazenadas por um
objeto de uma classe, representando o estado de cada objeto. Os métodos são procedimentos que
formam os comportamentos e serviços oferecidos por objetos de uma classe.

Outros possíveis membros de uma classe são:

• Construtores - definem o comportamento no momento da criação de um

objeto de uma classe.
• Destrutor - define o comportamento no momento da destruição do objeto de
uma classe. Normalmente, como em C++, é utilizado para liberar recursos do
sistema (como memória), já em outras linguagens, como em Java e C♯ isto é
realizado de modo automático pelo Garbage collector.
• Propriedades - define o acesso a um estado do objeto.
• Eventos - define um ponto em que o objeto pode chamar outros
procedimentos de acordo com seu comportamento e estado interno.

[editar] Encapsulamento
Ver artigo principal: Encapsulamento

Em linguagens orientadas a objetos, é possível encapsular o estado de um objeto. Em termos

práticos, isso se realiza limitando o acesso a atributos de uma classe exclusivamente através de
seus métodos. Para isso, as linguagens orientadas a objeto oferecem limitadores de acesso para
cada membro de uma classe.

Tipicamente os limitadores de acesso são:

 • público (public) - o membro pode ser acessado por qualquer classe. Os
membros públicos de uma classe definem sua interface.
• protegido (protected) - o membro pode ser acessado apenas pela própria
classe e suas sub-classes.
• privado (private) - o membro pode ser acessado apenas pela própria classe.

Cada linguagem de programação pode possuir limitadores de acesso próprios. Por exemplo, em
Java, o nível de acesso padrão de um membro permite que qualquer classe de seu pacote
(package) possa ser acessado. Em C♯, o limitador de acesso interno (internal) permite que o
membro seja acessado por qualquer classe do Assembly (isto é, da biblioteca ou executável).

No exemplo abaixo, implementado em Java, a classe Pessoa permite o acesso ao atributo nome
somente através dos métodos setNome e getNome.

public class Pessoa {

private String nome;

public String getNome() {

return nome;
}

public void setNome(String nome) {

this.nome = nome;
}
}

[editar] Herança

Representação de herança entre classes em UML

Ver artigo principal: Herança (programação)

A herança é um relacionamento pelo qual uma classe, chamada de sub-classe, herda todos
comportamentos e estados possíveis de outra classe, chamada de super-classe ou classe base. É
permitido que a sub-classe estenda os comportamentos e estados possíveis da super-classe (por
isso este relacionamento também é chamado de extensão). Essa extensão ocorre adicionando
novos membros a sub-classe, como novos métodos e atributos.
É também possível que a sub-classe altere os comportamentos e estados possíveis da super-
classe. Neste caso, a sub-classe sobrescreve membros da super-classe, tipicamente métodos.

Quando uma classe herda de mais de uma super-classe, ocorre uma herança múltipla. Esta
técnica é possível em C++ e em Python, mas não é possível em Java e C♯, no entanto estas
linguagens permitem múltipla tipagem através do uso de interfaces.

[editar] Polimorfismo
Ver artigo principal: Polimorfismo

Na programação orientada a objetos, o polimorfismo permite que referências de tipos de classes

mais abstratas representem o comportamento das classes concretas que referenciam. Assim, um
mesmo método pode apresentar várias formas, de acordo com seu contexto. O polimorfismo é
importante pois permite que a semântica de uma interface seja efetivamente separada da
implementação que a representa. O termo polimorfismo é originário do grego e significa 'muitas
formas' (poli = muitas, morphos = formas).

[editar] Associação

Uma associação é um vínculo que permite que objetos de uma ou mais classes se relacionem.
Através destes vínculos é possível que um objeto convoque comportamentos e estados de outros
objetos.

Exemplo de associação unária em UML

As associações podem ser:

• unárias - quando a associação ocorre entre objetos de uma mesma classe.

• binárias - quando a associação ocorre entre dois objetos de classes distintas.
• múltiplas - quando a associação ocorre entre mais de dois objetos de classes
distintas.

Cada associação possui características de:

 • cardinalidade ou multiplicidade - determina quantos objetos no sistema são
possíveis em cada vértice da associação.
• navegação - se é possível para cada objeto acessar outro objeto da mesma
associação.

No exemplo de associação unária acima, cada pessoa tem um único pai (cardinalidade 1) e
qualquer número de filhos (cardinalidade *). De acordo com a seta de navegação, só é possível
navegar para o pai de cada pessoa. Desta forma cada objeto da classe Pessoa consegue acessar
seu objeto pai, mas não consegue acessar seus objetos filhos.

[editar] Agregação

Tipo de relacionamento com características todo-parte, onde existe um grau de coesão entre o
todo e as partes menos intenso, podendo haver certo grau de independência entre eles.

[editar] Composição

Tipo de relacionamento com características todo-parte, onde existe um alto grau de coesão entre
o todo e as partes, com total grau de dependência entre eles (todo e as partes). Desta forma, se o
todo não existir, as partes também não existirão.

Um exemplo de composição é a mão:

Uma mão é composta por dedos. Os dedos compõem a mão.

Não há lógica em existir um dedo sem mão, porém pode-se ter uma mão sem um ou mais dedos

[editar] Classes abstratas e concretas

Uma classe abstrata é desenvolvida para representar entidades e conceitos abstratos. A classe
abstrata é sempre uma superclasse que não possui instâncias. Ela define um modelo (template)
para uma funcionalidade e fornece uma implementação incompleta - a parte genérica dessa
funcionalidade - que é compartilhada por um grupo de classes derivadas. Cada uma das classes
derivadas completa a funcionalidade da classe abstrata adicionando um comportamento
específico.

Uma classe abstrata normalmente possui métodos abstratos. Esses métodos são implementados
nas suas classes derivadas concretas com o objetivo de definir o comportamento específico. O
método abstrato define apenas a assinatura do método e, portanto, não contém código.

Por outro lado, as classes concretas implementam todos os seus métodos e permitem a criação de
instâncias. Uma classe concreta não possui métodos abstratos e, geralmente, quando utilizadas
neste contexto, são classes derivadas de uma classe abstrata.
Evento (computação)
Origem: Wikipédia, a enciclopédia livre.

Ir para: navegação, pesquisa

Em computação, um evento é o resultado de uma ação. A ocorrência de um evento pode

provocar uma reação, que seria uma ação (ou conjunto de ações) à ser tomada.

Índice
[esconder]

• 1 Exemplos
o 1.1 Eventos de mouse
o 1.2 Eventos de teclado

• 2 Referências

[editar] Exemplos
[editar] Eventos de mouse

Pressionando um botão de um dispositivo apontador, como um mouse, determina a ocorrência de

um evento "mouse click". O programador pode codificar instruções para que o programa
responda a este evento. Tipicamente, eventos do mouse incluem movimentos do mouse e
pressionamento/liberação de botão do mouse.[1]

[editar] Eventos de teclado

Quando um usuário pressiona uma tecla em um teclado, o programa em execução recebe um

evento "KeyDown" (pressionamento de tecla) acompanhado de dados relevantes, como a
identificação da tecla pressionada.[1]

Referências