1 - Aula - Uml

ANÁLISE ORINETADA A OBJETOS
- METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE

Já faz alguns anos que o desenvolvimento de software deixou de
ser sinônimo apenas de código. Hoje, sabe-se que é necessária a
utilização de uma metodologia de trabalho.
Mas o que é necessariamente uma metodologia de software?
Entende-se por metodologia, como a maneira – forma – de se

utilizar um conjunto coerente e coordenado de métodos para
atingir um objetivo, de modo que se evite, tanto quanto
possível, a subjetividade na execução do trabalho. Fornecendo
um roteiro, um processo dinâmico e interativo para
desenvolvimento estruturado de projetos, sistemas ou software,
visando à qualidade e produtividade dos projetos.
É objetivo de uma metodologia definir de forma clara “quem”

faz “o que”, “quando”, “como”, e até mesmo “onde”, para todos
os que estejam envolvidos diretamente ou não com o
desenvolvimento de software. Deve definir também qual o papel
dos técnicos, dos usuários, e o da administração da empresa no
processo de desenvolvimento. Com isso, evita-se a situação a
qual o conhecimento sobre o sistema é de poucos, comumente
apelidados, de “os donos do sistema”.
Com isso, o uso de uma metodologia possibilita:

- Ao gerente: controlar o projeto de desenvolvimento de
software mantendo o rumo do projeto sobre controle para que
não haja desvios de planejamentos de custos e prazos, que, se
negligenciados ou mal conduzidos, podem por em risco o
sucesso do projeto.
- Ao desenvolvedor: obter a base para produzir de maneira
eficiente, software de qualidade que satisfaça os requisitos
estabelecidos.
Uma metodologia não deve limitar a criatividade profissional,

mas deve ser um instrumento que determine um planejamento
sistemático, que harmonize e coordena as áreas envolvidas. O
que limita a criatividade não é a metodologia, mas os requisitos
de qualidade e produtividade de um projeto.
Como uma metodologia é um conjunto de métodos, convém
definir o que é um método e qual o seu objetivo.
* MÉTODO: é abordagem técnica passo a passo para realizar

uma ou mais tarefas indicadas na metodologia. Ou seja, é (são)
o(s) procedimento(s) necessário(s) a ser (em) adotado(s) para
atingir um objetivo.
Já uma TÉCNICA, pode ser compreendida como sendo um modo
apropriado de se investigar sistematicamente um universo de
interesse ou domínio do problema. Para tanto, utiliza-se de uma
notação. Como exemplo de técnica, temos: Análise estruturada,
Análise Essencial, Projeto Estruturado, Análise Orientada a
Objetos.
- UM POUCO DE HISTÓRIA
Desde os primeiros sistemas desenvolvidos, nas décadas de 40 e
50, até aproximadamente os meados de 1970 as aplicações não
atingiam grandes dimensões, pois as máquinas existentes
possuíam várias limitações. A modelagem do software era
realizada com textos escritos em linguagem natural e sem
nenhum critério formal. Nessa época, a única ferramenta
utilizada era o fluxograma.
O conceito de Engenharia de Software surgiu como uma forma

de combater à crise de software e, com o seu nascimento,
surgiu a Análise Estruturada (baseada no paradigma de
Programação Estruturada).
Muito se conseguiu melhorar no processo de desenvolvimento
de sistemas com essa metodologia e isso tornou possível a
criação de produtos de melhor qualidade. Entretanto, existem
problemas na metodologia de análise estruturada.
* Na análise estruturada existe um problema bastante delicado:
processos e dados são vistos de forma independente.
Com o surgimento da Programação Orientada a Objetos, surgiu

também a Análise Orientada a Objetos que possibilitou a
resolução desses problemas. Diversos métodos de análise OO
foram apresentados, porém não havia uma padronização e isso
gerava confusão quanto a escolha dos métodos por parte dos
desenvolvedores.
Por volta de 1993, os métodos que mais cresciam no mercado
eram o Booch (de Grady Booch), o OMT (Object Modeling
Technique, de James Rumbaugh) e o OOSE (Object-Oriented
Software Engineering, de Ivar Jacobson). Nesse contexto, Booch,
Rumbaugh e Jacobson decidiram unir forças e criar um método
único em que as melhores características dos três métodos
anteriores se combinavam.
Em 1996, os três amigos (como eram conhecidos) lançaram uma

