Introducao V5

Desenvolvimento de
Software
https://www.dimap.ufrn.br/~jair/ES/c1.html
https://sisacad.educacao.pe.gov.br/bibliotecavirtual/bibliotecavirtual/texto/CadernodeINFOProjetodeDesen
volvimentodeSoftwareRDDI.pdf
Engenharia de requisitos: https://www.dimap.ufrn.br/~jair/ES/c3.html
https://profareane.files.wordpress.com/2013/07/aula-4-uml.ppt
Análise e Projetos Orientado a Objetos – Rudson K.S. Carvalhpo - diagramasumlv3-140325212653-phpapp01
Fonte: André Constantino da Silva Júnia C. A. Silva DC- UFSCar 2003

Projeto e Desenvolvimento de Sistemas
Sistemas:
◦ Conjunto de partes coordenadas que concorrem para a realização de um determinado objetivo
◦ Conjunto de elementos identificáveis que tem entre si relações e que atuam segundo um objetivo
Projeto e Desenvolvimento de Sistemas: O que é?
Um processo de desenvolvimento de software pode ser visto como um conjunto de atividades organizadas,
usadas para definir, desenvolver, testar e manter um software.
◦ Alguns objetivos do processo de desenvolvimento:
 Definição das atividades a serem executadas;
 Quando determinada atividade deve ser executada;
 Pessoa ou grupo a executar tais atividades;
 Padronização no processo de desenvolvimento.
Determinar o objetivo do sistema, definir o papel do hardware, software, pessoal, base de dados e
procedimentos, obter, analisar, especificar, modelar, validar e gerencias os requisitos
Antes de fabricar o software deve-se entender o sistema no qual está inserido
https://www.google.com.br/url?sa=i&source=images&cd=&ved=2ahUKEwjt4v3bovfcAhWEgJAKHYPWB6cQjxx6BAgBEAI&url=https%3A%2F%2Fslideplayer.com.br%2Fslide%2F341643%2F&psig=AOvVaw0TmeX6ZLvLliHG8zI
mQND0&ust=1534704386892732
https://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de-software/5413
Engenharia de Sistemas
Projeto e Desenvolvimento de Sistemas: O que é?
Independente do processo de desenvolvimento, há as seguintes atividades básicas:
 Levantamento de requisitos;
 Análise de Requisitos;
 Projeto;
 Implementação;
 Testes;
 Implantação.
https://www.google.com.br/url?sa=i&source=images&cd=&ved=2ahUKEwjt4v3bovfcAhWEgJAKHYPWB6cQjxx6BAgBEAI&url=https%3A%2F%2Fslideplayer.com.br%2Fslide%2F341643%2F&psig=AOvVaw0TmeX6ZLvLliHG8zI
mQND0&ust=1534704386892732
Atividades Básicas
Levantamento de Requisitos:
◦ Objetivo: compreender as necessidades dos clientes em relação ao sistema a ser desenvolvido. Levantar e priorizar as necessidades
(requisitos) dos futuros usuários do software
compreender o problema desenvolvedores e usuários devem ter a mesma visão do que deve ser construído
Análise de Requisitos (especificação de requisitos)
◦ Objetivo: estudo detalhado dos dados levantados na atividade anterior  construção dos modelos que representam o sistema de
software a ser desenvolvido. ( estratégia da solução)
◦ Definir o que o sistema deve fazer, antes de definir como o sistema irá fazer.
◦ Realizar a validação e verificação dos modelos construídos, antes de partir para solução do problema.
◦ Validação: tem por objetivo, assegurar que o sistema de software está atendendo às reais necessidades do cliente;
◦ Verificação: verifica se os modelos construídos na análise estão em conformidade com os requisitos do cliente.
Como esta especificação precisa ser validada por clientes e usuários, normalmente ela é feita através de uma notação informal, como
a linguagem natural, ou usando uma linguagem gráfica semi-formal como UML
Atividades Básicas
Projeto
• Objetivo: definir como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos
• Aspectos a considerar: arquitetura do sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de
Dados (SGBD) utilizado, padrão de interface gráfica, entre outros.
◦ No projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, e deve ser coerente com a
descrição realizada na fase de análise de requisitos.
◦ O projeto OO possui duas atividades básicas:
◦ projeto da arquitetura (ou projeto de alto nível): visa distribuir as classes de objetos relacionados do sistema em subsistemas e
seus componentes, distribuindo também esses componentes pelos recursos de hardware disponíveis. Normalmente é realizado
por um arquiteto de software
◦ projeto detalhado (ou projeto de baixo nível): visa modelar as relações de cada módulo para que realizem as funcionalidades do
módulo,desenvolver o projeto de interface com o usuário e o projeto de banco de dados .
Atividades Básicas
Implementação
• Objetivo: codificar o sistema a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna
possível a compilação e geração do código-executável para o desenvolvimento software. Em PDOO, a implementação se dá,
definindo as classes de objetos do sistema em questão, fazendo uso de linguagens de programação ou frameworks de
desenvolvimento ( que podem fazer o uso de ferramentas CASE, que dinamizam o processo de desenvolvimento, nas várias
atividades, onde inclui-se geração de código-fonte, documentação, etc.)
Testes
• Objetivo: validar o produto de software, testando cada funcionalidade de cada módulo, levando em consideração a especificação
feita na fase de projeto. Ao final dessa atividade, os diversos módulos do sistema são integrados, resultando no produto de software.
Implantação
• Objetivo: instalar o software no ambiente do usuário. Inclui os manuais do sistema, importação dos dados para o novo sistema e
treinamento dos usuários para o uso correto e adequado do sistema. Em alguns casos quando da existência de um software anterior,
também é realizada a migração de dados anteriores desse software.
Fronteira entre Análise e Projeto
Principais funções de AOO:

