Engenharia de Software I

Prof.ª Esp.ª Mythian Bastos Queiroz

Objetivos
• Entender e saber trabalhar com os principais diagramas UML.
• Analisar e criar projetos de software fazendo uso dos recursos oferecidos
pela UML.
Introdução
• A UML tornou-se, nos últimos anos a linguagem padrão de modelagem de
sistemas, sendo adotada internacionalmente pela indústria de engenharia
de software.

• O objetivo da modelagem é auxiliar os engenheiros de software a definir

características do software, tais como seus requisitos, seu comportamento,
sua estrutura lógica, a dinâmica de seus processos e até mesmo as suas
necessidades físicas em relação ao equipamento sobre o qual o sistema
deverá ser implantado.
Ferramentas de modelagem
• IBM Rational Requisite Pro
• JUDE (atual, ASTAH)
• Umbrello UML
• Poseidon para UML
• Microsoft Visual Modeler
• Argo UML
O que é UML?
• Linguagem gráfica de modelagem
─ Visualizar
─ Especificar
─ Construir
─ Documentar
• A UML não é uma metodologia.
• Não é exclusiva para o uso de sistemas orientados a objetos.
• Permite que os desenvolvedores visualizem os produtos de seus trabalhos
em diagramas padronizados.
DIAGRAMA DE CASO DE USO
Diagrama de Caso de Uso
• O Diagrama de Caso de Uso procura por meio de uma linguagem simples,
facilitar a compreensão do comportamento externo do sistema por qualquer
pessoa, tentando apresentar o sistema através de uma perspectiva do
usuário.
• É o mais flexível e informal. Costumam-se utilizá-lo no inicio da modelagem
do sistema principalmente nas etapas de Levantamento e Análise de
Requisitos, embora venha a ser consultado e modificado durante todo o
processo de engenharia e venha servir de base para construção de outros
diagramas.
• O objetivo é apresentar uma visão externa geral das funções e serviços que
o sistema deverá oferecer aos usuários, sem se preocupar como essas
funções serão implementadas.
Diagrama de Caso de Uso
• O diagrama de caso de uso tenta identificar os usuários que irão interagir
com o sistema, quais papéis esses usuários irão assumir e quais funções
serão requisitadas para cada usuário específico.
• Os elementos são:
─ Atores
─ Relacionamentos
─ Casos de uso
Diagrama de Caso de Uso
ATORES
• Os atores representam os papéis
desempenhados pelos diversos usuários que
poderão utilizar os serviços e funções do
sistema, eventualmente pode representar
algum hardware especial ou mesmo um
outro software que interaja com o sistema,
como no caso um sistema integrado. Assim
um ator pode ser qualquer elemento externo
que interaja com o software.
Diagrama de Caso de Uso
CASOS DE USO
• Os casos de uso referem-se aos serviços, tarefas ou funções que podem ser
utilizadas de alguma maneira pelos usuários do sistema.
• Sua descrição deve ser bem sucinta.
Diagrama de Caso de Uso
DOCUMENTAÇÃO DE CASOS DE USO
• Os casos de uso costumam ser documentados, fornecendo instruções de
como será seu funcionamento, quais atividades deverão ser executadas, qual
evento forçará sua execução, quais atores os poderão utilizar, quais sua
possíveis restrições, entre outras.

• O objetivo principal da documentação de um caso de uso é fornecer um

relatório ao cliente explicando qual o comportamento pretendido para um
determinado caso de uso e quais funções ele executará quando for solicitado.
Nome do Caso de Abrir Conta 3. Se for necessário, gravar ou
Uso atualizar o cadastro do cliente. Se
Nome do Caso de o cliente não possuir outras contas
Uso Geral deve ser registrado como inativo.

Ator Principal Cliente 4. Avaliar o pedido do cliente

Atores Funcionário 5. Aprovar o pedido

