Desenvolvimento de Softwares e Modelagem de Sistemas

Prévia do material em texto

Prof.: JOSE CARLOS MILLAN 
O desenvolvimento de softwares no mercado requer cada vez mais o conhecimento do processo de negócio e as 
informações que são produzidas, pois o valor agregado da tecnologia nas empresas está centrado no potencial dos 
sistemas em extrair conhecimento e colaborar para as estratégias e tomadas de decisão. Sendo assim a modelagem 
tem uma importância fundamental na medida em que oferece suporte para investigação, conferência e validação 
dos procedimentos apreendidos durante as etapas de definição. Quanto mais aderência a realidade do usuário o 
sistema estiver, maior é o sucesso nos resultados. 
A linguagem de representação utilizada na disciplina oferece uma diversidade de modelos para representação das 
partes físicas e lógicas do sistema em desenvolvimento. 
A capacidade de representação do negócio através de modelos da UML e ter visibilidade para a construção do 
sistema são competências que devem ser desenvolvidas no aluno nesta disciplina. 
Ao final dessa disciplina você será capaz de: 
•Identificar requisitos funcionais e não-funcionais para representação em modelos; 
•Utilizar os modelos da UML; 
•Construir modelos baseados na UML; 
•Analisar a melhor forma de representação do negócio; 
•Conhecer os princípios e práticas da Metodologia RUP; 
•Conhecer o ciclo de vida iterativo e incremental, utilizados no desenvolvimento de software baseado na Orientação 
a Objetos. 
•Definir a ordem de desenvolvimento das iterações do sistema. 
•Conhecer a Metodologia RUP e a técnica de definição da ordem de desenvolvimento; 
•Empregar as técnicas de acordo com a natureza do modelo a ser desenvolvido; 
Nesta aula, você irá: 
 
1 - Diferenciar mundo real e mundo simbólico; 
 
2 - Listar as fases do processo unificado; 
 
3 - Definir uma iteração; 
 
4 - Analisar aspectos importantes para a modelagem de sistemas; 
 
5 - Aprender sobre o produto RUP para modelagem; 
Você sabe o que é mundo real? E mundo simbólico? 
Neste tópico, vamos desenvolver esses conceitos. 
 
 
 
Processo Unificado 
O Processo Unificado é iterativo e consiste em subdividir o projeto para sua implementação por partes. O PU é 
constituído de atividades divididas em quatro fases: 
I – Fase da Concepção - Nesta fase se “imagina” o produto, o que fará. Seu objetivo e suas principais funções. Pode-
se fazer uma estimativa, ainda que “grosseira” de prazos e custo. Pode-se “imaginar como funcionária a sua função 
principal”. Nessa fase, decide-se se o produto é viável ou não. Pode-se dizer que, nessa fase, definimos o ESCOPO do 
produto, definindo o que faz e quais as suas limitações. 
II- Nesta fase pegamos cada função, segundo o escopo do produto, e lhe damos um tratamento técnico, definindo 
como será feito. Nessa fase, o que se “imaginou” na fase anterior deve ganhar forma, isto é, deve ser 
viabilizado. Inicia-se a identificação de requisitos funcionais (necessidade do usuário) e não funcionais (necessidades 
técnicas), para implementar as funções do produto. Nessa fase surge o projeto. 
III- As definições feitas na fase de elaboração são construídas. No caso de software, nesta fase fazemos a 
programação, definimos arquivos, testamos o que se “imaginou” virar realidade. 
IV - Após o produto pronto, ele precisa ser disponibilizado. Nessa fase, fazem-se os ajustes necessários para 
viabilizar o uso do produto. No caso de software, fazem-se as implantações. Ajustes em programas e arquivos já 
existentes. Testes de integração e aceitação. Essa fase é responsável por disponibilizar o produto para uso. 
Exemplo do planejamento de um desenvolvimento em software: 
No primeiro momento, identificamos as tarefas mais evidentes nas fases: 
Concepção: 
 Missão do produto: Apoiar o controle de livros da biblioteca. 
Funções: Registrar o acervo de livros. Controlar os empréstimos. 
Elaboração: 
 
 
 
 
 
 
 
 
 
 
 
 
Nesta aula, você: 
 Atentou para o conceito de mundo simbólico; 
 Percebeu que importante organizar o trabalho em fases; 
 Avaliou a importância das as quatro fases do PU: concepção, elaboração, construção e transição; 
 Compreendeu a importância de subdividir as fases em iterações; 
 Aprendeu como especificar uma iteração; 
 Aprendeu o que o RUP. 
 
1. 
 Marque a afirmativa totalmente correta: 
 1) No Mundo real e mundo simbólico se confundem e sempres se repetem. 
 2) Sistemas existem no mundo real, detro de computadores, assim o processamento é do mundo real. Não existe 
mundo símbólico quando se processa com sistemas de informações informatizados. 
 3) O mundo das representações é igual em várias empresas, assim como o conhecimento que cada pessoa tem. 
 4) Cada empresa tem o seu mundo de representações que depende da lei, da cultura e das pessoas que compõem 
a empresa. 
 5) A analise de sistemas trabalha no mundo real, assim precisamos observar as coisas do mundo real e não como 
as pessoas usam o conhecimento. 
 4 
 2. 
 Abaixo temos a carteira de identidade de Luiz da Silva usa ribeiro 
 Sobre ela veja a afirmativa correta. 
 
 1) A carteira de identidade é do mundo real. É usada por todos não serve para processamento. 
 2) A carteira de identidade é uma imagem que representa uma pessoa para processamentos no mundo simbólico 
do Ministerio de Justiça 
 3) A carteira de identidade é a representação da pessoa, portanto, toda empresa obrigatoriamente incorpora a 
carteira de identidade 
 4) O simbólico da empresa não pode criar as suas próprias representações por isto usa a carteira de identidade. 
 5) A carteira de identidade é diferente do CPF com relação a repesentação dos processamentos de informações 
nos respectivos mundos simbólicos 
 2 
 3. 
 Sobre o processo do software pode-se afirmar que: 
 1) É uma burocracia desnecessária, um programador com experiência não precisa disto. 
 2) é sempre igual para todo e qualquer produto de software 
 3) é uma forma de se controlar o projeto e gera muito mais trabalho 
 4) O programador incia o desnvolvimento do código, e não precisa de processo. É muito mais rápido 
 5) É uma forma de se assegurar que o projeto será feito de forma correta, com método, com qualidade, e pode 
