Aula 04 UC Modelagem de Software 2020-2

UNIDADE CURRICULAR:
MODELAGEM DE
SOFTWARE
PROF. ANDRÉ LUIZ PERIN
AULA 04 - 2020
Modelagem de Software
Diagrama de Atividade
◦ Mostra o comportamento, ou seja o aspecto dinâmico de partes
do sistema
◦ Captura o comportamento de forma detalhada, focada em uma
parte do sistema.
◦ Gráfico do fluxo das atividades
◦ A sequência e como são encadeadas as atividades, incluindo as condicionais para que
as atividades acontecem se houver esta situação.
◦ Elementos
◦ Nó inicial
◦ Identifica o inicio do fluxo, é representado por um circulo totalmente preenchido
◦ Pode haver mais de um nó inicial
◦ Se houver opcionalmente pode-se usar o elemento de anotação para melhorar o
entendimento
Início do processo
◦ Elementos
◦ Ação
◦ É o elemento mais básico do diagrama de atividades, seu objetivo é representar a
transformação de dados por meio do processamento do sistema, ou mostrar algum
passo ou alguma rotina sendo executada
◦ É representada pela figura de um retângulo com os cantos arredondados contendo
em seu interior o nome da atividade, que deve começar por um verbo no infinitivo.
◦ Uma atividade pode ser formada por um conjunto de ações ou de outras atividades.
◦ Ações são coisas feitas pelo usuário ou respostas dadas pelo sistema
◦ Elementos
◦ Ação
Preencher Nota
fiscal
Imprimir Nota
Fiscal
Emitir etiqueta de
Identificação
◦ Elementos
◦ Fluxo de controle Preencher Nota
◦ Conecta as ações, mostra qual fiscal
ordem de execução e é disparado

pela conclusão da ação anterior
Imprimir Nota
◦ É representado por um segmento Fiscal
de reta contendo uma seta de
direção em uma das suas
extremidades que aponta Emitir etiqueta de
Identificação
para a próxima ação, ou seja, a
próxima atividade.
◦ Elementos
◦ Nó Final
Preencher Nota
◦ Determina um ponto de saída de fiscal
um processo.
◦ Representado por um circulo
preenchido dentro de um circulo Imprimir Nota
vazado. Fiscal
◦ Da mesma forma que o Nó Inicial,

também pode haver vários Nós
Finais em um diagrama de Emitir etiqueta de
Identificação
atividades, caso ocorra,
opcionalmente pode-se usar o
elemento de anotação para melhorar
o entendimento.
◦ Elementos
◦ Nó de Decisão
◦ Utilizado quando se representa uma escolha feita pelo usuário, ou um desvio de
fluxo feito pelo sistema mediante uma condição de guarda que foi atendida
◦ Representado pela figura de um diamante (losango).
◦ Apesar de ele só ter quatro cantos, não impede que mais que 4 fluxos possam
derivar dele.
◦ O Nó de decisão é semelhante ao comando muito utilizado em programação “IF
THEN ELSE”
◦ Elementos
◦ Nó de Decisão
◦ Exemplo
Procurar produto
Não Fora do
Filtrar por preço
encontrado orçamento
Comprar
◦ Elementos
◦ Nó de Bifurcação (barra de sincronização)
◦ Utilizado para mostrar que em um determinado ponto do fluxo de controle, há uma
transformação para dois ou mais fluxos de controle que ocorrem ao mesmo tempo,
ou seja concorrentes.
Emitir etiqueta
Enfileirar produtos Colar etiqueta Colocar na caixa

◦ Elementos
◦ Nó de União (Join)
◦ Utilizado para mostrar que dois ou mais fluxos de controle se tornam um único fluxo
de controle.
Emitir etiqueta
Enfileirar produtos Colar etiqueta Colocar na caixa
Emitir etiqueta
◦ Elementos
◦ Merge (fusão)
◦ Utiliza o mesmo símbolo do nó de decisão porem mostra outro significado, é
utilizado para mostrar que vários fluxos de controle chegaram, porem a saída do
fluxo de controle é única.
◦ Parecido com o Nó de União porem não existe sincronização de ações como
acontece com o Nó de União
◦ Elementos
◦ Merge (fusão)
Receber pedido Receber pedido Receber pedido