Principais funções de POO:
– Identificar as funcionalidades e entidades do sistema
– Atribuir responsabilidades às entidades do sistema
– Encontrar abstrações adequadas para representar o
– Encontrar abstrações adequadas para representar a solução
problema
Ambos são representados através de modelos

Modelos de Software
O que são modelos?
◦ Um modelo pode ser visto como uma representação idealizada de um sistema que se planeja construir.
– Abstrações da realidade
– Focam somente no que realmente
interessa para um
determinado observador em um dado
momento
É uma simplificação da realidade:
Planos de detalhes, podem ser
estruturais (organização do
sistema) ou comportamentais
(dinâmica do sistema
Modelos são construídos para permitir um melhor entendimento sobre o sistema que está sendo construído: especificar a estrutura e comportamento;
guia para construção do sistema; documentam as decisões tomadas
Nenhum modelo único é suficiente Conjunto de modelos independentes.
11
Razões para construção de modelos
a construção de modelos como uma atividade que atrasa o desenvolvimento do software propriamente dito?
Mas essa atividade propicia...
◦ O gerenciamento da complexidade inerente ao desenvolvimento de software.
◦ A comunicação entre as pessoas envolvidas.
◦ A redução dos custos no desenvolvimento.
◦ A predição do comportamento futuro do sistema.
– Possibilitar a comunicação entre pessoas

– Permitir lidar com problemas complexos
– Testar hipóteses antes de realizá-las
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição

12
Razões para construção de Modelos
Formas de Modelos
Modelos de processo desoftware
Um conjunto de atividades fundamentais exigida para desenvolver um sistema de
software
Especificação.
Projeto e implementação.
Validação.
Evolução.
Um modelo de processo de software é uma representação abstrata de um processo.
Representa uma descrição de um processo a partir de uma perspectiva particular.
15
Diagramas e Documentação
No contexto de desenvolvimento de software, correspondem a desenhos gráficos que seguem algum
padrão lógico.
Podemos também dizer que um diagrama é uma apresentação de uma coleção de elementos gráficos que
possuem um significado predefinido.
Diagramas normalmente são construídos de acordo com regras de notação bem definidas.
◦ Ou seja, cada forma gráfica utilizada em um diagrama de modelagem tem um significado específico.

16
Por que Modelar? resumo
Abstração
Melhor entendimento e maior compreensão
Visualização
Visualização antecipada antes da implementação
Visões complementares do software
Especificação
Descrição precisa do que deve ser feito
Construção
Geração automática com ferramentas baseadas em modelos
Documentação
Comunicação entre equipes na diferentes fases do ciclo de vida
17
Por que modelar?
Comunicar a estrutura e o comportamento desejado de um sistema.
Visualizar e controlar a arquitetura de um sistema.
Para melhorar o nosso entendimento de um sistema e, assim, expor oportunidades para melhorias e
reutilização.
Para administrar os riscos
A UML (Linguagem de Modelagem Unificada) permite modelar:
Elementos;
Relacionamentos;
Mecanismos de extensibilidade;
Diagramas
18
UML (Linguagem de Modelagem Unificada)
“A UML é a linguagem padrão para: Object Modeling

◦ visualizar, Technique
◦ especificar,
◦ construir e
◦ documentar
os artefatos de software de um sistema.”
- Mentores: Booch, Rumbaugh e Jacobson

◦ “Três Amigos”-
- Mantida pelo: Object Management Group (OMG),

com contribuições e direitos de autoria das seguintes
empresas: Hewlett- Packard, IBM, ICON Computing, i-
Logix, IntelliCorp, Electronic Data Services, Microsoft,
ObjecTime, Oracle, Platinum,Ptech, Rational, Reich, Object
Softeam, Sterling, Taskon A/S e Unisys IBM Rational Oriented
(www.rational.com) Software
Engineering
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 19
Modelos x Diagramas
O modelo contém toda a informação que representa o problema ou a solução
O diagrama é uma visualização de parte de um modelo sob uma perspectiva
Se está no diagrama, está no modelo

se não está no diagrama, pode ou não estar no modelo
UML: Para que serve?
“A UML é a linguagem padrão para: visualizar, especificar, construir e documentar os artefatos de software de um sistema.”
Visualização:
A existência de um modelo visual facilita a comunicação Construção:
e faz com que os membros de um grupo tenham a Geração automática de código a partir do modelo visual.
mesma ideia do sistema. Geração do modelo visual a partir do código
Cada símbolo gráfico tem uma semântica bem definida. Ambientes de desenvolvimento de software atuais
permitem mapeamentos em ambos sentidos e
O que modelamos? manutenção da consistência entre as duas visões.
Dimensões: dados, função, comportamento
Especificação: Documentação:
•Especificar significa construir modelos precisos, sem •Artefatos como requisições de negócios, modelo de
ambiguidades e completos. arquitetura, código fonte, modelo de análise, protótipo e
•A UML atende todos os requisitos de especificação outros documentos, pode ser documentados com a UML.
dentro de um processo, desde a fase de análise até a fase
de testes e implementação do sistema concluído
Por que usar UML?
oSuporta todo o ciclo de vida do software
oSuporta diversas áreas de aplicação
oÉ baseado na experiência e necessidades da comunidade de utilizadores
oÉ suportado por muitas ferramentas
Por que usar UML?
oÉ padronizado (garante organização).
oComunicar a estrutura e o comportamento desejado de um sistema.
oVisualizar e controlar a arquitetura de um sistema. UML oferece uma descrição Arquitetônica do Sistema,
isto é, uma forma padrão de se desenhar as “plantas” (como em arquitetura) de um sistema de forma a
incluir
 aspectos abstratos (processos de negócio, funcionalidades do sistema)
 aspectos concretos (classes C++/Java esquemas de bancos de dados, componentes de
software reutilizáveis)
oPara melhorar o nosso entendimento de um sistema e, assim, expor oportunidades para melhorias e
reutilização.
oUtilização de uma notação padronizada que abrange qualquer tipo de sistema.
oFacilidade no entendimento da orientação a objetos.
oConceito em realidade.
Componentes da UML
A estrutura de conceitos da UML consiste num conjunto variado de notações, as quais
podem ser aplicados em diferentes domínios de problemas e a diferentes níveis de
abstração. Pode ser vista através das seguintes noções:
• “Coisas” ou elementos básicos, com base nos quais se definem os modelos;

• Relações, que relacionam elementos;
• Diagramas, que agrupam elementos.
Os elementos estão organizados considerando a sua funcionalidade ou responsabilidade.

Os elementos existentes são de estrutura, comportamento, agrupamento e de anotação.
Diagramas da UML
Um diagrama na UML é uma apresentação de uma coleção de elementos gráficos que possuem um
significado predefinido.
◦ No contexto de desenvolvimento de software, correspondem a desenhos gráficos que seguem algum padrão lógico.
Um processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação de
diversos documentos.
◦ Estes documentos, denominados artefatos de software, podem ser textuais ou gráficos.
Os artefatos gráficos produzidos no desenvolvimento de um SSOO são definidos através dos diagramas da
UML.
oA UML 2.0 possui 13 diagramas, que servem para especificar a estrutura de um sistema.
oOs diagramas da UML estão organizados em conjuntos ou categorias distintas, cada categoria visando
apoiar um tipo de modelagem.

25
Diagramas da UML 2.0
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 26

Para que tantos diagramas?
 O objetivo é fornecer múltiplas visões do software a ser modelado.
 Cada diagrama da UML analisa o sistema, ou parte dele, sob uma
determinada óptica.
 A utilização de diversos diagramas permite que falhas sejam descobertas.
Organização Comportamento
Para que usar os diagramas UML?
oOs diagramas UML são usados para:
• Ajudar a conceber as ideias, em relação ao sistema que estivermos projetando;
• Pensar antes de codificar;
• Apresentar as ideias ao grupo de forma que todos possam interagir e discutir um determinado
ponto;
• Aumentar a participação e envolvimento do time;
• Documentar as ideias quando elas já estiverem bem consolidadas para que novos integrantes e
novos colaboradores possam acelerar sua compreensão dos sistemas desenvolvidos pelo grupo.
Diagrama: revisão
Um diagrama provê uma parcial representação do sistema.
Ele ajuda a compreender a arquitetura do sistema em desenvolvimento.
Os diagramas:
Caso de uso, classes, sequência, objeto, colaboração, atividade, estado, implantação, pacotes,
componentes
30
Diagramas de classes
Diagramas de classe são a espinha

dorsal da maioria dos métodos
orientados a objeto, inclusive UML
Descrevem a estrutura estática do

sistema (entidades e relacionamentos)
31
Diagramas de pacotes
Organizam elementos do sistema em
grupos relacionados a fim de minimizar a
dependência entre eles
32
Diagramas de objetos
Descrevem a estrutura estática de um

sistema em um determinado
momento
Podem ser usados para testar a

precisão dos diagramas de classe
33
Diagramas de casos de uso
Modelam a funcionalidade do sistema

através de atores e casos de uso
Casos de uso são serviços ou funções

fornecidas pelo sistema aos seus usuários
34
Diagramas de seqüências
Descreve as interações entre as classes

através das trocas de mensagens ao
longo do tempo
35
Diagramas de Comunicação
Representam as interações entre

objetos em termos de mensagens
em seqüência
Descrevem tanto a estrutura

estática como o comportamento
dinâmico do sistema
36
Diagramas de estados
Descrevem o comportamento dinâmico

do sistema em resposta a estímulos
externos
São especialmente úteis para modelar

objetos reativos cujos estados são
disparados por eventos específicos
37
Diagramas de atividades
Ilustram a natureza dinâmica de um sistema
modelando o fluxo de controle de uma
atividade para outra
Uma atividade representa uma operação em
uma classe do sistema que resulta na
mudança do estado do sistema
Tipicamente, são usados para modelar
fluxo de trabalho ou processos de
negócio e funcionamento interno
38
Diagramas de componente
Descreve a organização dos
componentes físicos de software
Ex.: código-fonte, código em tempo

de execução (binário) e executáveis
39
Diagramas de implantação
Descrevem os recursos físicos em um

sistema, incluindo nós, componentes e
conexões
40
Aplicando UML no projeto de sistemas
Identificação de requisitos Projeto:

funcionais/análise: •Diag. de Seqüência
Diag. de Caso de uso •Diag. de Atividade
Diag. de Seqüência •Diag. De Estados
Diag. de Atividade •Diag. de Objetos
•Diag. de Classes
•Diag. de Componentes
•Diag. de Implantação
(deployment)
Resumo
oUML é...
• Uma linguagem visual.
• Independente de linguagem de programação.
• Independente de processo de desenvolvimento.
oUML não é...

• Uma linguagem de programação.
• Uma técnica de modelagem.
Exemplo
Revendedora de Automóveis
Uma revendedora de automóveis deseja automatizar os
registros de venda e de seus serviços de manutenção.
Para isso, deseja manter informações sobre os carros novos e
vendidos, clientes, e serviços prestados a esses clientes com
seus carros (troca de peça, revisão, etc).
Deseja-se que o sistema possa gerar relatórios de vendas, de
clientes, de carros novos, de serviços.
https://pt.slideshare.net/andreconstantino/uml-exemplos-de-modelagem-em-uml
Substantivos
• Atores (fonte de informação/solicitação ao sistema) •Atributos dos
Cliente (Gerente) objetos
• Objetos
(coisas sobre as quais os sistema quer guardar informações) •Novos
•Carro •Vendidos
•Venda
•Serviços de manutenção
•Cliente
•Troca de peças
• Agentes (meio entre ator e sistema) •revisão
Verbos de ação
Funções do sistema use case
(sistema) manter informações sobre carros (novos e usados)

(sistema) manter informações sobre clientes
(sistema) manter informações sobre serviços prestados
(sistema) gerar relatório de vendas
(sistema) gerar relatório de clientes
(sistema) gerar relatório de carros novos
(sistema) gerar relatório de serviços
Tabela e Eventos
nº descrição entrada saída Use case
1 Cliente compra carro dadosVenda Msg1, Carro comprarCarro
2 Cliente solicita serviço de manutenção dadosManu Msg2 fazerManutenção
tenção, carro
3 Cliente retira carro após manutenção carro retirarCarroManutenção
Funcionário registra serviço efetuado dadosManute Msg4 adionarServiçoManutenção

nçãoServiço
5 Cliente solicita cadastro dadosCliente Msg5 cadastrarCliente
6 É hora de imprimir relatório de vendas Relatório imprimirRelatórioVendas
Vendas
7 É hora de imprimir relatório de clientes Relatório IiprimirRelatórioClientes
Clientes
8 É hora de imprimir relatório de carros Relatório imprimirRelatórioCarrosNovos
novos CarrosNovos
9 É hora de imprimir relatório de serviços Relatório de imprimirRelatórioServiços
serviços
Casos de Uso para o ator Cliente
c adast rar C li ente
dados C liente
m sg5
dados V end a
dados Manutenç ão, c arro
c om pr arCar ro ms g2 faz erM anutenç ão

m s g1, c arro A torC liente
c ar ro
retirarC arroM anutenç ão

Casos de Uso para atores Funcionário e Gerente
dados Manut enç ãoS erviç o
Im prim irR elatórioV endas

A torF unc ionário A dic ionarS erviç oM anut enç ão
m s g4
Re lat óri oV enda s
dad os Carro
Relatório Clientes
c adas trarC arro

m s g6 Im prim irR elat ório C lientes
A torG erent e
Re lat óri oC arrosN ov os

Rela tórioS erviç os
Im prim irR elatórioS erviç os Im prim irR elatório C arros Novos

Descrição do caso de uso: comprarCarro
dado sVe nda
Curso Normal
1.O cliente informa as características do carro
desejado;
Compr arCar ro
2.O sistema obtém todos os carros disponíveis para m s g1, c arro A torCliente
venda;
3.O sistema exibe os carros disponíveis para venda Cursos Alternativos
ao cliente;
4.O cliente informa ao sistema o carro escolhido; Caso 1: Não existe carro disponível para venda com as
5.O sistema verifica se este cliente já está características solicitadas pelo cliente.
cadastrado; 3.O sistema emite a msg1 'Nenhum carro disponível para
6.Em caso afirmativo, o sistema solicita confirmação venda com tais características'
do cliente; 4.Finalizar caso de uso.
7.O cliente confirma a compra;
8.O sistema cadastra a nova venda; Caso 2: O cliente não foi cadastrado.
9.O sistema altera a situação do carro para 6.O sistema emite a msg1 'Cliente não cadastrado';
'vendido'; 7. Finalizar caso de uso.
10.O sistema emite a msg1 'Carro vendido'.
Diagrama de Seqüência – comprarCarro (curso normal)
: V enda : C arroV enda : C liente
1.O cliente informa as características do carro : A torC liente
desejado; dad os Carro

2.O sistema obtém todos os carros disponíveis para
V enderC arro( )
venda;
obt erCar ros Di sponívei s( )
3.O sistema exibe os carros disponíveis para venda
ao cliente; c arros Dis po níveis
4.O cliente informa ao sistema o carro escolhido;
5.O sistema verifica se este cliente já está carr oE s c olhido, dados Cli ente
cadastrado; V erific arC liente Cadas trado( )
6.Em caso afirmativo, o sistema solicita confirmação 'c adas tr ado'

do cliente;
s olic itaç ãoC onfirm aç ã o
7.O cliente confirma a compra;
8.O sistema cadastra a nova venda; c onfirm aç ão
9.O sistema altera a situação do carro para Cadast rar NovaV enda( )
'vendido';
alterarS ituaç ão ( " vendido" )
10.O sistema emite a msg1 'Carro vendido'. o'
m s g1 'Carro vendid
Diagrama de Seqüência – comprarCarro (cursos alternativos)
: V enda : C arro V enda : C liente

: A torC liente
dados V enda
: V en da : C arroV enda
: A to rClien te
V enderC arro( )
dado sV end a obt erC ar ros D i sponí vei s( )
V ende rCarro( )
c arros D is p o níveis
obt erC arros Dis po níveis ( )

c arr o E s c olh ido
m s g1 'Nen hum c ar r o dis pon ível para venda c om tais c arac terís tic as '
dados C liente
V erific arC lient e Cadas trado( )
'não c a das trado'
m s g1 'Cliente não c a das trado'

Descrição do caso de uso: fazerManutenção
dados Manutenç ão, c arro
Curso Normal
1.O cliente informa os seus dados;

faz erMan utenç ão
2.O sistema verifica se o cliente já está A torC liente m s g2
cadastrado;
3.Em caso afirmativo,verifica quais carros
Cursos Alternativos
foram comprados pelo cliente;
4.O sistema solicita a escolha do carro que vai Curso 1: O cliente não está cadastrado.
para a manutenção; 3.Em caso negativo, sistema emite a
5.O cliente informa o carro; msg2 'Cliente não cadastrado'.
6.O sistema solicita o motivo do serviço; 4.Finalizar caso de uso.
7.O cliente informa o motivo do serviço;
8.O sistema cadastra o serviço; Curso 2: O cliente não comprou carro.
9.O sistema emite a msg2 'Carro enviado para 4.O sistema emite a msg2 'Cliente não
realizar o serviço'. comprou carro nesta revendedora'.
5.Finalizar caso de uso.
Diagrama de Seqüência – fazerManutenção(curso normal)
Curso Normal : S erviç o : C liente : Carro
: A tor Cli ente
1.O cliente informa os seus dados;
dados Cliente
2.O sistema verifica se o cliente já está V erific arC lient eC adas trado( )
cadastrado; 'c adas trado'
3.Em caso afirmativo,verifica quais
carros foram comprados pelo cliente; obterC arroCom pradoC liente( )
4.O sistema solicita a escolha do carro 'c arros c om prado s lis t a de c arros
que vai para a manutenção; s olic i ta ç ãoE s c olh aCa rro
5.O cliente informa o carro; c arro
6.O sistema solicita o motivo do serviço; s olic itaç ãoM otivoS erviç o
7.O cliente informa o motivo do serviço; m otivoS erviç o
8.O sistema cadastra o serviço; s olic i taS erviç o( )
9.O sistema emite a msg2 'Carro m s g2 'C arro enviado para r ealizar o s erviç o'
enviado para realizar o serviço'.

Diagrama de Classes
V enda
data
C li ente C arro
nome 0 ..1 0. .n p lac a
c om pra
endereç o fabr ic a nte
telefone m odelo
envia para s erviç o
CP F 1 1. .n a no
S erviç o
des cr iç ão
preç o
Diagrama de Classes V enda
data
Cli ente C ar ro
n ome 0. .1 0.. n plac a
c om pra
e ndere ç o fabric ante
t elefo ne m odelo
envia para s erviç o
CP F 1 1.. n ano
S erviç o
des cr iç ão
preç o
Revis ão Troc aP eç as
Diagrama de Classes (atributos e métodos)
Ca rro
pla c a
fab ricante
1
m odelo é en viado
an o
verific arC arroC ada s tra do()

alt erarS it uaç ão() 0..n
0..n M anut enç ão

dataS oli c itaç ã o S erviç o
CarroV enda s ituaç ão des c riç ão
situaç ão pos sui m ot ivo pre ç o
real iza
ob terC arros D is pon íveis () ad Ca das trarMa nut en ç ão() Im prim irRelató rioS erviç os ()
V e rific arE x is tên c iaM an utenç ão() 0. .n 1..n adic iona rS ervic oR elatorio ()
ic io narC arroR elato rio() im
prim irRe la tórioC arros Novos () V erific arTérm inoM anut enç ão() obt erTod os S erviç os () loc
A lt erarS itua ç ã o () lo c aliz aliz arS e rviç o () ex ibirS
0..n
0.. n arMa nut en ç ão() adic ionarS er erviç os ()
Clie nte viç o Rea liz ado()
nom e 0..n
com pra ende reç o
telefon e
solic ita
CP F
0. .1 1
V erific arC lient eC adas trado()
O bt erTod os C lie ntes () Im
prim irRelató rioC lientes ()
V end a adic iona rClie nteR elató rio()
data
V e nderC arro() Ca das

trarN ovaV enda() i mp ri
mirR elat óri oV endas () obt
er Toda sV endas () adic i
onar Ve nd aR elatór io()
Mais sobre os
diagramas
HT TPS://WWW.LUCIDCHART.COM/PAGES/PT/MODELOS -E-
EXEMPLOS-DE-DIAGRAMAS-UML
Diagramas de Caso de Uso
Representação visual dos itens
do Escopo
Auxílio ao usuário final no
entendimento do que será
desenvolvido
Formaliza o Escopo
Diferencia os vários papéis
dentro do Sistema
Diagramas de Classes
Refere-se a descrição de um
conjunto de objetos que
compartilham os mesmos
atributos, operações, relações e
semântica.
UML sugere capitalizar todas as

primeiras letras de cada palavra
no nome (ex.: ``Lugar'',
``DataReserva'').
Uma boa pratica é manter nomes

de classe no singular, classes por
padrão “contem” mais de um
objeto, o plural é implícito. .
[NicolasAnquetil]
Diagramas de Classes:
Diferença entre Classes x Objetos
Funcionário
Nome: João
data_admissão:12/12/2000
CPF: 111111111
salário_base:1000.00
Classes
Estrutura
Define as características que um conjunto de elementos (objetos) tem em comum
Durante a modelagem do sistema definimos CLASSES
Objetos
Instância (ocorrência)
Na execução do sistema o que existe é um conjunto de OBJETOS
Diagrama de Objetos
Usado na modelagem de estrutura de objetos
Fornece uma visão instantânea (“congelada”)
de um conjunto de objetos no Sistema,
descrevendo o estado de cada objeto e as
relações que existem entre esses objetos em
um dado ponto no tempo.
A representação de um objeto (instância) é
semelhante ade uma classe:
◦ No compartimento do nome, indica-se o nome do
objeto (variável de referência) seguido por : (dois
pontos) e o nome da classe que o objeto
representa, e ambos sublinhados.
◦ O nome da referência pode ser omitido,
resultando assim em uma instância anônima.
◦ No compartimento dos atributos, indica-se o valor
dos atributos em um determinado momento da
execução do sistema.
Diagrama de Pacotes
Um Diagrama de Pacotes
demonstra o agrupamento das
classes e/ou interfaces.
Um pacote é representado por

um retângulo com uma aba no
canto esquerdo da borda superior
Modelo
Modelo
Cliente Produto
Diagrama de Pacotes
Um Diagrama de Pacotes
demonstra o agrupamento das
classes e/ou interfaces.
Demonstra a decomposição de
um sistema: em subsistemas, em
um sistema de camadas
Um pacote é representado por

um retângulo com uma aba no
canto esquerdo da borda superior
Modelo
Cliente Produto
Diagrama de Pacotes
Demonstra a decomposição em subsistemas: Demonstra a decomposição em camadas:
<<tier>> <<tier>> <<tier>> <<tier>>
Cliente Apresentação Negócio Dados
<<System>>
Banco Online
<<Subsystem>> <<Subsystem>> <<Subsystem>>
Apresentação Relatórios Administração

Diagrama de Atividades
Diagrama comportamental
(visualiza aspectos dinâmicos)
usado para modelar o fluxo de
trabalho (fluxo de uma atividade
para outra).
Descreve o fluxo de eventos de
um cenário de um Caso de Uso.
Similar a um fluxograma usado
em Lógica de Programação.
Diagramas de Interação
Os Diagramas de Interação são usados para modelar o comportamento dinâmico do sistema. Descrevem os
fluxos de controle, como os objetos interagem durante a execução de uma tarefa do sistema.
Demonstram as trocas de mensagens entre os objetos.
São divididos em quatro tipos:
• Diagrama de sequência (ênfase no tempo )
• Diagrama de Colaboração / Comunicação (ênfase na organização dos objetos)
• Diagrama de Tempo
• Diagrama de Visão de Interação
Diagrama de Sequência
Demonstra a troca de mensagens entre
os objetos do sistema em uma ordem
temporal. (ênfase à ordem em que as
mensagensentre objetos são trocadas.)
Mostra visualmente o fluxo de controle

ao longo do tempo.
Linha de Vida do Objeto: tracejada

vertical ligada a um objeto.Representa a
existência desse objeto em um período
de tempo.
Foco de Controle (barra de ativação /

barra de execução) : Retângulo estreito
sobre a linha de vida que mostra o
período durante o qual um objeto está
desempenhando uma ação.
Mensagem / Chamada de método.

Diagrama de Colaboração ou Comunicação
Demonstra a troca de mensagens
entre os objetos do sistema de
forma a capturar as relações
estruturais entre eles.
Mostra como os objetos estão

vinculados
Diagrama de Colaboração
Diagrama de Estados
Descreve o ciclo de vida de um objeto,
mostrando seus possíveis estados e as
transições entre eles como respostas a eventos
durante a sua existência.
• Estado: é uma condição ou situação em que
um objeto se encontra num determinado
momento
. É representado por um retângulo de cantos arredondados.
Estado Inicial e Final: Estados especiais que definem
respectivamente o início e o fim do ciclo de vida.
◦ Transições (“Eventos”): é um relacionamento

entre dois estados, indicando a mudança de
um estado para outro após a realização de
certas ações.
◦ São representadas por uma linha contínua com uma seta
apontando do estado origem para o estado final.
◦
Diagrama de estados
◦ Uma transição é formada por cinco partes:
◦ Estado de Origem: Estado em que o objeto
se encontra quando recebe um evento de
ativação para realizar uma troca de estado
◦ Evento de Ativação: Estímulo que ocorre
em um objeto, capaz de disparar uma
transição de estado.
◦ Condição de Proteção / Condição de
Guarda: Expressão booleana entre
colchetes que é avaliada quando uma
transição é iniciada pelo evento de
ativação e define se a transição será ou
não executada.
◦ Ação: Computação que pode ocorrer em
uma transição,.
◦ Estado Destino: estado final da troca
Diagrama de Componentes
Um componente é uma parte
substituível e executável de um
sistema cujos detalhes de
implementação são ocultos.
Pode ser reutilizado em vários sistemas
sem a necessidade de modificar sua
implementação.
É representado por um retângulo com dois
outros retângulos menores na borda
esquerda ou através de um retângulo com
um ícone de componente no canto
superior direito.
Relação de dependência: um componente pode usar
uma ou mais Interfaces
– Um componente que usa outro componente através
de uma interface bem definida, não deve depender da
implementação (do componente em si), mas apenas da
interface)
Diagrama de
Implantação/Implementação/Desdobramento
Modela como o sistema está fisicamente
distribuído demonstrando a configuração
dos nós de processamento e os
componentes executados nesses nós.
Nó: é um elemento físico que representa
um recurso computacional. Executa
componentes. É representado por um cubo.
Os diagramas de implementação são
empregados para a modelagem da visão
estática da implementação de um sistema.
Em geral, envolve a modelagem da
topologia do hardware em que o sistema é
executado;
São utilizados para visualizar, especificar e
documentar sistemas embutidos,
cliente/servidor, distribuídos e
gerenciamento de sistemas xecutáveis;
Diagrama de
Implantação/Implementação/Desdobramento
Casos de uso
Diagrama de Classes
Diagrama de Atividade
Diagrama de sequência