ser gerneciado 
 5 
 4. 
 Sobre o processo unificado escolha a alternativa totalmente correta. 
 1) O processo unificado não permite modificações no projeto. 
 2) Na fase de concepção ou iniciação deve-se definir detalhes do que será construído. 
 3) Na fase de elaboração deve-se detalhar os requisitos funcionais do sistema 
 4) Na fase de construção nada mais pode-se acrescentar, msmo que se identifique falha. 
 5) A programação e definição de arquivos devem ser feitas na fase de concepção. 
 3 
 5. 
 Sobre o RUP podemos afirmar com certeza. 
 1) é uma forma de se implementar o processo de cascatas com “templates” – gabaritos. 
 2) é um produto que é constituído de gabaritos escritos em HTLM geram os programas automaticamente. 
 3) Não permite implementar iterações nas fases de concepção. 
 4) Permite definir uma iteração sempre que necessário 
 5) É um novo processo de desenvolvimento e análise de sistemas, portanto não é um produto. 
 4 
 
Nesta aula, você irá: 
1. Aprender como apareceu a análise por objetos; 
2. Relacionar os objetivos da A.O.O; 
3. Aprender porque surgiu UML; 
4. Relacionar requisitos funcionais e não funcionais; 
5. Relacionar um caso e uso; 
6. Identificar um ator de caso e uso; 
7. Identificar comando de utilização; 
8. Definir estereótipos; 
9. Aprender a dicionarizar um comando de utilização. 
Surgimento do UML 
UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson, que são conhecidos como “os três 
amigos”. UML(Unified Modeling Language) é um conjunto de diagramas padronizados e integrados para ajudar na 
descrição da análise e projeto de um software. O UML, foi propostoem 1976, com objetivo de padronizar o uso de 
ferramentas. Nessa época existiam vários autores, propondo soluções para a modelagem. O surgimento do UML 
possibilitou uma padronização e apóia o projeto de software, desde seu levantamento de requisitos até sua 
implantação. O UML , hoje, é controlado pelo OMG(Object Management Group). 
O UML é um conjunto de diagramas, como mostrado na imagem.
 
Análise Orientada Por Objetos 
A orientação a objetos tem-se desenvolvido desde o lançamento da 1ª linguagem orientada a objetos, a 
SIMULA. Autores consagrados da engenharia de software, como: Peter Coad, Edward Yourdon e Roger Pressman, 
consideram a análise orientada a objetos como o maior avanço para o desenvolvimento de software. 
 A orientação a objetos não é só teoria, mas uma tecnologia de eficiência e qualidade comprovadas, usadas em 
inúmeros projetos e para construção de diferentes tipos de sistemas. 
Quando o sistema é desenvolvido com esta tecnologia, tem-se: 
 
Desenvolvimento Diagramas De Caso E Uso 
Você sabe o que é um requisito de um usuário? Sabe como identificá-lo? 
 
Desenvolvimento Do Diagrama De Caso E Uso 
A documentação de um caso e uso é muito extensiva e, alguns casos e uso, podem apresentar um conjunto de 
tarefas repetidas. Isso quer dizer que estamos documentando duas ou mais vezes a mesma coisa. 
Para evitarmos isso, antes de documentarmos o fluxo principal, podemos analisar a descrição dos casos e uso de 
levantamento e identificarmos conjunto de tarefas iguais. Esse conjunto de tarefas iguais devem ser destacadas, 
pois, um dos nossos objetivos é não gerar redundância e re aproveitar código e isto deve ser feito desde o início da 
análise. 
Assim, no nosso exemplo, conversando com os atores, verificamos que o ação e uso controlar estoque e controlar 
pedido tem um conjunto de tarefas iguais e que se repetiriam no fluxo principal, destes . Ao conjunto de tarefas 
iguais chamamos de Identificar pedido e estamos retirando dos comando e de uso iniciais. 
 
O novo comando de utilização: Identificar pedido- contém as tarefas comuns de identificar pedidos, que são 
realizadas em controlar estoque e controlar pedido. Observe que os arcos estão marcados com a palavra 
include. INCLUDE é o que chamamos de estereótipos, mas não vamos nos preocupar com isto agora. Observe, 
ainda que,a nova elipse também tem a sua descrição, suas condições de pré e pós-condições. E ela é iniciada pelos 
casos e uso, não por atores. Assim, deve-se dicionarizar a nova elipse e indicar a chamada do include nos fluxos dos 
outros caso e uso. 
Nesse diagrama, ainda usamos linhas cheias mas o correto é trabalhar com linhas pontilhadas. As linhas pontilhadas 
indicam que a elipse de identificar pedido só pode existir se existirem as outras duas elipse. É o que chamamos de 
dependência. A linha pontilhada representa a dependência. 
Agora o diagrama esta correto. O dicionário agora ficará na forma: 
 
Existe ainda uma situação que pode acontecer, quando estamos trabalhando, por exemplo, com o incluir 
pedido. Suponha que existe uma situação MUITO particular que pode acontecer, quando se identifica um pedido. 
Nesse caso, vamos destacá-la, para que os desenvolvedores saibam que uma situação condicional que pode 
ocorrer. Vamos também trabalhar com a linha pontilhada, pois, esse novo conjunto de tarefas, que 
representaremos por uma nova elipse – tratar pedido internacional – só poderá existir se a elipse identificar pedido 
existir. Vamos usar o termo EXTENDED, vamos ver isto em seguida. O diagrama com o respectivo dicionário de 
identificar pedido é mostrado na imagem abaixo: 
 