Secundários 6. Escolher a
Resumo Este caso de uso descreve as senha da conta
etapas percorridas por um cliente 7. Abrir contar
para abrir uma conta corrente 8. Definir cliente como ativo
Pré-condições O pedido de Abertura precisa ser 9. Fornecer valor
aprovado a ser depositado
Pós-condições É necessário realizar um depósito 10. Registrar o depósito
inicial
11. Emitir cartão da conta
Ações do Ator Ações do Sistema
Restrições/ 1. Para abrir um conta corrente é
1. Solicitar Validações preciso ser maior de idade
abertura de conta 2. O número mínimo do depósito
2. Consultar cliente por seu CPF é de R$ 5,00.
Diagrama de Caso de Uso
ASSOCIAÇÕES
• Representam as interações ou relacionamentos entre os atores que fazem
parte do diagrama, entre os atores e os casos de uso, ou entre os casos de
uso.

• Os relacionamentos entre casos de uso recebem nomes especiais como:

─ Inclusão
─ Extensão
─ Generalização
Diagrama de Caso de Uso
ASSOCIAÇÕES – Especialização/Generalização
• Associação entre casos de uso na qual existem dois ou mais casos de uso com
características semelhantes, apresentando pequenas diferenças entre si.
Quando tal situação ocorre costuma-se definir um caso de uso geral que
descreve as características compartilhadas por todos os casos de uso em
questão e então relacioná-lo com os outros casos de uso envolvidos, cuja
documentação conterá somente as características de cada um.
• Os casos de uso herdam também quaisquer possíveis associações de inclusão
ou extensão que o caso de uso geral venha a possui, bem como quaisquer
associações com os atores que utilizem o caso de uso geral.
Diagrama de Caso de Uso
ASSOCIAÇÕES – Especialização/Generalização
• Um relacionamento de especialização/generalização também pode ser
aplicado sobre atores.
Diagrama de Caso de Uso
ASSOCIAÇÕES – Inclusão (include)
• Costuma ser utilizada quando existe um serviço, situação ou rotina comum a
mais de um caso de uso. Quando isso ocorre a documentação dessa rotina é
colocada em um caso de uso específico para que os outros casos de uso
utilizem desse serviço. Os relacionamentos de inclusão indicam uma
obrigatoriedade, ou seja, quando um determinado caso de uso possui um
relacionamento de inclusão com o outro, a execução do primeiro obriga
também a execução do segundo.
Diagrama de Caso de Uso
ASSOCIAÇÕES – Extensão (extend)
• São utilizadas para descrever cenários opcionais de um caso de uso. Assim as
associações de extensão indicam a necessidade de um teste para determinar
se é necessário também o caso de uso estendido ou não. Eles ocorrerão em
uma situação específica, se uma determinada condição for satisfeita.
DIAGRAMA DE CLASSES
Diagrama de Classes
• Seu principal enfoque está em permitir a visualização das classes que irão
compor o sistema com seus respectivos atributos e métodos, bem como em
demonstrar como as classes do diagrama se relacionam, complementam e
transmitem informações entre si.
• Esse diagrama apresenta uma visão estática de como as classes estão
organizadas, preocupando-se em como definir a estrutura lógica das mesmas.
• Está baseado no conceito de Classe, portanto, para que se crie um diagrama
de classes é imprescindível conhecer todos os conceitos do Paradigma da
Orientação a Objetos relacionados à noção de classes.
Diagrama de Classes
CLASSES, ATRIBUTOS E MÈTODOS
• A classe é um molde para criação de objetos, porque permite descrever um
conjunto de objetos que compartilham a mesma estrutura de dados e as
mesmas operações.
Diagrama de Classes
VISIBILIDADE
• A visibilidade é um utilizada para indicar o tipo acesso permitido a um
determinado atributo ou método. Existem basicamente três modos de
visibilidade pública, protegida e privada.

TIPO SÍMBOLO DESCRIÇÃO

Pública + Significa que o atributo ou método pode ser
utilizado por qualquer classe.

Protegida # Somente a classe possuidora do atributo ou

método ou as suas subclasses podem ter acesso ao
mesmo.
Privada - Somente a classe possuidora do atributo ou
métodos poderá utilizá-lo.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
• As classes relacionam-se de maneiras variadas para juntas apresentarem uma
solução ao problema. Os relacionamento podem ser fracos, indicando que as
classes não possuem uma grande afinidade, ou forte, atestando uma grande
interdependência entre elas.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Multiplicidade
• A multiplicidade representa a informação dos limites inferior e superior da
quantidade de objetos aos quais um outro objeto pode estar associado.
• As multiplicidades são bastante semelhantes ao conceito de cardinalidade
encontrado no diagrama de entidade e relacionamento (E-R) bastante
conhecido na comunidade de banco de dados.
MULTIPLICIDADE SIGNIFICADO

