PRS – PROGRAMAÇÃO DE SISTEMAS

ENG. RUBEN BAQUI

HUAMBO/2022
CONCEITOS DE OO (ORIENTAÇÃO A OBJECTO)

É o facto de podemos abstrair de uma maneira mais fidedigna as

situações do dia a dia. Para alcançarmos esta facilidade precisamos
mudar a forma de pensar sobre sistemas.

Esta abstracção é feita por representação do mundo real , chamadas

de objecto. Só precisamos voltar a praticar o conhecimento que
possuímos desde a nossa infância: identificar os objectos e seus
comportamentos, o que possibilita que eles sejam caracterizados.
PRINCIPAIS LINGUAGENS ORIENTADAS A OBJECTOS

• Eiffel
• C++
• Objective-c
• Object Pascal
• Java
OBJETO
Na concepção de objecto de sistemas, um
objecto é qualquer coisa existente no mundo
real, em formato concreto ou abstracto, ou seja
que exista fisicamente ou apenas
conceitualmente.
CLASSES

Uma classe é a representação de um conjunto

de objectos que compartilham a mesma
estrutura de atributos, operações e
relacionamentos, dentro de um mesmo
contexto.
HERANÇA
Consiste em criamos uma classe mais genérica,
chamada de classe-pai ou superclasse, contendo
atributos que servem a qualquer situação. A partir dessa
classe criamos uma outra mais especifica chamada de
classe- filha ou subclasse. Esta classe contem somente
atributos a ela pertencente. Estamos diante dos
conceitos de generalização e especificação.
 TIPOS DE METODOLOGIAS DE DESENVOLVIMENTO DE
SOFTWARE

• Scrum
• Agil
• Cascata
• Lean
• Xp
• Kamba
• Devops
• Rup
PARTE 1#: CONHECENDO A UML
A UML é uma linguagem de modelagem, não é um
método.

A UML é uma linguagem para especificação,

visualização, construção e documentação de artefactos de
sistemas de software.
PARTE 1#: CONHECENDO A UML

Booch , Rumbaugh e Jacobson escrevem: A UML proporciona

uma forma padrão para a preparação de planos de arquitectura
de projectos de sistemas, incluindo aspectos conceituais tais
como processos de negócios e funções do sistema, além de
itens concretos como as classes escritas em determinadas
linguagem de programação, esquemas de BD e componentes de
software reutilizáveis.
MODELANDO COM A UML

Para modelarmos sistemas com a UML,

trabalhamos com: Elementos básicos do
modelo, Relacionamentos, Diagramas e
Regras de formação.
Elementos Básicos do Modelo

Podemos citar como os elementos básicos para

utilização na modelagem de qualquer sistema (em
ordem alfabética):
• Ações
• Artefatos
• Atividades
• Caso de Uso
Elementos Básicos Do Modelo

• Classe
• Classes Activas
• Colaboração
• Componentes
• Estado
Elementos Básicos Do Modelo
• Interacção
• Interface
• Nó
• Nota
• Pacote
• Partes
• Portas
RELACIONAMENTO
Realizam a ligação, entre si, dos elementos do modelo. São eles:
Dependência, associação, generalização.

• Dependência – É um relacionamento entre dois elementos de

modelagem que indica que a mudança em um elemento afetará o
outro.

• Associação – É um relacionamento entre dois ou mais

classificadores que envolvem conexões entre suas instancias.
RELACIONAMENTO

Generalização – É um
relacionamento entre um elemento
mais genérico e outro mais
especifico.
 DIAGRAMAS
A UML define em sua versão 2.0 treze tipos de diagramas, divididos em duas
categorias: Diagrama estruturais ou estáticos e Diagramas comportamentais ou
dinâmicos.

Já na versão 2.2 foi acrescentado mais um diagrama, o Diagrama de Perfil.

• Diagramas Estruturais:
• Diagrama de Classe
• Diagrama de Objetos
• Diagrama de Componentes
• Diagrama de Pacotes
• Diagrama de Implantação
• Diagrama de Estrutura Composta
 DIAGRAMAS
Diagramas Comportamentais:

• Diagrama de Casos de Uso

• Diagrama de Interação
– Diagrama de Visão Geral
– Diagrama de Sequencias
– Diagrama Temporal
– Diagrama de Comunicação
• Diagrama de Atividades
• Diagrama de Máquina de Estados
DIAGRAMA DE CASO DE USO

A maior dificuldade em modelarmos um sistema não