Uso De Estereótipo 
Você verificou que usamos um palavra entre << >>. Isto é, para indicar o que chamamos de estereótipos. Um 
estereótipos é uma série de características que servem para classificar alguma coisa. No diagrama, o estereótipos 
indica que devemos dar o mesmo tratamento de análise e construção, quando formos construir o sistema. Assim, o 
<<include>> indica que devemos tratar todos os arcos da mesma forma (sugiro o tratamento por função ou 
módulo). É comum, também, se usar << use >>, com as mesmas características. 
O << EXTENDED>> indica o tratamento comum. Se eu fosse o desenvolvedor, sempre trataria os elementos gerados 
a partir destas elipses como especiais e os separaria dos demais. Existem, ainda, o << INTERFACE>>, que é o arco 
entre o ator e o comando de utilização, nesse caso se informa que o tratamento de chamada deve ser feito do 
mesmo modo, por exemplo: com telas de entrada. Você pode criar o seu próprio estereótipos, por exemplo: 
<<ORACLE>> pode indicar que você deseja que os elementos da elipse marcadas com este estereótipos deverão ser 
implementadas no ORACLE. O importante é que se apresente o dicionário de estereótipos. 
Erros Comuns 
Muitas pessoas mal informadas consideram o diagrama de caso e uso como se fosse um DFD. Isto é um erro 
grave. O diagrama representa conjunto de atividades. Os arcos não indicam fluxos de dados. São chamadas a 
grupos de atividades. 
Assim, é comum vermos diagramas de caso e uso mal feitos, representando programas, como o mostrado abaixo: 
 
 
 
Nesta aula, você: 
 Aprendeu COMO APARECEU A ANÁLISE POR OBJETOS; 
 Aprendeu quais OS OBJETIVOS DA A.O.O; 
 Aprendeu porque surgiu UML; 
 Analisou com identificar o tipo e requisitos - requisitos funcionais e não funcionais; 
 Aprendeu a diagramar um caso e uso; 
 Aprendeu a identificar um ator de caso e uso; 
 Aprendeu a dicionarizar um comando de utilização; 
 Aprendeu a usar e definir estereótipos; 
 Aprendeu a identificar uma realização de um comando de realização; 
 Aprendeu o que o RUP; 
 Analisou algumas características do RUP. 
Na próxima aula, vamos aprender sobre classes e objetos. Esse diagrama é um dos mais importantes na análise por 
objetos. Você verá que, durante o desenvolvimento, já estamos solucionando muito dos requisitos identificados nos 
diagramas de caso e uso. Muitas pessoas acham que se pode fazer o diagrama de classes em qualquer fase do 
projeto mas, quando trabalhamos focados nos diagramas de caso e uso, evitamos desperdício de esforços. As 
classes que vamos estudar, na próxima aula, são chamadas de classes de domínio ou conceituais. Até lá. 
 
1. 
 Considere a A.O.O para verificar a afirmativa correta abaixo: 
 1) Trata-se de um modismo que serve para colocar novas linguagens no mercado, sem ganho para o desenvolvimento. 
 2) Permite que se desenvolva de forma organizada e econômica, pois, permite o reaproveitamento de código. 
 3) É constituída de diagramas padronizados para evitar a confusão no desnvolvimento. 
 4) É uma foram de se programar, mas devem-se buscar maneiras que gerem menos código, para no caso de reutilização 
ficar mais fácil gerar o mesmo código. 
 5) Trata-se de uma forma moderna de se desenvolver software, desde que se usem apenas novas linguagens. 
 2 
2. 
 Considere o UML: 
 1) Trata-se de uma linguagem que permite programar um sistema, de forma rápida, inclusive com geração de código. 
 2) É um banco de dados composto por dados e diagaramas. 
 3) Produz um desenvolvimento com o uso de diagramas integrados e padronizados. 
 4) É uma forma de se poder desenvolver o sistema com diagramas integrados, porém despadronizados. 
 5) No uso de diagramas do UML, só pode usar um tipo de diagrama por projeto. 
 3 3. 
 Sobre o ator, pode-se afirmar, com certeza: 
 1) É um personagem que interage com o sistema. 
 2) É um órgão ou pessoa responsável pelo sistema. 
 3) Representa um conjunto de pessoas que trabalham no sistema. 
 4) Repesenta um conjunto de pessoas que desenvolvem o sistema. 
 5) Repesenta um conjunto de pessoas interessados no sistema. 
 1 
Nesta aula, você irá: 
 
1. Identificar uma classe e objetos; 
 
2. Definir os tipos de classes; 
 
3. Identificaratributos e visibilidade de atributos; 
 
4. Relacionar classes; 
 
5. Definir os tipos de qualificações feitas nos relacionamentos; 
 
6. Classes dependentes; 
 
7. Modelar estruturas de herança; 
 
8. Modelar associações; 
 
9. Exemplos. 
Diagrama de Classe - Modelo de domínio 
Diagrama de classes 
O diagrama de classes é o principal dos diagramas do UML. O diagrama é como uma fotografia dos elementos usados pela 
aplicação. É uma representação estática e não deve ser usado para representar dinâmicas da aplicação, embora também as 
retrate, como veremos. Existem vários níveis de diagrama de classes, eles são usados no nível de domínio – conceitual – e em 
nível de projeto. Nesta aula vamos abordar o diagrama de classes a partir da observação do mundo real para um determinado 
contexto, vamos construir o diagrama, em nível de domínio. Isto é, não se devem representar estruturas de projeto (chaves, 
arquivos, campos...). O foco da análise é o negócio. Imagine que você está no século 15 e que não tem computador – quando 
estiver fazendo esse modelo. 
 
Identificando Classes. 
Uma classe é uma forma de representarmos no mundo simbólico um conjunto do mundo real. Ao observar um conjunto sobre 
o qual temos alguns interesses dizemos que temos uma classe. As propriedades que desejo observar são chamado de 
atributos. 
 
Representando Uma Classe 
Existem várias formas gráficas para se representar uma classe, mas em UML, quando temos interesse em um conjunto do 
mundo real, desenhamos: 
 
 
Uma classe é a descrição de um tipo de objeto do mundo real. Usam-se classes para classificar os objetos que identificamos no 
mundo real. As classes devem ser retiradas do domínio do problema. 
 
Uma classe completa, no UML, é representada por um retângulo dividido em três compartimentos: o compartimento de 
nome, que conterá apenas o nome da classe modelada, o de atributos, que possuirá a relação de atributos que a classe possui 
e o compartimento de operações chamadas de métodos. Nós veremos o que é método e sua modelagem em aulas futuras. 
 