No mínimo zero (nenhum) e no máximo um. Indica que os objetos das

0.1 classes associadas não precisam, obrigatoriamente, se relacionar, mas se
houver relacionamento indica que apenas uma instância da classe se
relaciona com as instâncias da outra classe.
Um e somente um. Indica que apenas um objeto da classe se relaciona com
1.1 os objetos da outra classe.
No mínimo nenhum, e no máximo muitos. Indica que pode ou não haver
0.* instâncias da classe participando do relacionamento.
Muitos. Indica que muitos objetos da classe estão envolvidos no
* relacionamento.
No mínimo um, e no máximo muitos. Indica que há pelo menos um objeto
1.* envolvido no relacionamento, podendo haver muitos envolvidos.
Intervalo específico. Onde as expressões li, ls devem ser substituídas por
1li.1ls valores correspondentes aos limites inferiores e superiores,
respectivamente, do intervalo que se quer representar.
Diagrama de Classes
Ex:
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Associações
• A associação entre classes pode ser binária, unária, ternária ou N-ária, embora
esta última seja um tipo de associação mais rara e complexa. O objetivo é
definir a maneira como as classes estão unidas e interagem entre si,
compartilhando informações.
• Uma associação determina que as instâncias de uma classe estão de alguma
forma ligadas as instâncias das outras classes envolvidas na associação,
podendo haver troca de informações entre elas e compartilhamento de
métodos. Uma associação pode ainda identificar algum nível de dependência
entre as classes que a compõem.
Diagrama de Classes
Associações (cont.)
• As associações são representadas por retas ligando as classes envolvidas,
podendo também possuir setas em suas extremidades para indicar para
indicar a navegabilidade da associação, o que representa o sentido em que as
informações são transmitidas entre as classes envolvidas. Se não houver setas,
significa que as informações podem trafegar entre todas as classes da
associação.
Diagrama de Classes
Associações – Unária ou reflexiva
• Este tipo de associação ocorre quando existe um relacionamento de uma
classe para consigo mesma. Cada objeto tem um papel distinto nessa
associação. A utilização de papéis é bastante importante para evitar
ambiguidades na leitura da associação.
• Essa associação não quer dizer que o objeto se associa a ele mesmo, indica
que um objeto de uma classe se associa com outros objetos da mesma classe.
Diagrama de Classes
Associações – Binária
• Este tipo de associação ocorre quando são identificados relacionamentos
entre duas classes. São as mais comuns encontradas nos diagramas de classes.
Diagrama de Classes
Associações – Ternária ou N-ária
• São associações que conectam mais de duas classes. São representadas por
um losango para onde convergem todas as ligações da associação.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Agregação
• A agregação é um caso especial de associação. É utilizada para representar
conexões entre objetos que guardam uma relação todo-parte entre si.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Composição
• Um associação do tipo composição constitui-se em uma variação da
associação de agregação. Uma associação de composição representa um
vínculo mais forte entre os objetos-todo e os objetos-parte, procurando
demonstrar que os objetos-parte têm de pertencer exclusivamente a um único
objeto-todo com que se relacionam. Em uma composição, um mesmo objeto-
parte não pode associar-se a mais de um objeto todo.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Herança
• É um mecanismo que permite o reaproveitamento de atributos e métodos,
otimizando o tempo de desenvolvimento, além de diminuir as linhas de
código, bem como facilitar futuras manutenções. Herança é também
conhecida como Generalização/Especificação.
• O conceito de herança trabalha com os conceitos de superclasses e subclasses.
Uma superclasse (classe-mãe) é uma classe que possui classes derivadas a
partir dela., chamadas sub-classes (classes-filha). As sub-classes herdam todas
as características da classe-mãe, podendo possuir atributos e métodos
próprios.
Diagrama de Classes
Ex:

GENERALIZAÇÃO ESPECIALIZAÇÃO
Diagrama de Classes
Herança (cont.)
• Esse tipo de relacionamento permite também demonstrar a ocorrência de
métodos polimórficos nas classes especializadas do sistema, o chamado
Polimorfismo.
• No polimorfismo, métodos podem ser redeclarados em uma classe
especializada, possuindo o mesmo nome, mas comportando-se de forma
diferente, não sendo necessário modificar o código-fonte do sistema com
relação as chamadas de métodos das classes especializadas, porque o nome
do método não mudou, apenas foi redeclarado em uma classe especializada e
só se comporta de maneira diferente quando for chamado por objetos dessa
classe.
Diagrama de Classes
Ex:
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Herança Múltipla
• Quando uma classe possui mais de uma superclasse caracteriza-se uma
herança múltipla.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Dependência
• Esse relacionamento, como o próprio nome já diz, indica um certo grau de
dependência de uma classe em relação a outra, isto é, sempre que ocorrer
uma mudança na classe na qual uma outra classe depende, esta deverá
também sofrer uma mudança.
Diagrama de Classes
RELACIONAMENTO ENTRE AS CLASSES
Realização
• O relacionamento de realização entre classes une características dos
relacionamentos de generalização e dependência, sendo usado no diagrama
de classes para identificar classes responsáveis por executar funções para
classes que representam interfaces. Esse tipo de relacionamento herda o
comportamento de uma classe, mas não sua estrutura.
Diagrama de Classes
CLASSE ASSOCIATIVA
• São classes que estão ligas a associações, em vez de estarem ligadas a outras
classes. Esse tipo de classe normalmente aparece quando duas ou mais
classes estão associadas, e é necessário manter informações sobre a
associação. Embora seja mais comum encontrar classes associativas ligadas a
associações de conectividades muitos para muitos, uma classe associativa
pode estar ligada a associações de qualquer tipo de conectividade.
Diagrama de Classes
CLASSE ASSOCIATIVA (cont.)
• Podem perfeitamente ser substituídas por classes normais, chamadas de
classes intermediárias, mas que desempenham a mesma função das classes
associativas
Diagrama de Classes
RESTRIÇÃO
• Podem ser associadas sobre uma associação para condicionar a forma pela
qual a associação dever ser implementada.
Diagrama de Classes
RESTRIÇÃO (cont.)
• As restrições podem ser aplicada também para validar um atributo ou método
de uma classe específica, por meio do uso de notas.
Diagrama de Classes
ESTEREÓTIPOS
• Costuma-se categorizar os objetos de um sistema de acordo com o tipo de
responsabilidade a ele atribuído, com o uso dos estereótipos.
• Esses estereótipos são uma maneira de destacar determinados componentes
do diagrama, tornando explicito que esses componentes executam alguma
função um pouco diferente dos outros componentes apresentados no
diagrama.
• A linguagem UML permite a criação de estereótipos particulares por parte de
quem for utilizar, porém possuem três estereótipos predefinidos, utilizados
nos diagramas de classes, que são os objetos de entidade, <<entity>>, objetos
de fronteira, <<boundary>>, e os objetos de controle. <<control>>.
Diagrama de Classes
ESTEREÓTIPOS

Estereótipos Ícone
<<boundary>>

<<control>>