nova versão do “método unificado”, surgiu então a UML
(Unified Modeling Language). Em 1997, a UML foi adotada
como padrão pela OMG(*) (Object Management Group).
(*)Object Management Group, ou OMG, é uma organização

internacional que aprova padrões abertos para aplicações
orientadas a objetos. A OMG supervisiona a definição e
manutenção de especificações UML
- UML - UNIFIED MODELING LANGUAGE (LINGUAGEM

MODELADA UNIFICADA)
- UML - UNIFIED MODELING LANGUAGE (LINGUAGEM

MODELADA UNIFICADA)
- O QUE É UML?
UML É um padrão para desenvolvimento de software que reúne
melhores práticas de metodologia de sistemas. Neste modelo,
diversos diagramas auxiliam na visualização do problema e a
concepção da solução, permitindo uma visão macro dos objetos
e seus relacionamentos; ela propõe uma linguagem visual para
especificação (modelagem) de sistemas orientados a objetos,
fornece representação gráfica para os elementos essenciais do
paradigma de objetos como classes, atributos, objetos, troca de
mensagens, etc
A modelagem proporcionada pela UML permite simplificar o

entendimento de um sistema, ao transformar suas
complexidades em objetos gráficos simples, onde a lógica
interna de seu funcionamento é abstraída.
Através da modelagem também conseguimos estruturar um
sistema. A manutenção que ocorrer nos posteriores ciclos de
desenvolvimento fica mais fácil de ser efetuada já que a mesma
ocorre inicialmente num nível lógico, e não no código
(programa), de forma que se pode evoluir os diagramas que
serão alterados e verificar suas consequências, antes de se
preocupar com a fase de desenvolvimento.
A Linguagem de modelagem unificada (UML) foi criada para

estabelecer uma linguagem de modelagem visual comum,
semanticamente e sintaticamente rica, para arquitetura, design e
implementação de sistemas de software complexos, tanto
estruturalmente quanto para comportamentos. Além do
desenvolvimento de software, a UML tem aplicações em fluxos
do processo na fabricação.
É análoga aos modelos utilizados em outros campos, e é
composta por diferentes tipos de diagramas.
* De modo geral, diagramas UML descrevem o limite, a
estrutura e o comportamento do sistema e os objetos nele
contidos.
A UML não é uma linguagem de programação, mas existem

ferramentas que podem ser usadas para gerar código em várias
linguagens por meio de diagramas UML. A UML tem uma
relação direta com a análise e o design orientados a objetos.
UML é uma linguagem para visualização, especificação,

construção e documentação de artefatos de um software
orientado a objeto.
Sua grande vantagem é que ela é única para as quatro
atividades: análise, “design”, implementação e teste.
O modelo subjacente à linguagem é composto de:
- itens;
- relacionamentos;
- diagramas.
1. ITENS
- Estruturais
– classes, interfaces, casos de uso, componentes ...
- Comportamentais
– interações, máquinas de estado.
- Grupos de elementos
– pacotes, frameworks e subsistemas.
- Anotacionais
– notas
2. RELACIONAMENTOS
- Dependência
- Associação
- Generalização
- Realização
Os relacionamentos são entre itens como classes, casos de uso e
etc.
3. DIAGRAMAS
- Diagrama de classes
- Diagrama de objetos
- Diagrama de casos de uso
- Diagrama de sequência
- Diagrama de colaborações
- Diagrama de gráficos de estados
- Diagrama de atividades
- Diagrama de componentes
- Diagrama de implantação
O modelo do sistema é representado pelos dois conjuntos de
diagrama, estático e dinâmico (observe a imagem a seguir).
* Vermelho: estático (ou estrutural);

* Azul: dinâmico (ou comportamental).
Um diagrama instanciado é uma visão parcial de um sistema, sob