está nos diagramas que temos de desenhar, no código
que devemos criar ou nas bases de dados que devemos
projetar. Na realidade está nos requisitos que devemos
gerenciar.
Levantamento de Requisitos

UML e a modelagem de caso de uso não interfere nas técnicas

usadas pelos desenvolvedores e para levantamento de
requisitos. Pelo contrario, o caso de uso torna-se o ”braço
direito” do desenvolvedor, auxiliando-o a validar os requisitos
extraídos junto ao usuário.
O QUE É O CASO DE USO?

Descreve uma sequencia de ações que representam um

cenário principal e cenário alternativos, com o objetivos
de demonstrar o comportamento de um sistema (ou parte
dele), através de interação com atores.
Relacionamento entre casos de uso e atores
• Para relacionamento de casos de uso, entre si, temos os tipos:
generalização, extensão e inclusão.

• Para relacionamento de atores, entre si, temos um único tipo que é o

relacionamento de generalização.

• Para um relacionamento entre atores e casos e uso temos apenas a

associação.
 Relacionamento entre casos de uso e atores
• Um relacionamento de Inclusão: é representado graficamente por uma seta
tracejada com a ponta aberta, que parte do caso de uso base e contém o estereótipo
”Include”.

• Um relacionamento de extensão é representado representada graficamente por uma

seta tracejada com a ponta aberta, que parte do caso de uso estendido e contém o
estereotipo “extend”.

• Generalização é representado graficamente pela seta de generalização, que

corresponde a uma linha sólida com uma única seta fechada, mas não preenchida
em uma das pontas. A seta parte do caso de uso mais especifico em direção ao mais
Modelando requisitos com casos de uso

Não existe uma ordem que determine quais

diagramas devem ser modelados primeiramente. A
ordem é determinada pela preferência do
desenvolvedor ou processo que esteja sendo usado.
Criando o diagrama de casos de uso

Utilizamos um diagrama de caso de uso para

expressar a fronteira do sistema, ou modelar os
requisitos do mesmo. Não é obrigatório a construção
de disgrama de caso de uso. Todavia, sua existência
permite uma visão geral dos relacionamentos entre
casos de uso entre casos de uso e atores.
Os diagramas de caso de uso podem conter
também notas, restrições e pacotes.

Um diagrama de casos de uso é representado por

um elipse contendo o seu nome. O nome pode ser
também colocado a baixo do elipse, que pode
conter ou não compartimentos referentes a
atributos, operações e pontos e extensão.
DIAGRAMA DE ATIVIDADE

Um diagrama de atividade na versão anterior da UML

era considerada um caso especial do diagrama de estado.
Na UML 2.0 o diagrama de atividade foi redesenhado
para usar uma semântica semelhante a um gráfico de
Petri, no lugar da maquina de estado.
Modelando Diagrama de Atividade

Para termos uma primeira ideia do que seja um

diagrama de atividades, vamos pensar como
modelaríamos atividades simples de nossa vida,
como Sair de casa.
 AÇÕES
• É uma unidade básica existente para a especificação de
um comportamento que venha a representar alguma
transformação ou processamento na modelgem de um
sistema.
• Um conjunto de ação é a modelagem de um passo
REPRESENTAÇÃO DAS AÇÕES

Uma ação é representada graficamente como um

retângulo de cantos arredondados. O nome da ação
ou outra descrição são colocadas dentro da figura.
Exemplo:
ATIVIDADES

Uma atividade é composta de

uma sequencia de ações ou
outras atividades.
FLUXO DE CONTROLE

Mostra o fluxo que conecta ações e atividades, ou

seja, mostra a sequencia de execução. Representa a
conclusão de uma atividade e inicialização da
próxima. Na versão anterior da UML era definido
como transição.
 NÓ DE DECISÃO

Permite que, a partir de condições de guarda,

sejam escolhidos entre mais de um fluxo de
saída. Utilizado para simular a construção de um
if-then-else.
NÓ DE INTERCALAÇÃO

A mesma representação gráfica de decisão é

utilizada para marcar o fim de fluxo disparados
por uma decisão. Esta representação é
identificada como uma intercalação.
NÓ DE BIFURCAÇÃO

A bifurcação separa um fluxo de entrada em vários

fluxos concorrentes, sendo que todos eles são disparados
ao mesmo tempo. A representação gráfica é feita através
de uma linha grossa (no formato de uma barra).
NÓ DE UNIÃO

A união é um nó que sincroniza múltiplos