via site via balcão via e-mail
Faturar produto
◦ Elementos
◦ Subatividade
◦ Mostra que uma atividade possui dentro subatividades (subordinadas a atividade
que as possui), identificada por um ramo parecido com o um tridente).
◦ Útil para balancear o nível de detalhamento das atividades do diagrama.
◦ Elementos
◦ Subatividade
Checar a validade do
Preencher formulário
certificado
Assinar
Gerar arquivo PDF
digitalmente
Enviar formulário por e-mail Salvar arquivo PDF

◦ Elementos
◦ Raias
◦ Quando o fluxo possui interação com dois ou mais atores, sejam eles pessoas,
organizações, sistemas, etc.
◦ Utiliza-se Raias para identificar a participação destes atores, as Raias podem estar na
horizontal ou vertical
◦ Conectores
◦ Para fluxos extensos demostram que o fluxo continua em outro ponto.
◦ Sempre em pares de círculos que contem o mesmo numero dentro, indicando a
conexão.
◦ Exemplo: Loja física
◦ Diagrama de caso de uso
Loja física
UC001
Vender
Vendedor
Cliente UC002
Pagar
Caixa
◦ Fluxo principal
◦ O Cliente escolhe o produto na vitrine
◦ Solicita ao Vendedor que a mostre
◦ O Vendedor mostra o produto e propõe a venda
◦ Fluxo alternativo
◦ O Cliente não aceita comprar
◦ O fluxo termina
◦ O Cliente então aceita comprar e paga o produto
◦ O Caixa recebe o valor do cliente pelo produto comprado
◦ O vendedor entrega o produto
◦ O Cliente recebe o produto
◦ Diagrama de Atividades
Cliente Vendedor Caixa
Fim do Escolher produto Mostrar produto

fluxo
else
Vender produto
compra
confirmada
Pagar Receber pagamento
Receber produto Entregar produto

