Engenhari

a
de
Software

SUMRIO
Introduo................................................................................................................. 3
Software.................................................................................................................... 3
Caractersticas de Software.......................................................................................3
Tipos de Software...................................................................................................... 3
Mtodos..................................................................................................................... 4
Paradigmas de Engenharia de Software.....................................................................5
Processos................................................................................................................... 5
Tcnicas de entrevistas e de coleta de dados............................................................5
Tipos de entrevistas................................................................................................... 6
Problemas.................................................................................................................. 6
Diretrizes Para a Realizao de Entrevistas...............................................................6
Introduo a UML....................................................................................................... 7
Por que modelar os softwares?..................................................................................7
Desenvolvimento Orientado a objetos.......................................................................7
Levantamento de Requisitos......................................................................................7
Definio de modelagem........................................................................................... 8
Modelagem................................................................................................................ 8
Abstrao................................................................................................................... 9
Diagramas na UML................................................................................................... 10
Classes.................................................................................................................... 10
Diagrama de classes................................................................................................ 10
Atributos.................................................................................................................. 11
Operaes e mtodos.............................................................................................. 11
Associaes............................................................................................................. 12
Mecanismos da UML................................................................................................ 14
Perfis........................................................................................................................ 15

INTRODUO
A engenharia de software uma derivao da engenharia de sistemas e de
hardware. Ela abrange um conjunto de trs elementos fundamentais - mtodos,
ferramentas e procedimentos - que possibilita o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a
construo de software de alta qualidade produtivamente. E tais elementos
ajudam a estabelecer um modo de pensar para a prtica segura da construo
do Software.

SOFTWARE
H 30 anos menos de 1% da populao poderiam descrever o que um
software, hoje dificilmente algum no sabe descreve o que seja.
Entre as dcadas de 50 e 70 quando a maioria das linguagens de programao
apareceram, ningum poderia prever que nos tempos atuais elas seriam
indispensveis a negcios e a at mesmo a nossa vida cotidiana com uso de
computadores, telefones e qualquer tipo de servio, uma vez que todos os
setores dependem de softwares.
A grande dificuldade relacionado ao desenvolvimento de programas que o
nosso produto no nada fsico e sim completamente lgico. E desempenha um
duplo papel: produto e canal de distribuio. Na atualidade ele que trabalha
com bem mais precioso para qualquer corporao A Informao.

CARACTERSTICAS DE SOFTWARE
A definio de Software necessita de uma compreenso mais formal para o
pleno entendimento do seu real significado. Por isso algumas caractersticas
ajudam a base de compreenso.
1. O Software desenvolvido ou passa por processo de Engenharia de
Software e no fabricado no sentido clssico;
2. Software no se desgasta se deteriora;
3. O software tem sua construo contnua;

TIPOS DE SOFTWARE
Software de Sistema conjunto de sistemas para atender a outros programas.
Ex.: Compiladores, editores, utilitrios para gerenciamento de arquivos.
Software de aplicao programas sob medida para solues de negocio
Software Cientifico ou de Engenharia caracterizado por algoritmos number
cruching
Software embutido reside em um outro sistema e utilizado para implementar
funes para o usurio final
Software para linha de produtos projetado para prover capacidade especifica
de utilizao por muitos clientes diferentes.
3

Software aplicao WEB chamada de WebApps centralizado em rede abarca

uma vasta gama de aplicaes.
Software de inteligncia artificial soluo de algoritmos no numricos para
solucionar problemas complexos que no so passiveis de computao ou de
anlise direta.
Ainda existem alguns termos associados a software. E alguns so desafios
relacionados a problemas intencionais outros relacionados a tecnologia.
SISTEMAS LEGADOS
So programas antigos mas ainda atuantes no mercado dos negcios.
Estes vem a dcadas recebendo melhorias em seus requisitos de
negcios e plataformas computacionais para adequar-se as tecnologias
atuais e so motivos de ateno e preocupao desde os anos 60.
Camadas de Engenharia de Projetos

Fer
ra
me
nt
as
Mtodos

Processos

Foco na qualidade

MTODOS
Os Mtodos de Desenvolvimento de Sistema se diferenciam pela maneira
como o problema deve ser visualizado e como a soluo do problema deve
ser modelada. So eles:
1.

Mtodo baseado na Decomposio de Funes: Abordagem estruturada

caracterizada pela decomposio das funes. Os tipos de modelos que
representam as funes so:

DFD (Diagrama de Fluxo de Dados) se caracteriza pela

decomposio hierrquica de processos.

MHT (Modelo Hierrquico de Tarefas) se baseia na decomposio

hierrquica de tarefas.

2. Mtodo baseado na Estrutura de Dados:

Abordagem baseada na
decomposio de um problema a partir dos dados. Exemplos de tipos de
modelos dessa classe:
4

MER (Modelagem Entidade-Relacionamento)

Tcnica de Warnier .

3. Mtodo de Anlise baseado na Orientao a Objeto. Os tipos de modelos que

representam essa classe so:

UML (Unified Process) notao de modelagem, independente de

processos de desenvolvimento.

Cenrios

PARADIGMAS DE ENGENHARIA DE SOFTWARE

Segundo Roger Pressman, Paradigmas so os modelos de processos que
possibilitam:

ao gerente: o controle do processo de desenvolvimento de sistemas

de software,

ao desenvolvedor: a obter a base para produzir, de maneira

eficiente, software que satisfaa os requisitos preestabelecidos.

Os paradigmas especificam algumas atividades que devem ser executadas,

assim como a ordem em que devem ser executadas.
A funo dos
paradigmas diminuir os problemas encontrados no processo de
desenvolvimento do software, e deve ser escolhido de acordo com a
natureza do projeto e do produto a ser desenvolvido, dos mtodos e
ferramenta a ser utilizado e dos controles e produtos intermedirios
desejados.

PROCESSOS
Processo um conjunto de atividades, aes e tarefas realizadas na criao
de algum produto de trabalho. Uma atividade esfora-se para atingir um
objetivo amplo e utilizada independentemente do campo de aplicao, do
tamanho do projeto, da complexidade ou do grau de rigor que a Engenharia
de Software ser aplicada. Uma ao um conjunto de tarefas que resultam
num componente do projeto. Uma tarefa se concentra num pequeno
objetivo, porem bem definido e produz um resultado tangvel.

TCNICAS DE ENTREVISTAS E DE COLETA DE DADOS

So diretrizes para as entrevistas que voc far durante a fase de anlise de
sistemas do projeto de desenvolvimento de um sistema. Provavelmente
entrevistar usurios, gerentes, auditores, programadores e auxiliares que
utilizam sistemas j existentes (informatizados ou manuais) e tambm vrias
outras pessoas envolvidas.

Por que fazemos entrevistas durante a anlise de sistemas? Porque:

Precisamos coletar informaes sobre o comportamento de um

sistema atual ou sobre os requisitos de um novo sistema de pessoas
que tm essas informaes armazenadas em algum lugar em suas
cabeas.

Precisamos verificar nossa prpria compreenso, como analistas de

sistemas, do comportamento de um sistema atual ou dos requisitos
de um novo sistema. Essa compreenso deve ser adquirida atravs
de entrevistas em combinao com informaes coletadas de modo
independente.

Precisamos coletar informaes sobre o(s) sistema(s) atual(is) para a

execuo do estudo de custo/benefcio para o novo sistema.

TIPOS DE ENTREVISTAS

Reunio

Resposta de questionrios

Descrio por escrito dos requisitos

JAD

PROBLEMAS
Em muitos projetos de alta tecnologia, tem-se observado que a maioria dos
problemas difceis no envolvem hardware nem software, mas sim o
pleopleware. Os problemas de peopleware na anlise de sistemas so muitas
vezes encontrados nas entrevistas. Os problemas mais comuns a que voc
deve estar atento so:

Entrevistar a pessoa errada no momento errado

Fazer perguntas erradas e obter respostas erradas

Criar ressentimentos recprocos

DIRETRIZES PARA A REALIZAO DE ENTREVISTAS

1. Desenvolva um Plano Geral de Entrevistas

extremamente importante que o analista descubra quem deve ser

entrevistado

2. Certifique-se de que tem Autorizao para Falar com os Usurios

Em empresas informais no haver restries mas em empresas de

grande porte devera ter previa autorizao, porque

Nem todos os usurios so capazes de compreender ou

detalhar os requisitos do sistema

Desconfiar dos requisitos

usurios

Interferncia nas atribuies dos usurios

Se negar a responder apropriadamente por achar que sabe

mais do que os outros.

e intenses de determinados

3. Planeje a Entrevista para Fazer Uso Eficiente do Tempo

coletar, antes da entrevista, tantos dados pertinentes quanto