uma determinada perspectiva (um tipo de usuário).
- ATUALIZAÇÕES EM UML 2.0

A UML é aprimorada de forma contínua. UML 2.0 estende as
especificações UML para abranger mais aspectos do
desenvolvimento. O objetivo foi reestruturar e aperfeiçoar a
UML para que a usabilidade, implementação e adaptação fossem
simplificadas. Seguem algumas das atualizações aos diagramas
UML:
- Maior integração entre modelos estruturais e

comportamentais.
- Capacidade de definir hierarquia e dividir um sistema de
software em componentes e subcomponentes.
- UML 2.0 aumenta o número de diagramas de 9 para 13.
A UML está na versão 2.5 (lançada em 2015). Conforme a OMG,

a UML possui atualmente 14 tipos de diagramas, divididos em
duas grandes categorias: Estruturais e Comportamentais. Sete
tipos de diagramas representam informações estruturais, e os
outros sete representam tipos gerais de comportamento,
incluindo quatro em uma subcategoria que representam
diferentes aspectos de interação. Estes diagramas estão
divididos hierarquicamente. Os diagramas estruturais modelam
o “esqueleto” do seu sistema e com eles é possível representar,
por exemplo, todas as classes do seu software, bem como os
seus relacionamentos. Os diagramas comportamentais
modelam o fluxo real de funcionamento do seu sistema.
ANÁLISE ORINETADA A OBJETOS - DIAGRAMAS
- DIAGRAMAS DE PACOTES
Existem dois tipos especiais de dependências definidas entre
pacotes: a importação do pacote e a mesclagem do pacote. Para
revelar a arquitetura, os pacotes representam os diferentes
níveis de um sistema. Dependências de pacotes podem ser
marcadas para mostrar o mecanismo de comunicação entre os
níveis.
Pacote é um mecanismo de agrupamento, onde todos os

modelos de elementos podem ser agrupados. Em UML, um
pacote é definido como: "Um mecanismo de propósito geral
para organizar elementos semanticamente relacionados em
grupos." Todos os modelos de elementos que são ligados ou
referenciados por um pacote são chamados de "Conteúdo do
pacote". Um pacote possui vários modelos de elementos, e isto
significa que estes não podem ser incluídos em outros pacotes.
Notação:
Pacotes podem importar modelos de elementos de outros

pacotes. Quando um modelo de elemento é importado, refere-
se apenas ao pacote que possui o elemento. Na grande maioria
dos casos, os pacotes possuem relacionamentos com outros
pacotes. Embora estes não possuam semânticas definidas para
suas instâncias. Os relacionamentos permitidos entre pacotes
são de dependência, refinamento e generalização (herança).
O pacote tem uma grande similaridade com a agregação. O fato
de um pacote ser composto de modelos de elementos cria uma
agregação de composição. Se este for destruído, todo o seu
conteúdo também será.
ANÁLISE ORINETADA A OBJETOS – CASOS DE USO
- DIAGRAMAS DE CASOS DE USO

Representa uma determinada funcionalidade de um sistema, e
foi criado para ilustrar a forma como as funcionalidades se
relacionam e seus controladores internos e externos (atores).
O Diagrama de Casos de Uso é um modelo gráfico que agrupa

determinados casos de usos e atores de um determinado
sistema, de forma a visualizar-se de maneira rápida e fácil o
relacionamento entre eles, servindo de documento para
comunicação entre os participantes do projeto.
Tem o objetivo de auxiliar a comunicação entre os analistas e o
cliente e descreve um cenário que mostra as funcionalidades do
sistema do ponto de vista do usuário.
* O cliente deve ver no Diagrama de Casos de Uso as principais
funcionalidades de seu sistema.
Um caso de uso é uma lista de passos que definem a interação