Foi instanciado o objeto Pablo Barros, da classe cliente. E as operações que se pode fazer com ele são: criar() e 
destruir(). Vamos aprender como identificar os métodos, ainda em aulas futuras 
Relacionamentos 
Outro elemento importante, para a modelagem de classes, é o relacionamento. Aqui, o relacionamento tem o mesmo 
conceito matemático estabelecido em teoria dos conjuntos. Tem-se um relacionamento, quando estabelecemos alguma 
“ligação”, do nosso conhecimento, entre os conjuntos. VIU... Não é uma ligação física... é uma ligação do nosso 
conhecimento – ou do domínio da aplicação- por isto, não tem como se constatar fisicamente. É um elemento conceitual. 
Reflete o conhecimento a respeito de alguma coisa. Só existe no mundo simbólico. 
Vamos esclarecer com alguns exemplos: 
Você tem o conjunto dos homens e o conjunto das mulheres. 
 
Um relacionamento é um estabelecimento conceitual entre elementos de um conjunto com outro que depende de que aspecto 
do mundo real estamos analisando. 
Multiplicidade Dos Relacionamentos: 
Uma informação importante, quando trabalhamos com os relacionamentos é de como os elementos do conjunto se comportam 
em relação ao outro. Quando eu tenho um conjunto A e um conjunto B, na matemática um relacionamento representa um 
par (a,b) onde a pertence ao conjunto A e b pertence ao conjunto B. 
Pode ser que todos os elementos de A tenham o par (a, b), neste caso se fala PARA TODO a pertencente ao conjunto A temos 
uma imagem b no conjunto B. Observe que não INTERESSA como chega ou para quem chega ao conjunto B. 
Existem quatro possibilidades de multiplicidade do conjunto A em relação ao conjunto B: 
 
 
 
 
Análise Dos Relacionamentos: 
Quando fazemos a análise dos relacionamentos, estabelecemos duas informações: Relacionamento do conjunto A para o 
conjunto B; e do conjunto B para o conjunto A. Assim, vamos completar os exemplos anteriores: 
 
 
 
 
De forma resumida para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos 
estão relacionados. O intervalo pode ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), 
dois (2), cinco para 11 (5..11) e assim por diante. É também possível expressar uma série de números como (1, 4, 6..12). 
Se não for descrita nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1). 
Classes Dependentes 
Existem alguns conjuntos que, no processo de modelagem, desejamos condicioná-los à existência de outros conjuntos. São 
chamados de conjuntos dependentes. A dependência de conjuntos é uma ferramenta da modelagem. Nesse caso, o 
modelador deseja que a identificação do conjunto dependente seja feita a partir do conjunto a. A representação da 
dependência é por uma linha tracejada. 
O diagrama significa que o familiar deve ser identificado a partir da identificação do empregado. Na realidade, um objeto 
dependente só pode ser dependente de um único objeto, por isto é desnecessário a indicação da multiplicidade 1. 
 
Associações 
Outro recurso importante é a associação. Uma associação é um conjunto criado com objetivo de ligar outros dois (ou mais) 
conjuntos existentes. As classes associadoras são representadas por linhas cheias e a classe que as associa é ligada a esta linha 
cheia por uma linha pontilhada. Toda vez que tivermos um relacionamento de multiplicidade ( 0..*) para os dois lados do 
relacionamento, deve-se usar a classe associativa. O modelo de classes de objetos é determinista, isto é, devemos saber 
quem se relaciona com quem, portanto a multiplicidade 1 é obrigatória nos relacionamentos fora da estrutura associativa. 
 
Exemplo 
Uma empresa trabalha com projetos. Todo empregado trabalha em um projeto, cada projeto é coordenado por um órgão. O 
departamento de pessoal precisa saber que dia e hora o empregado entrou e saiu de cada projeto. Faça um modelo de classes 
que permita fornecer esta informação: 
Primeiro passo : O modelador iniciaria identificando os conjuntos existentes: 
 
 
 
 
Nesta aula, você: 
 Aprendeu que o diagrama de classes é o mais importante na análise por objetos; 
 Aprendeu o que é um objeto e como fazer um diagrama de objetos; 
 O diagrama deve ser iniciado, forçando-se no caso e uso crítico; 
 Aprendeu a estabelecer relacionamentos e como representar conjuntos; 
 Usou as classes associativas e verificou a importância delas para dar flexibilidade aos sistemas criados a 
partir destes modelos; 
 Aprendeu que se pode qualificar os relacionamentos e definir restrições junto às classes; 
 Aprendeu a modelar uma associação. 
Na próxima aula, vamos aprender a usar esta importante ferramenta do UML, desenvolvendo alguns estudos de 
casos, para o desenvolvimento de suas habilidades de análise. Você aprenderá alguns complementos de 
representação usado pelo UML, no diagrama de classes. Até lá. 
 
 
1. 
 Responda, falso ou verdadeiro: 
No UML, a representação de uma classe é formada em três compartimentos, sendo: o primeiro, para identificar o nome da 
classe, abaixo vem o compartimento com os objetos relativos à classe e, por último, o compartimento dos atributos. 
 1) FALSO 
 2) VERDADEIRO 
 1 
2. 
 Dadas as seguintes afirmações, marque a opção falsa, em relação à generalização: 
 1) Todas as instâncias de uma classe filha são também instâncias da classe mãe. 
 2) É uma associação ‘é um tipo de’. 
 3) Todas as instâncias da classe mãe são também instâncias das classes filhas. 
 4) Uma classe pode ter várias ou nenhuma classe mãe. 
 5) Uma classe pode ter nenhuma ou várias classes filhas. 
 3 
3. 
 Quais dos relacionamentos abaixo podem haver entre classes? 
I – Include (inclusão) . II – Extends (extensão). 
III – Agregação. IV – Generalização. 
V – Composição.VI – Associação. 
 1) Todos 
 2) Nenhum 
 3) II, III, IV, VI 
 4) III, IV, V, VI 
 5) I, II, IV 
 4 
4. 
 Dadas as seguintes afirmações, marque a opção falsa, em relação à herança: 
 1) A herança é um mecanismo que deriva novas classes, a partir de uma classe já existente, através de um processo de 
