Aula 6 - Engenharia II - quarta - noturno

Prévia do material em texto

Centro Universitário FMU
Disciplina: 
Engenharia de Software II
Aula 6
Bacharelado em Sistemas de Informação
Tecnologia em Sistemas para Internet
Prof.: Celso Eduardo Guimarães
celso.guimaraes@fmu.br
Diagrama de Classes
• Em programação, um diagrama de 
classes é uma representação da estrutura e 
relações das classes que servem de modelo
para objetos.
• É uma modelagem muito útil para o 
desenvolvimento de sistemas, pois define 
todas as classes que o sistema necessita
possuir e é a base para a construção dos 
diagramas de comunicação, sequência e 
estados.
Modelo Conceitual de Classes
Visão Geral
❑ É um artefato do domínio do problema e não do domínio da solução, portanto, 
não é utilizado para especificação da arquitetura do sistema.
❑ Ele é formado pelos conceitos (classes de abstração) obtidos a partir da análise 
textual da definição do problema (enunciado do problema e casos de uso), 
atributos (deve-se preocupar somente com os atributos obtidos a partir da 
abstração do problema ou em decorrência do conhecimento do domínio do 
problema) e associações (relacionamentos).
❑ Um modelo “completo” do diagrama de classes será obtido posteriormente.
❑ Nesse momento, a especificação do diagrama de classes estará voltado às 
definições da solução a nível de arquitetura do sistema, portanto, do domínio da 
solução e não mais do domínio do problema.
Modelo Conceitual de Classes
❑ Na fase de Análise e Design o modelo conceitual do diagrama de classes 
evolui para uma especificação mais completa, com a inclusão de atributos, não 
identificados no momento da elaboração do modelo conceitual, e das operações 
das classes. 
❑ Uma reestruturação das classes e relacionamentos também pode ocorrer nesta 
evolução do modelo conceitual para o modelo “completo”, provocando a inclusão 
de novas classes e relacionamentos com semântica mais apurada e, também, 
especificação de hierarquias de classes com a inclusão de relacionamentos de 
herança.
Modelo Conceitual de Classes
O modelo conceitual do diagrama de 
classes é um artefato que especifica um 
nível intermediário de abstração entre 
as fases de “Requisitos” e “Análise e 
Design”, cujo objetivo principal é 
prover um mecanismo capaz de auxiliar 
no processo de identificação das 
classes de objetos do domínio do 
problema.
Modelo Conceitual de Classes
A construção do modelo conceitual do 
diagrama de classes identifica o 
produto final da abstração das classes 
candidatas obtidas a partir de uma 
análise gramatical do domínio do 
problema.
Identificação de Classes e Objetos
❑ Pode-se começar a identificar objetos (classes) 
examinando o enunciado do problema ou executando 
uma “análise gramatical” da narrativa de 
processamento do sistema a ser construído.
❑ As classes são identificadas sublinhando cada 
substantivo ou cláusula substantivada, logo após, as 
possíveis classes candidatas deverão ser 
relacionadas, para que uma análise mais aprofundada 
possa ser feita com o objetivo de verificar a existência 
ou não da classe relacionada.
As candidatas à classe se manifestam da seguinte maneira:
• Entidades externas (outros sistemas, dispositivos e pessoa) – que produzem ou consomem 
informação a ser usada por um sistema baseado em computador;
• Coisas (relatórios, figuras, cartas, sinais) – que são parte do domínio de informação do 
problema;
• Ocorrências de eventos (efetua pagamento, emite recibo) – que ocorrem dentro do contexto 
da operação do sistema;
• Papéis (gerente, engenheiro, vendedor) – desempenhados por pessoas que interagem com o 
sistema;
• Unidades organizacionais (divisão, grupo, equipe, setor) – que são relevantes para uma 
aplicação;
• Lugares (recepção, estoque) – que estabelecem contexto do problema ou a função global do 
sistema;
• Estruturas (sensores, impressora, computadores, leitora de código de barra) – que definem 
uma classe de objetos ou classes relacionadas de objetos.
A lista continuaria até que todos os substantivos na narrativa de processamento 
tivessem sido considerados.
Seis características de seleção podem ser usadas quando um 
analista considera cada classe em potencial para inclusão no 
modelo de análise:
• Informação retida – A classe potencial vai ser útil durante a análise apenas se a informação 
sobre ela tiver que ser lembrada para que o sistema possa funcionar.
• Serviços necessários – A classe potencial deve ter um conjunto de operações identificáveis que 
podem mudar o valor de seus atributos de algum modo.
• Atributos múltiplos – Durante a análise de requisito, o foco deve ficar na informação 
“importante”; uma classe com um único atributo pode ser útil durante o projeto, mas é 
provavelmente melhor representada como atributo de outra classe durante a atividade de 
análise.
• Atributos comuns – Um conjunto de atributos pode ser definido para o objeto potencial e esses 
atributos se aplicam a todas as ocorrências dos objetos.
• Operações comuns – Um conjunto de operações pode ser definido para a classe potencial e 
essas operações se aplicam a todas as ocorrências dos objetos.
• Requisitos essenciais – Entidades externas que aparecem no espaço do problema e produzem 
ou consomem informação essencial para a operação de qualquer solução do sistema vão quase 
sempre serem definidas como classes no modelo de requisitos de objetos.
Primeiras diretrizes para Atividade 2 (A3).
• A partir do documento produzido na Atividade 1 (Requisitos do 
sistema), o grupo deverá se reunir virtualmente para identificar as 
classes candidatas para ser a base de um modelo de classes de análise.
Exemplo de Diagrama de Classes Conceitual
➢ Considerando a 
abstração de classes 
candidatas, um 
modelo conceitual do 
diagrama de classes 
pode ser especificado 
(em um alto nível de 
abstração). 
➢ Um segundo modelo 
conceitual (em um 
nível menor de 
abstração) poderá ser 
obtido, incluindo 
informações obtidas a 
partir de um 
levantamento mais 
detalhado dos 
requisitos do sistema.
Exemplo de Diagrama de Classes Conceitual
NÍVEL ALTO DE ABSTRAÇÃO
❑Considerando um conhecimento prévio do domínio do problema e 
uma experiência em procedimentos de modelagem, o Analista de 
Requisitos ou o Analista de Projeto podem produzir um modelo um 
pouco mais detalhado:
❑encontrando novas classes ou atributos que em um primeiro 
momento não foram possíveis abstrair a partir dos artefatos 
existentes. 
❑Neste momento, quando itens importantes são incluídos no 
modelo, deve-se avaliar se os artefatos utilizados para a 
abstração dos conhecimentos necessários para a construção 
do modelo conceitual do diagrama de classes estão 
incompletos e necessitando, de uma readequação
❑produzindo uma evolução dos modelos.
Modelo conceitual do diagrama de classes obtido a partir de um nível de abstração mais detalhado do que o 
diagrama 1º. Considerando, desta maneira, um evolução do modelo.
Esse apresenta um modelo mais 
apurado do diagrama de classes, mas 
ainda é um, modelo conceitual .
Inclusão das operações e outros 
atributos ainda não foi considerada 
na totalidade. 
Quando a evolução do diagrama de 
classes obtiver um resultado 
satisfatório ele deixa de ser um 
modelo conceitual e passa a ser um 
representação completa da 
arquitetura de objetos de dados do 
sistema e, neste momento, ele é 
incluído como artefato (diagrama de 
classes) da disciplina de Análise e 
Design.
Vamos aprender agora um 
outro diagrama:
O Diagrama de Objetos
Vamos desvendar de uma vez por todas a diferença 
conceitual entre
OBJETOS E CLASSES
Classe
Nada mais é, do que a especificação do que um dia poderá vir 
a ser um objeto.
Objeto
Trata-se da instância de uma classe.
Instância é a concretização de uma classe. 
Em termos intuitivos, uma classe é como um "molde" que gera 
instâncias de um certo tipo; 
um objeto é algo que existe fisicamente e que foi "moldado" na classe.
Vamos desvendar de uma vez por todas a diferença 
conceitualentre
OBJETOS E CLASSES
Classe
Nada mais é, do que a especificação do que um dia poderá 
vim a ser um objeto.
Objeto
Trata-se da instância de uma classe.
• Imagine uma forma (molde) de bonecos de gessos. 
• Pois bem, essa é nossa classe ou tipo, ou seja, define o formato, 
tamanho e diversos outros aspectos dos objetos fabricados, no caso, os 
bonecos de gesso. 
Percebeu a diferença? 
• A classe é um molde para os objetos. 
• Quando se diz: “Instância de uma classe ou tipo”, nada mais é do que o 
objeto dessa classe ou tipo.
Diagrama de objetos
❑São instâncias dos Diagramas de Classes.
Instanciar 
Classes 
Criar Objetos
Você também poderá encontrar a denominação 
especificação de instância.
Diagrama de objetos
São 2 
compartimentos
Identificação 
do objeto
Valores para 
os atributos
A identificação do 
objeto deve ser 
sublinhada.
❑Como o diagrama de classes, o diagrama de 
objetos também é estrutural.
➢ Ele exibe uma “fotografia” do sistema em 
certo momento, exibindo as ligações 
formadas entre objetos conforme estes 
interagem e de acordo com os valores dos 
seus atributos.
Diagrama de objetos
❑Esse não é um diagrama muito utilizado na 
prática, pois as aplicações OO tendem a ter 
inúmeros objetos instanciados enquanto 
rodam.
❑Entretanto, em termos didáticos, esse diagrama 
pode ser útil para explicar um momento 
específico do software.
Diagrama de objetos
DIAGRAMA DE 
ATIVIDADES
• Mostra a lógica de 
execução, em passo-a-
passo, de uma ação do 
sistema.
DIAGRAMA DE 
ATIVIDADES
❑É pertinente utilizá-lo quando o propósito é:
✓Documentar o aspecto funcional (não estrutural) do 
software, quando é necessário representar o fluxo da 
informação que o software trabalhará, e quando 
existam condições/decisões que precisam 
detalhadas/descritas.
✓Mostrar aspectos específicos de alguma rotina do negócio 
que será automatizada pelo software, como um “zoom” em 
parte de alguma funcionalidade, por exemplo.
DIAGRAMA DE ATIVIDADES
❑Ele serve basicamente para representar fluxos de processos!
✓É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade 
para outra e serão empregados para fazer a modelagem de aspectos dinâmicos do 
sistema. 
✓Mostra o comportamento do sistema, denotando os caminhos lógicos que um processo 
deve seguir.
✓Faz parte da dinâmica da UML e baseia-se em um modelo gráfico que permite analisar
a estrutura e o comportamento dinâmico dos sistemas em que cada evento tem pré-
condições para sua ocorrência e pós-condições dela decorrentes.
✓Especifica a coordenação de execuções de comportamentos, usando um modelo de 
fluxo de controle de dados. O fluxo de execução é modelado como nós de atividades 
conectados por extremidades.
A ação cadastrar cliente, nesse 
exemplo, é condicional portanto 
escolha o elemento de “Decisão” (no 
ArgoUML é chamado de “Nova 
Junção”.
Ponto inicial 
(“novo início”)
Parâmetro de 
atividade
Estado de ação
Um parâmetro de atividade é usado para 
representar uma entrada ou saída de atividade.
No exemplo, ele denota que a atividade produz 
um pedido de cliente, mas ainda sem itens 
associados.
Atividade “Validar Cliente”
Quatro ações compõem fazer pedido.
Nesse exemplo, 
um cliente 
pode escolher 
um ou mais 
produtos.
O parâmetro de 
saída anterior é 
entrada para esse.
Poderia ser uma 
sub-atividade
Há um problema aqui:
Dá a entender que somente um item, ou um só produto 
poderia ser escolhido.
Região de expansão
Uma região de expansão permite representar processos paralelos, isto é, grupos de ações 
executadas simultaneamente sobre um ou mais elementos, processos iterativos, como é o 
caso do exemplo, e processos de streaming, em que uma coleção de dados é enviada por 
um canal de forma sequencial (os bytes são enviados em pequenos pacotes que são 
reorganizados quando chegam no destino).
A região de 
expansão será 
executada várias 
vezes.
Fluxos Simultâneos
Compondo 
demais 
atividades que 
compõem a 
venda
❑ Cada uma das áreas 
organizacionais representa 
um papel dentro da execução 
do processo. 
❑ As atividades ocorrem sob a 
responsabilidade de algum 
desses papéis.
Outra forma de usar o particionamento.
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.
Conceitos
Diagrama de Sequência
Também conhecido 
como Diagrama de 
Mensagens
Ferramenta da UML usada 
para representar a 
interação de um sistema 
orientado a objetos.
Enfatiza a ordem de chamada das operações 
em uma determinada situação do sistema 
em função do tempo.
➢ Projeto pode ter uma grande 
quantidade de métodos em 
classes diferentes
> É difícil determinar a 
sequência global do 
comportamento. 
➢ O diagrama de sequência 
representa essa informação.
Diagrama de Sequência
Exemplo
➢ Ele procura determinar a 
sequencia de eventos que 
ocorrem em um determinado 
caso de uso.
➢ Quais operações devem ser 
disparadas entre os objetos 
envolvidos e em qual ordem
(sequência) para a realização 
completa do caso de uso.
Diagrama de Sequência
Exemplo
Baseia-se nos 
diagramas de 
classes e casos 
de uso
Esteriótipos
Ator: representa um usuário ou 
outro sistema interagindo com o 
sistema.
Esteriótipos
Interface: Classe que fará a troca de 
mensagens com o ator. 
Caso esse ator seja uma pessoa, 
esse será a classe que 
representará a interface gráfica 
daquela sequência que está 
sendo desenhada.
Esteriótipos
Controle: Essa é a classe que possuirá 
a lógica de negócio do sistema para a 
sequência modelada.
Esteriótipos
Entidade: Essa classe é conhecida 
por armazenar o conteúdo das 
entidades que estão sendo tratadas 
por aquele sistema.
Lifelaine
ou 
Linha de Vida
Um retângulo magro 
indica o período em 
que o objeto está 
participando 
ativamente do 
processo
Exemplo de Login
Diagrama de 
caso de uso
Exemplo de Login
Diagrama de 
Classe
Exemplo de Login
Diagrama de 
sequência