Projeto Orientado a Objetos
◦ Conceitos
◦ Como o nome indica, os principais "atores" no paradigma orientado a objetos são
chamados objetos.
◦ Cada objeto é uma instância de uma classe.
◦ Cada classe apresenta para o exterior mundo uma visão concisa e consistente dos
objetos que são instâncias desta classe, sem entrar em detalhes desnecessários ou dar
aos outros acesso ao interior funcionamento dos objetos.
◦ Conceitos
◦ A definição de classe especifica os campos de dados, também conhecido como
variáveis de instância (atributos), que um objeto contém, assim como métodos
(operações) que um objeto pode executar.
◦ Essa visão da computação cumpre vários objetivos e incorpora princípios de design
◦ Objetivos
◦ Robustez
◦ Adaptabilidade
◦ Reuso (Reutilização)
◦ Objetivos
◦ Robustez
◦ Todo bom programador quer desenvolver software correto, o que significa que um
programa produz a saída certa para todas as entradas previstas na aplicação do
programa.
◦ Além disso, queremos que o software seja robusto, isto é, capaz de manipular
entradas inesperadas que não sejam explicitamente definidas para sua aplicação.
◦ Por exemplo, se um programa estiver esperando um número inteiro positivo (talvez
representando o preço de um item) e, em vez disso, receber um número inteiro
negativo, o programa poderá recuperar-se normalmente desse erro.
◦ Objetivos
◦ Robustez
◦ Mais importante ainda, em aplicações críticas, onde o software não pode causar
ferimentos ou perda de vidas, o software que não é robusto pode ser fatal.
◦ Objetivos
◦ Adaptabilidade
◦ Aplicativos de software modernos, como navegadores da Web e mecanismos de
pesquisa da Internet, geralmente envolvem programas grandes que são usados por
muitos anos.
◦ O software, portanto, precisa ser capaz de evoluir com o tempo, em resposta às
mudanças de condições em seu ambiente.
◦ Objetivos
◦ Adaptabilidade
◦ Assim, outro objetivo importante do software de qualidade é que ele atinja a
capacidade de adaptação.
◦ Relacionado a este conceito está a portabilidade, que é a capacidade do software
rodar com mudanças mínimas em diferentes plataformas de hardware e sistemas
operacionais. Uma vantagem de escrever software em Java é a portabilidade
fornecida pela própria linguagem.
◦ Objetivos
◦ Reutilização
◦ Acompanhar a adaptabilidade é o desejo de que o software seja reutilizável, ou seja,
o mesmo código deve ser usado como componente de diferentes sistemas em várias
aplicações.
◦ O desenvolvimento de software de qualidade pode ser uma empresa dispendiosa, e
seu custo pode ser um pouco desviado se o software for projetado de forma a torná-
lo facilmente reutilizável em aplicativos futuros.
◦ Princípios
◦ Entre os princípios da abordagem orientada a objetos, que visam facilitar os objetivos
já descritos, estão os seguintes:
◦ Abstração
◦ Encapsulamento
◦ Modularidade
◦ Princípios
◦ Abstração
◦ A noção de abstração é destilar um sistema complicado até as partes mais
fundamentais.
◦ Normalmente, descrever as partes de um sistema envolve dar nome a elas e explicar
sua funcionalidade. Aplicando o paradigma de abstração para o design de estruturas
de dados dá origem a tipos de abstratos dados (TADs).
◦ Princípios
◦ Abstração
◦ Um TAD (Tipo Abstrato de Dados) é um modelo matemático de uma estrutura de
dados que especifica o tipo de dados armazenados, as operações suportadas neles e
os tipos de parâmetros das operações. Um TAD especifica o que cada operação faz,
mas não como ela é executada.
◦ Um TAD é realizado por uma estrutura de dados concreta, que é modelada em Java
por uma classe. Uma classe define os dados que estão sendo armazenados e as
operações suportadas pelos objetos que são instâncias da classe.
◦ Princípios
◦ Encapsulamento
◦ Outro princípio importante do design orientado a objetos é o encapsulamento.
◦ Diferentes componentes de um sistema de software não devem revelar os detalhes
internos de suas respectivas implementações.
◦ Uma das principais vantagens do encapsulamento é que ele oferece a liberdade de
um programa para implementar os detalhes de um componente, sem preocupação
de que outros programadores estejam escrevendo códigos que dependem
intricadamente dessas decisões internas
◦ Princípios
◦ Encapsulamento
◦ Uma das principais vantagens do encapsulamento é que ele oferece a liberdade de
um programa para implementar os detalhes de um componente, sem preocupação
de que outros programadores estejam escrevendo códigos que dependem
intricadamente dessas decisões internas.
◦ A única restrição no programador de um componente é manter a interface pública
para o componente, pois outros programadores escreverão código que depende
dessa interface.
◦ Princípios
◦ Encapsulamento
◦ O encapsulamento produz robustez e adaptabilidade, pois permite que os detalhes
de implementação de partes de um programa sejam alterados sem afetar
negativamente outras partes, facilitando a correção de bugs ou a adição de novas
funcionalidades com alterações relativamente locais em um componente.
◦ Princípios
◦ Modularidade
◦ Sistemas de software modernos normalmente consistem em vários componentes
diferentes que devem interagir corretamente para que todo o sistema funcione
corretamente. Manter essas interações simples requer que esses diferentes
componentes estejam bem organizados.
◦ Modularidade refere-se a um princípio organizador no qual diferentes componentes
de um sistema de software são divididos em unidades funcionais separadas. A
robustez aumenta muito porque é mais fácil testar e depurar componentes
separados antes que eles sejam integrados em um sistema de software maior.
Classes
◦ É um tipo de abstração da UML cujas principais características
são:
◦ Atributos (propriedades)
◦ Operações (métodos)
Classes
◦ Atributos
◦ São propriedades pertencentes à classe.
◦ Alguns desses atributos podem representar os fins das associações binárias.
◦ Operações
◦ Podem ser invocadas em um objeto, dado um conjunto particular de valores para os
parâmetros da Operação.
◦ Uma Classe não pode acessar Recursos particulares de outra Classe ou Recursos
protegidos em outra Classe que não seja seu antecessor.
Classes
◦ Objetos
◦ Devem conter valores para cada atributo que pertence a essa classe, de acordo com as
características do atributo, por exemplo, seu tipo e multiplicidade.
◦ Quando um objeto é instanciado em uma classe, para cada atributo da classe que
possui um padrão especificado, se um valor inicial do atributo não for especificado
explicitamente para a instanciação, o valor padrão será usado para definir o valor
inicial do atributo para o objeto.
Classes
◦ Níveis de Visibilidade entre objetos de Classes
◦ Publico
◦ Qualquer objeto de qualquer classe tem acesso, é representando por +
◦ Protegido
◦ Somente objetos de classes descendentes por herança tem acesso, é representando
por #
◦ Privado
◦ Somente objetos da própria Classe tem acesso, é representando -
◦ Pacote
◦ Somente objetos do mesmo pacote tem acesso, é representando ~
Modelagem de Software mostra a opção de
agrupamento de visibilidade
Classes
aplicada aos compartimentos
detalhes como valores padrão, de atributos e operações na
parâmetros e marcações de janela de classes.
◦ Notação visibilidade bem como os
cabeçalhos dos compartimentos
opcionais Window
todos os compartimentos
attributes
suprimidos
Window public
size: Area = (100, 100)
attributes
Window +size: Area = (100, 100)
defaultSize: Rectangle
protected
#visibility: Boolean = true visibility: Boolean = true
Window private
xWin: XWindow
size: Area
operations
visibility: Boolean
operations public
display() display()
display()
hide() hide()
hide()
-attachX(xWin: Xwindow) private
attachX(xWin: Xwindow)
atributos e operações, cada