refinamento. 
 2) Uma classe derivada herda atributos e operações da classe base. 
 3) A classe derivada não pode adicionar novos atributos ou operações às já existentes. 
 4) Quando uma classe herda de mais de uma classe, temos a herança múltipla. 
 5) A classe derivada pode redefinir a implementação de operações existentes na classe base. 
 3 
 
Estar sempre preparado para mudar o diagrama de caso de uso, pois ele pode sendo alterado a medida que se implementa o 
projeto. 
Aula 4: Prática e Particularidades do UML - Diagrama Caso de Uso e Classe 
Nesta aula você irá aprender sobre: 
 
1. Fazer uma nota (observação) nos diagramas do UML; 
2. Fazer auto relacionamentos; 
3. Definir a navegação no diagrama de classes 
4. Especificar restrições; 
5. Trabalhar com a estrutura a todo-parte; 
6. Diferenciar uma agregação de uma composição; 
7. Fazer um diagrama de pacotes; 
8. Definir visibilidade de atributos; 
9. Identificar as informações que o UML definiu para os relacionamentos. 
Diagrama De Classes 
O UML específica uma série de informações complementares aos conjuntos identificados do mundo real e seus 
respectivos relacionamentos. Essas informações têm o objetivo da implementação. Sim, porque não devemos 
esquecer que o objetivo é definir um sistema de informações. Alguns dos instrumentos apresentados são para 
outros diagramas e vamos aprender a usar estas ferramentas em outros diagramas. 
Completando As Associações 
Uma associação é um conceito que liga dois conjuntos, matematicamente é um par (a,b) onde: a pertence a um 
conjunto e b pertence ao outro conjunto. 
Quando apresentamos a associação, mostramos que existem duas informações - do conjunto A para o conjunto B 
e do Conjunto B para o conjunto A – e representamos estas informações. Estávamos NOMEANDO 
OS relacionamentos mas, na prática, não há necessidade de se qualificar estes relacionamentos, pois, o nosso 
principal objetivo é a multiplicidade. 
 
 
 
 
 
 
 
 
 
Mutabilidade 
Indica se os relacionamentos estabelecidos são mutáveis (podem ser agregados, apagados). Quando nada é dito, 
indica que nenhum indicador é necessário. A propriedade {congelado} indica que após ser criado, nenhum vinculo 
pode ser feito. A propriedade {somarSomente} indica que os vínculos podem ser somados. 
 
Relacionamentos Recursivos Ou Autorelacionamento. 
Imagine que você tem um conjunto de equipamentos de hardware. Nesse conjunto temos equipamentos como 
teclados, vídeos, mouses, que são únicos, ou seja, tem um identificador e um único fabricante. Existem também 
computadores (equipamentos compostos) que são compostos por equipamentos únicos. Para representar isto 
temos: 
Ou seja, estamos criando relacionamento entre os elementos do próprio conjunto. 
É possível conectar uma classe a ela mesma, através de uma associação e que ainda representa, semanticamente, 
a conexão entre dois objetos; mas os objetos conectados são da mesma classe. Uma associação deste tipo é 
chamada de associação recursiva. 
 
Relacionamentos Recursivos Ou Autorelacionamento. 
Apesar de o UML definir o autorelacionamento, no meu entender, não há necessidade de se usar este tipo de 
recursos, pois, fica pouco claro como ocorre o relacionamento e não se define que objetos estão associados. Você 
já tem o recurso do subconjunto, portanto, basta modelar os subconjuntos e estabelecer o relacionamento entre 
eles. Assim, no exemplo, temos dois tipos de equipamentos: Simples e Compostos – podemos definir dois 
subconjuntos e depois associar os componentes. 
 
Sempre que possível, desenvolva a análise, identifique que objeto se relaciona com que objeto. Isso evitará 
problemas, na fase de implementação do sistema. 
Associação Exclusiva 
Uma associação exclusiva é uma restrição em duas ou mais associações. Ela especifica que objetos de uma classe 
podem participar de, no máximo, uma das associações, em um dado momento. 
 Uma associação exclusiva é representada por uma linha tracejada entre as associações, que são partes da 
associação exclusiva, com a especificação “{ou}” sobre a linha tracejada. 
No diagrama, um contrato não pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que 
o relacionamento é exclusivo a somente uma das duas classes. Novamente, lembro que podemos destacar como 
subconjuntos e mostrarmos a disjunção. 
 
 
 
 
 
 
 
Nesta aula, você: 
 Aprendeu a colocar anotações no diagrama de classes; 
 Aprendeu a criar um pacote; 
 Aprendeu a estabelecer informações nos relacionamentos; 
 Aprendeu a trabalhar com a agregação e a composição; 
 Aprendeu o que é uma estrutura toda parte; 
 Aprendeu sobre visibilidade de atributos; 
 Aprendeu sobre auto relacionamentos. 
Na próxima aula, vamos aprender o que é um método, uma mensagem e como identificá-los. Vamos 
aprender uma nova ferramenta que nos ajuda na identificação de métodos e, desta forma, podemos 
representar um novo diagrama de classes, mas desta vez, já considerando alguns aspectos da 
implementação 
 
1. 
 Indique que grupo de informações pode ser representado junto ao relacionamento: 
 1) Agregação, multiplicidade, navegação, atributo. 
 2) Composição, ordenação, atributo, navegação. 
 3) Ordenação, composição, qualificação, navegação. 
 4) Objeto, composição, classificação, restrição. 
 5) Generalização, nomeação, classe, ordenação. 
 3 
10. 
 Considere as seguintes classes e associações e escolha a alternativa correta 
 
 1) Classe B compõe a Classe A, Classe D é uma Classe C, Classe F tem visibilidade para Classe E 
 2) Classe B é uma classe A; Classe D compõe a Classe A; Classe F tem visibilidade para Classe E 
 3) Classe B tem visibilidade para Classe A; Classe D é uma Classe C; Classe F compões a Classe E 
 4) Classe A compõe a Classe B; Classe C é uma Classe D; Classe E tem visibilidade para Classe F 
 5) Classe A compõe a Classe B; Classe D tem visibilidade para Classe C; Classe F é uma Classe E 
 1 