Introducao V5

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

Introducao V5

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento de

Engenharia de requisitos: https://www.dimap.ufrn.br/~jair/ES/c3.html

Fonte: André Constantino da Silva Júnia C. A. Silva DC- UFSCar 2003

Principais funções de AOO:

Ambos são representados através de modelos

Nenhum modelo único é suficiente Conjunto de modelos independentes.

– Possibilitar a comunicação entre pessoas

Princípios de Análise e Projeto de Sistemas com UML - 2ª edição

Princípios de Análise e Projeto de Sistemas com UML - 2ª edição

“A UML é a linguagem padrão para: Object Modeling

- Mentores: Booch, Rumbaugh e Jacobson

- Mantida pelo: Object Management Group (OMG),

Se está no diagrama, está no modelo

• “Coisas” ou elementos básicos, com base nos quais se definem os modelos;

Os elementos estão organizados considerando a sua funcionalidade ou responsabilidade.

Princípios de Análise e Projeto de Sistemas com UML - 2ª edição

Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 26

Diagramas de classe são a espinha

Descrevem a estrutura estática do

Descrevem a estrutura estática de um

Podem ser usados para testar a

Modelam a funcionalidade do sistema

Casos de uso são serviços ou funções

Descreve as interações entre as classes

Representam as interações entre