entre um ator (um ser humano que interage com o sistema, ou
com um sistema externo) e o próprio sistema. Diagramas de
caso de uso descrevem as especificações de um caso de uso e
modelam as unidades funcionais de um sistema. Estes
diagramas ajudam equipes de desenvolvimento a entender as
necessidades de seu sistema, incluindo o papel da interação
humana no seu interior e as diferenças entre vários casos de uso.
Um diagrama de caso de uso pode exibir todos os casos de uso
do sistema, ou apenas um grupo de casos de uso com
funcionalidade semelhante.
- NOTAÇÃO
O diagrama de Caso de Uso é representado por:
- atores;
- casos de uso;
- relacionamentos entre estes elementos.
Estes relacionamentos podem ser:

- associações entre atores e casos de uso;
- generalizações entre os atores;
- generalizações, extends e includes entre os casos de uso.
Casos de uso podem opcionalmente estar envolvidos por um

retângulo que representa os limites do sistema.
- ATORES
Um ator é representado por um boneco e um rótulo com o
nome do ator. Um ator é um usuário do sistema, que pode ser
um usuário humano ou um outro sistema
- CASO DE USO
Um caso de uso é representado por uma elipse e um rótulo
com o nome do caso de uso.
Um caso de uso define uma grande função do sistema. A
implicação é que Diagrama de Casos de Uso uma função pode
ser estruturada em outras funções e, portanto, um caso de uso
pode ser estruturado.
- RELACIONAMENTOS
- Entre um Ator e um caso de uso: Associação
Define uma funcionalidade do sistema do ponto de vista do
usuário.
- Entre Atores: Generalização

Os casos de uso de B são também casos de uso de A;
A tem seus próprios casos de uso.
- Entre Casos de Uso

Um relacionamento include de um caso de uso A para um caso
de uso B indica que B é essencial para o comportamento de A.
Pode ser dito também que B is_part_of A.
<<inclui-se>> que especifica que um Caso de Uso toma lugar
dentro de outro Caso de Uso;
- Entre Casos de Uso

Um relacionamento extend de um caso de uso B para um caso
de uso A indica que o caso de uso B pode ser acrescentado para
descrever o comportamento de A. A extensão é inserida em um
ponto de extensão do caso de uso A.
<<estende>> que especifica que em determinadas situações, ou
em algum ponto (chamado um ponto de extensão) um Caso de
Uso será estendido por outro;
- Include - Extend
- Entre casos de uso: Generalização

Caso de uso B “é um” caso de uso A (A é uma generalização de
B, ou B é uma especialização de A).
Um relacionamento entre um caso de uso genérico para um mais
específico, que herda todas as características de seu pai.
- SISTEMA
- Limites do sistema: representado por um retângulo
envolvendo os casos de uso que compõem o sistema.
- Nome do sistema: Localizado dentro do retângulo.
- DIAGRAMAS DE CLASSES
É o diagrama UML mais usado, e a principal base de qualquer
solução orientada a objetos. Classes dentro de um sistema,
atributos e operações, e a relação entre cada classe. Classes são
agrupadas para criar diagramas de classes quando há uma
diagramação de grandes sistemas.
Os Diagramas de Classes mostram as diferentes classes que

compõem um sistema e como elas se relacionam umas com as
outras. Os Diagramas de Classes são apontados normalmente
como "estáticos" porque mostram as classes, em conjunto com
os seus métodos e atributos, assim como as relações estáticas
entre elas, quais as classes que "conhecem" outras classes ou
que "fazem parte" de outra classe, mas não mostram as
chamadas de métodos entre elas.
- Diagramas de Classe podem conter diversos outros itens além

das classes:
- INTERFACES
Interfaces são classes abstratas que significam instâncias que
não podem ser diretamente criadas delas. Elas podem conter
operações, mas não podem conter atributos. Classes podem
derivar de interfaces (através da realização de uma associação) e
instâncias podem então ser feitas destes diagramas.
- TIPOS DE DADOS
Tipos de dados são primitivos uma vez que são tipicamente
construídos numa linguagem de programação. Exemplos
comuns são inteiros e lógicos. Eles não podem ser relacionados à
classes, mas classes podem se relacionar com eles.
- ENUMERAÇÕES
Enumerações são uma lista simples de valores. Um exemplo
típico é uma enumeração para dias da semana. As opções de
uma enumeração são chamadas Literais de Enumeração. Como
tipos de dados, elas não podem ter relacionamentos para
classes, mas classes podem relacionar-se com elas.
- PACOTES
Pacotes representam um espaço de nomes numa linguagem de
programação. Num diagrama eles são usados para representar
partes de um sistema que contém mais de uma classe, talvez
centenas de classes.
* Exemplo de Diagrama de Classes