2. 
 Uma agregação indica que: 
 1) a classe que agrega deve colocar todos os itens em ordem. 
 2) a classe que agrega deve colocar restrições em todos os itens. 
 3) a classe que agrega deve criar uma relação de dependência para todos os itens. 
 4) a classe que agrega deve ser trabalhada como uma associação entre seus itens. 
 5) a classe que agrega deve carregar automaticamente todos os itens que a compõem. 
 5 
3. 
 Uma nota em UML é colocada em uma figura e deve ser usada: 
 1) para completar com algum comentário para o entendimento do diagrama. 
 2) só no diagrama de classe. 
 3) para uma informação que detalha a forma de implementar e que interessa apenas ao programador. 
 4) para uso obrigatório quando fazemos um diagrama de classes. 
 5) para uma informação referente ao diagrama de casos e uso. 
 1 
4. 
 Considere o diagrama abaixo, e veja a opção absolutamente correta: 
 
 1) O conjunto aluno é ordenado por matrícula. 
 2) O conjunto veículo é ordenado por placa. 
 3) O conjunto veículo é ordenado. 
 4) O conjunto de veículos é ordenado com base no CPF. 
 5) O conjunto aluno e o conjunto veículo são ordenados. 
 3 
5. 
 Dadas as seguintes afirmações, marque a opção falsa em relação à generalização: 
 1) Todas as instâncias de uma classe filha são também instâncias da classe mãe. 
 2) É uma associação ‘é um tipo de’. 
 3) Todas as instâncias da classe mãe são também instâncias das classes filhas. 
 4) Uma classe pode ter nenhuma ou várias classes mãe. 
 5) Uma classe pode ter nenhuma ou várias classes filhas. 
 3 
6. 
 Quais dos relacionamentos abaixo que podem haver entreclasses? 
I – Include (inclusão) II – Extends (extensão) 
III – Agregação IV – Generalização 
V – Composição VI – Associação 
 1) Todos 
 2) Nenhum 
 3) II, III, IV, VI 
 4) III, IV, V, IV 
 5) I, II, IV 
 4 
7. 
 Dadas as seguintes afirmações, marque a opção falsa em relação à herança. 
 1) A herança é um mecanismo que deriva novas classes, a partir de uma classe já existente através de um processo de 
refinamento. 
 2) Uma classe derivada herda atributos e operações da classe base. 
 3) A classe derivada não pode adicionar novos atributos ou operações as já existentes. 
 4) Quando uma classe herda de mais de uma classe, temos a herança múltipla. 
 5) A classe derivada pode redefinir a implementação de operações existentes na classe base. 
 3 
8. 
 Dadas as seguintes afirmações, marque a opção falsa em relação à herança. 
 1) A herança é um mecanismo que deriva novas classes a partir de uma classe já existente, através de um processo de 
refinamento. 
 2) Uma classe derivada herda atributos e operações da classe base. 
 3) A classe derivada não pode adicionar novos atributos ou operações as já existentes. 
 4) Quando uma classe herda de mais de uma classe, temos a herança múltipla. 
 5) A classe derivada pode redefinir a implementação de operações existentes na classe base. 
 3 
9. 
 _______________ e ___________________ - chamados diagramas de interação – são dois dos cinco diagramas utilizados na UML, 
para a modelagem dos aspectos ____________ de sistema 
 1) Sequencia – atividade – dinâmicos 
 2) Sequencia – colaboração – dinâmicos 
 3) Sequencia – colaboração – estáticos 
 4) Sequencia – atividade – estáticos 
 5) Gráfico de estado – colaboração – dinâmicos 
 2 
Aula 5: Identificação de Métodos e Mensagens 
Nesta aula, você irá: 
 
1. Modelar um método. 
2. Identificar a diferença de método e mensagem. 
3. Identificar os componentes de um diagrama de sequência. 
4. Identificar a seqüência de métodos. 
5. Identificar os três tipos de visibilidade de atributos e como representá-los. 
6. Identificar uma característica de sincronismo de métodos. 
7. Identificar uma característica de um método assíncrono. 
8. Identificar quando e como um método deve criar um objeto. 
Diagrama de sequência 
Os casos e uso devem ser implementados, deve-se definir como devem ser implementados. Os diagramas de 
interação, que mostram como as classes interagem, são o diagrama de sequência e o diagrama de colaboração. 
Nesta aula vamos estudar os principais aspectos do diagrama de sequência. No diagrama de sequência estamos 
definindo que funções devem ser implementadas, se definir como é o código, para que o caso e uso possa ser 
realizado. O objetivo é identificar funções, que são as unidades para definir novas funções. 
Comparando com fatoração de números, no diagrama de sequência “fatoramos” os caso e uso. Não confunda – 
Um diagrama de sequência mostra a sequência de execução de funções, portanto, não mostra troca de 
informação. Um diagrama de sequência é uma espécie de algoritmo de alto nível em que se destaca a chamada das 
funções. 
Os casos e uso devem ser implementados, deve-se definir como devem ser implementados. Os diagramas de 
interação, que mostram como as classes interagem, são o diagrama de sequência e o diagrama de colaboração. 
Nesta aula vamos estudar os principais aspectos do diagrama de sequência. No diagrama de sequência estamos 
definindo que funções devem ser implementadas, se definir como é o código, para que o caso e uso possa ser 
realizado. O objetivo é identificar funções, que são as unidades para definir novas funções. Comparando com 
fatoração de números, no diagrama de sequência “fatoramos” os caso e uso. Não confunda – Um diagrama de 
sequência mostra a sequência de execução de funções, portanto, não mostra troca de informação. Um diagrama 
de sequência é uma espécie de algoritmo de alto nível em que se destaca a chamada das funções. 
 
 
Métodos: 
Um método é uma função que colocamos dentro da classe, isto quer dizer que a função está encapsulada e só 
pode ser executada a partir da classe. 
Não é uma boa prática de modelagem colocar métodos nas classes sem o desenvolvimento de um dos diagramas 
de interação. 
 