fluxos concorrentes, ou seja, a união concatena
fluxos de regiões concorrentes em um único
fluxo simples.
FLUXO FINAL

Indica o nó final que termina um

fluxo. Utilizado para finalizar algum
fluxo, mais não todos.
NÓ FINAL

Indica o nó que para todos os fluxos

numa atividade. Similar ao estado
final do diagrama de máquina de
estado.
NÓ INICIAL

Indica o nó que para todos os fluxos

quando uma sequencia de atividades é
invocada. Similar ao estado inicial do
diagrama de máquina de estado.
DIAGRAMA DE CLASSE
INTRODUÇÃO
Após extrairmos dos requisitos os objectos da aplicação,
precisamos separar e classificar suas caracteristicas,
modelando, por conseguinte, as classes do sistema. Entretanto,
a essência de um sistema não esta apenas em suas classes, mas
principalmente nos seus relacionamentos. Já diz o ditado que,
“uma andorinha não faz verão”, portanto não conseguiremos
um sistema com classes isoladas.
Conceitos Gerais
Existem alguns conceitos que são de uso geral
dentro do diagrama de classes e fornecem
informações adicionais a diversos elementos
estruturais da UML como por exemplo:
Relacionamento, atributos operações, etc. Essas
informações constituem-se de detalhes preciosos
para o projecto do sistema.
Visibilidade
Identifica por quem uma propriedade (atributos ou operação)
pode ser utilizada.
Definimos a visibilidade de uma propriedade (atributos ou
operação) por palavras chaves, conforme descrito a seguir:
Publico: O elemento_A que pode ser tanto um atributo como
uma operação (classe na qual o atributos ou método foi
declarado).
Privado: O acesso é permitido somente aos métodos da própria
classe(classe na qual o atributos ou método foi declarado).
Visibilidade
Protegido: O acesso é permitido á própria classe
e as classes descendentes (herança). (classe na
qual o atributos ou método foi declarado).
Pacote: O acesso é permitido por todas as
entidades dentro do pacote que hospeda a classe.
(classe na qual o atributos ou método foi
declarado).
Multiplicidade
Indica uma faixa de cardinalidade permitida a um elemento, isto é, a
quantidade de instancias possíveis em um relacionamento.
Ex: Homem pode ser casado com nenhuma ou uma Mulher (0..1).
Homem é pai de nenhum ou várias crianças (0..*).

As multiplicidade mais comuns são:

0..1(valo opcional)
1 ou 1..1 (exatamente um)
0 ou 0..* (qualquer valor inteiro não-negativo)
1..* (qualquer valor inteiro positivo)
Criando Diagrama de Classe
O diagrama de classe é a estrela principal de um sistema
orientado a objecto. Nesse diagrama é possível modelar
detalhes e seus relacionamentos. Também são visíveis outros
elementos como interfaces e pacotes.

Diagrama de classes podem ser organizados dentro de

pacotes, assim como um pacote pode ser representado por um
ou mais diagramas de classes.
Criando Diagrama de Classe
Um diagrama de classe é representado por um
rectângulo subdividido em três compartimentos,
separados por linhas horizontais que nessa armazenam:
Nome da classe e outras propriedades
Lista e atributos
Lista de operações ou métodos
Criando Diagrama de Classe
Normas de estilos da UML determinam que:

Nome da classe seja centralidade e negritado

Para todas a linguagens que distinguem entre caracteres minúsculos
e maiúsculos, escrever as iniciais dos nomes das classes em
maiúsculas, inclusive as primeiras letras de nomes compostos.
Ex: AlunoUniversitário, PessoaFísica, Funcionário
Os atributos e operações devem ser escritos com formatação normal
e alinhados á esquerda.
Atributos e Operações
Ao definirmos atributos não informamos
apenas seu nome ou tipo de dados. Podemos
determinar, também, seu valor inicial,
visibilidade e outras características. A Única
informação obrigatória é o próprio nome do
atributo.
Relacionamento
As classes dentro do contexto da modelagem de um sistema,
na sua maioria, não trabalham sozinhas. Pelo contrario, elas
colaboram uma com as outras por meio de relacionamentos.

No diagrama de classe temos os relacionamentos de