<<entity>>
Diagrama de Classes
ESTEREÓTIPOS <<entity>>
• Tem por objetivo deixar explicito que uma classe é uma entidade, ou seja, o
objeto contém informações recebidas ou geradas por meio do sistema. São
classes que normalmente possuirão muitos objetos e que estes possivelmente
terão um período de vida longo, isto é existe a possibilidade de que os objetos
destas classes precisem ser preservados.
• Esses objetos representam conceitos do domínio de negócios. Normalmente
esses objetos armazenam informações persistentes do sistema.
• Uma outra característica desse tipo de objeto é que os atores do sistema não
te acesso direto a esses objetos. Objetos de entidade se comunicam com o
exterior do sistema por meio de outros objetos.
Diagrama de Classes
ESTEREÓTIPOS <<boundary>>
• Também conhecido como estereótipo da fronteira, e identifica uma classe que
serve de comunicação entre atores externos e o sistema propriamente dito.
Um objeto de fronteira existe para que o sistema possa se comunicar com o
mundo exterior.
• Classes de fronteira realizam a comunicação direta do sistema com atores,
sejam eles de outros subsistemas, equipamentos ou seres humanos.
• Uma classe do tipo fronteira muitas vezes necessita interagir com outra classe
do tipo controle.
Diagrama de Classes
ESTEREÓTIPOS <<control>>
• Também chamado de controlador e serve como uma ponte de comunicação
entre objetos de fronteira e objetos de entidade. São eles os responsáveis por
controlar a lógica de execução correspondente a um caso de uso.
• Os objetos controladores são responsáveis por interpretar os eventos
ocorridos sobre os objetos de fronteira, como o movimento do mouse, ou o
pressionamento de um botão e retransmiti-los para os objetos de entidade
que compõem o sistema.
DIAGRAMA DE OBJETOS
Diagrama de Objetos
• Fornece uma visão dos valores armazenados pelos objetos das classes
definidas no diagrama de classes, em um determinado momento da execução
do processo.
• Objetos são representados por retângulos semelhantes às classes e não
possuem métodos, somente atributos.
• O nome do objeto pode se apresentar de três formas:
─ Escrito com letras minúsculas seguidas de dois pontos e o nome da classe a que
pertence.
─ Somente os dois pontos e o nome da classe.
─ Somente o nome do objeto, sem os dois pontos
• OBS: no diagrama de objetos o nome de ser sublinhado.
Diagrama de Objetos
• O nome do objeto pode se apresentar de três formas:
─ Escrito com letras minúsculas seguidas de dois pontos e o nome da classe a que
pertence.
─ Somente os dois pontos e o nome da classe.
─ Somente o nome do objeto, sem os dois pontos
• OBS: no diagrama de objetos o nome de ser sublinhado.
Diagrama de Objetos
• O diagrama de objetos modela as instâncias das classes contidas no diagrama
de classes, isto é, o diagrama de objetos mostra um conjunto de objetos e
seus relacionamentos no tempo. Estes diagramas são importantes para
construir os aspectos estáticos do sistema. Normalmente, são compostos
por: objetos e vínculos.
O exemplo acima mostra um diagrama de
objetos para o cliente Michael Richardson e
seus dois pedidos na Virtual LTDA. O
diagrama pode ser lido da seguinte
maneira: O objeto R. Michael Richardson da
classe Cliente está associado a ambos os
objetos 123456 e 123700 da classe Pedido.
Usa-se o diagrama de objetos para modelar
a visão estática de um sistema. Ele mostra o
retrato do sistema em determinado
momento.
DIAGRAMA DE PACOTES
PACOTES E CLASSES
• Uma analogia para entender como funcionam os pacotes, é entender o que
fazem os empacotadores de supermercado. Todos os produtos que são
similares vão para o mesmo pacote com o objetivo de organizar e facilitar o
transporte dos produtos.
• Todas as classes que possuem características em comum podem ser incluídas
em um mesmo pacote, tornando a manutenção e até mesmo a
implementação menos complexas.
PACOTES E CLASSES
• Em muitos casos um único diagrama de classes pode ser exageradamente
grande para representar todo o sistema. Assim é conveniente utilizar um
elemento para organizar os modelos. Para isto utiliza-se o diagrama de
pacotes. Um diagrama de pacotes pode ser utilizado em qualquer fase do
processo de modelagem.
• Um diagrama de pacotes é composto de pacotes e relacionamentos entre
pacotes. O critério para definir os pacotes é subjetivo e depende da visão e
das necessidades do projetista. Este deve definir uma certa semântica e
colocar os elementos similares e que tendem a serem modificados em
conjunto num mesmo pacote.
PACOTES E CLASSES
Como se vê na figura abaixo, pode-se usar os pacotes
para mostrar a arquitetura do sistema.
Referências Bibliográficas
• UNIVERSIDADE FEDERAL DE MINAS GERAIS. Glossário UML. Disponível em:
<https://homepages.dcc.ufmg.br/~amendes/GlossarioUML/>. Acessado em:
29 de out. 2018.
• BERTA, Caroline; ALMEIDA; Érika. Guia Prático de UML. Santarém: [s.e], 2006.
• LAROZA, Jonnas Piccin; SEABRA, Rodrigo Duarte. REA-UML: Recurso
Educacional Aberto para Ensino da UML. Disponível em:
<http://sgvclin.altervista.org/rea-uml/>. Acessado em 31 de out. 2018.