um listando os recursos,
mas suprimindo detalhes
Diagrama de Classes
◦ Mostra um conjunto de classes e as interações entre elas
◦ Exemplo:
Produto LocalArmazenagem
- código - código
- nome - area_Util
- valor - status_Alocacao
- dataValidade
+ informaValor + informaQuantidade
+ informaValidade Armazenado + informaData_in
+ informaNome + informaData_out
0..1 0..*
Relacionamento
◦ Conceito
◦ Uma classe se relaciona a outras classes, porque suas instancias (objetos) interagem
uns com os outros
◦ Principais tipos de relacionamento na UML:
◦ Herança (Generalização/Especialização)
◦ Associação
◦ Dependência
Relacionamento
◦ Herança
◦ Uma maneira natural de organizar vários componentes estruturais de um pacote de
software é de forma hierárquica, com definições abstratas semelhantes agrupadas em
uma maneira de nível para nível que vai de específico a mais geral à medida que se
percorre a hierarquia.
◦ Utiliza o conceito de Generalização/Especialização
◦ É quando uma classe deriva de outra, herdando características fundamentais, mas por
sua vez, adiciona outras novas características, estas características podem ser novos
métodos e atributos, ou mesmo somente atributos novos com modificação de
métodos existentes.
Relacionamento
◦ Herança
◦ A classe existente é tipicamente descrita como a classe base, classe pai ou superclasse,
enquanto a classe recém-definida é conhecida como subclasse ou classe filha.
◦ A subclasse estende a superclasse.
◦ A subclasse herda automaticamente, em princípio, todos os métodos da superclasse
(exceto construtores).
◦ A subclasse pode se diferenciar de sua superclasse de duas maneiras:
◦ Pode aumentar a superclasse adicionando novos campos e novos métodos.
◦ Pode, também, pode especializar os comportamentos existentes, fornecendo uma
nova implementação que substitui um método existente.
Relacionamento
◦ Herança
Construcao
Edificio Casa Comercial
Baixo Alto Sobrado Terrea Arranha-ceu