- OBJETOS
Os objetos são instanciações de classes. Enquanto as classes são
abstrações, os objetos existem no mundo real. Um objeto
representa uma entidade que pode ser física, conceitual ou de
software. É uma abstração de algo que possui fronteira definida
e significado para a aplicação. Na UML a representação de um
objeto é quase igual a de uma classe. A única diferença é que o
nome dos objetos aparecem sublinhados, como na imagem a
seguir. Se quiser, pode escrever o nome da classe depois do
nome do objeto para que fique mais claro a que classe ele
pertence.
- OBJETOS
* POO – CLASSES:
Na lógica de programação orientada a objetos uma classe é
uma abstração de um conjunto de objetos com as mesmas
características (atributos, operações, relacionamentos e
semântica). Uma classe define os atributos de seus objetos e
métodos.
Os atributos são elementos das classes semelhantes as
variáveis da lógica de programação estruturada. Cada atributo
representa uma propriedade do item que está sendo modelado.
Para cada atributo é definido um intervalo de valores possíveis.
Por exemplo, a classe funcionário pode ter os atributos nome,
endereço, telefone, número de identidade, salário, cargo.
Na UML, os Atributos são mostrados como tendo o seu nome,

pelo menos, e poderão mostrar também o seu tipo, o seu valor
inicial e outras propriedades. Os atributos também poderão ser
mostrados com a sua visibilidade:
- + Representa atributos públicos;
- # Representa atributos protegidos;
- - Representa atributos privados.
A seguir, uma representação de uma classe com seus atributos

na linguagem UML:
Além de atributos as classes têm métodos. Um método é uma

operação que pode ser executada sobre os objetos de uma
classe. São os métodos que executam todas as funcionalidades
do programa, como fazer cálculos, exibir mensagens, gerar
relatórios, etc.
As operações (métodos) são também mostradas contendo pelo
menos o seu nome e poderão também mostrar os seus
parâmetros e tipos de valor devolvidos. As operações podem,
assim como os Atributos, mostrar a sua visibilidade:
- + Corresponde a operações públicos;
- # Corresponde a operações protegidos;
- - Corresponde a operações privados.
- RELACIONAMENTO NAS CLASSES

Além de identificar as classes do seu sistema será preciso
representar os relacionamentos que existem entre elas. Há três
tipos de relacionamentos: dependências, generalizações e
associações.
1- DEPENDÊNCIA
Uma dependência é um relacionamento em que um item usa
dados e serviços de outro item. Representa-se uma
dependência em UML com uma linha tracejada apontando do
item que depende de alguma informação para o que a fornece.
2- GENERALIZAÇÃO
Uma generalização é um relacionamento entre ítens gerais e
itens mais específicos. Esse tipo de relacionamento indica que
objetos da classe específica podem ser utilizados em qualquer
lugar onde a classe geral ocorra. A classe específica, que pode
ser chamada de filha, herda todas as características da classe
geral, ou classe mãe. Isto é, a filha tem todos os atributos e
todos os métodos da classe geral. Ela pode ter também atributos
e métodos próprios, que não estão na classe mãe. Na UML
representa-se uma generalização com uma linha que aponta da
filha para a mãe.
3- ASSOCIAÇÃO
Uma associação representa uma relação entre classes e dá a
semântica e a estrutura comum para vários tipos de "ligações"
entre os objetos.
As associações são o mecanismo que permite aos objetos
comunicarem uns com os outros. Descrevem a ligação entre as
diferentes classes (a ligação entre os objetos em si é chamada
de ligação do objeto).
As associações podem ter um papel que indica o objetivo da
associação e pode ser unidirecionais ou bidirecionais (indica se
os dois objetos que participam na relação poderão enviar
mensagens um para o outro, ou se só um deles é que conhece o
outro). Cada extremo da associação também tem um valor de
multiplicidade, que define quantos objetos desse lado da
associação poderão se relacionar com um objeto do outro lado.
No UML, as associações são representadas como linhas que

