MODELAGEM DE SISTEMAS - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.14259131932123.pdf · Modelagem de Sistemas Orientação a Objetos A Orientação a Objetos (OO)

MODELAGEM DE SISTEMAS Da Orientação a Objetos à UML

UHLMANN, Erwin A. Título do trabalho. Instituto Siegen. Guarulhos, 2015

Prof. Erwin Alexander Uhlmann - www.institutosiegen.com.br - Guarulhos, 2015 � de �1 24

http://www.institutosiegen.com.br

Agradecimentos

Agradeço à minha esposa Kátia por entender minha ausência, meu filho Henrique que me motiva trabalhar (!!!), meus pais Mirtes e Günter por terem criado meu caminho, aos meus alunos que viabilizaram este trabalho e a todos os autores de livros e bibliotecas que consultei para que pudesse devidamente embasar este.



Sumário



Modelagem de Sistemas Orientação a Objetos A Orientação a Objetos (OO) é um paradigma de programação concebido para o

reaproveitamento de códigos em um mesmo software ou em outros externos.

A OO se vale de conceitos do mundo real para facilitar a programação, melhorar a

qualidade do software, aumentar a produtividade e facilitar a manutenção, ou seja, a

manutenabilidade e a documentação.

Um objeto é uma entidade que possui uma identificação própria. Este é um conceito

importante, pois cada objeto deve ser único e identificável. Os objetos podem

compartilhar aspectos semelhantes, comportamentos idênticos e até os mesmos

atributos. Quando objetos apresentam os mesmos atributos e comportamentos, eles são

agrupados em classes. As classes então possuem objetos, chamados de instâncias e

elas é que são as chamadas para ativarem os objetos. Vamos ver os exemplos:

Objeto Um Objeto é como no mundo real algo tátil(exceto por isto!), que possui determinadas

características (Atributos ou Propriedades) e tem alguma utilidade (Método, Operação

ou Comportamento) e pertencem a algo ou alguém (Visibilidade[Público, Protegido,

Privado ou Pacote]).

Para construir no plantUML:

@startuml object computador @enduml

Atributos ou Propriedades

Os atributos de um Objeto possuem dois tipos de dados: Nome e tipo de dados.

O Nome, de forma geral, remete ao que o Atributo contém, como no Objeto Casa, o

Atributo Cômodo remete à um cômodo da casa e o Tipo de dado, também de forma

geral, é relacionado o que deve conter, como o numero (integer) de cômodos ou o

nome (character) deles.



No plantUML:

@startuml object computador 'o atributo é marcado pelo[] computador: atributo[] @enduml

Podem haver vários atributos, como:

E no plantUML:

@startuml object computador computador: processador[] computador: memoriaRam[] computador: discoRigido[] computador: dispositivoDeEntrada[] computador:dispositivosDeSaida[] @enduml

Métodos, Operações ou Comportamentos

As Operações são as determinações de ação de um Objeto. Elas obedecem os

parâmetros determinados em programação e estes parâmetros atendem os valores. Um

parâmetro típico é o “H” de hora da função date. O valor é recebido pelo sistema.

Outro exemplo de parâmetro é “$_POST[]” que recebe os dados escritos num

formulário. O valor é o que é digitado pelo usuário. Uma Operação então é o

descritor das atividades de um objeto.

@startuml 'object computador computador : processador[] computador : memoriaRam[] computador : discoRigido[] computador : dispositivoDeEntrada[] computador : dispositivosDeSaida[] computador : realizaCalculos() @enduml



Visibilidade

Podem ser quatro estados: Público, Protegido, Privado ou Pacote.