Descrevem tanto a estrutura

Descrevem o comportamento dinâmico

São especialmente úteis para modelar

Ex.: código-fonte, código em tempo

Descrevem os recursos físicos em um

Identificação de requisitos Projeto:

oUML não é...

Funções do sistema use case

(sistema) manter informações sobre carros (novos e usados)

Funcionário registra serviço efetuado dadosManute Msg4 adionarServiçoManutenção

c adast rar C li ente

c om pr arCar ro ms g2 faz erM anutenç ão

retirarC arroM anutenç ão

dados Manut enç ãoS erviç o

Im prim irR elatórioV endas

c adas trarC arro

Re lat óri oC arrosN ov os

Im prim irR elatórioS erviç os Im prim irR elatório C arros Novos

desejado; dad os Carro

cadastrado; V erific arC liente Cadas trado( )

6.Em caso afirmativo, o sistema solicita confirmação 'c adas tr ado'

: V enda : C arro V enda : C liente

dado sV end a obt erC ar ros D i sponí vei s( )

obt erC arros Dis po níveis ( )

'não c a das trado'

m s g1 'Cliente não c a das trado'

1.O cliente informa os seus dados;

que vai para a manutenção; s olic i ta ç ãoE s c olh aCa rro

5.O cliente informa o carro; c arro

7.O cliente informa o motivo do serviço; m otivoS erviç o

8.O sistema cadastra o serviço; s olic i taS erviç o( )

enviado para realizar o serviço'.

verific arC arroC ada s tra do()

0..n M anut enç ão

V e nderC arro() Ca das

UML sugere capitalizar todas as

Uma boa pratica é manter nomes

Um pacote é representado por