Relacionamento
◦ Associação
◦ Descreve a estrutura de vinculo entre classes, aonde os respectivos objetos destas
classes possuem interação
◦ Quanto ao numero de classes envolvidas pode ser:
◦ Unária (reflexiva)
◦ Binária
◦ Múltipla
◦ Tipos especiais:
◦ Agregação
◦ Composição
Relacionamento
◦ Associação
◦ Unária (reflexiva)
◦ A classe se relaciona associando-se com ela mesma
Pessoa
- cpf
- nome 0..*
+ informaNome Filiação
+ informaCpf 2
+ alteraIncluiNome
+ alteraIncluiCpf
Relacionamento
◦ Associação
◦ Binária
◦ A classe se relaciona associando-se com outra classe
Pessoa Departamento
- cpf - codigo
- nome Alocação - nome
- codDepartamento
0..* 1
+ informaNome + informaNome
+ informaCpf + informaCodigo
+ alteraIncluiNome + alteraIncluiNome
+ alteraIncluiCpf + alteraIncluiCodigo
+ associaDepart
Relacionamento
◦ Associação
◦ Múltipla
◦ Várias classes compartilham a mesma associação
Professor Turma
- matricula Leciona Possui - numeroIdentifcacao
- nome 1..* 1..*
+ informaNome 1..* Utiliza + informaIdentific
+ informaMatricula + alteraIncluiIdentific
+ alteraIncluiNome SalaDeAula
+ AlteraIncluiMatricula - numeroSala
- predio
+ informaPredio
+ informaNumero
+ alteraIncluiPredio
+ alteraIncluiNumero
Relacionamento
◦ Associação
◦ Agregação
◦ Chamada também de “todo-parte”.
◦ Quando duas classes se associam e uma delas é a parte da outra, e a outra é a
agregadora.
◦ O tempo de vida do objeto criado na classe ”parte” não depende do tempo de vida
do objeto “todo”.
◦ A Classe ”parte” esta agregada mas não depende da classe ”todo” para existir.
Relacionamento
◦ Associação
◦ Agregação
◦ A classe se relaciona associando-se à outra por agregação, tornando-se parte, mas
ainda pode existir sem a outra classe
EdicaoRevista ArtigoCientifico
- numero Contém - titulo
- data - autores
6..10 - data
+ criaRevista
+ publicaRevista + criaArtigo
+ forneceArtigo
Relacionamento
◦ Associação
◦ Composição
◦ Chamamos também de “todo-parte”
◦ Quando duas classes se associam e uma delas é a parte da outra, formando uma
composição.
◦ O tempo de vida do objeto criado na classe ”parte” depende do tempo de vida do
objeto “todo”.
◦ A Classe ”parte” é de fato uma composição e depende da classe ”todo” para existir.
Relacionamento
◦ Associação
◦ Composição
Pedido itemPedido
- numero Composto de - linha
- data - quantidade
1..*
+ criaPedido + criaItem
+ alteraPedido + alteraItem
Relacionamento
◦ Dependência
◦ Quando duas classes se relacionam e uma delas se sofrer alteração poderá por
consequência provocar mudança na outra classe.
◦ Chamamos de classe fornecedor a classe que é independente, e de cliente a classe
que por consequência poderá ser alterada
Relacionamento
◦ Dependência
Embalagem Produto
- codigo
- codigo
- descricao
- dimensoes
- dimensoes
+ informaDimensoes + informaCodigo
+ registraDimensoes + incluiAlteraCodigo
+ informaDescricao
+ incluiAlteraDescricao
+ informaDimensoes
+ registraDimensoes
Multiplicidade
◦ Multiplicidade ou Cardinalidade
◦ Determina quanto objetos de cada classe (instâncias) podem ser
conectados em uma ocorrência da associação.
◦ É escrita como uma expressão de valores mínimo e máximo, que
podem ser iguais, e utilizamos dois pontos horizontalmente
dispostos para separar os valores mínimo e máximo.
Multiplicidade
◦ Valores possíveis:
◦ Um mínimo e um máximo
◦ 1..1
◦1
◦ Zero ou um
◦ 0..1
◦ Zero ou muitos
◦ 0..*
◦*
◦ Um ou mais
◦ 1..*
◦ Ou determinar valores exatos
◦ 2..5
◦ 2 (neste caso o mínimo e máximo é igual a 2)
Navegação
◦ Consegue-se identificar direta e facilmente o objeto da outra
classe a qual esteja associado.
◦ A navegação é bidirecional a menos que esteja explicita com a
seta.
◦ Utiliza-se uma seta aberta para indicar a direção da navegação.
◦ Lembrando:
◦ A seta fechada é utilizada para a Generalização/Especialização (herança).
Navegação
◦ A seta aberta na extremidade da associação indica a direção da
navegação
Pessoa Departamento
- cpf - codigo
- nome Alocação - nome
- codDepartamento
0..* 1
+ informaCpf + informaCodigo
+ alteraIncluiCpf + alteraIncluiCodigo
+ associaDepart
Classes de Associação
◦ As classes de associação são necessárias quando há atributos
relacionados à associação e que não podem ser armazenados em
nenhuma das classes envolvidas
◦ Outra característica é que há multiplicidade muitos (*) em todas
as extremidades da associação, mas nem sempre toda associação
com multiplicidade nas suas extremidades necessitará de uma
classe de associação.
Classes de Associação
Aluno Turma
- nome Leciona Possui - nome
* 1..*
Matricula
- numeroMatricula
- dataMatricula
+ informaMatricula
+ AlteraIncluiMatricula
+ informaData
+ alteraIncluiData

Aula 04 UC Modelagem de Software 2020-2

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

Aula 04 UC Modelagem de Software 2020-2

Enviado por

Direitos autorais:

Formatos disponíveis

UNIDADE CURRICULAR:

ordem de execução e é disparado

◦ Da mesma forma que o Nó Inicial,

Enfileirar produtos Colar etiqueta Colocar na caixa

Enfileirar produtos Colar etiqueta Colocar na caixa

Receber pedido Receber pedido Receber pedido

Enviar formulário por e-mail Salvar arquivo PDF

Fim do Escolher produto Mostrar produto

Pagar Receber pagamento

Receber produto Entregar produto

atributos e operações, cada

Edificio Casa Comercial

Baixo Alto Sobrado Terrea Arranha-ceu

Você também pode gostar