associação, generalização, dependência e realização. Como
variação do relacionamento de associação, ainda é possível
modelar relacionamentos de agregação e composição.
Relacionamento
Associação: é um relacionamento que conecta duas (associação
binária) ou mais classes. Associação binária é representada
graficamente por uma linha sólida que liga uma classe a outra ou uma
classe a ela própria.
Generalização: generalização entre classes envolve elementos mais
genéricos e ouros mais específicos.
Dependência: indica que uma mudança na interface de uma delas
pode causar mudanças na outra. Ex: AgendaConsultas HorarioMedico
Realização: é uma abstração especializada de um relacionamento de
dependência.
DIAGRAMA DE INTERAÇÃO
Interação corresponde a um conjunto de mensagens
trocadas entre objetos, com o objetivo de alcançar um
determinado propósito, respeitando-se o contexto do
sistema.
Iteração corresponde as fases que se repetem, nas quais
a entrada de uma fase corresponde á saída da sua
antecessora. Em uma abordagem mais simples,
corresponde a um processo de repetição.
DIAGRAMA DE INTERAÇÃO
um diagrama de interação mostra por meio de uma
visão dinâmica do sistema. Pode representar um
sistema, subsistema, operação, classe ou cenário de
um caso de uso, sendo essa ultima representação a
mais frequente. Um diagrama de interação é
formado, basicamente, por objectos,
relacionamento e mensagens.
Os diagramas de interação se apresentam, na
versão 2.0 da UML, de quatro forma:

• Diagrama de Sequencia
• Diagrama de comunicação
• Diagrama de visão geral
• Diagrama temporal
Diagrama de Sequencia
Para melhor ilustrarmos, vamos imaginar
um precesso X qualquer de uma empresa,
na qual trabalham os funcionários
António, João e Carlos.
Representações Gráfica
A representação gráfica de um diagrama de sequencia é
baseado em duas dimensões. A primeira dimensão é
vertical e representa as mensagens trocadas no decorrer
de um tempo de vida (eixo Y). A segunda dimensão é
horizontal e representa os objectos participantes das
interações (eixo X). As mensagens correspondem a
chamada de serviço dos objetos, ou seja, as chamadas de
duas operações.
Objetos
A representação dos objetos em um diagrama de
sequencia é feita com um rectângulo alinhado do
topo do diagrama, partindo dele uma linha vertical
tracejada denominada linha de vida, que é
desenhada até o fim do diagrama. A linda de vida
representa a vida desde objeto dentro de um
determinado período de tempo.
Mensagens
As menagens são enviadas de um objeto ao outro,
por meio de setas que partem de uma linha de vida
para a outra. Essas setas são identificadas com o
nome da operação que esta sendo chamada. As
mensagens podem carregar a solicitação de um
processamento, a comunicação de uma evento ou
outras informações relevantes para o cumprimento
de responsabilidades.
Mensagens
A sequencia de mensagens podem ser
numeradas, mas o seu uso é desnecessário
nesse tipo de diagrama, a não ser que
esteja sendo feita a modelagem de fluxos
concorrentes.
Ativação
Ao alcançar o outro lado, a mensagem dá inicio á
Ativação, que corresponde ao período de tempo durante
o qual um determinado método deum objeto está sendo
executado. Essa ativação é mostrada graficamente como
um rectângulo fino, branco ou cinza, que tem sua parte
superior alinhada ao final da seta ativadora e se estende
até o fim do processamento, que pode ter uma
representação extra com uma mensagem de retorno.
Ativação
A Seta de mensagem, além do nome da operação,
também pode conter uma condição ou uma
expressa de iteração. Textos de identificação como
restrições de tempo, descrições de ações durante
ativação, entre outros, também podem ser
mostrados na margem esquerda do diagrama ou
perto dos elementos que eles identificam.
Iteração
Representa o envio da mesma
mesagem diversas vezes para o
objeto, sendo comum no trabalho de
coleções de objetos.
Auto-Chamada
No caso da chamada recursiva (um objeto
passa mensagem pra si próprio), o
segundo símbolo de ativação é desenhado
á direita do primeiro, dando a impressão
de que estão empilhado.
Mensagem de Retorno
Num fluxo de controle procedual, a mensagem de retorno pode
ser omitida, pois fica implícito que, ao final da ativação,
retorno ocorrerá, ou seja, assume-se que toda mensagem de
chamada faz par com uma menagem de retorno. Para fluxos
como mensagens de processamento paralelo, mensagens de
retorno devem ser mostradas explicitamente.
Na arrumação dos objetos, deve-se colocar como o primeiro
objeto exatamente aquele que dá inicio á interação.
 REFERENCIA BIBLIOGRAFICA
Melo, Ana Cristina. Desenvolvendo aplicações
com a UML 2.2: do conceitual á implementação.
3 ed. Rio de Janeiro, 2010.