@startuml comput : (-) privado[] comput : (+) público[] comput : (#) protegida() comput : (˜) pacote() @enduml

Público

Qualquer objeto pode utilizar um Atributo público. É representado pelo símbolo “+”.

Uma Operação ou Atributo público de exemplo são os dispositivos de entrada e saída

de um computador, pois qualquer computador da rede

pode utilizá-los.

@startuml computador : processador[] computador : memoriaRam[] computador : discoRigido[] computador : + dispositivoDeEntrada[] computador : + dispositivosDeSaida[] computador : realizaCalculos() @enduml

Privado

São os Atributos ou Métodos que podem ser utilizados somente pelo Objeto pai. É

representado pelo símbolo “-“, como a memória RAM, o HD ou o processador.

@startuml computador : - processador[] computador : - memoriaRam[] computador : - discoRigido[] computador : + dispositivoDeEntrada[] computador : + dispositivosDeSaida[] computador : realizaCalculos() @enduml

Protegida

É representada pelo símbolo “#” e pode ser visualizada pela classe pai e as subclasses.

As classes relacionada não visualizam. Um exemplo é o método ou operação do objeto



computador. Seus dados podem ser visualizados por

todos os componentes, mas somente por eles, por outro

objeto não.

@startuml computador : - processador[] computador : - memoriaRam[] computador : - discoRigido[] computador : + dispositivoDeEntrada[] computador : + dispositivosDeSaida[] computador : # realizaCalculos() @enduml

Pacote

Representado pelo “˜”, o o pacote pode ser visualizado pelos que pertencerem a ele,

ou seja, os objetos que pertençam ao pacote podem visualizar. O monitor e o teclado

não foram retratados aqui, mas fazem parte do pacote em que o computador está

inserido.

@startuml teclado : ~exibeDados() @enduml

Herança

A Herança é um dos mais importantes conceitos da Orientação a Objetos. Ela garante

que os Atributos e Operações do Objeto pai ou Superobjeto sejam aproveitados em

código pelos objetos filhos ou subobjetos. Um o exemplo de herança é um sistema de

login e senha. A busca do login que pode ser o e-mail e a senha. O e-mail pode ser

público e a senha protegida, logo privada. No entanto outros objetos protegidos

podem prec i sar do e -mai l ,

herdando sua validação, não

apenas o dado.

@startuml sistLogin : + email[] sistLogin : #senha[] sistLog : email[] sistLog : + dataEHora[] sistLog : armazenarDadosLog() sistInsDados : ~ email[] sistInsDados : gravarDados() sistLogin <|-- sistLog sistLogin <|-- sistInsDados @enduml



Herança Múltipla

Assim como a Herança simples, a múltipla recebe ou herda dados de mais de um

objeto. Como é possível notar, o Atributo dataEHora do Objeto sistLog é público e o

A t r i bu t o ema i l do Ob j e t o

sistInsDados é privado a todos

que pertençam ao pacote, logo

um novo Objeto herdará estes

atributos.

@startuml sistLogin : + email[] sistLogin : #senha[]

sistLog : email[] sistLog : + dataEHora[] sistLog : armazenarDadosLog()

sistInsDados : ~ email[] sistInsDados : gravarDados()

relatorios : email[] relatorios : dataEHora[] relatorios : imprimirRelatorios()

sistLogin <|-- sistLog sistLogin <|-- sistInsDados sistLog <|-- relatorios sistInsDados <|-- relatorios @enduml

Polimorfismo

Polimorfismo é um método de reutilizar um objeto em outro objeto especializando-o, ou

seja, se em um objeto que realiza determinada Operação é necessário em outro objeto

porém com alguma especialização, isto constitui o polimorfismo. Ex.: Imagine um

código que exiba números em ordem decrescente. Em outro ponto do software

(pacote), você precisa exibir os três primeiros ou os três últimos colocados. Para quê

reprogramar? Herde o métodos e decida como utilizá-los.

Outro caso: Em um banco cliente é um objeto. Todos os clientes obedecem a uma regra

básica: Quanto e quando depositou, quanto e quando retirou. Só isto já é difícil de

controlar! Imagine quando você altera o status de um destes clientes, mas não de



todos(-), para cliente especial, com crédito, ou seja, cheque especial. Quanto a mais

pode retirar e quanto e quando vai pagar?

@startuml sistLogin : + email[] sistLogin : #senha[] sistLog : email[] sistLog : + dataEHora[] sistLog : armazenarDadosLog() sistInsDados : ~ email[] sistInsDados : gravarDados() sistLogin <|-- sistLog sistLogin <|-- sistInsDados @enduml

Programação Orientada a Objeto Na programação, o Objeto é representado nesta linguagem pela function e seu nome é

hora. Ignore a linguagem. O resultado é a exibição da hora atual, este é seu atributo.

function hora(){ $hora = date('H:i:s'); echo $hora; }

Se imaginarmos o seguinte novo objeto:

function data(){ $data = date('d/m/Y'); echo $data; }

Os objetos hora e data possuem o mesmo comportamento: Exibir uma informação,

especificamente informações sobre data e hora, então eles podem pertencer à mesma

classe, a classe tempo.

class Tempo{ function hora(){ $hora = date(‘H:i:s’); echo $hora; } function data(){ $data = date(‘d/m/Y’);



echo $data; } }

A classe Tempo possui duas instâncias, hora e data, e para chamar seu resultado, ou

dispará-lo, por assim dizer, é preciso instanciá-lo. Mais uma vez ignore a linguagem.

$instancia = new Tempo; $instancia -> hora();

Todas vez que seu programa precisar exibir a hora atual, basta instanciar o objeto

hora(). Isto reduz o número de linhas de programação e pode-se aproveitar este

código em outros softwares. Outra vantagem da Orientação a Objetos é o

Polimorfismo, ou seja, o programa se comporta conforme o ambiente. Como ignoramos

a linguagem, esta impressão de hora é estática, isto é, ocorre apenas uma vez, mas e

se chamarmos este objeto em um looping? A hora irá mudar a cada novo segundo!

O programa é o mesmo, mas o comportamento muda conforme o meio! Polimorfismo!

$instancia = new Tempo; $instancia -> hora(); for($i=$instancia+60;$i<$instancia;$i++){ $instancia; }

Herança é o comportamento da OO para os atributos de um objeto poderem ser

incorporados por um novo objeto, aproveitando um código já escrito, sendo assim, a

classe pai, envia os dados para a classe filho.

class Pai{ $valor = '1, 2, 3, 4, 5'; strrev($valor); } class Filho extends Pai{ $parteValor = substr($valor, 0, 4); echo $parteValor; }



Introdução à UML O projeto do software é um esquema visual que permite a criação do projeto antes de

sua execução ou programação. A Unified Modeling Language (UML), para Guedes

(2011) é uma linguagem visual utilizada para modelar softwares baseados no

paradigma da orientação a objetos. O autor explica ainda que a programação

orientada a objetos é um método de atribuir identidade a scripts que realizem funções

específicas e pertençam a uma parte maior de um software.

A UML é constituída de 14 diagramas com especificidades e representações para

diversas situações, como explica Guedes (2011).

Para criarmos os diagramas, vamos utilizar o NetBeans 8.0 (https://netbeans.org/),

com o plugin PLantUML (http://plugins.netbeans.org/plugin/49069/plantuml) e o

Graphviz(http://www.graphviz.org/) como gerador de imagens.

ArgoUML (http://argouml.tigris.org/)


http://plugins.netbeans.org/plugin/49069/plantuml

http://www.graphviz.org/

http://argouml.tigris.org/


Diagramas Diagrama de Casos de Uso O diagrama de Casos de Uso, comumente chamado de UC, por questões óbvias, é

normalmente o primeiro a ser desenvolvido. Isto por que ele permite a primeira visão

do sistema numa rápida conversa com o cliente e sua demonstração do uso, da

dinâmica do software, além disto ele serve como guia para o desenvolvimento deste e

é recorrentemente consultado e alterado para se adequar.

O Diagrama de Casos de Uso tem por objetivo apresentar a visão externa das

funcionalidades do sistema, isto é, a visão do usuário sobre o uso do sistema, sem se

preocupar com a implantação destas funções.

Para criar um Diagrama de Casos de Uso é preciso compô-lo de:

Scripts @startuml title Exemplos de Sintaxe de Casos de Uso

'direcionamento 'left to right direction 'top to bottom direction

(Caso de Uso) usecase (Caso de Uso Dois) as CUD :Ator 1: actor Ator2 actor :Outro Ator: as OA

'relação entre atores e casos de uso

:Ator 1: -- (Caso de Uso) 'Uma declarado como ator, chame somente o nome Ator2 -> CUD OA --> (Terceiro \nCaso de Uso) :Ator 4: ---> (Caso de Uso) : Uma mensagem simples

'extensão 'O Caso de Uso Dois leva ao Outro Ator OA <|-- CUD Ator2 --|> OA

'notas de projeto note right of :Ator 4: : Nota de projeto note "Nota em meio de caminho" as N2 CUD .. N2 N2 .. (Terceiro \nCaso de Uso)

'direções e ligações :AtorCentral: (CasoDeUso1)



(CasoDeUso2) (CasoDeUso3) (CasoDeUso4) :AtorCentral: -left- (CasoDeUso1) : associação :AtorCentral: -up-> (CasoDeUso2) : link ou encaminhamento :AtorCentral: .right.> (CasoDeUso3) : <<include>> inclusão :AtorCentral: <.down. (CasoDeUso4) : extensão <<extend>> @enduml

Atores Representa qualquer elemento externo que interaja com o sistema, podendo

ser um usuário, um hardware ou outro software.

@startuml :Ator: @enduml

Casos de Uso Os Casos de Uso servem para expressar o comportamento

primário ou secundário de um sistema. Quando primário ele

é associado às funções para o qual o software foi concebido

e o secundário para funções de manutenção, por exemplo.

Num sistema de cadastro de usuário, o cadastro é a função primária e a edição destes

dados é a função secundária.

@startuml (Caso de Uso) @enduml

Os atores acessam as funcionalidades de um sistema, desta forma eles representam

fracamente um descritivo destas funções, como segue:

@startuml :Usuário: --> (Cadastro de usuário) :Usuário: --> (Editar cadastro) @enduml



No plantUML, você pode definir o ator entre dois pontos ou especificá-lo como actor,

veja:

@startuml 'actor Ator 'ou :Ator: @enduml

O Caso de Uso possui, de forma geral, uma documentação que descreve de forma

sucinta a sequencia de ações do sistema.

Observe que no ator principal, o texto “além de todo conteúdo” foi tachado, pois não

pertence ao Caso de Uso UC 01 que descreve ações de acesso ao sistema.

A continuidade é o descritivo do fluxo de ações do sistema.

Nome do Caso de Uso Descrição

UC 01 Acesso ao sistema

Ator principal: Diretor Cadastra usuários, edita e exclui, além de todo conteúdo

Ator secundário: Gerente Cadastra usuários

Ator terciário: Funcionário Acessa o sistema

Ator quaternário: Usuário Não pode acessar

Nome do Caso de Uso Descrição

UC 01 Acesso ao sistema

1 - Ator solicita acesso por login e senha

2 - Sistema busca no Banco de Dados o login

3 - Caso o usuário seja encontrado, solicita a senha

4 - Caso a senha esteja correta, permite acesso, senão solicita o cadastro

5 - Abre a sessão



Associação é a relação criada entre atores e atores ou casos de uso e casos de uso dentro de um

diagrama. Exemplos:

@startuml :Cliente: -- (Cadastro de clientes) :Cliente: -- (Edita cadastro) :Suporte: -- (Edita cadastro) :Cliente: -- Suporte (Edita cadastro) -- (Cadastro de clientes) : Verifica existência \n do cadastro @enduml

Generalização ou Especialização O diagrama de Especialização

ou Generalização determina um

plano abstrato e o decompõe em

níveis mais baixos, veja:

@startuml (Usuário Diretor) -up-> (Usuário) (Usuário Gerente) -up-> (Usuário) (Usuário Funcionário) -up-> (Usuário) @enduml

Também se especifica as permissões, como segue:

@startuml :Diretor: -- (Cadastra, edita e exclui usuário) :Gerente: -- (Cadastra usuários) :Funcionário: -- (Acessa o sistema) @enduml



Include É utilizado quando uma função é recorrente em um sistema, assim um Caso de uso ou

ator pode chamar este processo e incluí-lo no sistema. De forma geral, o Include é

utilizado quando você deve consultar outro processo para concluir o primeiro, este

outro processo é o Include.

@startuml :Ator 1: --> (Acesso ao Sistema) (Acesso ao Sistema) ..> (Log do sistema) :Ator 2: --> (Excluir dados) (Excluir dados) ..> (Log do sistema) @enduml

O Include é representado pelo

tracejado.

Extend É indicado quando uma excessão é executada

ou uma condição específica, como um

cadastro que é feita apenas na primeira vez.

No extend, em oposição ao Include, a seta é

invertida. De maneira ampla, o Extend é

utilizado quando o processo primário não

pode concluir o serviço, então chama-se outro

extenso a ele, como uma condição.

@startuml :Usuário: --> (Acesso ao Sistema) (Acesso ao Sistema) ..> (Log do sistema)

note "Caso não tenha cadastro \n (Opicional)" as nota1

(Acesso ao Sistema) <.. nota1 nota1 .. (Cadastro de usuário) :Funcionário: --> (Excluir dados) (Excluir dados) ..> (Log do sistema)



note "Confirmação de motivo \n(Opcional)" as nota2

:Funcionário: <.. nota2 nota2 .. :Usuário: @enduml

Multiplicidade Um para muitos ou um para um. Um processo pode ser chamado n vezes por um ator

ou o inverso.

Estereótipos Para representar processos, utiliza-se os sinais << e >>, assim, o processo de validação

de acesso ao sistema, pode ser representado apenas como:

@startuml (<<Acesso>> \n Acesso ao sistema) @enduml

Exercício 1 Crie a UML de um sistema de login simples com validação de login e recriação e

validação de sessão (caso correto) e três páginas protegidas e uma de cadastro.

@startuml title Sistema de login simples left to right direction (Acesso ao Sistema) as AS (Valida Login) as VL (Cadastro) (Página Protegida 1) as PP1



(Página Protegida 2) as PP2 (Página Protegida 3) as PP3 (Valida Sessão) as VS (Menu de Acesso) as MA :master: -- AS :funcionário: -- AS AS --|> VL VL ..> (Cadastro) : <<extend>> VL --|> PP1 PP1 <.. VS : <<include>> PP1 <.. MA : <<include>> PP2 <.. VS : <<include>> PP2 <.. MA : <<include>> PP3 <.. VS : <<include>> PP3 <.. MA : <<include>> (Cadastro) <.. VS @enduml

Documentação de Casos de Uso Casos de Uso de Login Descritivo

UC 01

Ator Cliente 1 - Acessa o sistema

2 - Acessa cadastro de usuário

3 - edita dados próprios se cadastrado

4 - exclui-se do BD

Ator Master 1 - Acessa o sistema

2 - Acessa cadastro de usuário

3 - edita dados próprios se cadastrado

4 - exclui-se do BD

5 - Inclui novos usuários

6 - Exclui usuários

7 - Edita dados de usuários

7.1 - Edita o tipo de usuário como adm/usuário



Fluxo das Informações

Exercício 2 Crie um sistema de controle de petshop. Seus requisitos são:

• Agenda de serviços, animais e clientes;

• Tipo de serviço: Consulta veterinária ou petshop (banho)?;

• Dados par ao serviço (Doença, tosa, castração…);

• Exames a serem marcados pelo veterinário;

• A secretária é o ator agenciador entre clientes, veterinários e agenda do petshop.

Casos de uso de Login

Requisição Resposta

1 - Acessa o sistema

2 - Sistema procura do BD o email e a senha

3 - usuário entra no sistema

4 - acessa página de edição de dados

5 - sai do sistema



Diagrama de Casos de Uso

@startuml title <b>Casos de Uso de uma veterinária</b> :Animal: :Cliente: :Secretária:



:Veterinário: :Tratador: :Animal: -- :Cliente: :Cliente: -- :Secretária: :Secretária: -- (Serviço) : acessa | \nconsulta (Serviço) <-- (Serviço veterinário) (Serviço) <-- (Serviço petshop) :Secretária: -- (Agenda) : acessa | \nconsulta :Secretária: -- (Cadastro veterinário) :Secretária: -- (Cadastro tratador) :Secretária: -- (Cadastro clientes) :Secretária: -- (Cadastro animais) (Cadastro clientes) <.. (Cadastro animais) : <<include>> (Serviço) <.. (Agenda) : <<include>> (Insumos veterinários) <.. (Serviço) : <<include>> :Veterinário: -- (Insumos veterinários) : informa :Veterinário: -- (Cadastro veterinário) (Cadastro veterinário) ..> (Autocadastro) : <<extend>> (Autocadastro) <.. (Tipo função) : <<include>> :Veterinário: -- (Serviço) :Veterinário: -- (Agenda) :Veterinário: -- (Serviço veterinário) note bottom of (Serviço veterinário) : Cadastra novos serviços (Insumos petshop) <.. (Serviço) : <<include>> :Tratador: -- (Insumos petshop) : informa :Tratador: -- (Cadastro tratador) (Cadastro tratador) ..> (Autocadastro) : <<extend>> :Tratador: -- (Serviço) :Tratador: -- (Agenda) :Tratador: -- (Serviço petshop) note bottom of (Serviço petshop) : Cadastra novos serviços @enduml



Documentação de Casos de Uso Casos de Uso Agenda Veterinária Descritivo

UC 01 Acesso à Agenda

Ator Secretária 1 - Consulta horários, agenda novos e desmarca;

2 - Consulta serviços

3 - Cadastra, edita e exclui clientes e animais, veterinários e tratadores.

4 - Emite relatórios

Ator Veterinário 1 - Cadastra-se como veterinário (validado pelo CPF)

2 - Cadastra novos serviços de veterinária

3 - Consulta e marca novos compromissos na agenda

Ator Tratador 1 - Cadastra-se como novo Tratador (validado pelo CPF)

2 - Cadastra novos serviços de petshop

3 - Consulta e marca novos compromissos na agenda

Ator Cliente 1 - Consulta verbalmente o Ator Secretária

Ator Animal 1 - Dependente do Ator Cliente



Fluxo das Informações Casos de uso da Veterinária

Requisição Resposta

1 - O Cliente entra em contato com o Ator Secretária solicitando uma consulta

2 - O Ator Secretária questiona o tipo de serviço

3 - O Ator Cliente descreve o tipo de serviço: Veterinário ou petshop

4 - O Ator Secretária, consulta na Agenda o Serviço e verifica as datas e horários disponíveis por profissional Veterinário ou Tratador;

5 - O Ator Cliente concorda com a data

6 - O Ator Secretária solicita os dados do Ator Cliente, caso não exista no sistema, deve ser cadastrado e o Ator Animal cadastrado como dependente do Ator Cliente; O Ator Secretária associa o profissional ao cliente na data e horário solicitado.



Diagrama de Classes O Diagrama de Classes é um dos mais importantes da UML, servindo de base para

outros. Este diagrama serve para projetar, documentar ou mesmo compreender como

um software foi projetado e como as métodos dos objetos interagem, servindo de base

para os diagramas de Sequência, Estados e Comunicação.

Uma Classe é um elemento que contém diversos objetos que tenham as mesmas

características ou aspectos. Ex.: A Classe Login reúne os Objetos ValidaLogin,

ValidaSessao e LogDeErros. Todos eles servem ao login.

Neste diagrama podem ser definidos Atributos como a Visibilidade, Tipo de Dados,

Multiplicidade e Propriedade.



Documents

MODELAGEM DE SISTEMAS - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.14259131932123.pdf · Modelagem de Sistemas Orientação a Objetos A Orientação a Objetos (OO)