ligam as classes que participam na relação e poderá também
mostrar o papel e a multiplicidade de cada um dos participantes.
A multiplicidade é mostrada como um intervalo [mín..máx] de
valores não-negativos ou com um asterisco (*) no lado do
máximo que representa o infinito.
- 3- ASSOCIAÇÃO – AGREGAÇÃO
As agregações são um tipo especial de associações nas quais as
duas classes participantes não têm um estado igual, mas têm
uma relação "do 'todo' para as partes". Uma agregação diz
como é que a classe que tem o papel do 'todo' é composta (ou
tem) as outras classes, que tem o papel das partes. Para as
agregações, a classe que atua como o 'todo' tem sempre uma
multiplicidade de um.
No UML, as agregações são representadas por uma associação
com um losango do lado do 'todo'.
- 3- ASSOCIAÇÃO – Composição
As composições são associações que representam agregações
muito fortes. Isto significa que as composições formam também
relações do 'todo' para as partes, mas a relação é tão forte que
as partes não podem existir por si só. Elas só existem dentro do
todo e se o todo for destruído, as partes desaparecem também.
No UML, as Composições são representadas por um losango a
cheio do lado do 'todo'.
- REFERÊNCIAS:
- http://www.purainfo.com.br/
- http://www.devmedia.com.br/
- http://cafeinacodificada.com.br/
- http://www.dsc.ufcg.edu.br/

1 - Aula - Uml

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1 - Aula - Uml

Enviado por

Direitos autorais:

Formatos disponíveis

ANÁLISE ORINETADA A OBJETOS

- METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE

Entende-se por metodologia, como a maneira – forma – de se

É objetivo de uma metodologia definir de forma clara “quem”

Com isso, o uso de uma metodologia possibilita:

Uma metodologia não deve limitar a criatividade profissional,

* MÉTODO: é abordagem técnica passo a passo para realizar

O conceito de Engenharia de Software surgiu como uma forma

Com o surgimento da Programação Orientada a Objetos, surgiu

Em 1996, os três amigos (como eram conhecidos) lançaram uma

(*)Object Management Group, ou OMG, é uma organização

- UML - UNIFIED MODELING LANGUAGE (LINGUAGEM

- UML - UNIFIED MODELING LANGUAGE (LINGUAGEM

A modelagem proporcionada pela UML permite simplificar o

A Linguagem de modelagem unificada (UML) foi criada para

A UML não é uma linguagem de programação, mas existem

UML é uma linguagem para visualização, especificação,

* Vermelho: estático (ou estrutural);

Um diagrama instanciado é uma visão parcial de um sistema, sob

- ATUALIZAÇÕES EM UML 2.0

- Maior integração entre modelos estruturais e

A UML está na versão 2.5 (lançada em 2015). Conforme a OMG,

Pacote é um mecanismo de agrupamento, onde todos os

Pacotes podem importar modelos de elementos de outros

- DIAGRAMAS DE CASOS DE USO

O Diagrama de Casos de Uso é um modelo gráfico que agrupa

Um caso de uso é uma lista de passos que definem a interação

Estes relacionamentos podem ser:

Casos de uso podem opcionalmente estar envolvidos por um

- Entre Atores: Generalização

- Entre Casos de Uso

- Entre Casos de Uso

- Entre casos de uso: Generalização

Os Diagramas de Classes mostram as diferentes classes que

- Diagramas de Classe podem conter diversos outros itens além

* Exemplo de Diagrama de Classes

Na UML, os Atributos são mostrados como tendo o seu nome,

A seguir, uma representação de uma classe com seus atributos

Além de atributos as classes têm métodos. Um método é uma

- RELACIONAMENTO NAS CLASSES

No UML, as associações são representadas como linhas que

Você também pode gostar