Mensagem: 
Os objetos precisam trabalhar de forma coordenada, e por isto devem se comunicar através de seus métodos. Um 
objeto pode chamara a execução de um método de outro objeto. A chamada do método de outra mensagem é o 
que chamamos de mensagem. 
Quando desejamos definir como e quais mensagens são transmitidas, podemos fazer um diagrama de sequência 
ou um diagrama de colaboração são chamados de diagramas interativos. 
Para cada caso e uso desenhamos que classes e que mensagens são necessárias para se implementar o caso e uso. 
 
Diagrama de sequência 
Mostra a sequência de chamada de métodos (MENSAGENS) ao longo do tempo. 
Para isto devemos estanciar os objetos que irão ser utilizados. 
Para se representar um objeto instanciado, por exemplo, para a classe aluno, temos: 
: aluno representa que um objeto qualquer da classe aluno foi instanciado- João 
: aluno representa que o objeto nomeado como João, da classe aluno, foi instanciado. 
 
 
 
Autodelegação 
Um método pode ser chamado por outro método dentro de uma classe. Nesse caso, o objeto está enviando uma 
mensagem para ele mesmo. È o chamamos de autodelegação e representa-se: 
 
Na prática, as linguagens de programação, ao executarem um método, guardam o endereço desta execução em uma 
variável especial chamada THIS. Quando se faz a auto delegação, busca-se, para execução do método, o endereço 
armazenado nessa variável. 
Podemos indicar a execução da forma: THIS.mesagem(); 
 
Uma mensagem é uma chamada a esse método. Pode-se indicar o acesso a um atribulo, ou método de um objeto, 
indicando o nome do objeto. 
Assim para a classe: 
 
Podemos chamar a função construtora, que vai criar o objeto. Suponha que desejamos o objeto João. 
As linguagens, geralmente, fazem isso por um método com o mesmo nome da função ou pelo operador new. 
 Aluno João: /aluno é um novo tipo e foi criado o objeto João. 
João = new aluno; / João é um objeto que foi criado da classe aluno. 
Podem-se acessar os atributos da classe, indicando o objeto e a estrutura que desejamos de dentro da classe. 
 Nome --> indica que estamos acessando a variável nome do objeto João 
 João.Telefone = “23657854”. --> indica que o telefone 23657854 foi atribuído a variável telefone no objeto João. 
 João.transferir(); --> indica que foi ativada (executar) a função transferir, a partir do objeto João e com as 
características existentes no objeto, na hora da chamada. 
Vamos construir alguns diagramas de sequência para explicitar alguns conceitos: 
Considere o caso e uso: Matricular um aluno em uma universidade. 
 Com uma única classe´. 
 
Para incluir um objeto aluno, temos o seguinte diagrama de sequência: 
Inicialmente, registramos os objetos que serão usados com a representação de sua existência na linha da vida. 
Depois, começamos a desenhar cada método com as respectivas mensagens. 
Observe que o nome do caso e uso é o método inicial no diagrama. E esse método estabelece uma série de 
mensagens. Todas as mensagens são feitas no próprio objeto. A primeira mensagem chama o método 
mostrar_tela(); este método é responsável por criar uma tela para ser preenchida com os dados do aluno e, 
também, faz a crítica desses dados (eu estou definindo isto), ao se clicar OK (eu estou imaginando um botão de OK 
na tela) os dados (nome, matrícula e telefone), correspondente aos atributos da classe, serão conhecidos e devem 
ser incluídos no conjunto (arquivos ou banco de dados, não é momento de definir isto agora), para isto vou estipular 
outro método com o nome de incluir_aluno(); e vou passar estes dados como parâmetros. 
O diagrama de sequência com os métodose mensagens fica: 
 
Observação: 
Observe que a chamada de métodos (mensagens) só pode ser feita para métodos definidos na classe, por isto vamos 
colocando os métodos identificados por cada classe. 
Se analisarmos a estrutura do caso e uso do exercício, verificamos que a forma que foi projetado não é adequada, 
pois, permitirá que se inclua duplicatas de alunos. O ideal é que verificássemos se o aluno já existe no 
conjunto. Nesse caso, deveríamos colocar um método para verificar isso, poderíamos, por exemplo, criar um 
método que retorne a string “sim”, se ele já existe ou não, se ele não existe. Só vamos incluir se voltar não. 
Com as informações do diagrama, podemos completar a classe aluno, colocando os métodos que identificamos: 
 
Veja que o digrama de sequência serve para verificar a melhor forma de implementar. Por isso, durante o estudo e 
definição de que métodos vamos definir, podemos fazer vários diagramas, até decidirmos pelo mais adequado. 
Se tivermos uma linguagem de programação orientada a objetos, teríamos de definir nossa classe assim: 
 Classe Aluno 
 { atributos: 
 String Nome; 
 String end; 
 Int matrícula; 
 Métodos: 
 Void matricular(); 
 Void mostrar_tela(); 
 String Validar(); 
 Void incluir-_aluno(); 
 } 
O diagrama corresponde a um algoritmo que incida métodos usados: 
Vamos mostrar, com uma pseudolinguagem, como ficaria o método matricular(); 
Aluno:: void matricular() 
 { string variável; // para receber a volta da validação 
 ..... 
 // nome, end, matrícula são variáveis da classe e são 
 //acessadas pelos métodos 
 This.mostrar_tela(); 
 // esta função lê e armazena dados nos atributos; 
 Variável= this.validar(); //retorna sim ou não para a variável 
 Se (variável==”não”) 
 This.incluir_aluno() 
 Senão 
 Imprimir “aluno já existe” 
retornar 
 } 
O diagrama de sequência com os métodos e mensagens fica: 
 
Exemplo 
Considere que o analista de requisitos nos enviou o seguinte: 
 
Os Objetos envolvidos para se realizar o método são: :matrícula, :aluno e :curso Esses objetos precisam estar na 
memória (pelo menos achamos isto inicialmente) para podermos executar as funções (que vamos identificar) e 
acessar os valores dos atributos. 
Observe, no meu diagrama, que comecei pelo objeto matrícula, você pode contestar isso. Para fazermos a 
matrícula, no diagrama de classes vemos que precisamos, de alguma forma, buscar o código do aluno e o código da 
disciplina, então mandamos mensagens para esses objetos retornarem esses códigos. Com o conhecimento dos 
códigos, podemos incluir no conjunto associativo. 
 
 
A título de exemplo, teríamos o algoritmo em pseudocódigo correspondente ao diagrama de classes, par ao método 
mat(): 
 
 
 
 
 
 
Mensagens etiquetadas 
Já vimos nos itens anteriores o que UML classifica como uma mensagem etiquetada. Uma mensagem etiqueta é 
quando se estabelece uma série de condições que devem ser cumpridas para se enviar a mensagem 
De acordo com a UML a sintaxe da etiqueta é: 
<Predecessor><condição><expressão><retorno> := <mensagem> (<parâmetros>); 
 