possvel
certificar-se de que o usurio conhece o assunto da entrevista
realizar a entrevista em uma hora ou menos

Os dados dessa entrevista sero manipulados, documentados, analisados e

convertidos em uma forma que o usurio pode nunca ter visto antes. Desse
modo, pode ser necessrio marcar uma entrevista posterior para verificar:

que o analista no cometeu nenhum engano em seu entendimento

do que o usurio lhe disse,

que o usurio no mudou de opinio nesse nterim,

que o usurio entende a notao ou a representao grfica dessas

informaes.

4. Utilize Ferramentas Automatizadas que Sejam Adequadas, Mas No Abuse

elas serviro pra ajudar e no complicar.

INTRODUO A UML
UML (Linguagem de modelagem unificada) e uma linguagem visual utilizada para
modelar software no paradigma orientado a objetos. Tornou-se nos ltimos anos,
um padro adotado internacionalmente, nos ltimos anos ela engenharia de
software. A UML oferece um grande nmero de diagramas que enfocam nas
caractersticas estruturais e comportamentais de um software. Cada diagrama
possui funo especifica.

POR QUE MODELAR OS SOFTWARES?

Por mais simples que seja um software, ele deve ser modelado antes de inicia sua
implementao, entre outras coisas porque, naturalmente os sistemas tendem a
crescer (abrangncia, tamanho ou complexidade. Por isso o sistema nunca esto
totalmente finalizados. Tais situaes se devem aos seguintes fatores

Clientes desejam constantemente modificaes ou melhorias

Novas estratgias das corporaes e consequentemente de seus sistemas
Promulgaes de leis, novos impostos e alquotas fazendo com que os
sistemas necessitem de manutenes.

Por isso a necessidade da documentao detalhada, precisa e atualizada para que

quando necessrio possamos interferir nos sistemas sem muitos erros, corrigindo o
que for necessrio e principalmente sem provocar mais problemas.

DESENVOLVIMENTO ORIENTADO A OBJETOS

Refere-se ao ciclo de vida do software> analise, projeto e implementao. Sua
essncia a identificao e organizao de conceitos de aplicao. O problema que
ser resolvido por um software traz a dificuldade que manipular sua essncia e
complexidade utilizando-se de modelos para mais fcil compreenso e
desenvolvimento estratgico.
O desenvolvimento [e um processo conceitual, sendo fundamentalmente um modo
de pensar e no uma tcnica de programao.

LEVANTAMENTO DE REQUISITOS

Levantamento de Requisitos constitui na principal fase da modelagem. Dependendo

do mtodo/processo adotado, essas etapas ganham, por vezes, nomenclaturas
diferentes, podendo algumas delas ser condensadas em uma etapa nica, ou uma
etapa pode ser dividida em duas ou mais. Veremos que este se divide em fases:

Concepo - onde feito o levantamento de requisitos;

Elaborao - onde feita a anlise dos requisitos e o projeto do

software.

As fases de Elaborao e Construo ocorrem, sempre que possvel, em ciclos

iterativos, dessa forma, sempre que um ciclo completado pela fase de Construo,
volta-se fase de Elaborao para tratar do ciclo seguinte, at todo o software ser
finalizado.
A fase de levantamento de requisitos deve identificar dois tipos de requisitos: os
funcionais e os no-funcionais. Os requisitos funcionais correspondem ao que o
cliente quer que o sistema realize, ou seja, as funcionalidades do software. J os
requisitos no-funcionais correspondem s restries, condies, consistncias,
validaes que devem ser levadas a efeito sobre os requisitos funcionais. Alguns
requisitos no-funcionais identificam regras de negcio, ou seja, as polticas,
normas e condies estabelecidas pela empresa que devem ser seguidas na
execuo de uma funcionalidade.
Durante essa fase, modelamos as questes que foram abstradas durante as
entrevistas iniciais para termos certeza se o que o usurio solicitou foi de fato
compreendido.

DEFINIO DE MODELAGEM
um modo de pensar a respeito dos problemas aplicando-se modelos organizados
em torno de conceitos do mundo real.
Superficialmente, o termo OO significa organizarmos o software como uma coleo
de objetos distintas ou incorporam estruturas de dados e comportamentos.
Geralmente, incluem 4 aspectos: identidade, classificao, herana e polimorfismo.
Identidade significa que os dados so organizados em entidades distintas e
intangveis, os objetos.
Num mundo real, um objeto simplesmente existe, mas em uma Linguagem de
Programao, cada projeto possui referencia nica pela qual ele pode ser acessado.
Classificao significa que os dados com a mesma estrutura (atributos) e
comportamentos (mtodos ou operaes) so agrupados em uma classe.
Uma classe uma abstrao que descreve propriedades importantes para uma
aplicao e ignora as demais.
Cada objeto considerado uma instancia de sua classe, tendo seu prprio valor,
mas que compartilha atributos e mtodos.
Herana o compartilhamento de atributos e operaes entre classes com base
em um relacionamento hierrquico.

 uma superclasse que possui informaes gerais que as subclasses refinam. Uma
subclasse herda todos os recursos e componentes da classe me.
Polimorfismo significa que a mesma operao pode se comportar de forma
diferente para classes diferente. Uma operao [e um procedimento ou
transformao que um objeto realiza ou a que est sujeito e essa operao
realizada atravs da classe se chama mtodos.

MODELAGEM
Modelo uma abstrao de algo com a finalidade de entende-lo antes de construlo. A abstrao a capacidade humana fundamental, que nos permite com uma
complexidade. Para montar um sistema, engenheiros e desenvolvedores precisam
abstrair diferentes vises do sistema, montar modelos e notaes exatas.
Recomenda-se trs tipos de modelos:

modelo de classes que descreve a estrutura esttica de um sistema em

termos de classes e relacionamentos.

Modelo de estado que descreve a estrutura de controle de um sistema de

termos de eventos e estados

Modelo de interaes que descreve como os objetivos individuais

colaboram para conseguir o comportamento do sistema como um todo.

Diferentes problemas do nfase diferente aos trs

ABSTRAO

o exame
abstrao
os aspectos
incompletas

seletivo de certos aspectos de um problema. O objetivo da

isolar os aspectos importantes para alguma finalidade e suprir
que no so importantes. Todas as abstraes so descries
de um mundo real e se permitem ser incompletas e imprecisas.

Na modelagem voc no precisa procrar uma verdade absoluta, mas a

adequao para uma finalidade. No existem um modelo correto ou mais
correto, existe apenas modelo adequado ou inadequado.

O vocabulrio da UML abrange trs tipos de blocos de construo

Itens
Relacionamentos
Diagramas
Os itens so abstraes identificadas como validao de primeira classe em um
modelo. Os relacionamentos agrupam colees interessantes de itens.
Itens da UML
1. Itens estruturais
2. Itens Comportamentais
10

3. Itens Agrupamentos
4. Itens anotacionais
1) so os substantivos utilizado em modelos da IML. So as partes mais estticas do
modelo, representando elementos conceituais ou fsicos. So chamados de
classificadores. Ex.: classe, colaborao, interfaces e componentes.
2) so as partes dinmicas dos modelos de UML. So os verbos de um modelo,
representando comportamentos no tempo e no espao.
Ex.: Caso de uso e interaes

DIAGRAMAS NA UML
a apresentao grfica de um conjunto de elementos, geralmente representados
com itens e relacionamentos. Um diagrama constitui uma projeo de um
determinado sistema representando uma viso parcial dos elementos que compe o
sistema. Temos um conjunto com 13 modelos diferentes.

CLASSES
So blocos de construo mais importantes de qualquer sistema Orientado a
Objetos. Uma classe no um objeto individual, mas uma descrio de um conjunto
de objetos que compartilham os mesmos atributos, operaes, relacionamentos e
semntica.
A escolha das classes depende da natureza e do escopo de uma aplicao, uma
questo de critrio. Pode implementar uma ou mais interfaces. representada
graficamente com um retngulo.
Simples

Sensor de temperatura
Cliente

ou

Parede

Qualificado

regras de negcio:: Agente de Fraude

java::awt:: Retangulo

Regras

O smbolo :: reservado para pacote

Nome de classe [e sempre em letra maiscula
11

ou

Nome de pacote sempre em letras minsculas

Nome composto cada palavra comea com letra maiscula

DIAGRAMA DE CLASSES
Oferecem uma notao grfica para modelar classes e seus relacionamentos,
descrevendo assim possveis objetos. So usados por erem concisos, fceis de
entender e funcionam bem na pratica e correspondem a um conjunto infinito de
objetos.
Um diagrama de classes formado por:

ATRIBUTOS
uma propriedade nomeada de uma classe que descreve um intervalo de valores
que as instancias da propriedade podem apresentar. Representa alguma
propriedade do item que est sendo modelado, compartilhado por todos os objetos
dessa classe.

Valor um elemento dos dados e no os confunda com objetos. Um atributo

descreve valores.

OPERAES E MTODOS
Uma operao a implementao de um servio que pode ser solicitado por algum
objeto de classe para modificar um comportamento. Em programao a
conhecemos como funes e procedimentos.
Regra
12

O nome de um mtodo um verbo ou uma locuo verbal leve, representando

algum comportamento de classe correspondente.
Uma operao pode ser aplicada em classes diferentes com comportamentos
diferentes. Essa operao se chama POLIMORFISMO
Quando uma operao tem mtodos em diversas classes, importante que todos
tenham a mesma assinatura o nmero e os tipos de argumentos e do tipo de
resultado.
Relacionamentos
Ao construir modelos abstratos, possvel identificar que diferentes classes no
trabalham sozinhas. A maioria colabora com outras de vrias maneiras.
Uma ligao uma conexo ou conceitual entre objetos.
Ex.: Joo Silva TrabalhaPara empresa Simplex
Ligaes so associaes que normalmente aparecem cimo verbos em relatos de
problemas.
Na modelagem Orientada a Objetos existem 3 tipos de relacionamentos:
Dependncias => representam relacionamentos de utilizao entre casses
(incluindo relacionamentos de refinamento, rastreamento e vnculos),
Generalizaes => relacionam classes generalizadas s suas especializaes

ASSOCIAES

Uma associao uma descrio de um grupo de ligaes com estrutura semntica

comuns.
O nome em uma associao opcional, se o modelo no ambguo. Ambiguidade
surge quando um modelo possui vrias associaes entre as mesmas classes.
Quando existem mais associaes ou nomes na extremidade da associao

Dentro de um diagrama de classes os relacionamentos ligam a classes de alguma

forma obedecendo seu contexto. Lembrando, elas podem ser de 3 tipos distintos:
dependncia, associao e generalizao.
13

Graficamente, cada um desses tipos possui um modelo, uma representao.

Dependncia geralmente em uma nica direo, sendo representada por
Frequentemente, o contato da dependncia representa uma assinatura, ou seja, a
alterao de uma afeta a outra, mas s numa direo.

J anela
+abrir()
+fechar()
+mover()
+exibir()
+tratarEvento()

Evento

Associao Unria ou reflexiva relaciona uma classe com o objeto da mesma

classe. Tambm a chamamos de auto relacionamento.

+Chefia
Funcionario

Associao Binaria relaciona objetos de duas classes distintas.

Socio
-nome
-endereo
-telefone
-data_socio

+possui

Dependente

representado por um diamante aberto. Caso haja um cruzamento de linha dessem

ser representados com:

Associao Ternria relaciona objetos de duas ou mais classes. Utilizam um

losango para convergir todas as ligaes da associao

14

Generalizao relaciona classe-me / filho ou superclasse. Deriva de um item mais

geral par um mais generalizado.
Nesse caso a filha herda todos os atributos da me e em seus valores o que
prevalece o valor da me.

J anela
+abrir()
+fechar()
+mover()
+exibir()
+tratarEvento()

CaixaDeDialogo

J anelaConsole

Numa assinatura, as filhas devem ter TODOS parmetros e nomes.

Associao numa associao, fundamentalmente podemos ter 4 tipos de
aprimoramentos.
Nome identifica a associao que descreve a natureza de relacionamento.
Para evitar a ambiguidade, podemos adicionar uma direo.

Pessoa

TrabalhaPara

Empresa

Papel tem o papel apenas de nomear explicitamente o papel desempenhado por

uma classe na associao.

Pessoa

Empresa
+Funcionario

+Empregador

Uma mesma classe pode executar papeis diferentes iguais e/ou diferentes em
outras associaes.
Multiplicidade em algumas situaes importante determinar a quantidade de
objetos que podem ser conectadas por uma associao.

15

Pessoa

1..*
+Funcionario

*
+Empregador

Multiplicidade
0..1

Empresa

Significado
Indica que os objetos das classes
associadas
no
precisam
obrigatoriamente estar relacionados,
mas se houver relacionamento indica
que pelo menos uma instancia da
classe relaciona-se com as instancias
da outra classe
Indica que apenas um objeto da classe
relaciona-se com objetos da outra
classe
Indica que pode haver ou no
instancias da classe participando do
relacionamento
Indica que muitos objetos da classe
esto envolvidos na associao
Indica que h pelo menos um objeto
envolvido no relacionamento, podendo
haver muitos objetos envolvidos
Estabelece que existem pelo menos
trs
instancias
envolvidas
no
relacionamento e no mximo 4 ou 5 as
instancias envolvida e no mais do que
isso.

1..1

0..*

*
1..*

3..5

Agregao uma associao entre duas classes representando um par, onde um

significa o todo e o outro a parte.

Empresa

Departamento

Quando temos uma generalizao de uma classe, entramos noutro conceito O.O. de
herana.

16

Composio constitui uma variao da agregao, onde apresentado um vnculo

mais forte entre objetos todo e os objetos parte, procurando demonstrar que os
objetos-parte tem de estar associado a um nico objeto-todo.

So basicamente 2 tipos> herana simples e herana mltipla

Simples

Mltipla

17

Ao modelarmos relacionamentos de herana devemos considerar:

Considerando um conjunto de classes, procure o que so comuns em duas

ou mais classes
Eleve as responsabilidades, atributos e operaes comuns para uma classe
mais geral.
Especifique que as classes mais especficas herdaro ad classe mais geral,
determinando um relacionamento de generalizao, definindo a partir da
especificao para a classe-me.

Em algumas situaes, necessitamos que nossas classes no recebam objetos que

no so o que chamamos de classe-folha porque so incompletas. Essas classes
identificamos como classe abstratas. A identificamos em UML com o texto em
itlico.
Essa conveno se aplica a operao que fornecem uma assinatura, mas est
incompleta e deve ser implementada por algum nvel mais baixo de abstrao.
<<figura>>
Uma herana/generalizao unidirecional, somente a classe especializada recebe
valor vindo da classe-me.
Numa associao existe um par bidirecional
<<figura>>

Mecanismos da UML
18

So mecanismos para fazermos referencias e alteraes, temos:

Notas so artefatos que dependem de papeis importantes tem finalidade de
fazermos comentrios diferenciados dos modelos que conhecemos. Tem notao
grfica especifica>

Esteretipos permite a criao de novos tipos de blocos de construo

representado graficamente por << >>
No um relacionamento de generalizao onde criamos uma classe-mae e filhas.
um meta tipo criando o equivalente a uma nova classe num meta modelo da UML.
Temos uma forma parecida com o RUP da Rational. Cria um modelo utilizado limites,
controles e entidades de classes atravs de fronteiras.
Dentro de esteretipos podemos utilizar notaes grficas, como cones e cores
para compor uma indicao individual sutil
Valor atribudo - um esteretipo que permite a criao de novas informaes de
especificao.
Tudo na UML tem seu conjunto de propriedades, usamos valores atribudos para
acrescentar novas propriedades e podemos utilizar em modelo existentes ou
esteretipos individuas e que no sejam os mesmos atributos de uma classe e o
considere como um metadado.
So adicionados com uma nota anexas num valor afeado atravs de uma
representao de nota ligado atravs de uma linha tracejada.
Restrio tem conotao semntica e serve para adicionar nova semntica ou
alterar regras existentes. Representada graficamente com sequencia entre chaves {
}
Podem adicionar uma nova semntica ou mudar regras existentes. Uma restrio
deve ser considerada verdadeira para que o modelo seja bem formado. As mais
utilizadas so relacionadas a tempo e espao. Seriam como pr-condies para
coisas podem acontecer. Podem ser escritas de forma livre. Quando um tipo mais
formal, utilizamos o OCL modelo de auto relacionamento e prximo ao elemento de
associao.

PERFIS
Frequente vale a pena definir um padro de programao e banco de dado, com
comportamentos diferenciados dependendo das linguagens utilizadas no projeto.
um conjunto de esteretipos, valores atribudos e restries que selecionam um

19

conjunto de sub-elementos para que modelador no fique confuso em relao a

elementos particulares.
Dentro dos perfis, caso seja necessrio, fazermos comentrios dentro dos modelos.
Existem basicamente 4 regras.
1. Incluir um comentrio com o texto em uma nota prximo ao elemento a que
se refere
2. Ocultar e tornar visvel elementos conforme desejar. No e necessrio
manter visvel Exiba seus comentrios em diagramas somente quando
necessrios.
3. Caso o comentrio seja extenso colocar em documentao externa em
forma de anexo.
4. A medida de que evoluir mantenha os comentrios que registram
informaes significativas.
Quando houver a necessidade de incrementar os modelos com blocos que
no so elementos bsicos devemos ter um cuidado maior, mas podem ser
feitos atravs de esteretipos e valores atribudos De antemo certifique-se
que no h possibilidade de faz-lo com itens bsicos da UML e em seguida
adicione uma nova propriedade alo elemento individual ao esteretipo.
Regras de generalizao sero aplicadas.

DIAGRAMA DE CLASSES
Seu principal enfoque permitir a visualizao das classes que comporo o
sistema com seus respectivos atributos e mtodos, bem como em demostrar
como as classes se relacionam, alm de ser a base para a criao de vrios
outros diagramas.
Lembre-se que ao criar um diagrama de classes em UML, que so apenas
uma apresentao grfica da viso esttica do projeto de um sistema e no
precisa captar tudo dobre a viso de projeto do sistema.
Um diagrama bem estruturado:
Enfatiza a comunicao de um nico aspecto da viso esttica do
projeto
Contem somente apenas elementos essncias para compreenso
Fornece detalhes consistente com seu respectivo nvel de abstrao
No muito minimalista
Ao criar o diagrama de classes:
Atribua um nome que identifique-se com seu proposito
Distribua seus elementos e evite o cruzamento de linhas
Organize para que elementos de semanticamente relacionados
fiquem fisicamente prximos
Use notas e cores como indicaes visuais com finalidade de chamar
ateno para caractersticas importantes
Procure no exibir uma quantidade excessiva de tipos de
relacionamentos.
Ao criarmos as classes comum, mas no obrigatrio, que as mesmas
possuam atributos e mtodos. Alm dessas propriedades, encontramos os
classificadores, que caracterizam a visibilidades tanto para tributos como

20

para mtodos, multiplicidade com relao a quantidade de instancias dessa

classe, assinaturas e polimorfismos.
Smbo
lo
+
#
~

Tipo

Descrio

Pblico
Privado
Protegido
Pacote

Visvel
Visvel
Visvel
Visvel

para qualquer classe

apenas para descendentes da classe
somente dentro da classe
apenas para classes do mesmo pacote

EXERCCIOS
Sistema de controle de cinema

Um cinema pode ter muitas salas, sendo necessrio, portanto, registrar

informaes a respeito de cada sala, como sua capacidade, ou seja, o nmero
de acentos disponveis.
O cinema apresenta muitos filmes. Um filme tem informaes como ttulo e
durao. Assim, sempre que um filme for apresentado, deve-se registr-lo
tambm.
Um filme tem um nico gnero, mas um gnero pode se referir a vrios filmes.
Um filme pode ter muitos atores atuando nele, e um ator pode atuar em
muitos filmes. Em cada filme, um ator interpretar um ou mais papis
diferentes. Por uma questo de propaganda, til anunciar os principais
atores do filme e que papis eles interpretam.
Um mesmo filme pode ser apresentado em diferentes salas e horrios. Cada
apresentao em uma determinada sala e horrio chamada Sesso. Um
filme sendo apresentado em uma sesso tem um conjunto mximo de
ingressos, determinado pela capacidade da sala.
Os clientes do cinema podem comprar ou no ingressos para assistir a uma
sesso. O funcionrio deve intermediar a compra do ingresso. Um ingresso
deve conter informaes como o tipo de ingresso (meio ingresso ou ingresso
inteiro). Alm disso, um cliente s pode comprar ingressos para sesses ainda
no encerradas.

21

Sistema de locao de veculos

Desenvolva o diagrama de classes para um sistema de locao de veculos,
levando em considerao os seguintes requisitos:
A empresa possui muitos automveis. Cada automvel tem atributos como
nmero de placa, cor, ano, tipo de combustvel, nmero de portas,
quilometragem, renavam, chassi, valor de locao, etc.
Cada carro tem um modelo e uma marca, mas um modelo pode relacionar-se
a vrios carros e uma marca pode referir-se a vrios modelos, embora cada
modelo so tenha uma nica marca especfica.
Um carro pode ser alugado pode ser alugado por vrios clientes, em
momentos diferentes, e um cliente pode alugar muitos carros. preciso saber
quais carros esto locados ou no. Sempre que um carro for locado preciso
armazenar a data e a hora de sua locao e, quando for devolvido, a data e a
hora da devoluo.

22