<predecessor> é uma lista de números separada por virgulas terminando por uma “/” 
 Exemplo: 1.1, 1.2, 1.2.1, 1.2.2, 1.2.2.3/ 
<CONDIÇÃO> 
<EXPRESSAO> É uma lista de termos de sequência separados por . seguida por dois pontos. 
Exemplo 1: 3.1 [x<y] : variável:= função (valor1,valor2); 
 
Exemplo 2: 1.1b ,1.1 c [x<10] : variável := função (valor1,valor2); 
 - Indica que serão executas as mensagens consecutivamente 
 <Retorno> uma lista de nomes separados por virgula que são retornados pela função. 
Exemplo3: 3.1 * [x=1..n] : nome,endereço,matricula:= id_aluno(); 
 Obs: * indica repetição - para valores de x de 1 ate n. 
Exemplo4: 3.1 * [x=1;x<100,x++] : nome,end := id_al (); 
 Obs: pode-se usar estruturas de sintaxe de linguagens de programação. 
Exemplo5 : 3.1 *|| [x=1; x<100,x ++] : nome,end id_al(); 
 Obs: o símbolo *|| indica que as mensagens podem executar em paralelo, isto é, não existe sincronismo na 
execução. 
<Mensagem> é o nome da função. 
<parâmetros> é o conjunto de parâmetros passados na função pode-se usar sintaxe de alguma linguagem como por 
exemplos passar simplesmente o nome dos parâmetros: 
 1.2 : int nome:= Id_aluno (matricula, curso) 
Ou passar o tipo junto ao parâmetro: 
 1.2 : int nome:= id_aluno (string:matricula, int:curso); 
Casos especiais de representação 
Tempo real: Um sistema em tempo real, em principio, tem o tempo como o principal fator para sua execução. O 
sistema precisa responder conforme projetado, permitindo a execução simultânea de processos em 
paralelo. Precisa-se definir tempo de resposta, comportamento, comunicação entre processos. 
Embedded System: Um sistema de tempo real, normalmente, tem os processos muito integrados a dispositivos de 
hardware. Este tipo de sistema é chamado de Embedded System. 
Classe ativa: Normalmente os objetos (de uma classe passiva) só são instanciandos quando recebem mensagens – as 
classes que vimos nos exemplos anteriores-. Uma objeto de uma classe ativa pode tomar iniciativa para executar 
ações sem enviar mensagens. Para isto deve-se representar os métodos com a preocupação de definir a forma de 
comunicação entre os objetos ativos e sua sincronização. Na UML uma classe ativa é representado com a indicação 
do estereótipos <<classe ativa>>. 
A UML indica a forma de sincronismo durante a transferência das mensagens, por variações na ponta da flecha: 
 
 
 
 
 
Exemplo de mensagem assíncrona: figura do livro Modelagem de Objetos – Furlan,Jose,David. 
Observação: Uma ativação é a execução de uma ação. 
 
 
Um diagrama de sequência, usando todas as representações da UML, dá para o implementador uma série de 
informações importantes. 
Quando o diagrama de sequência envolve vários objetos, pode-se ter dificuldadade de visualizar o método que se 
está desenhando. Para resolver isto temos um outro tipo de diagrama chamado diagrama de colaboração. O 
diagrama de colaboração tem o mesmo objetivo do diagrama de sequência, mas permite uma melhor visualização, 
pois só se representa as classes envolvidas no método. 
Dica: 
 Seja simples: 
 1 - Não queira iniciar usando todas as representações apresentadas nesta aula. Use as básicas e a medida que for 
ganhando experiência vá introduzindo novas representações 
2 – O diagrama de seqüência é para ser simples. Por isto desenhe apenas o desenvolvimento de um método ou caso 
e uso completo por diagrama. Não resolva vários caso-uso ou método no mesmo diagrama 
3 – pratique, este é o segredo. Lembre-se que ao desenhar um diagrama de seqüência você esta definindo código. 
Nesta aula, você: 
 Aprendeu o que é encapsula mento. 
 Aprendeu o que é um método e como modelá-lo. 
 Aprendeu a diferença entre método síncrono e método assíncrono. 
 Aprendeu sobre a visibilidade de atributos. 
 Aprendeu sobre as características de um diagrama de sequência. 
 Aprendeu a definir uma classe de projeto. 
 
1. 
 Um diagrama de interação serve para: 
 1) mostrar o fluxo de informação entre o ator e o sistema 
 2) mostra como as mensagens retornam para o ator 
 3) mostra a seqüência de chamada de métodos 
 4) mostra a seqüência de instancias de objetos graficamente 
 5) mostar como o fluxo de informação deve ser armazenado 
 3 
2. 
 A linha da vida serve para: 
 1) definir o sincronismo entre a criação de objetos 
 2) representar o tempo de vida de um objeto 
 3) representa o tempo de vida de uma classe 
 4) representa o tempo de vida de um método assíncrono 
 5) representa o tempo de vida de um método síncrono 
 2 
3. 
O método: 
 2.1.2 a [sexo = “m”] : string:nome,int:numero:= MSG(int:CPF) 
Significa: 
 1) o método é etiquetado, portanto deverá ser criado um fluxo de informação contendo nome e numero 
 2) o método esta etiquetado, mas não esta correta na sua sintaxe,pois falta a indicação de sexo = “f”. 
 3) é uma mensagem que indica que a classe MSG deverá apresentar os dados de nome e número quando se passa r o CPF. 
 4) é um fluxo que é chamado de 2.1 se o sexo = “m” e apresenta na tela o nome de quem possui o CPF informado 
 5) é um método etiquetado que retorna o nome e matricula quando for chamado para um CPF 
 5