MDULO DE:

METODOLOGIA de ANLISE de SISTEMAS

AUTORIA:

Ms. Carlos Valente








2

Mdulo de: METODOLOGIA de ANLISE de SISTEMAS
Autoria: Ms. Carlos Valente

Primeira edio: 2007
















Todos os direitos desta edio reservados
ESAB ESCOLA SUPERIOR ABERTA DO BRASIL LTDA
http://www.esab.edu.br
Av. Santa Leopoldina, n 840/07
Bairro Itaparica Vila Velha, ES
CEP: 29102-040
Copyright 2007, ESAB Escola Superior Aberta do Brasil

3

APRESENTAO
O processo de desenvolvimento de sistemas necessita de mtodos especficos para se obter
softwares de qualidade. Atravs de metodologias adequadas o trabalho do analista se
profissionaliza.

OBJETIVO
Definir as principais funes de um analista de sistemas, e as principais ferramentas para
desenvolver sistemas de mdia e grande complexidade. Possibilitar a escolha da melhor
metodologia e ferramentas conforme as necessidades dos usurios de sistemas.

EMENTA
Apresentar os fundamentos das metodologias de anlise de sistemas consagradas no
mercado. Detalhar o processo de modelagem e prototipagem no desenvolvimento de
sistemas. Definir as metodologias e as suas principais ferramentas. Descrever os diagramas
da UML.

SOBRE O AUTOR
Professor e Consultor de Tecnologia de Informao

4

Doutorando (ITA) e Mestre (IPT) em Engenharia de Computao, Ps-Graduado em
Anlise de Sistemas (Mackenzie), Administrao (Luzwell-SP), e Reengenharia (FGV-
SP). Graduado/Licenciado em Matemtica.
Professor e Pesquisador da Universidade Anhembi Morumbi, UNIBAN, e ESAB
(Ensino a Distncia). Autor de livros em Conectividade Empresarial. Prmio em E-
Learning no Ensino Superior (ABED/Blackboard).
Consultor de T.I. em grandes empresas como Sebrae, Senac, Granero, Transvalor,
etc. Viagens internacionais: EUA, Frana, Inglaterra, Itlia, Portugal, Espanha, etc.


5

SUMRIO:
UNIDADE 1 .............................................................................................................................. 8
Introduo Anlise de Sistemas ......................................................................................... 8
UNIDADE 2 ............................................................................................................................ 12
Reviso Geral de Engenharia de Software ......................................................................... 12
UNIDADE 3 ............................................................................................................................ 15
Estrutura Geral de um Desenvolvimento Incremental e Iterativo ........................................ 15
UNIDADE 4 ............................................................................................................................ 19
Processo de Desenvolvimento de Software: Levantamento de Requisitos ......................... 19
UNIDADE 5 ............................................................................................................................ 25
Processo de Desenvolvimento de Software: Anlise de Requisitos.................................... 25
UNIDADE 6 ............................................................................................................................ 29
Processo de Desenvolvimento de Software: Projeto, Implementao, Testes e Implantao
............................................................................................................................................ 29
UNIDADE 7 ............................................................................................................................ 33
O que Metodologia ? O que Anlise de Sistemas ? O contexto dentro de Engenharia
de Software ......................................................................................................................... 33
UNIDADE 8 ............................................................................................................................ 37
O que faz um Analista de Sistemas ? A evoluo das Metodologias e ferramentas CASE 37
UNIDADE 9 ............................................................................................................................ 45
Metodologias de Anlise de Sistemas: Viso Geral ............................................................ 45
UNIDADE 10 .......................................................................................................................... 49
Metodologia Estruturada ..................................................................................................... 49
UNIDADE 11 .......................................................................................................................... 53
DFD Diagrama de Fluxo de Dados .................................................................................. 53
UNIDADE 12 .......................................................................................................................... 60
MER e DER Modelo e Diagrama de Entidades e Relacionamentos ................................ 60
UNIDADE 13 .......................................................................................................................... 66
Evoluo da Metodologia Estruturada................................................................................. 66
UNIDADE 14 .......................................................................................................................... 70

6

Modelagem de Sistemas Orientados a Objetos .................................................................. 70
UNIDADE 15 .......................................................................................................................... 74
O que Modelo ? ................................................................................................................ 74
UNIDADE 16 .......................................................................................................................... 79
Princpios da Modelagem .................................................................................................... 79
UNIDADE 17 .......................................................................................................................... 84
UML Unified Modeling Language ..................................................................................... 84
UNIDADE 18 .......................................................................................................................... 90
O Paradigma da Orientao de Objetos ............................................................................. 90
UNIDADE 19 .......................................................................................................................... 95
Encapsulamento, Polimorfismo e Herana ......................................................................... 95
UNIDADE 20 .......................................................................................................................... 99
Linguagens Orientada a Objetos ......................................................................................... 99
UNIDADE 21 ........................................................................................................................ 102
Diagrama de Casos de Uso .............................................................................................. 102
UNIDADE 22 ........................................................................................................................ 105
Casos de Uso: Formato, Detalhamento e Abstrao ........................................................ 105
UNIDADE 23 ........................................................................................................................ 109
Caso de Uso Atores e Relacionamentos ........................................................................ 109
UNIDADE 24 ........................................................................................................................ 113
Viso Geral dos Diagramas da UML e as suas categorias ............................................... 113
UNIDADE 25 ........................................................................................................................ 117
Diagrama de Classes e Diagrama de Estrutura ................................................................ 117
UNIDADE 26 ........................................................................................................................ 119
Diagrama de Componentes e Diagrama de Instalao ..................................................... 119
UNIDADE 27 ........................................................................................................................ 122
Diagrama de Objetos e Diagrama de Pacotes .................................................................. 122
UNIDADE 28 ........................................................................................................................ 125
Exemplo prtico: apresentao geral ................................................................................ 125
UNIDADE 29 ........................................................................................................................ 127
Exemplo prtico: Diagrama de Classes ............................................................................ 127
UNIDADE 30 ........................................................................................................................ 130

7

Exemplo prtico: Mecanismos e Componentes ................................................................ 130
GLOSSRIO ........................................................................................................................ 134
REFERNCIAS .................................................................................................................... 151


8

UNIDADE 1
Introduo Anlise de Sistemas
Objetivo: Contextualizar historicamente o incio da Anlise de Sistemas.
ANLISE DE SISTEMAS: COMO SURGIU?
A ideia de sistema surgiu aps a Primeira Guerra Mundial, como resultado do crescimento
das organizaes modernas e da necessidade de seu controle. E com a evoluo natural das
indstrias possibilitou a produo dos computadores.
A definio de Sistema sugerida pelo American National Standards Institute (ANSI) :
Sistema, para processamento de dados, o conjunto de pessoas, mquinas e mtodos
organizados de modo a cumprir um certo nmero de funes especficas.
Concomitantemente aplicao desse desenvolvimento surgiu a necessidade prtica de
administrao nas grandes empresas ou nos complexos civis e militares, envolvendo o
domnio de enormes quantidades de dados. Isso deu origem a diversos esforos em busca
da racionalizao e segurana desta tarefa.
A indstria eletrnica preparava o terreno para o que seria mais tarde chamada Segunda
Revoluo Industrial, isto , a informatizao da sociedade. Mas tudo comeou com os
computadores sendo tratados somente como equipamentos destinados pesquisa cientfica
ou, no mximo, realizao de clculos estatsticos com fins militares.
Foram duas as principais transformaes do mundo econmico e social, surgidas em
decorrncia da Revoluo Industrial. A primeira com a concentrao da produo e a
multiplicao da capacidade produtiva do homem atravs do domnio da energia. E a
segunda, o maior aproveitamento das mquinas e processos, cada vez mais concentrados e
homogneos.

9

Desta forma, a oficina artesanal desapareceu e deu lugar no incio a uma pequena fbrica,
que com o passar do tempo cresceu, assim como seu ambiente. Tornou-se impossvel
resolver todos os problemas no contexto da oficina artesanal e da pequena fbrica, que
estavam ao alcance de uma ou duas pessoas. Da a necessidade de algum para cuidar das
mquinas, algum para a questo contbil e legal, algum para as compras de matria prima
e algum para tratar com os clientes.
Para que tudo funcionasse de maneira que agradasse a todos, todas estas pessoas
participavam do processo produtivo, administrativo e comercial e deviam comunicar-se, uma
vez que todo o trabalho dependia cada vez mais dos outros e dos fatores externos
empresa. As tarefas deviam ser harmonizadas, organizadas e divididas entre todos, com
funes diferentes para cada um.
A comunicao era restrita, ou seja, cada indivduo s podia trocar informaes com poucos.
Esta prtica provocou a reduo do tempo gasto para passar as informaes, bem como
para a assimilao das mesmas, muitas vezes excessivas e inteis ou de pouca importncia
para o desempenho de uma tarefa.
Em funes destes fatos surgiu o planejamento de organizao definindo medidas
complementares de comunicao (o que e a quem comunicar). Alm disso, foram
aprimoradas as regras sobre a comunicao escrita. Descobriu-se que a utilizao de
formulrios impressos propiciava maior preciso de comunicao e economia de tempo
(definido em administrao como burocracia).
Apesar do controle mais rgido da comunicao de um indivduo com outro, ocorria perda de
informaes importantes. Para economizar tempo era necessrio comunicar e registrar
apenas o essencial. Porm, como saber o que era importante? O que essencial para uma
funo pode no ser para outra.
Outras formas de comunicao e controle foram estabelecidas. Novos formulrios e regras
se impuseram para se adaptar a nova realidade econmica.


10

A informao passou a ser administrada, independente de seu significado e uso. Tornou-se
necessrio planejar e definir procedimentos de tratamento, produo e controle dos fluxos de
informaes.
Nesse momento, comeava a Segunda Revoluo Industrial eram usadas ideias de
mecanizao pelo uso da eletricidade para o processamento das informaes, como
calculadoras mecnicas, controle automtico de equipamentos, e tabuladoras tipo "Hollerith"
para armazenamentos de dados. Procuravam-se, ao mesmo tempo, mtodos matemticos e
lgicos para avaliar situaes complexas com que as empresas, mais evoludas e de maior
porte, defrontavam
Foi a que surgiu a necessidade de ampliar a capacidade do homem em manusear e
processar informaes, fossem elas numricas ou no, empresariais ou militares, detalhadas
ou sintticas.
Assim, foram estudadas as estruturas organizacionais, procurando visualizar e examinar os
diversos mecanismos de interao entre as mesmas, enfatizando a dinmica da informao.
Os estudos destas estruturas permitiram, atravs da anlise de sistemas e sua consequente
informatizao, dominar a complexidade de empresas gigantescas que gradativamente iam
surgindo a partir da dcada de 50.
Depois que passamos pela segunda Revoluo Industrial entramos numa nova era. A partir
da dcada de 90, com o advento das Novas Tecnologias de Informao e Comunicao
(NTICs) propiciamos a formao da Sociedade da Informao ou do Conhecimento. A dita
terceira Revoluo Industrial ou a Era da Informao.

11




Aproveite para conhecer o American National Standards Institute (ANSI) atravs do
seu site: http://www.ansi.org/
e mais caractersticas deste importante rgo no Wikipdia (
http://pt.wikipedia.org/wiki/Ansi ).




Descreva sucintamente como foi o incio histrico da Anlise de Sistemas e as trs
fases da Revoluo Industrial



12

UNIDADE 2
Reviso Geral de Engenharia de Software
Objetivo: Revisar de forma sinttica os principais conceitos de Engenharia de Software.
Vamos agora revisar a Engenharia de Software aos olhos da Metodologia de Anlise de
Sistemas. Um dos tpicos iniciais o modelo de Ciclo de Vida. Podemos resumir os diversos
modelos existentes na prtica em dois: o Modelo Cascata e o Modelo Iterativo e
Incremental.
Modelo Cascata
O Modelo Cascata tambm chamado de Clssico ou Linear se caracteriza por possuir uma
tendncia na progresso sequencial entre uma fase e a seguinte. Eventualmente, pode haver
uma retroalimentao de uma fase para a fase anterior, mas de um ponto de vista macro, as
fases seguem fundamentalmente de forma sequencial.
Os projetos de desenvolvimento reais raramente seguem o fluxo sequencial que esse
modelo prope. Tipicamente, algumas atividades de desenvolvimento podem ser realizadas
em paralelo. E a entrega do sistema ao usurio, por esse modelo, somente ocorrer no final
do projeto. O que na maioria dos casos ocorre que os requisitos iniciais foram alterados ou
modificados e o sistema no vai mais corresponder realidade, ou s necessidades do
usurio.

13


Modelo Iterativo E Incremental
O Modelo de ciclo de vida Iterativo e Incremental foi proposto justamente para ser a resposta
aos problemas encontrados no Modelo em Cascata. Um processo de desenvolvimento
segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos.
Em cada ciclo de desenvolvimento, podem ser identificadas as fases de anlise, projeto,
implementao e testes. Essa caracterstica contrasta com a abordagem clssica, na qual as
fases de anlise, projeto, implementao e testes so realizadas uma nica vez.
No Modelo de ciclo de vida Iterativo e Incremental, um sistema de software desenvolvido
em vrios passos similares (iterativo). Em cada passo, o sistema estendido com mais
funcionalidades (incremental).
A abordagem incremental incentiva a participao do usurio nas atividades de
desenvolvimento do sistema, o que diminui em muito a probabilidade de interpretaes
erradas em relao aos requisitos levantados.
Outra vantagem dessa abordagem que os riscos do projeto podem ser mais bem
gerenciados. Um risco de desenvolvimento a possibilidade de ocorrncia de algum evento
que cause prejuzo ao processo de desenvolvimento, juntamente com as consequncias
desse prejuzo. Os requisitos a serem considerados primeiramente devem ser selecionados
com base nos riscos que eles fornecem. Os requisitos mais arriscados devem ser
considerados, to logo possvel.

14

Para entender o motivo de que o conjunto de requisitos deve ser considerado o mais cedo
possvel, vamos nos lembrar de uma famosa frase do consultor Tom Gilb (1988): Se voc
no atacar os riscos ativamente, ento estes iro ativamente atacar voc. Ou seja, quanto
mais cedo a equipe de desenvolvimento considerar os requisitos mais arriscados, menor a
probabilidade de ocorrerem prejuzos devido a esses requisitos.


Conhea mais sobre o polmico engenheiro de sistemas Tom Gilb no Wikipdia
americano: http://en.wikipedia.org/wiki/Tom_Gilb




Responda a questo: Quais so os diferenciais do Modelo de ciclo de vida
Iterativo e Incremental quanto ao modelo clssico?



15

UNIDADE 3
Estrutura Geral de um Desenvolvimento Incremental e Iterativo
Objetivo: Detalhar e definir a estrutura geral de um Desenvolvimento Incremental e Iterativo.
Basicamente o ciclo de vida de processo Incremental e Iterativo pode ser estudado segundo
duas dimenses: a temporal e a de atividades. Veja mais atentamente a figura abaixo:

A dimenso temporal, na horizontal (na parte mais inferior do grfico), os processos esto
estruturados em FASES (concepo, elaborao, construo e transio). Em cada uma
dessas fases, h uma ou mais iteraes. Cada iterao tem uma durao preestabelecida
(de duas a seis semanas). Ao final de cada iterao, produzido um incremento, ou seja,

16

uma parte do sistema final. Um incremento pode ser liberado para os usurios, ou pode ser
somente um incremento interno.
A dimenso de atividades (ou de fluxos de trabalho) apresentada verticalmente na figura
anterior. Essa dimenso compreende as atividades realizadas durante a iterao de uma
dessas fases: levantamento de requisitos, anlise de requisitos, projeto, implementao,
testes e implantao (as mesmas atividades que veremos mais detalhadamente adiante).
Em cada uma dessas fases, diferentes artefatos de software so produzidos, ou artefatos
comeados em uma fase anterior so estendidos com novos detalhes. Cada fase concluda
com um MARCO. Um marco um ponto do desenvolvimento no qual decises sobre o
projeto so tomadas e importantes objetivos so alcanados. Os marcos so teis para o
gerente de projeto estimar os gastos e o andamento do cronograma de desenvolvimento.
Como vimos anteriormente as fases que so delimitadas pelos marcos so: concepo,
elaborao, construo e transio. Vejamos agora com mais detalhes cada uma dessas
fases:
CONCEPO:
Nessa fase a ideia geral, e o escopo do desenvolvimento, so desenvolvidos. Um
planejamento de alto nvel do desenvolvimento realizado. So determinados os marcos que
separam as fases.
ELABORAO
alcanado um entendimento inicial sobre como o sistema ser construdo. O planejamento
do projeto de desenvolvimento completado. Nessa fase, o domnio do negcio analisado.
Os requisitos do sistema so ordenados considerando-se prioridade e risco. Tambm so
planejadas as iteraes da prxima fase, a de construo. Isso envolve definir a durao de
cada iterao e o que ser desenvolvido em cada iterao.



17

CONSTRUO
As atividades de anlise e projeto aumentam em comparao s demais. Esta a fase na
qual ocorrem mais iteraes incrementais. No final dessa fase, decidido se o produto de
software pode ser entregue aos usurios sem que o projeto seja exposto a altos riscos. Se
este for o caso, tem incio a construo do manual do usurio e da descrio dos
incrementos realizados no sistema.
TRANSIO
Os usurios so treinados para utilizar o sistema. Questes de instalao e configurao do
sistema tambm so tratadas. Ao final desta fase, a aceitao do usurio e os gastos so
avaliados. Uma vez que o sistema entregue aos usurios, provavelmente surgem novas
questes que demandam a construo de novas verses do mesmo. Neste caso, um novo
ciclo de desenvolvimento iniciado.
Em cada iterao, uma proporo maior ou menor de cada dessas atividades realizada,
dependendo da fase em que se encontra o desenvolvimento. Na figura, com o intuito de
mostrar um modelo amplo da estrutura geral de um Desenvolvimento Incremental e Iterativo,
permite-se perceber, por exemplo, que na fase de transio, a atividade de implantao a
predominante. Por outro lado, na fase de construo, as atividades de anlise, projeto e
implementao so as de destaque. Normalmente, a fase de construo a que possui mais
interaes. No entanto, as demais fases tambm podem conter iteraes, dependendo da
complexidade do sistema.
O principal representante da abordagem de desenvolvimento incremental e iterativo o
denominado RUP - Rational Unified Process (Processo Unificado Racional). Este processo
de desenvolvimento patenteado pela empresa Rational, ondem trabalham os famosos trs
amigos (J acobson, Booch e Rumbaugh). A descrio feita nesta seo uma verso
simplificada do Processo Unificado.
Veremos nas unidades a seguir um detalhamento de cada uma das fases apresentadas
nesta aula.

18




Aproveite para visitar o site da Rational
http://www.rational.com/products/rup/index.jtmpl e leia o artigo Best Practices for
Software Development Teams.




Tente reproduzir, somente de memria, o grfico apresentado nesta unidade
representando o modelo amplo da estrutura geral de um Desenvolvimento
Incremental e Iterativo.



19

UNIDADE 4
Processo de Desenvolvimento de Software: Levantamento de Requisitos
Objetivo: Destacar as caractersticas e a importncia, no desenvolvimento de software, da
fase de levantamento de requisitos.
Para dar uma ideia da realidade atual no desenvolvimento de sistemas de software, so
listados a seguir alguns dados levantados no Chaos Report
(www.projectsmart.co.uk/docs/chaos-report.pdf), um estudo feito pelo Standish Group, sobre
projetos de desenvolvimento:
Porcentagem de projetos que terminam dentro do prazo estimado: 10%
Porcentagem de projetos que so descontinuados antes de chegarem ao fim: 25%
Porcentagem de projetos acima do custo esperado: 60%
Atraso mdio nos projetos: 1 ano
Como j vimos em unidades anteriores um processo de desenvolvimento pode ser
estruturado em atividades realizadas durante a construo de um sistema de software. E h
vrios processos de desenvolvimento propostos, no entanto no existe o melhor processo de
desenvolvimento. Cada processo tem suas particularidades em relao ao modo de arranjar
e encadear as atividades de desenvolvimento. Veremos a seguir as mais comuns e
tradicionais atividades de um processo de desenvolvimento.
Levantamento De Requisitos
Pela definio de Maciaszek (2000), temos que requisito uma condio ou capacidade
que deve ser alcanada ou possuda por um sistema ou componente deste para satisfazer
um contrato, padro, especificao ou outros documentos formalmente impostos.

20

Normalmente os requisitos de um sistema so identificados a partir do domnio do negcio.
Denomina-se domnio de negcio a rea de conhecimento especfica na qual um
determinado sistema de software ser desenvolvido. Ou seja, domnio de negcio
corresponde parte do mundo real que relevante ao desenvolvimento de um sistema. O
domnio de negcio tambm chamado de domnio do problema ou domnio da aplicao.
Veja a figura a seguir:

Durante o levantamento de requisitos, a equipe de desenvolvimento tenta entender o
domnio do negcio que deve ser automatizado pelo sistema de software. O levantamento de
requisitos compreende um estudo exploratrio das necessidades dos usurios e da situao
do sistema atual (se esse existir). Alguns autores aconselham ao analista a no perder
tempo com o sistema atual, e partir diretamente para a concepo do novo. Este conselho se
deve ao fato de o analista no ficar amarrado aos conceitos da estrutura antiga, e poder ser
mais inovador possvel em sua nova proposta.
O produto final do levantamento de requisitos o Documento de Requisitos, que declara os
diversos tipos de requisitos do sistema. Normalmente esse documento escrito em
linguagem natural (notao informal). As principais sees de um documento de requisitos
so:

21

REQUISITOS FUNCIONAIS
Definem as funcionalidades do sistema. Veremos mais adiante nesta apostila que
tipicamente os Requisitos Funcionais sero alvo na UML, dos modelos de Caso de Uso.
Alguns exemplos prticos de requisitos funcionais so:
o sistema deve permitir que cada professor realize o lanamento de notas das turmas nas
quais lecionou
o sistema deve permitir que o aluno realize a sua matrcula nas disciplinas oferecidas em um
semestre
os coordenadores de escola devem poder obter o nmero de aprovaes, reprovaes e
trancamentos em todas as turmas em um determinado perodo
REQUISITOS NO-FUNCIONAIS
Declaram as caractersticas de qualidade que o sistema deve possuir e que esto
relacionadas s suas funcionalidades. Para voc visualizar melhor esse conceito, alguns
tipos de requisitos no funcionais so relacionados a seguir:
CONFIABILIDADE
Corresponde a medidas quantitativas da confiabilidade do sistema, tais como tempo mdio
entre falhas, recuperao de falhas ou quantidade de erros por milhares de linhas de cdigo-
fonte.
DESEMPENHO
Requisitos que definem tempos de respostas esperados para as funcionalidades do sistema.
PORTABILIDADE
4acilidade para transportar o sistema para outras plataformas.
SEGURANA

22

Limitaes sobre a segurana do sistema em relao a acessos no autorizados.
USABILIDADE
Requisitos que se relacionam ou afetam a usabilidade do sistema. Exemplos incluem
requisitos sobre a facilidade de uso e a necessidade ou no de treinamento dos usurios.
Uma das formas de se medir a qualidade de um sistema de software atravs de sua
utilidade. E um sistema ser til para seus usurios se atender aos requisitos definidos.
O enfoque prioritrio do levantamento de requisitos responder claramente a questo: O
que o usurio necessita do novo sistema?. Requisitos definem o problema a ser resolvido
pelo sistema de software; eles no descrevem o software que resolve o problema.
Lembre-se sempre: novos sistemas sero avaliados pelo seu grau de conformidade aos
requisitos, no quo complexa a soluo tecnolgica tenha sido aplicada.
O levantamento de requisitos a etapa mais importante em termo de retorno de investimento
feito para o projeto de desenvolvimento. Muitos sistemas foram abandonados ou nem
chegaram a serem usados porque os membros da equipe no dispensaram tempo suficiente
para compreender as necessidades do cliente. Em um estudo baseado em 6.700 sistemas
feitos em 1997, Carper J ones mostrou que os custos resultantes da m realizao desta
etapa de entendimento podem ser 200 vezes maiores que o realmente necessrio.
O Documento de Requisitos serve como um termo de consenso entre a equipe tcnica de
desenvolvedores e o cliente. Esse documento constitui a base para as atividades
subsequentes do desenvolvimento do sistema e fornece um ponto de referncia para
qualquer validao futura do software construdo. O envolvimento do cliente desde o incio do
processo de desenvolvimento ajuda a assegurar que o produto desenvolvido realmente
atenda s necessidades identificadas.
Alm disso, o Documento de Requisitos estabelece o escopo do sistema, isto , o que faz
parte e o que no faz parte do sistema. O escopo de um sistema muitas vezes muda durante
o seu desenvolvimento. Desta forma, se o escopo muda, tanto clientes quando

23

desenvolvedores tm um parmetro para decidirem o quanto de recursos de tempo e
financeiros devem mudar.
Outro ponto importante sobre requisitos a sua caracterstica de volatilidade. Um requisito
voltil aquele que pode sofrer modificaes durante o desenvolvimento do sistema.
A menos que o sistema a ser desenvolvido seja bastante simples e esttico, caractersticas
cada vez mais raras nos sistemas atuais, humanamente impossvel pensar em todos os
detalhes em princpio. Alm disso, quando o sistema entrar em produo e os usurios
comearem a utiliz-lo, eles prprios descobriro requisitos nos quais nem sequer tinham
pensado anteriormente.
Em resumo, os requisitos de um sistema complexo inevitavelmente mudaro durante todo o
seu desenvolvimento. No desenvolvimento de sistemas de software, a existncia de
requisitos volteis corresponde mais a regra do que exceo.

24




Visite o site do Prof. Maciaszek: http://www.comp.mq.edu.au/~leszek/
http://www.branqs.com.br/universidade/aulas_EngSoft_Ciencias/0002_Levantame
ntoDeRequisitos/LevantamentoDosRequisitosDoSistema.pdf
http://www2.iesam-pa.edu.br/pids/descrs/DescLevantamentoRSw.html




Baseado em sua experincia acadmica, tente desenvolver um Documento de
Requisitos para um imaginvel Sistema de Controle Universitrio. Esse sistema deve
controlar as funes bsicas de uma faculdade tais como: controle das inscries de
alunos em disciplinas, alocao de turmas, salas e professores e assim por diante.
Deve permitir tambm o controle de notas atribudas aos alunos nas diversas
disciplinas.


25

UNIDADE 5
Processo de Desenvolvimento de Software: Anlise de Requisitos
Objetivo: Descrever os principais pontos da fase de Anlise de Requisitos no processo de
desenvolvimento de software.
Formalmente, o termo anlise corresponde a quebrar um sistema em seus componentes, e
estudar como tais componentes interagem com o objetivo de entender como esse mesmo
sistema funciona. No contexto dos sistemas de software, esta a etapa na qual os analistas
realizam um estudo detalhado no Documento de Requisitos levantado na atividade anterior.
A partir desse estudo, so construdos modelos para representar o sistema a ser construdo
(veja mais detalhes na figura a seguir). A Anlise de Requisitos tambm chamada por
alguns autores como Especificao de Requisitos.


26

Assim como no levantamento de requisitos, a Anlise de Requisitos no leva em conta o
ambiente tecnolgico a ser utilizado. Nessa atividade, o foco de interesse tentar construir
uma estratgia de soluo, sem se preocupar com a maneira como essa estratgia ser
realizada.
A razo dessa prtica tentar obter a melhor soluo para o problema sem se preocupar
com os detalhes da tecnologia a ser utilizada. necessrio saber o que o sistema proposto
precisa fazer para ento, definir como esse sistema ir faz-lo.
Ocorre que, frequentemente na prtica, as equipes de desenvolvimento passam para a
construo da soluo sem antes terem definido completamente o problema. Portanto, os
modelos construdos nesta fase devem ser cuidadosamente validados e verificados, atravs
da validao e verificao dos modelos respectivamente.
O objetivo da validao assegurar que as necessidades do cliente esto sendo atendidas
pelo sistema: ser que o software correto est sendo construdo?.
J a verificao tem o objetivo de verificar se os modelos construdos esto em conformidade
com os requisitos definidos: ser que o software est sendo construdo corretamente?.
Na verificao dos modelos, so analisadas a exatido de cada modelo em separado e a
consistncia entre os modelos.
Em um processo de desenvolvimento orientado a objetos, o resultado da anlise so
modelos que representam as estruturas das classes de objetos que sero componentes do
sistema. Alm disso, a anlise tambm resulta em modelos que especificam as
funcionalidades do sistema de software.
Prototipagem
A construo de prottipos uma tcnica que serve de complemento anlise de requisitos.
No contexto do desenvolvimento de software, um prottipo um esboo de alguma parte do
sistema.
Prottipos so construdos para telas de entrada, telas de sada, subsistemas, ou mesmo
para os sistemas como um todo. A construo de prottipos utiliza as denominadas

27

linguagens de programao visual. Exemplos so o Delphi, o PowerBuilder e o Visual Basic
que, na verdade, so ambientes com facilidades para a construo da interface grfica (telas,
formulrios, etc.). Alm disso, muitos Sistemas de Gerncia de Bancos de Dados tambm
fornecem ferramentas para a construo de telas de entrada e sada de dados.
Na prototipagem, aps o levantamento de requisitos, um prottipo do sistema construdo
para ser usado na validao. O prottipo revisto por um ou mais usurios, que fazem suas
avaliaes e crticas acerca das caractersticas apresentadas. O prottipo ento corrigido
ou refinado de acordo com as intervenes dos usurios.
Esse processo de reviso e refinamento continua at que o prottipo seja aceito pelos
usurios. Portanto, a tcnica de prototipagem muito til e tem o objetivo de assegurar que
os requisitos do sistema foram realmente bem entendidos.
O resultado da validao atravs do prottipo pode ser usado para refinar os modelos do
sistema. Aps a aceitao, o prottipo (ou parte dele) pode ser descartado ou utilizado como
uma verso inicial do sistema.
Embora a tcnica de prototipagem seja opcional, ela frequentemente aplicada em projetos
de desenvolvimento de software, especialmente quando h dificuldades no entendimento dos
requisitos do sistema, ou h requisitos arriscados que precisam ser mais bem entendidos.
A ideia que um prottipo mais concreto para fins de validao do que modelos
representados por diagramas bidimensionais (tipo DFD, ou mesmo o UML). Isso incentiva a
participao ativa do usurio na validao. Consequentemente, a tarefa de validao se
torna menos suscetvel a erros. No entanto, destacamos que alguns desenvolvedores usam
essa tcnica como um substituto construo de modelos de sistema.
Tenha em mente que a prototipagem uma tcnica complementar construo dos modelos
do sistema. Os modelos do sistema devem ser construdos, pois so eles que guiam as
demais fases do projeto de desenvolvimento de software.

28

Idealmente, os erros detectados na validao do prottipo devem ser utilizados para
modificar e refinar os modelos do sistema. Portanto, devemos utilizar a prototipagem como
complemento ao Modelo de Ciclo de Vida Iterativo e Incremental, e no para substitu-la.



Veja o interessante texto, no Wikipdia, sobre o uso da prototipagem:
http://pt.wikipedia.org/wiki/Uso_da_Prototipagem_na_Eng._de_Requisitos




Veja o blog http://maozinhadaweb.blogspot.com/2007/05/anlise-de-requisitos-
funcionais-x-no.html e realize uma anlise crtica do aluno da UFB.

29

UNIDADE 6
Processo de Desenvolvimento de Software: Projeto, Implementao, Testes e
Implantao
Objetivo: Apresentar as ltimas etapas e a relao das mesmas no Processo de
Desenvolvimento de Software.
O foco principal da anlise so os aspectos lgicos e independentes de implementao de
um sistema, os requisitos. Na fase de Projeto, determina-se como o sistema funcionar
para atender aos requisitos, de acordo com os recursos tecnolgicos existentes a fase de
projeto considera os aspectos fsicos e dependentes de implementao.
Aos modelos construdos na fase de anlise so adicionadas as determinadas restries de
tecnologia. Exemplos de aspectos a serem considerados na fase de projeto: arquitetura do
sistema, padro de interface grfica, a linguagem de programao, o Gerenciador de Banco
de Dados, etc.

30


Esta fase produz uma descrio computacional do que o software deve fazer, e deve ser
coerente com a descrio feita na anlise. Em alguns casos, algumas restries da
tecnologia a ser utilizada j foram amarradas no Levantamento de Requisitos. Em outros
casos, essas restries devem ser especificadas. Mas, em todos os casos, a fase de projeto
do sistema direcionada pelos modelos construdos na fase de anlise e pelo planejamento
do sistema.
O projeto consiste de duas atividades principais: Projeto da Arquitetura, tambm conhecido
como projeto de alto nvel, e Projeto Detalhado denominado tambm como projeto de baixo
nvel.
Em um processo de desenvolvimento orientado a objetos, o Projeto da Arquitetura consiste
em distribuir as classes de objetos relacionados do sistema em subsistemas e seus
componentes. Consiste tambm em distribuir esses componentes fisicamente pelos recursos

31

de hardware disponveis. Os diagramas da UML normalmente utilizados nesta fase do
projeto so os Diagramas de Implementao.
No Projeto Detalhado, so modeladas as colaboraes entre os objetos de cada mdulo com
o objetivo de realizar as funcionalidades do mdulo. Tambm so realizados o projeto da
interface com o usurio e o projeto de Banco de Dados. Os principais diagramas da UML
utilizados nesta fase do projeto so: Diagrama de Classe, Diagrama de Casos de Uso,
Diagrama de Interao, Diagrama de Estados e Diagrama de Atividades.
Embora a Anlise e o Projeto sejam descritos didaticamente em sees separadas,
importante notar que na prtica no h uma distino to clara entre essas duas fases.
Principalmente no desenvolvimento de sistemas orientados a objetos, as atividades dessas
duas fases frequentemente se misturam.
IMPLEMENTAO
Na Implementao, o sistema codificado, ou seja, ocorre a traduo da descrio
computacional da fase de projeto em cdigo executvel atravs do uso de uma ou mais
linguagens de programao.
Em um processo de desenvolvimento orientado a objetos, a implementao envolve a
definio das classes de objetos do sistema utilizando linguagens de programao como
C++, J ava, etc. Alm da codificao desde o incio, a Implementao pode e deve tambm
utilizar componentes de software e bibliotecas de classes preexistentes para agilizar a
atividade.

32

TESTES
Diversas atividades de teste so realizadas para verificao do sistema construdo, levando-
se em conta a especificao feita na fase de Projeto. O principal produto dessa fase o
Relatrio de Testes, contendo informaes sobre erros detectados no software. Aps a
atividade de testes, os diversos mdulos do sistema so integrados, resultando finalmente no
produto de software.
IMPLANTAO
O sistema empacotado, distribudo e instalado no ambiente do usurio. Os manuais do
sistema so escritos, os arquivos so carregados, os dados so importados para o sistema e
os usurios so treinados para utilizar o sistema corretamente. Em alguns casos,
principalmente em sistemas legados, aqui tambm ocorre a migrao de sistemas de
software e de dados preexistentes.



Reflita e responda as seguintes perguntas:
1. Como estas ltimas quatro fases do desenvolvimento de software se relacionam
com as primeiras etapas?
2. Como voc classificaria todas essas fases em ordem de importncia?



33

UNIDADE 7
Objetivo: Conceituar metodologia e relacionar com a Anlise de Sistemas dentro do contexto
da Engenharia de Software.
O que Metodologia? O que Anlise de Sistemas? O contexto dentro de Engenharia
de Software
Iremos comear esta unidade pela frase do Prof. J ayr Figueiredo
(http://donjf.sites.uol.com.br/) que retrata bem a realidade da implantao de metodologias na
rea de Sistemas:
Quando voc tentar implantar uma nova metodologia para desenvolvimento de sistemas,
certamente ir cometer erros. Porm, se no tentar implant-la, j estar errando.
Para nos aprofundarmos nesse conceito precisamos distinguir as palavras Mtodo e
Metodologia. Embora utilizada indiscriminadamente tanto de uma forma com de outra,
existe diferena significativa entre essas palavras.
Mtodo
o caminho pelo qual se atinge um objetivo. Pode-se definir tambm como um programa
que regula previamente uma srie de operaes que se devem realizar, apontando erros
evitveis, em vista de um resultado determinado. Com isso, temos que o mtodo o
caminho ordenado e sistemtico para chegar a um fim.
Metodologia
a arte de dirigir o esprito na investigao da verdade, ou simplesmente como o estudo
dos mtodos e, especialmente, dos mtodos da cincia. Consiste em avaliar, analisar e
estudar os vrios mtodos disponveis pela emisso e aprovao das tcnicas, as quais
sero aplicadas futuramente, oferecendo algumas formas de divulgao que orientem outras
aplicabilidades.

34

Portanto, a Metodologia mais ampla que Mtodo, pois a primeira estuda a segunda. Dentro
desse contexto a metodologia pode ser considerada como um sistema para desenvolver
sistemas. Devemos lembrar que nem sempre a metodologia de trabalho adotada pode trazer
benefcios e os resultados esperados pelas empresas. Principalmente se a metodologia
apresentar uma filosofia, uma poltica e uma estrutura eficazes, mas pouco eficiente ou muito
burocrtica.
Por outro lado, uma metodologia bem implantada pode propiciar a qualquer empresa vrios
benefcios. Vejamos a seguir essas principais vantagens.

Benefcios De Uma Metodologia Bem Implantada
Aumento Da Qualidade Dos Sistemas
Os desenvolvedores tm sua disposio mtodos que permitem levantar com preciso as
necessidades dos usurios e construir sistemas melhores estruturados. O uso de uma
notao padronizada melhora a comunicao com os usurios e entre os prprios
profissionais de sistemas. Portanto, fundamental documentar.
Independncia Dos Analistas
Como os sistemas so bem documentados e estruturados, um analista consegue dar
manuteno a um sistema que no conhea previamente. Evita-se o erro da criao do
dono do sistema, situao indesejvel tanto para a empresa, para os usurios e para o
prprio analista. Esse analista proprietrio do sistema, alm de no poder evoluir para outros
desafios na empresa, fica to amarrado ao seu prprio sistema que, muitas vezes, nem
frias consegue tirar.
Facilidade De Manuteno
Complemento ao item anterior, destacando-se que com manutenes mais fceis e rpidas,
sobra mais tempo para desenvolver sistemas novos, ou a reengenharia dos antigos.
Aumento Da Produtividade

35

Sistemas bem construdos tm mais partes reutilizveis. E, como o sistema bem
especificado e projetado, gastam-se menos tempo em testes e gambiarras (emendas) para
atender ao usurio.
Um dos pontos que uma boa Metodologia aborda so as Mtricas de Software. Podem-se
definir Mtricas de Software a uma ampla variedade de medidas de software, bem como,
orientadas ao tamanho de medidas diretas do software e do processo por meio do qual ele
desenvolvido. Citando Pressman quando ao seu conceito de mtricas temos:
Quando se pode medir aquilo sobre o qual se est falando e express-lo em nmeros, sabe-
se alguma coisa sobre o mesmo; mas quando no se pode medi-lo, quando no se pode
express-lo em nmeros, o conhecimento que se tem de um tipo inadequado e
insatisfatrio; este pode ser o comeo do conhecimento, mas dificilmente algum ter
avanado em suas idias para o estgio da cincia.
Principais Objetivos Da Metodologia
Criar uma ferramenta que possibilite a desenvolvimento de projetos na empresa, em
harmonia com os princpios elementares da administrao, tais como: planejamento,
previso, organizao, deciso, comando, coordenao e controle;
Promover o cumprimento de prazos, eficincia e qualidade do servio, visando uma maior
produtividade atravs da padronizao das atividades de desenvolvimento e da
racionalizao dos controles e dos itens de documentao;
Servir de apoio ao desenvolvimento de projetos em suas etapas, orientando a execuo das
atividades requeridas em todos os nveis e setores envolvidos, de uma forma padronizada e
integrada;
Estabelecer uma estrutura de documentao padronizada e compatvel com a organizao
das fases e necessidades operacionais.

36




Visite o site do Prof. J ayr Figueiredo: http://donjf.sites.uol.com.br/
http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1249454,00.
html?track=NL-776&ad=587562&Offer=SWQmod425lg&asrc=EM_USC_1352054




Pesquise em sua empresa, ou na de colegas, o uso de metodologias. Que
metodologias so determinadas pela empresa e quais so as efetivamente
utilizadas por todos? Existe alguma punio no caso do no cumprimento dessas
metodologias? Quais so os principais motivos do no cumprimento das
metodologias?


37

UNIDADE 8
Objetivo: Especificar as principais funes de um Analista de Sistema e as principais
Metodologias aplicadas
O que faz um Analista de Sistemas? A evoluo das Metodologias e ferramentas CASE
Analista de Sistemas o profissional que deve ter conhecimento do domnio do negcio.
Esse profissional deve entender os problemas do domnio do negcio para que possa definir
os requisitos do sistema a ser desenvolvido. Especialistas do Domnio so as pessoas que
tem familiaridade com o domnio do negcio, mas no necessariamente com o
desenvolvimento de sistemas de Software. Frequentemente, estes especialistas so os
futuros usurios do Sistema em desenvolvimento.
Analistas devem estar aptos a se comunicar com especialistas do domnio para obter
conhecimento acerca dos problemas e das necessidades envolvidas da organizao
empresarial. O Analista no precisa ser um especialista do domnio. Contudo, ele deve ter
suficiente domnio do vocabulrio da rea de conhecimento na qual o sistema ser
implantado. Isso evita que ao se comunicar com o especialista de domnio, este no precise
ser interrompido a todo o momento para explicar conhecimentos bsicos da rea.
Tipicamente, o Analista de Sistemas o profissional responsvel por entender as
necessidades dos clientes em relao ao sistema a ser desenvolvido e repassar esse
entendimento aos demais desenvolvedores de sistemas. Nesse sentido, o Analista de
Sistemas representa a ponte de comunicao entre duas faces: a dos profissionais de
computao e a dos profissionais do negcio.
Para realizar suas funes, o Analista de Sistemas deve entender no s do domnio do
negcio da organizao, mas tambm ter conhecimento dos aspectos mais complexos da
computao. Nesse sentido, o Analista de Sistemas funciona como um tradutor, que mapeia
informaes entre duas linguagens diferentes: a dos especialistas de domnio e a dos
profissionais tcnicos da equipe de desenvolvimento.

38

Com a experincia adquirida atravs da participao no desenvolvimento de diversos
projetos, alguns analistas se tornam gerentes de projetos. Na verdade, as possibilidades de
evoluo da carreira de um analista so bastante grandes. Isso se deve ao fato de que,
durante a fase de levantamento de requisitos de um sistema, o analista se torna quase um
especialista no domnio do negcio da organizao. Para a organizao, bastante
interessante ter em seu quadro um profissional que entenda ao mesmo tempo de tcnicas de
desenvolvimento de sistemas e do processo de negcio da empresa. Por essa razo, no
rara a situao em que uma organizao oferece um contrato de trabalho ao analista de
sistemas terceirizado ao final do desenvolvimento.
Uma caracterstica importante que um analista de Sistemas deve ter a capacidade de
comunicao, tanto escrita como falada. Ele um agente facilitador da comunicao entre os
clientes e a equipe tcnica. Muitas vezes, as capacidades de comunicar agilmente e de ter
um bom relacionamento interpessoal so mais importantes para o analista do que o
conhecimento tecnolgico.
Outra caracterstica necessria a uma analista a tica profissional. Muitas vezes, o analista
de sistemas est em contato com informaes sigilosas e estratgicas dentro da organizao
na qual est trabalhando. Os analistas de Sistema tm acesso a informaes como preos
de custo de produtos, margens de lucro, algoritmos proprietrios, etc.
Certamente, pode ser desastroso para a organizao se informaes de carter confidencial
como estas carem em mos erradas. Portanto, a tica profissional do analista de sistemas
na manipulao de informaes como essas fundamental.
Os mandamentos do Analista de Sistemas e/ou Responsvel pelo Projeto
Estabelea claramente quem o lder do projeto, e defina cuidadosamente a
organizao do projeto.
Enfatize sempre a importncia do projeto como um todo, e no apenas de algumas
etapas, fases ou aspectos.
Dissipe os mitos contraproducentes sobre desenvolvimento de software.

39

Fornea sempre feedback para a sua equipe, e principalmente aos seus usurios.
Todos gostam de uma satisfao de como est a situao.
Transpire entusiasmo, sempre. Pode parecer um pouco piegas, mas todos estaro
vendo o seu desempenho no projeto e importante mostrar o seu envolvimento.
Crie visibilidade no projeto. Planeje reunies de follow-up para que todos os
envolvidos, os stackholders, estejam a par do que est acontecendo.
Envolva sempre a equipe nas atividades de planejamento, mesmo que tudo j esteja
planejado.
Seja sensvel s diferenas pessoais de estilo, de habilidades, de motivaes e de
problemas da sua equipe, e de seus usurios.
Equilibre liderana orientada para produo pela liderana orientada para pessoas.
Aprenda a priorizar e re-priorizar rapidamente.
Evoluo Das Metodologias De Desenvolvimento De Sistemas
Dcada de 50
-Sistemas de baixa complexidade
-Sistemas desenvolvidos sem planejamento
-Fluxogramas
-Diagramas de Mdulos
Dcada de 60 -Incio da Metodologia Estruturada
Dcada de 70
-Tcnicas de Modelagem de Dados
-Projeto de Banco de Dados
-Banco de Dados

40

Dcada de 80
-Especificao do Projeto
-Ferramentas de Software
-Modelagem de Dados
-Linguagens de quarta gerao
-Prototipao
-Interface com o usurio
-Automao das Metodologias
Dcada de 90
-Ferramentas de Gerao de Cdigo
-Metodologias Orientadas a Objetos (MOO)
Final da
Dcada de 90
-Maturidade da MOO
-Incio da UML

Como vimos, a Metodologia a reunio de normas, mtodos, controles, ferramentas,
tcnicas e polticas em uso numa empresa. Portanto, um conjunto muito grande de materiais
e informaes, visando a sua perfeita compreenso e utilizao.
A metodologia definida pelas organizaes no deve obrigar o uso de uma ou de outra
tcnica em especial. Deve estimular os profissionais a procurarem a tcnica mais adequada
ao problema a ser resolvido.
Cabe ao analista a escolha do ferramental especfico dentro da orientao que dada pela
Metodologia, baseada em normas internacionais e reconhecida pela Engenharia de
Software.


41



Ferramentas CASE
Um processo de desenvolvimento de software altamente complexo. Vrias pessoas, com
diferentes especialidades, esto envolvidas neste processo altamente cooperativo. Tal
atividade cooperativa pode ser facilitada atravs de uso de ferramentas que auxiliam na
construo de modelos de sistema, na integrao do trabalho de cada membro da equipe, no
gerenciamento do andamento do desenvolvimento, etc.
Sistemas de software que so utilizados para dar suporte ao ciclo de vida de
desenvolvimento so normalmente chamados de ferramentas CASE. O termo CASE uma
sigla em ingls para Engenharia de Software auxiliada por Computador (Computer Aided
Software Engineering). A utilizao dessa sigla j se consolidou no Brasil.
A Metodologia a base e CASE a automao da metodologia. As ferramentas CASE so
uma combinao de utilitrios de software com a Metodologia. Enfoca o problema da
produtividade e no somente os problemas de implementao. Para a sua implementao

42

so necessrias a incluso de treinamento intensivo e a seleo de grupo experiente para
esse treinamento.
Como principais caractersticas dessas ferramentas podem-se destacar a Engenharia
Reversa, repositrios (mecanismo para armazenamento e organizao de todas as
informaes concernentes ao sistema) e software reusvel.
Enfim, a automao das metodologias tornou-se uma constante nos sistemas. Otimiza e
evita o uso da programao manual. Com a tecnologia CASE, incrementa-se o processo
sistmico computacional em poder e capacidade.
Existem diversas ferramentas CASE disponveis no mercado. Algumas das caractersticas
que podem ser encontradas em ferramentas CASE so sucintamente descritas a seguir:
Diagramas
Criao de diagramas e manuteno da consistncia entre esses diagramas;

Round-trip engineering
Gerao de cdigo-fonte a partir de diagramas e gerao de diagramas a partir do cdigo-
fonte;
Depurao do cdigo-fonte
Ferramentas que permitem encontrar erros de lgica em partes de um programa;

Relatrios de testes
Ferramentas que geram relatrio informando sobre partes de um programa que no foram
testadas.
Testes automticos

43

Ferramentas que realizam testes automaticamente no sistema;
Gerenciamento de verses
Ferramentas que permitem gerenciar as diversas verses dos artefatos de software gerados
durante o ciclo de vida de um sistema;
Verificao de desempenho
Averiguar o tempo de execuo de mdulos de um sistema, assim como o trfego de dados
em sistemas de rede;
Erros
Verificao de erros em tempo de execuo;
Mudanas
Gerenciamento de mudanas nos requisitos.
Alem das ferramentas CASE, outras ferramentas importantes em um processo de
desenvolvimento so as que fornecem suporte ao grenciamento. Essas ferramentas so
utilizadas pelo Gerente de Projeto para desenvolver atividades tais como: cronogramas de
tarefas, definio de alocaes de verbas, monitoramento do progresso e os gastos, gerao
de relatrios de gerenciamento.

44




http://pt.wikipedia.org/wiki/Ferramenta_CASE
http://pt.wikipedia.org/wiki/An%C3%A1lise_de_sistemas#
http://br.answers.yahoo.com/question/index?qid=20061208183234AAXCP6A
http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=1308
http://www.timaster.com.br/revista/raiox/raiox.asp
http://www.brasilprofissoes.com.br/verprof.php?codigo=512




Leia o interessante artigo da Palloma P. Souza, e tambm o frum sobre a
discusso entre as diferenas entre o Analista de Sistema e o de Negcios:
http://osdir.com/ml/education.brazil.infoestacio/2006-10/msg00234.html
http://www.guj.com.br/posts/list/71342.java


45

UNIDADE 9
Objetivo: Apresentar historicamente as principais metodologias aplicadas a desenvolvimento
de sistemas.
Metodologias de Anlise de Sistemas: Viso Geral
As metodologias de sistemas como vimos so utilizadas para estabelecer ordem, definir
padres e usar tcnicas j provadas no desenvolvimento de sistemas, agilizando o processo
e garantindo maior qualidade no desenvolvimento.
Atualmente existem trs tipos de metodologias que se destacam: a estruturada, a de
desenvolvimento gil e a orientada por objetos. As diferenas nas metodologias esto
nas tcnicas de construo do processo de negcio, as definies dos dados e os modelos
de eventos.
Para apoiar as metodologias foram criadas ferramentas para acompanhar o ciclo de vida do
sistema, auxiliando no desenvolvimento de aplicativos (como as ferramentas CASE, visto na
unidade anterior) e no gerenciamento do projeto. Dentre as ferramentas mais utilizadas est
o RAD (Rapid Application Development), onde so utilizadas sesses de planejamento com
os usurios para definir o sistema de aplicao.
As metodologias para desenvolvimento de sistemas devem acompanhar todo o ciclo de vida
dos sistemas. Todas as metodologias usam grficos para representar os elementos de
sistemas. E as descries e definies de cada elemento so relacionadas no diagrama.
Metodologia Estruturada
Na metodologia estruturada de anlise e desenvolvimento de sistemas (SSAD Structured
System Analysis and Design) estabelecem-se sucessivos detalhamentos dos processos
desde o nvel macro, at o detalhe de mais baixo nvel. uma viso top-down de sistemas.
Essa a metodologia mais antiga, e ainda em uso por vrias instituies.

46

Para representar os elementos de
sistemas na Metodologia Estruturada se
usa o DFD (Data Flow Diagram). Os
DFDs descrevem o fluxo de dados no
sistema. Cada Diagrama de Fluxo de
Dados - DFD incorpora mais detalhes do
processo fazendo uma exploso de cada
componente do diagrama.
O diagrama DER (Entity Relation
Diagram - Diagrama Entidade
Relacionamento) de relacionamento de
entidades (por exemplo: um objeto, uma
pessoa, etc.) normaliza os dados do
ambiente e define os dados para a
aplicao. Em um diagrama de modelo
de dados com base no relacionamento
entre as entidades definem-se os
registros estruturados para serem
definidos nas bases de dados. No
diagrama de estrutura de dados
especificado como os dados devem
entrar e sair dos processos e serem
armazenados no sistema.
Uma ferramenta CASE pode armazenar
as descries em um
dicionrio/repositrio de dados.
Completando o diagrama tem-se o
modelo lgico do negcio, que uma
representao abstrata do mundo real.

47

Metodologia Desenvolvimento gil
A prpria Wikipdia define o desenvolvimento de software gil, que evoluram a partir da
metade de 1990, como parte de uma reao contra mtodos "pesados", caracterizados por
uma pesada regulamentao, regimentao e micro gerenciamento usado o modelo em
cascata para desenvolvimento. O processo originou-se da viso de que o modelo em cascata
era burocrtico, lento e contraditrio a forma usual com que os engenheiros de software
sempre realizaram trabalho com eficincia.
Uma viso que levou ao desenvolvimento de mtodos geis e iterativos era retorno prtica
de desenvolvimento vistas nos primrdios da histria do desenvolvimento de software.
Inicialmente, mtodos geis eram conhecidos como mtodos leves. Em 2001, membros
proeminentes da comunidade se reuniram em Snowbird e adotaram o nome mtodos geis.
Mais tarde, algumas pessoas formaram A Agile Alliance, uma organizao no lucrativa que
promove o desenvolvimento gil.
Os mtodos geis iniciais - criado a priore em 2000 (ver Manifesto gil em
http://agilemanifesto.org/ ) - incluam Scrum(1986), Crystal Clear, Programao extrema
(1996), Adaptive Software Development, Feature Driven Development, and Dynamic
Systems Development Method (1995).
Metodologia Orientada A Objetos
O desenvolvimento orientado a objetos (OOSD Object-oriented System Development)
encara cada processo como uma coleo de objetos. Os termos encapsulamento,
requerimento, herana e classe so bsicos dentro do contexto da metodologia. A
metodologia possui um conjunto prprio de diagramas e tambm usa alguns diagramas
similares aos da metodologia estruturada. Segundo Rumbaugh a tcnica de modelagem de
objetos possui quatro fases: anlise, projeto do sistema, projeto dos objetos e a
implementao.
Nos dias atuais a Metodologia Orientada a Objetos est vencendo a Estruturada. Para
facilitar o processo de migrao da Estruturada para a Orientada a Objetos, algumas

48

metodologias ponte esto sendo utilizadas na transio. Apesar dessa tendncia no
podemos nos esquecer da Metodologia Desenvolvimento gil que ainda possui muitos
adeptos a essa filosofia de desenvolvimento.




http://pt.wikipedia.org/wiki/Metodologia_%28engenharia_de_software%29




Voc pode se inteirar melhor das Metodologias ouvindo os interessantes
podcasts (MP3):
http://agilcoop.incubadora.fapesp.br/portal/agilcast/episodios/Agilcast01-intro.mp3
http://agilcoop.incubadora.fapesp.br/portal/agilcast/episodios/Agilcast07-
Perguntas.mp3



49

UNIDADE 10
Objetivo: Conceituar de forma geral e ampla da Metodologia Estruturada.
Metodologia Estruturada
Na Anlise Clssica de Sistemas gerado um documento descrevendo o sistema proposto.
Esse documento normalmente chamado de Especificao Funcional do Sistema. Por ser
um documento extremamente formal, costumeiramente os usurios assinam e no o leem
adequadamente. Praticamente os usurios interpretam como sendo um daqueles contratos
bancrios, com letras bem pequenas, e que todo mundo assina sem saber muito bem para
qu.
As principais desvantagens desse tipo de documento com especificaes tcnicas clssicas
podem ser resumidas da seguinte forma:
So monolticos e devem ser lidos do incio ao fim;
So redundantes, dando a mesma informao em diversos locais dentro do
documento;
So difcieis de se modificar e manter. Uma simples mudana nos requisitos do
usurio pode acarretar mudanas significativas na especificao;
So normalmente fsicas, ao invs de lgicas, pois descrevem os requisitos em termos
do hardware fsico, ou do tipo de estrutura fsica de arquivo que ser usado para
implementar o sistema. Confundindo-se a discusso sobre o que o usurio
efetivamente quer.
No entanto, a Anlise Estruturada veio com intuito de quebrar esse paradigma, utilizando de
ferramentas grficas para a documentao, gerando um novo tipo de especificao
funcional.

50

Ferramentas Da Anlise Estruturada
As principais ferramentas que a Anlise Estruturada criou na poca para a devida
documentao do Sistema foram:
Diagrama de Fluxo de Dados (DFD)
Modo grfico de representao da movimentao dos dados num sistema manual,
automtico ou misto. O DFD deve ser iniciado pelo sistema fsico atual, para tanto o
entendimento do analista como do usurio. Isso permita que se tenha uma viso top-down da
estrutura atual de trabalho dos usurios. Com essa compreenso parte-se para o incio do
fluxo lgico do sistema a ser proposto.
Dicionrio de Dados
o conjunto organizado das definies lgicas de todos os nomes de dados apresentados
no DFD.
Especificao de Processo
Permite que o analista descreva a direo de negcios, representada por cada um dos
processos. Devem-se detalhar todos os processos desde daqueles de nvel mais baixo
representados no DFD. A Especificao de Processo pode ser escrita de vrias formas
(frmulas, grficos), mas normalmente atravs do Portugus Estruturado. Esse recurso
possui um grupo limitado de verbos e substantivos, organizados a fim de garantir a
legibilidade e o rigor.
Diagrama Entidade Relacionamento (DER)
Procura enfatizar os principais objetos ou entidades de dados do Sistema, bem como a
relao entre esses objetos. importante destacar que os DFDs e o DERs enfatizam
aspectos diferentes do mesmo Sistema. Logo, existem correspondncias um a um que o
Analista de Sistemas deve verificar para assegurar um modelo geral coerente.


51

Caractersticas Da Anlise Estruturada
Modular
Ela foi estruturada, ao invs de monoltica da Anlise Clssica, para o conceito de mdulos,
quebrando o Sistema em partes lgicas.
Grfica
Consistindo em mais figuras do que palavras.
Top-Down
Apresentando a descrio do sistema em nveis progressivamente mais detalhados. Comea
com uma viso geral para depois entrar nos detalhes.
Lgica
Descreve um modelo independente de implementao.




http://pt.wikipedia.org/wiki/An%C3%A1lise_Estruturada




52




Tente descobrir porque ainda existem muitos sistemas que foram ou so
concebidos com a Metodologia Estruturada.




Antes de dar continuidades aos seus estudos fundamental que voc acesse sua
SALA DE AULA e faa a Atividade 1 no link ATIVIDADES.



53

UNIDADE 11
Objetivo: Exemplificar os Diagramas de Fluxo de Dados e os seus principais componentes e
tipos.
DFD Diagrama de Fluxo de Dados
O diagrama de fluxo de dados - DFD - representa o fluxo de dados num sistema de
informao, assim como as sucessivas transformaes que estes sofrem. O DFD uma
ferramenta grfica que transcreve, de forma no tcnica, a lgica do procedimento do
sistema em estudo, sendo usada por diferentes mtodos e principalmente pelos classificados
como orientados a processos.
O DFD a ferramenta mais usada para documentar a fase de anlise do convencional ciclo
de desenvolvimento de sistemas de informao. O diagrama de fluxo de dados apresenta
sempre quatro objetos de um sistema de informao: fluxo de dados, processos, arquivos de
dados e entidades externas. Esta ferramenta usada por diferentes autores, por exemplo,
Yourdon & DeMarco (veja Figura 11.1) e Gane & Sarson (veja Figura 11.2), que recorrem a
mtodos e smbolos diferentes para representar cada objeto:


54

No entanto, qualquer autor que use estes diagramas define os objetos do sistema da mesma
forma:
Entidades externas
Pessoa, grupo de pessoas ou subsistema/sistema fora do sistema em estudo que recebem
dados do sistema e/ou enviam dados para o sistema. As entidades externas funcionam
sempre como origem/destino de dados;
Fluxo de dados
Dados que fluem entre processos, entre processos e arquivos de dados ou ainda entre
processos e entidades externas, sem nenhuma especificao temporal (por exemplo
ocorrncia de processos simultneos, ou todas as semanas);
Arquivo de dados
Meio de armazenamento de dados para posterior acesso e/ou atualizao por um processo;
Processo
Recebe dados de entrada e transforma estes dados num fluxo de sada.
Atribuio De Nomes Aos Objetos
Qualquer objeto do sistema representado no DFD tem de ter um nome elucidativo e claro
para que os usurios possam interpretar facilmente o diagrama; os nomes devem refletir
exatamente a atividade do sistema.
Todos os autores ditam que o nome de um processo seja constitudo por um nico verbo e
um substantivo, devidamente escolhidos para que transmitam claramente o que o processo
faz. Assim verbos como processar, examinar, tratar, nunca devem ser usados, pois so
redundantes com o prprio conceito de processo e no deixam claro a prpria atividade do
processo.

55

Tambm, uma vez que o DFD representa logicamente o sistema, abstraindo-se de conceitos
fsicos, verbos como enviar ou armazenar no devem ser usados, pois tm caractersticas
fsicas.
Certos autores estipulam que o nome atribudo a entidades externas e arquivos de dados
deve ser escrito em letras maisculas e que o nome atribudo a processos e fluxos de dados
deve ser escrito em minsculas, exceto a primeira letra.
Como Ligar Os Objetos
Os fluxos de dados ligam entre si os outros objetos do sistema representados num DFD
(processos, arquivos de dados e entidades externas). Um processo tem, obrigatoriamente,
pelo menos um fluxo de entrada e um fluxo de sada, podendo ser a origem de um fluxo para
um determinado processo, um arquivo de dados ou uma entidade externa. De igual forma, o
destino de um fluxo de um determinado processo pode ser outro processo, um arquivo de
dados ou uma entidade externa.
Assim qualquer fluxo de dados tem sempre uma origem e um destino, sendo sempre
necessariamente um deles um processo. Um fluxo de dados tem obrigatoriamente um s
sentido.
Um arquivo de dados tem tambm, pelo menos, um fluxo para e/ou um processo (os
arquivos de dados esto sempre ligados a processos), no sendo obrigatrio ter ambos, pois
um arquivo de dados pode s ser atualizado ou s ser acessado pelo sistema em estudo,
significando que outro sistema tambm o utiliza.
Nunca se pode ter num DFD uma ligao entre uma entidade externa e um arquivo de
dados, entre dois arquivos de dados e entre duas entidades externas. Neste ltimo caso, se
h fluxo entre duas entidades externas ao sistema em estudo, pode-se dizer que esse fluxo
no pertence ao referido sistema e assim no deve ser considerado no diagrama.
Elaborao De Um DFD

56

Embora a prtica torne fcil a elaborao de um DFD, , no entanto, de importncia vital
efetuar sempre o estudo cuidadoso da definio da fronteira que delimita o sistema, pois s a
partir da possvel identificar os elementos que vo fazer parte do diagrama.
Para a elaborao de um DFD utiliza-se a abordagem top-down em que cada um dos
diferentes nveis de detalhe do sistema em estudo mostrado atravs de diferentes nveis de
DFD. A primeira representao do sistema elaborada atravs de um diagrama conhecido
como diagrama de contexto. Este diagrama, denominado nvel 0, representado atravs de
um processo e dos fluxos de entrada e sada do sistema, o que permite delimitar a rea em
estudo.
Depois, cada processo de DFD de nvel 1 pode ser decomposto sucessivamente noutros
DFDs onde j se mostram mais detalhes da lgica de procedimento. Esta tcnica de
subdividir DFDs de nvel superior em DFDs que representam sucessivamente o sistema com
mais detalhe conhecida por levelling.
No h uma regra geral que diga quando se deve acabar com esta subdiviso; alguns
autores defendem que quando os processos esto sob a forma de primitiva funcional,
outros que no se devem ultrapassar sete nveis de detalhe. No entanto, todos os autores
dizem que quando se decompe um processo num outro DFD de detalhe deve haver
conservao de fluxos, isto , os fluxos que entram e saem do processo do DFD de nvel
superior, tm tambm que entrar e sair no DFD que representa a decomposio desse
processo; esta propriedade denominada por balancing.


57


Figura 11.2 - DFD segundo Yourdon & DeMarco

58


Figura 11.2 - DFD segundo Gane & Sarson


59





http://pt.wikipedia.org/wiki/DFD




Com base nas figuras 11.1 e 11.2, elabore uma relao das principais diferenas
entre os DFDs dos autores Yourdon & DeMarco e Gane & Sarson




60

UNIDADE 12
Objetivo: Conceituar e diferenciar o Modelo e o Diagrama de Entidades e Relacionamentos.
MER e DER Modelo e Diagrama de Entidades e Relacionamentos
O Modelo Conceitual de Dados (ou Modelo de Entidades e Relacionamentos MER)
representado por um grfico denominado DIAGRAMA de ENTIDADES e
RELACIONAMENTOS (DER), proposto por Peter Chen (1976). Trata-se de um diagrama que
detalha as associaes existentes entre as entidades de dados e utiliza componentes
semnticos prprios.
A Elaborao Do Modelo De Entidades E Relacionamentos Segue Aos Seguintes
Princpios:
Cada Entidade representada por um retngulo na posio horizontal;
Cada tipo de relacionamento representado por um losango;
Pode haver um tipo de relacionamento entre mais do que duas Entidades;
Os relacionamentos podem conter atributos;
Pode haver mais de um tipo de relacionamento entre duas Entidades.
Para a compreenso do Modelo E x R necessrio considerar cada Entidade sob o enfoque
de dados, no levando em conta os processos (procedimentos ou rotinas). Os
relacionamentos se do entre os dados de uma Entidade em relao aos dados das demais
Entidades que formam o Modelo.
O princpio bsico o da Teoria de Conjuntos. Cada Entidade Conceitual deve ser vista
como sendo um conjunto que pode ou no ter relacionamento (interseo) com outro
conjunto.

61

Resumidamente, a seguinte terminologia bsica do MER:
ENTIDADE
So os componentes fsicos e abstratos utilizados pela empresa, sobre os quais so
armazenados dados;
ATRIBUTO
Corresponde representao de propriedades de uma Entidade. Um atributo no tem vida
prpria ou independente. Existe apenas para caracterizar uma Entidade;
OCORRNCIA
Conjunto de atributos de uma determinada Entidade;
RELACIONAMENTO
uma correspondncia entre duas entidades. Uma associao entre dois conjuntos de
dados (entidades);
IDENTIFICADOR ou ATRIBUTO DETERMINANTE
Um atributo ou uma coleo de atributos que determina de modo nico uma Ocorrncia de
Entidade;
GRAU DE RELACIONAMENTO
O nmero de entidades que participam da associao;
CLASSE DE RELACIONAMENTO ou CARDINALIDADE
Quantas ocorrncias de cada entidade esto envolvidas no relacionamento. Pode ser:
1:1 (um para um)
1:n (um para muitos)
m:n (muitos para muitos)

62





Criao Do Diagrama E-R (DER)
1. A descoberta dos relacionamentos existentes entre as ENTIDADES realizada pelo
analista e usurio, obedecendo-se as seguintes etapas:
2. Individualizar uma ocorrncia de uma entidade que integra o modelo conceitual;
3. Questionar se h algum relacionamento entre a ocorrncia da entidade de origem com
outra entidade do modelo (entidade de destino);
4. No caso de existir o relacionamento, batiz-lo com um nome representativo da
associao;
5. Assinalar a classe de relacionamento entre a entidade origem e a entidade destino;

63

6. Questionar qual a classe de relacionamento entre a entidade destino e sua entidade
de origem;
7. Assinalar a classe de relacionamento entre a entidade destino e a sua entidade de
origem;
8. Realizar as etapas de 1 a 6 at que todos os relacionamentos do modelo sejam
analisados, classificados os seus graus e assinalados no modelo.
Recomendaes Para Criao Do Diagrama E-R (DER)
1. Antes de comear a modelar, conhea o mundo real.
2. Identifique quais so as ENTIDADES.
3. Para cada Entidade represente seus ATRIBUTOS.
4. Confronte cada Entidade consigo mesma e com as demais na procura de possveis
RELACIONAMENTOS
5. Verifique a existncia de ATRIBUTOS de RELACIONAMENTO.
6. Para relacionamentos mltiplos estude a necessidade de AGREGAES.
7. Desenhe o DER, com todas as Entidades, Atributos, Relacionamentos, Classes e
Restries de Totalidade.
8. Analise cuidadosamente todas as restries que voc imps.
9. At que voc e os seus usurios estejam convencidos de que o DER reflete fielmente
o mundo real, volte ao item 1.

64



65




http://pt.wikipedia.org/wiki/Modelo_de_Entidades_e_Relacionamentos
http://pt.wikipedia.org/wiki/Diagrama_entidade_relacionamento




Com base na ltima imagem apresentada nesta unidade faa uma anlise crtica
sobre o respeito s recomendaes para a criao do Diagrama E-R (DER).



66

UNIDADE 13
Objetivo: Apresentar a evoluo natural da Metodologia Estruturada ao longo do tempo.
Evoluo da Metodologia Estruturada
A Anlise Estruturada foi popularizada por Tom DeMarco, surgindo ento, um importante
paradigma de desenvolvimento de sistemas. Obras importantes tais como Gane & Sarson,
Yourdon, Constantine e Page-J ones nas reas de anlise e projeto estruturados foram
decisivas na aprendizagem desse paradigma.
Passamos a conviver com Diagramas de Fluxos de Dados (DFD), Diagramas de Entidades e
Relacionamentos (DER), entre outros como vimos nas unidades anteriores. Muito se
conseguiu melhorar no processo de desenvolvimento e se difundir com esta metodologia,
fazendo com que o desenvolvimento de sistemas fosse enxergado com mais esmero,
respeitando sua complexidade. Tudo isso levou consecutivamente a produtos de melhor
qualidade.
Hoje possumos timos softwares que, tendo sido desenvolvidos plenamente dentro da
modelagem de anlise estruturada ou essencial, conseguiram obter seu lugar ao sol.
Todavia, existem problemas nessa metodologia. H uma dificuldade em garantir
compatibilidade entre as fases de anlise e projeto e, posteriormente, do projeto para a
implementao. Na grande maioria das vezes, grandes alteraes ou extenses dos
modelos criados geram um grande esforo.
No podemos esquecer que a comunicao entre desenvolvedores e usurios difcil, em
virtude dos diagramas no serem muito expressivos fora da compreenso da equipe de
desenvolvimento. Validaes dos usurios at ocorrem, mas no geral no refletem o
universo dos requisitos do sistema.

67

fcil lembrar os rostos dos usurios diante dos cuidadosamente desenhados DFD`s e
DER`s. At os desenvolvedores mais resistentes mudana de paradigma reconhecem que
no fcil conseguir uma validao precisa de um usurio, a partir das ferramentas usadas
na anlise estruturada.
Assim, o resultado final imprevisvel. Alm de tudo temos o problema mais delicado:
processos e dados so vistos de forma independente.
Talvez esses problemas no fossem to graves h 20 anos, poca em que os sistemas eram
menores, possuam menos complexidades, a Internet ainda no existia em nossas vidas e os
usurios no tinham noo do quanto podiam pedir!
Mas, atualmente, a complexidade, a urgncia e a adaptabilidade dos novos aplicativos tm
levado a se repensar os prs e contras dessa abordagem. Estamos vivendo uma era na qual
precisamos mais do que entregar softwares no prazo, dentro do oramento e sem falhas
at porque isto obrigao do desenvolvedor.
Precisamos desenvolver novos softwares gastando menos tempo, economizando
efetivamente e oferecendo um algo mais para o usurio. Lembra-se do comercial que dizia:
No basta ser pai, preciso participar? E isso que precisamos fazer: no basta entregar
um bom software, precisamos emocionar nossos usurios.
A partir de meados da dcada de 70, mtodos orientados a objetos comearam a surgir,
vislumbrando a mudana de paradigma. A programao orientada a objetos j estava
amadurecendo, bastava, portanto, criar para ela uma metodologia e comeamos a
conhecer a anlise orientada a objetos.
O principal ganho com esse novo paradigma o fato de que se uniformizaram os modelos
usados para anlise, projeto e implementao. Os principais diagramas so usados em todas
as fases, mudando-se apenas sua viso.
Partindo do conceito de orientao de objetos, h a unificao da perspectiva funcional e de
dados. No podemos esquecer o melhor dos mundos: a comunicao entre desenvolvedores
e usurios tornou-se mais facilitada.

68

Os usurios conseguem participar muito mais ativamente do processo de desenvolvimento,
pela anlise e validao dos diagramas apresentados. Assim garante-se que praticamente
no existiro surpresas quanto compreenso de requisitos, na entrega final do produto.


As linguagens tradicionais possuem o foco nos programas, responsveis pela parte ativa da
aplicao. Os dados so manuseados de forma passiva, perdendo, em alguns casos, sua
importncia de contexto.
Em contrapartida, nas linguagens orientadas a objeto, os dados esto protegidos por uma
cpsula, na qual residem procedimentos que intermediam o acesso a eles. Eles passam a
ser as estrelas do espetculo.
A Orientao a Objetos veio propiciar comunidade de desenvolvedores: aumento de
produtividade, diminuio do custo de desenvolvimento e principalmente de manuteno,
maior portabilidade e reutilizao de cdigo.



69




http://www.training.com.br/lpmaia/pub_prog_oo.htm
http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html




Com base no material desta unidade voc consegue identificar as diferenas
bsicas entre as anlises tradicionais e a anlise orientada a objetos? Voc acha
que era necessrio aplicar os conceitos de orientao a objetos no passado?
J ustifique a resposta.



70

UNIDADE 14
Objetivo: Explicar o conceito de modelagem pela viso orientada a objetos.
Modelagem de Sistemas Orientados a Objetos
A modelagem a parte central de todas as atividades que levam implantao de um bom
software. Construmos modelos para:
Comunicar a estrutura e o comportamento desejados do sistema.
Visualizar e controlar a arquitetura do sistema.
Compreender melhor o sistema que estamos elaborando.
Expor mais claramente oportunidades de simplificao e reaproveitamento do sistema
em estudo.
Gerenciar os riscos.
No prprio livro dos autores do UML existe um exemplo muito bacana de modelagem. Eles
comeam com a situao da construo de uma casa para um cachorro. Por ser uma
construo para um animal, que no final pouco ir reclamar dos detalhes, pois o cachorro
gosta mais do dono do que da casa, os cuidados a serem tomados so mnimos. Pegam-se
tbuas, pregos e algumas ferramentas bsicas como martelo, serrote e metro e manda-se
ver ... Bem, mesmo que no venha a ser a contento do co, no pior caso, se ele no gostar
da nova casa, pode-se ainda trocar de animal.
Em seguida, os autores evoluem no exemplo simulando que agora a casa ser construda
para a famlia. Os cuidados j sero outros, concorda?
No mnimo, para se ter uma casa de qualidade, exigir algum esboo do projeto, para que
todos possam contribuir e visualizar melhor o que ser construdo. E com a finalidade
tambm de ver detalhes prticos de energia, circulao e encanamento. A partir desses

71

planos, voc poder comear a fazer uma estimativa razovel da quantidade de tempo e de
material necessrios para essa tarefa.
Embora seja humanamente possvel construir uma casa sozinho, voc logo descobrir que
ser muito mais eficiente trabalhar com outras pessoas, talvez terceirizando vrios servios
bsicos ou comprando material pr-fabricado. Desde que voc se mantenha fiel aos planos e
permanea dentro dos limites de tempo e custos, provavelmente sua famlia ficar bem
satisfeita.
Se no der certo, a melhor soluo no ser trocar de famlia. Portanto, ser melhor definir
as expectativas desde o incio e gerenciar qualquer modificao com muita cautela.
Os autores terminam o exemplo com o cenrio de uma construo de um prdio comercial.
Para construir um prdio comercial com vrios andares, no ser uma boa ideia comear
com uma pilha de tbuas, alguns pregos e algumas ferramentas bsicas. Como
provavelmente voc usar o dinheiro de outras pessoas, como os diretores da empresa, eles
exigiro saber o tamanho, a forma e o estilo do futuro prdio.
Muitas vezes, essas pessoas mudaro de ideia, mesmo depois de iniciada a construo.
Valer a pena fazer um planejamento rigoroso, pois os custos de qualquer erro sero altos.
Voc ser apenas uma parte de um grupo bem maior, responsvel pelo desenvolvimento e
pela entrega do prdio. Assim, a equipe precisar de todos os modelos e esboos do projeto
para poderem se comunicar entre si, e para futuras manutenes.
Desde que voc consiga as pessoas certas e as ferramentas adequadas, alm de gerenciar
de maneira ativa o processo de transformao de um conceito de arquitetura em realidade,
provavelmente acabar obtendo um prdio que satisfar seus futuros ocupantes. Caso
pretenda continuar construindo prdios, voc tentar encontrar um equilbrio entre os desejos
dos futuros ocupantes e a realidade das tecnologias de construo, alm de manter um
relacionamento profissional com os demais integrantes de sua equipe, nunca os colocando
em risco, nem exigindo tanto que eles acabem exaustos ou doentes.

72

Curiosamente, muitas empresas de desenvolvimento de software comeam querendo
construir prdios de relativa complexidade, como se estivessem fazendo uma casinha de
cachorro.
Se voc realmente quiser construir softwares equivalentes a uma casa ou a um prdio de
qualidade, o problema no se restringir a uma questo de escrever uma grande quantidade
de software de fato, o segredo estar em criar o cdigo correto e pensar em como ser
possvel elaborar menos software.
Isso faz com que o desenvolvimento de software de qualidade se torne uma questo de
arquitetura, processo e ferramentas.
Ainda assim, muitos projetos so iniciados parecendo uma casa de cachorro, mas crescem
com a grandeza de um prdio simplesmente porque so vtimas de seu prprio sucesso.
Chega um momento em que, caso no tenham sido consideradas questes referentes
arquitetura, a processos e a ferramentas, a casa de cachorro, agora ampliada para um
grande prdio, sucumbir ao seu prprio peso. Qualquer erro na casa de cachorro poder
deixar seu co insatisfeito. A falha na construo de um grande prdio afetar materialmente
e fisicamente seus ocupantes e moralmente a toda equipe de trabalho.
Existem muitos elementos que contribuem para uma empresa de software de sucesso. Mas
com certeza um desses vitais componentes a utilizao efetiva da modelagem.

73





http://imasters.uol.com.br/artigo/3069/uml/como_modelar/




Avalie na sua atual empresa, ou em empresa de colegas, qual a forma com que
encarado o processo de modelagem de sistemas. Eles ainda esto no nvel de
arquitetos de casinha de cachorro, ou j chegaram ao nvel de grandes
construtores? Quais seriam as principais aes a serem implementadas para
corrigir isso? Ou quais so os pontos fortes e fracos da situao atual?



74

UNIDADE 15
Objetivo: Definir de forma prtica o que vem a ser Modelo.
O que Modelo?
Afinal o que modelo? Falando de uma maneira bem simples:
Um modelo uma simplificao da realidade.
Os modelos podem ser estruturais, dando nfase organizao do sistema, ou podem ser
comportamentais, dando nfase dinmica do sistema. Por que fazer a modelagem? Existe
um motivo fundamental:
Construmos modelos para compreendemos melhor o sistema que estamos desenvolvendo.
Com a modelagem, alcanamos quatro objetivos:
1. Ajudam a visualizar o sistema como ele ou como desejamos que seja.
2. Permitem especificar a estrutura ou o comportamento de um sistema.
3. Proporcionam um guia para a construo do sistema.
4. Documentam as decises tomadas.
A modelagem no se restringe a grandes sistemas. At os softwares equivalentes a casas
de cachorro podero receber os benefcios da modelagem. Porm, absolutamente
verdadeiro que, quanto maior e mais complexo for o sistema, maior ser a importncia da
modelagem, por uma razo bem simples:
Construmos modelos de sistemas complexos porque no possvel compreend-los em
toda a sua totalidade.

75

Existem limites para a capacidade humana de compreender complexidades. Com a ajuda da
modelagem, delimitamos o problema que estamos estudando, restringindo nosso foco a um
nico aspecto por vez.
Em essncia esse o procedimento de dividir para conquistar, do qual o matemtico e
filosfico Ren Descartes falava em seu Discurso sobre o Mtodo h anos: ataque um
problema difcil, dividindo-o em vrios problemas menores que voc pode solucionar.
Alm disso, com o auxlio da modelagem, somos capazes de ampliar o intelecto humano. Um
modelo escolhido de maneira adequada permitir a quem usa a modelagem trabalhar em
nveis mais altos de abstrao.
Qualquer projeto ser beneficiado pelo uso de algum tipo de modelagem. Inclusive no setor
de softwares comerciais, em que s vezes mais comum distribuir softwares inadequados
devido produtividade oferecida pelas linguagens de programao visual, a modelagem
poder auxiliar a equipe de desenvolvimento a visualizar melhor o planejamento do sistema e
permitir que o desenvolvimento seja mais rpido.
Quanto mais complexo for o sistema, maior ser a probabilidade de ocorrncia de erros ou
de construo de itens errados, caso no haja qualquer modelagem. Todos os sistemas teis
e interessantes apresentam uma tendncia natural para se transformarem em algo mais
complexo ao longo do tempo. Portanto, ainda que considere no ser preciso fazer a
modelagem hoje, medida que o seu sistema evoluir, voc se arrepender dessa deciso, e
a poder ser tarde demais.
So vrias as razes da utilizao de modelos para a construo de sistemas. Abaixo so
enumeradas algumas dessas razes:
Analogias Com Outras Engenharias
Na construo civil, frequentemente h profissionais analisando as plantas da construo
sendo realizada. A partir dessas, que podem ser vistas como modelos, os homens tomam
decises sobre o andamento da obra. Modelos de sistemas de software no so muito

76

diferentes dos modelos da engenharia civil. E ns temos outros exemplos de modelos
semelhantes tais como maquetes de edifcios e de avies, e plantas de circuitos eletrnicos.
Gerenciamento da Complexidade
Uma das principais razes pelas quais modelos so utilizados que h limitaes no ser
humano em lidar com a complexidade. Pode haver diversos modelos de um mesmo sistema,
cada modelo descrevendo uma perspectiva do sistema a ser construdo. Por exemplo, um
avio pode ter um modelo para representar sua parte eltrica, outro modelo para representar
sua parte aerodinmica etc. Atravs de modelos de um sistema, os indivduos envolvidos no
seu desenvolvimento podem fazer e predizer comportamentos do sistema. Como cada
modelo representa uma perspectiva do sistema, detalhes irrelevantes que podem dificultar o
entendimento do sistema podem ser ignorados por um momento estudando-se
separadamente cada um dos modelos.
Comunicao Entre As Pessoas Envolvidas
Certamente, o desenvolvimento de um sistema envolve a execuo de uma quantidade
significativa de atividades. Essas atividades se traduzem em informaes sobre o sistema
em desenvolvimento. Grande parte dessas informaes corresponde aos modelos criados
para representar o sistema. Nesse sentido, os modelos de um sistema servem tambm para
promover a difuso de informaes relativas ao sistema entre os indivduos envolvidos em
sua construo. Alm disso, diferentes expectativas em relao ao sistema geralmente
aparecem quando da construo dos seus modelos, j que estes servem como um ponto de
referncia comum.
Reduo Dos Custos No Desenvolvimento
No desenvolvimento de sistemas, seres humanos esto invariavelmente sujeitos a
cometerem erros, que podem se tanto erros individuais quanto erros de comunicao entre
os membros da equipe. Certamente, a correo desses erros menos custosa quando
detectada e realizada ainda nos modelos do sistema (por exemplo: muito mais fcil corrigir
uma maquete do que pr abaixo uma parte de um edifcio).

77

Lembre-se: Modelos de sistemas so mais baratos de construir do que sistemas.
Consequentemente, erros identificados em modelos tm um impacto menos desastroso nos
sistemas.
Predio Do Comportamento Futuro Do Sistema
O comportamento do sistema pode ser discutido atravs da anlise dos seus modelos. Os
modelos servem como um grande laboratrio, onde diferentes solues para um problema
relacionado construo do sistema podem ser experimentadas.
Nas prximas unidades apresentaremos diversos modelos cujos componentes so desenhos
grficos que seguem algum padro lgico. Esses desenhos so normalmente denominados
de diagramas. Um diagrama uma apresentao de uma coleo de elementos grficos que
possuem um significado predefinido. Dado um modelo de uma das perspectivas de um
sistema, diz-se que o seu diagrama, juntamente com a informao textual associada, forma a
documentao desse modelo.




Modelo de Definio de Sistemas da Microsoft:
http://www.microsoft.com/portugal/windowsserversystem/dsi/sdm.mspx
http://pt.wikipedia.org/wiki/Modelagem_computacional



78




Em sua viso qual a importncia da criao de modelos no processo de
desenvolvimento de sistemas? J ustifique.



79

UNIDADE 16
Objetivo: Apresentar formalmente os quatros princpios da modelagem.
Princpios da Modelagem
O uso da modelagem tem uma rica histrica em todas as disciplinas de engenharia e
arquitetura. Essa experincia sugere quatro princpios bsicos de modelagem.

PRIMEIRO PRINCPIO
A escolha do modelo tem profunda influncia sobre a maneira como um determinado
problema atacado e como uma soluo definida.
Em outras palavras, escolha bem os seus modelos. Os modelos corretos iluminaro de modo
brilhante os problemas de desenvolvimento mais complicados, proporcionando concluses
que simplesmente no seriam possveis de outra maneira; modelos inadequados causaro
confuses, desviando a ateno para questes irrelevantes.
Deixando de lado o desenvolvimento de software por um instante, suponha que voc esteja
tentando solucionar um problema de fsica quntica. Certos problemas, como a interao de
ftons no tempo-espao, implicam uma matemtica maravilhosamente complexa. Escolha
um modelo que no seja o de clculo e imediatamente essa complexidade inerente se
tornar manipulvel.
De modo semelhante, em um domnio inteiramente diferente, suponha que voc est
construindo um novo prdio e est interessado em saber como ele se comportar quando
houver fortes ventanias. Construindo um modelo fsico e submetendo-o a testes de tneis de
vento, voc aprender algumas coisas interessantes, apesar de os materiais em escalas
menores no se flexionarem exatamente como em escalas maiores. Assim, se elaborar um
modelo matemtico e depois submet-lo a simulaes, voc aprender algumas coisas

80

diferentes e provavelmente tambm ser capaz de trabalhar com um nmero maior de novos
cenrios do que se estivesse utilizando modelos fsicos. A partir de testes contnuos e
rigorosos com seus modelos, voc acabar obtendo um nvel de confiana muito superior em
relao ao fato de que o sistema, cuja modelagem foi realizada, de fato se comportar da
maneira esperada no mundo real.
Em relao aos softwares, a escolha de modelos poder ser modificada, de maneira
significativa, de acordo com sua viso de mundo. Construindo um sistema a partir da
perspectiva de um desenvolvedor de bancos de dados, provavelmente voc atribuir o foco a
modelos de relacionamentos entre entidades, cujo comportamento tende a privilegiar
procedimentos armazenados e os eventos que os iniciam. Construindo um sistema a partir
da perspectiva de um analista de anlise estruturada, provavelmente usar modelos
centrados em algoritmos, com o respectivo fluxo de dados de um processo para outro.
Construindo um sistema a partir da perspectiva de um desenvolvedor orientado a objetos,
provavelmente trabalhar com um sistema cuja arquitetura estar centrada em vrias classes
e os padres de interao que determinaro como essas classes funcionaro em conjunto.
Qualquer uma dessas solues poder ser correta para uma determinada aplicao e cultura
de desenvolvimento, apesar de a experincia indicar que a perspectiva orientada a objetos
superior para a criao de arquiteturas flexveis, inclusive no caso de sistemas que podero
conter grandes bancos de dados ou vrios componentes computacionais. Apesar desse fato,
o ponto mais importante que cada viso de mundo conduz a um tipo diferente de sistema,
com custos e benefcios diversos.

SEGUNDO PRINCPIO
Cada modelo poder ser expresso em diferentes nveis de preciso.
Ao desenvolver um sistema complexo, s vezes poder ser necessria uma viso
panormica por exemplo, para ajudar os investidores a visualizar a aparncia e o
funcionamento do futuro sistema. Em outras situaes, poder ser preciso retornar ao nvel

81

dos alicerces por exemplo, quando existe uma rotina cuja execuo crtica ou um
componente estrutural pouco comum.
O mesmo verdadeiro em relao aos modelos de software. s vezes, um modelo da
interface para o usurio, de execuo rpida e simples, ser exatamente o que voc
precisar; em outros casos, ser necessrio retornar a nveis mais baixos, como ao
especificar interfaces para vrias plataformas ou ao enfrentar congestionamentos em uma
rede. Em qualquer situao, os melhores tipos de modelos sero aqueles que permitem a
escolha do grau de detalhamento, dependendo de quem esteja fazendo a visualizao e por
que deseja faz-la. Um analista ou um usurio final dirigir a ateno em direo a questes
referentes ao que ser visualizado; o desenvolvedor mover o foco para a maneira como
esses objetos funcionaro. Todos esses observadores desejaro visualizar o sistema em
nveis diferentes de detalhamento em situaes distintas.

TERCEIRO PRINCPIO
Os melhores modelos esto relacionados realidade.
O modelo fsico de um prdio, que no responda da mesma forma que os materiais reais,
ter um valor apenas limitado; o modelo matemtico de um avio, em que so consideradas
apenas condies de vo ideais e fabricao perfeita, poder ocultar caractersticas
potencialmente fatais do avio de verdade. Ser melhor utilizar modelos que tenham uma
clara conexo com a realidade e, nos casos em que essa conexo seja fraca, saber, de
maneira exata, como esses modelos diferem do mundo real. Todos os modelos simplificam a
realidade; o segredo ser ter certeza de que sua simplificao no ocultar detalhes
importantes.
No caso dos softwares, o tendo de Aquiles das tcnicas de anlise estruturada est no fato
de no haver uma conexo bsica entre o modelo de anlise e o modelo de projeto do
sistema. Falhando a ponte sobre essa fenda, ao longo do tempo aparecer uma divergncia
entre o sistema concebido e o sistema construdo. Nos sistemas orientados a objetos,

82

possvel estabelecer alguma conexo entre todos os pontos de vista quase independentes
de um sistema em uma mesma totalidade semntica.

QUARTO PRINCPIO
Nenhum modelo nico suficiente. Qualquer sistema, no trivial, ser melhor investigado por
meio de um pequeno conjunto de modelos, quase independentes um do outro.
Para a construo de um prdio, no existe um nico conjunto de esboos de projetos capaz
de revelar todos os detalhes da construo. Pelo menos, sero necessrias plantas baixas,
areas, eltricas, de circulao e de gua e esgoto.
A expresso funcional aqui utilizada quase independente. Nesse contexto, a expresso
significa modelos que possam ser criados e estudados separadamente, mas que continuam
inter-relacionados. Assim como no caso de um prdio, voc poder estudar apenas as
plantas relacionadas energia eltrica, mas tambm poder ver o respectivo mapa na planta
baixa e talvez at sua interao com o direcionamento de canos na planta de gua e esgoto.
O mesmo verdadeiro em relao a sistemas de software orientados a objetos. Para
compreender a arquitetura desses sistemas, voc precisar recorrer a vrias vises
complementares e inter-relacionadas: a viso dos casos de uso (expondo os requisitos do
sistema), a viso de projeto (captando o vocabulrio do espao do problema e do espao da
soluo), a viso do processo (modelando a distribuio dos processos e threads do
sistema), a viso da implementao do sistema (direcionando a realizao fsica do sistema)
e a viso da implantao (com o foco voltado para questes de engenharia de sistemas).
Cada uma dessas vises poder conter aspectos estruturais como tambm aspectos
comportamentais. Em conjunto, essas vises representam a base do projeto do software.
Dependendo da natureza do sistema, alguns modelos podero ser mais importantes do que
outros. Por exemplo, no caso de sistemas que utilizam muitos dados, predominaro modelos
voltados para a viso esttica do projeto. Em sistemas centrados no uso de GUI, so
importantes as vises estticas e dinmicas dos casos de uso. Em sistemas de execuo

83

crtica em tempo real, a viso dinmica do processo tende a ser mais importante. Por fim, em
sistemas distribudos, como aqueles encontrados em aplicaes que utilizam a Web, os
modelos de implementao e de implantao so os mais importantes.



http://www.ppgia.pucpr.br/~alcides/Teaching/ProgramasAprendizagem/Modelagem
OrientadaObjetos/Introducao.html




Como voc aplicaria os quatro princpios da modelagem ao seu dia a dia de
Anlise de Sistemas? A modelagem altera as vises que temos de um sistema?



84

UNIDADE 17
Objetivo: Definir e apresentar a linguagem de modelagem unificada.
UML Unified Modeling Language
Pelas prprias palavras dos criadores Booch, Rumbaugh e J acobson, chamados
carinhosamente de os trs amigos, eles definem a UML da seguinte forma:
A UML proporciona uma forma padro para a preparao de planos de arquitetura de
projetos de sistemas, incluindo aspectos conceituais tais como processos de negcios e
funes do sistema, alm de itens concretos como as classes escritas em determinada
linguagem de programao, esquemas de bancos de dados e componentes de software
reutilizveis.

No processo de definio da UML,procurou-se aproveitar o melhor das caractersticas das
notaes preexistentes, principalmente das tcnicas propostas anteriormente pelos trs
amigos (essas tcnicas eram conhecidas pelos nomes Booch Method, OMT e OOSE). A
notao definida para a UML uma unio de diversas notaes preexistentes, com alguns
elementos removidos e outros elementos adicionados com o objetivo de torn-la mais
expressiva.
Finalmente, em 1997, a UML verso 1.1 foi aprovada como padro pelo OMG (ver nossa
ATIVIDADE ao final desta Unidade). Desde ento, a UML tem tido grande aceitao pela

85

comunidade de desenvolvedores de sistemas. A sua definio ainda est em
desenvolvimento e possui diversos colaboradores. Tanto que, desde o seu surgimento,
vrias atualizaes foram feitas no sentido de torn-la mais clara e til. Atualmente estamos
na verso 2.1.1 da UML, mas ela to dinmica que provavelmente quando voc estiver
fazendo a Atividade encontre uma verso ainda mais atual. Veja o histrico do UML na figura
a seguir.
A UML uma linguagem visual para modelar sistemas orientados a objetos. Isso quer dizer
que a UML uma linguagem constituda de elementos grficos utilizados na modelagem que
permitem representar os conceitos do paradigma da orientao de objetos. Atravs dos
elementos grficos definidos nesta linguagem podem-se construir diagramas que
representam diversas perspectivas de um sistema.
A UML uma linguagem de modelagem, no um mtodo, nem mesmo metodologia !!




86

Cada elemento grfico possui uma sintaxe, uma forma predeterminada de desenhar o
elemento, e uma semntica que definem o que significa o elemento e para que ele deve ser
utilizado. Alm disso, conforme veremos mais adiante, tanto a sintaxe quanta a semntica da
UML so extensveis. Essa extensibilidade permite que a UML seja adaptada s
caractersticas especficas de cada projeto de desenvolvimento.
Pode-se fazer uma analogia da UML com uma caixa de ferramentas. Um construtor usa sua
caixa de ferramentas para realizar suas tarefas. Da mesma forma, a UML pode ser vista
como uma caixa de ferramentas utilizada pelos desenvolvedores de sistemas para realizar a
construo de modelos.
A UML uma linguagem de modelagem destinada a realizar atividades especiais em
artefatos de um sistema complexo de software. Tais atividades so:
Visualizar Construir
Especificar Documentar
A UML independente tanto de linguagem de programao quanto de processos de
desenvolvimento. Isso quer dizer que a UML pode ser utilizada para a modelagem de
sistemas, no importando qual a linguagem de programao a ser utilizada, ou qual a forma
de desenvolvimento adotada. Esse um fator importante para a utilizao da UML, pois
diferentes sistemas de software requerem diferentes abordagens de desenvolvimento.
Vises De Um Si stema Pela UML
O desenvolvimento de um sistema de software complexo demanda que seus
desenvolvedores tenham a possibilidade de examinar e estudar esse sistema a partir de
diversas expectativas. Os autores da UML sugerem que um sistema pode ser descrito por
cinco vises interdependentes desse sistema. Cada viso enfatiza aspectos diferentes do
sistema (veja a figura a seguir). As vises propostas so as seguintes:



87

Viso de Casos de Uso
Descreve o sistema de um ponto de vista externo como um conjunto de interaes entre o
sistema e os agentes externos ao sistema. Esta viso criada inicialmente e direciona o
desenvolvimento das outras vises do sistema.
Viso de Projeto
Enfatiza as caractersticas do sistema que do suporte, tanto estrutural quanto
comportamental, s funcionalidades externamente visveis do sistema.
Viso de Implementao
Abrange o gerenciamento de verses do sistema, construdas atravs dos agrupamentos de
mdulos (componentes) e subsistemas.
Viso de Implantao
Corresponde distribuio fsica do sistema em seus subsistemas e conexo entre essas
partes.
Viso de Processo
Esta viso enfatiza as caractersticas de concorrncia (paralelismo), sincronizao e
desempenho do sistema.
Dependendo das caractersticas e da complexidade do sistema, nem todas as vises
precisam ser construdas. Por exemplo, se o sistema tiver de ser instalado em um ambiente
computacional de processador nico, no h a necessidade da viso de implantao.
Outro exemplo: se o sistema for constitudo de um nico processo, a viso de processo
irrelevante. De forma geral, dependendo do sistema, as vises podem ser ordenadas por
grau de relevncia.

88





Veja o rico material sobre o RUP e especificamente sobre vises em:
http://www.wthreex.com/rup/process/workflow/requirem/co_ucv.htm


89




Visite o site da OMG Object Management Group ( http://www.uml.org/ ) um
consrcio internacional formado por empresas tais como: HP, IBM, Oracle,
Microsoft e outras, e possui muitas informaes interessantes.
Uma delas a Especificao da Linguagem de Modelagem Unificada totalmente
gratuito da definio completa da UML. Tente baixar esse arquivo. Esse documento
possui um sumrio, semntica, guia da notao e extenses da linguagem UML.



90

UNIDADE 18
Objetivo: Descrever com mais detalhes o Paradigma da Orientao de Objetos.
O Paradigma da Orientao de Objetos
Uma definio simples de paradigma seria uma forma de abordar um problema. Pode-se
dizer, ento, que o termo Paradigma da Orientao a Objetos uma forma de abordar um
problema. H alguns anos, Alan Kay, um dos pais do Paradigma da Orientao a Objetos,
formulou a chamada analogia biolgica.
Nessa analogia, ele imaginou como seria um sistema de software que funcionasse com um
ser vivo. Nesse sistema, cada clula interagiria com outras clulas atravs do envio de
mensagens para realizar um objetivo comum. Adicionalmente, cada clula se comportaria
como uma unidade autnoma.
De uma forma mais geral, Kay pensou em como construir um sistema de software a partir de
agentes autnomos que interagem entre si. Ele, ento, estabeleceu os seguintes princpios
da orientao a objetos:
Qualquer coisa um objeto.
Objetos realizam tarefas atravs da requisio de servios a outros objetos.
Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos
similares.
A classe um repositrio para o comportamento associado ao objeto.
Classes so organizadas em hierarquias.



91

Paradigma Orientao De Objetos versus Paradigma Estruturado
Como j vimos anteriormente, antes da orientao de objetos, outro paradigma era utilizado
na modelagem de sistemas: o Paradigma Estruturado. Nesse paradigma, os elementos
principais so dados e processos. Processos agem sobre dados para que um objetivo seja
alcanado.
Por outro lado, no Paradigma da Orientao de Objetos, h um elemento, o objeto - uma
unidade autnoma - que contm seus prprios dados que so manipulados pelos processos
definidos para o objeto e que interage com outros objetos para alcanar tambm um objetivo.
o Paradigma da Orientao de Objetos que os seres humanos tipicamente utilizam no
cotidiano para a resoluo de problemas. Uma pessoa atende a mensagens (requisies)
para realizar um servio. Por sua vez essa mesma pessoa envia mensagens a outras para
que estas realizem outros servios. Por que no aplicar essa mesma forma de pensar a
modelagem de sistemas?
Vejamos o exemplo geral a seguir para revisar os conceitos apresentados anteriormente:
Joo quer comprar uma pizza, e por estar ocupado, pede a pizza por telefone. Joo informa
ao atendente Lus seu nome, a pizza e o seu endereo. Por sua vez Lus avisa ao pizzaiolo
Antonio qual a pizza a ser feita. Uma vez feita a pizza Lus chama Roberto, o motoboy, para
entreg-la na casa do Joo.
O objetivo de J oo foi atingido atravs da colaborao de diversos agentes, que so
denominados objetos. Estes objetos foram: Lus, Antonio e Roberto. Embora todos tenham
trabalhado em suas funes de forma individual, alcanaram o objetivo cooperando
conjuntamente. O comportamento do pizzaiolo Antonio, embora seja um do melhores da sua
classe, o mesmo esperado de qualquer um de sua profisso (fazer pizza). Logo Antonio
um objeto da classe Pizzaiolo. E todos os objetos pertencem a classes maiores por serem
seres humanos, animais, mamferos e assim por diante (hierarquias).



92

Classes E Objetos
Na terminologia de orientao de objetos coisas do mundo real como um cliente, uma loja,
uma venda, um pedido de compra, um fornecedor, esta apostila, so denominados objetos.
Os objetos possuem caractersticas ou propriedades que so seus atributos. Esses atributos
identificam o estado de um objeto. Um atributo uma abstrao do tipo de dados ou estado
que os objetos da classe possuem.
Nos, seres humanos, costumamos agrupar objetos. Provavelmente, fazemos isso para tentar
gerenciar a complexidade de entender as coisas do mundo real. Realmente, bem mais fcil
entender a ideia cavalo do que entender todos os cavalos que existem no mundo.
Na terminologia da orientao de objetos, cada ideia denominada classe de objetos, ou
simplesmente classe. Uma classe uma descrio dos atributos e servios comuns a grupo
de objetos. Sendo assim, pode-se entender uma classe como sendo um molde a partir do
qual objetos so construdos. Ainda sobre terminologia, diz-se que um objeto uma instncia
de uma classe.
importante notar que uma classe uma abstrao das caractersticas de um grupo de
coisas do mundo real. Na maioria das vezes, as coisas do mundo real so muito mais
complexas para que todas as suas caractersticas sejam representadas em uma classe.
Alm disso, para fins de modelagem de um sistema, somente um subconjunto de
caractersticas pode ser relevante. Portanto, uma classe representa uma abstrao das
caractersticas relevantes do mundo real.
Mensagens
Para que uma operao em um objeto seja executada, deve haver um estmulo enviado a
esse objeto. Se um objeto for visto como uma entidade ativa que representa uma abstrao
de algo do mundo real, ento faz sentido dizer que tal objeto pode responder a estmulos a
ele enviados, assim como faz sentido dizer que seres vivos reagem a estmulos que eles
recebem.

93

Independentemente da origem do estmulo, quando ele ocorre, diz-se que o objeto em
questo est recebendo uma mensagem requisitando que ele realize alguma operao.
Quando se diz que objetos de um sistema esto trocando mensagens significa que esses
objetos esto enviando mensagens uns aos outros com o objetivo de realizar alguma tarefa
dentro do sistema no qual eles esto inseridos.






http://pt.wikipedia.org/wiki/Orienta%C3%A7%C3%A3o_a_objeto



94




Como tipicamente identificamos e diferenciamos objetos por seus atributos, tente
identificar o objeto a seguir dado os seguintes atributos:

Nome
Endereo
Data de nascimento
Especializao
CRM



95

UNIDADE 19
Objetivo: Continuar a definir conceitos bsicos do paradigma da Orientao de Objetos.
Encapsulamento, Polimorfismo e Herana
Objetos possuem comportamento. O termo comportamento diz respeito a operaes
realizadas por um objeto e tambm ao modo pelo qual essas operaes so executadas. O
mecanismo de encapsulamento uma forma de restringir o acesso ao comportamento
interno de um objeto. Um objeto que precise da colaborao de outro objeto para realizar
alguma tarefa simplesmente envia uma mensagem a este ltimo. O mtodo que o objeto
requisitado usa para realizar a tarefa no conhecido dos objetos requisitantes.
Dentro desse conceito visualizamos o objeto como uma caixa preta. Quem descreve o
comportamento de um objeto a sua classe. Um objeto possui uma interface. A interface de
um objeto o que ele conhece e o que ele sabe fazer, sem descrever como o objeto
conhece o que faz. A interface de um objeto define os servios que ele pode realizar e
consequentemente as mensagens que ele recebe.
Uma interface pode ter vrias formas de implementao. Mas, pelo princpio do
encapsulamento, a implementao de um objeto requisitado no importa para o objeto
requisitante. Atravs do encapsulamento, a nica coisa que um objeto precisa saber para
pedir a colaborao de outro objeto conhecer sua interface. Nada mais. Isso contribui para
a autonomia dos objetos.
Cada objeto envia mensagens a outros objetos para realizar certas tarefas, sem se
preocupar em como as tarefas so realizadas. A aplicao da abstrao, nesse caso, est
em esconder os detalhes de funcionamento interno de um objeto.

96


Polimorfismo
O polimorfismo indica a capacidade de abstrair vrias implementaes diferentes em uma
nica interface. Um bom exemplo para explicar este conceito seria o controle remoto.
Embora ele seja normalmente fabricado especificamente para um tipo de aparelho, existem
controles remotos considerados universais. Portanto, mesmo com um controle remoto de
outro fabricante possvel acionar o aparelho de outro fornecedor.
Esse um exemplo de aplicao do princpio do polimorfismo. Note mais uma vez que a
abstrao tambm aplicada aqui: um objeto pode enviar a mesma mensagem para objetos
semelhantes, mas que implementam a sua interface de formas diferentes.
Herana
A herana outra forma de abstrao utilizada na orientao de objetos. As caractersticas e
o comportamento comuns a um conjunto de objetos podem ser abstrados em uma classe. A
herana pode ser vista como um nvel de abstrao acima da encontrada entre classes e
objetos.
Na herana, classes semelhantes so agrupadas em hierarquias. Cada nvel de uma
hierarquia pode ser visto como um nvel de abstrao. Cada classe em um nvel da
hierarquia herda as caractersticas das classes nos nveis acima. Esse mecanismo facilita o
compartilhamento comum entre um conjunto de classes semelhantes. Alm disso, as

97

diferenas ou variaes de uma classe em particular podem ser organizadas de forma mais
clara.





http://www.ic.unicamp.br/~cmrubira/aacesta/java/javatut10.html



98



Identifique paralelos entre as seguintes caractersticas de uma clula e os conceitos
da orientao a objetos descritos nesta unidade:
Mensagens so enviadas de uma clula a outra atravs de receptores qumicos.
Clulas tm uma fronteira, a membrana celular. Cada clula tem um
comportamento interno que no visvel de fora.
As clulas podem se reagrupar para resolver problemas ou para realizar uma
funo.




Antes de dar continuidades aos seus estudos fundamental que voc acesse sua
SALA DE AULA e faa a Atividade 2 no link ATIVIDADES.



99

UNIDADE 20
Objetivo: Apresentar as principais linguagens Orientada a Objetos no mercado e o seu
histrico.
Linguagens Orientada a Objetos
A primeira linguagem com os conceitos de orientao a objetos foi a linguagem Simula. Foi
iniciado o desenvolvimento dessa linguagem em 1962 na Noruega, por Ol-J ohan Dahl e
Kristen Nygaard, e curiosamente muito antes dos mtodos estruturais.
Baseada na linguagem Algol 60 seu desenvolvimento teve trs fases: Simula 0 (1962-1963),
Simula I (1963-1965) e Simula 67 (1966-1967). Com esse projeto surgiram os primeiros
conceitos de classes, com seus atributos e mtodos, encapsulamento e herana.
Simula 67
Influenciou a primeira linguagem totalmente orientada a objetos que viria seguir, a
SmallTalk. Essa linguagem foi desenvolvida por Alan Kay, no incio da dcada de 70, no
famoso e gerador das principais tecnologias usadas hoje, o Centro de Pesquisas da Xerox,
em Palo Alto.
Disponibilizada ao pblico no incio dos anos 80, SmallTalk solidificou para a comunidade os
conceitos de classe, objeto, atributo, mtodo, encapsulamento, herarquia, herana e
mensagem. Por ser uma linguagem puramente orientada a objetos, tudo em seu ambiente
visto como um objeto, e qualquer comunicao entre objetos feita por mensagens.
O SmallTalk continua sendo usado comercialmente por vrios fornecedores, com nomes
complementares distintos. Durante estas ltimas dcadas, a orientao a objetos
amadureceu. Com pequeno esforo implementam-se os modelos Orientado a Objeto nos
bancos de dados relacionais j existentes. Assim, no h a necessidade de se mexer nas
bases de dados mais antigas.

100

Podemos classificar as linguagens orientadas a objeto como hbridas e puras. Uma
linguagem hbrida criada a partir da ampliao de uma linguagem procedural, de origem na
anlise estruturada, permitindo a implementao da orientao a objetos. Ou seja, a
linguagem mantm a programao estruturada e acrescentada a orientada a objetos.
A linguagem pura s permite implementao baseada na programao orientada a objetos.
As nicas linguagens puras, atualmente no mercado, so: SmallTalk e Eiffel.
O Eiffel no possui linguagem de origem. Foi desenvolvido por Bertrand Meyer, em 1986, na
Interactive Software Engineering (ISE), seguindo os estritos princpios de orientao a
objetos. muito apreciada por acadmicos exatamente por permitir o aprendizado puro dos
conceitos de OO (Orientado a Objetos).
A linguagem C++ uma evoluo da linguagem C acrescentando suporte ao paradigma de
programao orientada a objetos. Portanto, uma linguagem hbrida. Tomou por base o
estilo de programao usado na linguagem Si mula.
Tornou-se a linguagem nativa de alguns ambientes integrados de desenvolvimento como:
C++ Builder (Borland Corporation) e Visual C++ (Microsoft) entre outros.
Object Pascal
Consiste numa evoluo da linguagem Pascal. A Borland foi responsvel direta por essa
evoluo. No incio dos anos 80, ela lanou o Turbo Pascal. Mais tarde, com o surgimento
do Windows, surgiu o Turbo Pascal for Windows e um pouco depois, o Borland Pascal,
considerada a primeira verso do Object Pascal. Hoje, utilizada como linguagem nativa
Borland Delphi.
Java
Foi desenvolvido como um subconjunto da linguagem C++, pela Sun Microsystems, e
lanada em 1995. Em virtude de seu uso em larga escala, em aplicaes para Internet,
Intranets e Extranets, tornou-se rapidamente popular. Seus cdigos-fontes so compilados e
transformados em arquivos-objetos, chamados bytecodes.

101

Esses bytecodes so executados por interpretadores Java, desenvolvidos para cada
plataforma de hardware/software, funcionando como Mquinas Virtuais J ava Virtual
Machine. Dessa forma, a linguagem consegue trabalhar com uma programao
multiplataforma.
Existem dois tipos de bytecodes: aplicaes Java e Applets. No primeiro caso, a aplicao
possui acesso completo mquina, manipulando memria e acessando arquivos. No caso
dos Applets, estes so tipicamente interpretados por browsers, devidamente capacitados, e
possuem restries de acesso memria e arquivos.
Tornou-se linguagem nativa de alguns ambientes integrados de desenvolvimento, como:
JBuilder (Borland Corporation), JDeveloper (Oracle Corporations), VisualAge for Java
(IBM), entre outros.




http://pt.wikipedia.org/wiki/Linguagem_de_programa%C3%A7%C3%A3o



Atravs do site http://www.levenez.com/lang/history.html, veja se voc consegue
identificar a maioria das linguagens citadas nesta Unidade.



102

UNIDADE 21
Objetivo: Inicializar os conceitos bsicos que envolvem o Diagrama de Casos de Uso.
Diagrama de Casos de Uso
A maior dificuldade em modelarmos um sistema no est nos diagramas que temos que
desenhar, no cdigo que devemos criar ou nas bases de dados que devemos projetar. Na
realidade est nos requisitos que devemos gerenciar.
O modelo de casos de uso uma representao das funcionalidades externamente
observveis do sistema e dos elementos externos ao sistema que interagem com ele. Este
modelo parte integrante da especificao de requisitos.
Na verdade, o Modelo de Casos de Uso molda os requisitos funcionais do sistema. O
diagrama da UML utilizado na modelagem de casos de uso o diagrama de casos de uso.
A tcnica de modelagem atravs de casos de uso foi idealizada por um famoso engenheiro
de software sueco, Ivar J acobson (um dos trs amigos), na dcada de 70, enquanto
trabalhava no desenvolvimento de um sistema na empresa de telefonia Ericson. Mais tarde,
J acobson incorporou essa tcnica a um processo de desenvolvimento de software
denominado Objetory. Posteriormente, ele se uniu a Booch e a Rumbaugh, e a notao de
casos de uso foi incorporada Linguagem de Modelagem Unificada.
Desde ento, esse modelo vem se tornando cada vez mais popular para realizar a
documentao de requisitos funcionais de uma aplicao. Devido sua notao grfica
simples e descrio em linguagem natural, o que facilita a comunicao de desenvolvedores
e usurios.
Este modelo um dos mais importantes da UML. Ele direciona diversas tarefas posteriores
ao ciclo de vida do sistema de software. Alm disso, o modelo de casos de uso fora os

103

desenvolvedores a moldarem o sistema de acordo com o usurio, e no o usurio de acordo
com o sistema.
O modelo de casos de uso composto de: casos de uso, atores e relacionamento entre
estes. Vejamos maiores detalhes de cada um a seguir.
Casos De Uso
Um caso de uso a especificao de uma sequncia de interaes entre um sistema e os
agentes externos que utilizam esse sistema. Um caso de uso deve definir o uso de uma parte
da funcionalidade de um sistema, sem revelar a estrutura e os comportamentos internos
desse sistema. Um modelo de casos de uso tpico contm vrios casos de uso.
Um caso de uso representa quem faz o que com o sistema, sem considerar o
comportamento interno do sistema.
Cada caso de uso deve ser definido atravs da descrio narrativa das interaes que
ocorrem entre os elementos externos e o sistema. A UML no define o formato e o grau de
abstrao a serem utilizados na descrio de um caso de uso.

Veremos na prxima unidade o detalhamento de cada um dos itens apresentados na figura
acima.

104




http://www.wthreex.com/rup/process/artifact/ar_uc.htm
http://www.wthreex.com/rup/process/artifact/ar_ucmgl.htm



Atravs do roteiro do site http://www.wthreex.com/rup/manuals/ucmgl/index.htm
tente desenvolver o seu prprio Diagrama de Casos de Uso.



105

UNIDADE 22
Objetivo: Detalhar os diversos itens que um Caso de Uso possui e suas definies.
Casos de Uso: Formato, Detalhamento e Abstrao

Casos De Uso Formato
Quanto ao FORMATO comumente so
utilizadas a descrio contnua, a descrio
numerada e a descrio particionada. Esses
tipos de narrativa so apresentados a seguir,
com o exemplo correspondente ao caso de
uso de saque de determinada quantia em um
caixa eletrnico de um sistema bancrio.
No formato de descrio contnua a narrativa feita atravs de um texto livre. Como exemplo
considere o caso de uso Realizar Saque em um caixa eletrnico:
O Cliente chega ao caixa eletrnico e insere seu carto. O sistema requisista a senha do
Cliente. Aps o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opes
de operaes possveis. O Cliente opta por realizar um saque. Ento o Sistema requisita o
total a ser sacado. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente.
No formato de descrio numerada, a narrativa descrita atravs de uma srie de passos
numerados. Considere como exemplo o mesmo caso de uso Realizar Saque:
1. Cliente insere seu carto no caixa eletrnico.
2. Sistema apresenta solicitao de senha.
3. Cliente digita senha.

106

4. Sistema exibe menu de operaes disponveis.
5. Cliente indica que deseja realizar saque.
6. Sistema requisita quantia a ser sacada.
7. Cliente retira a quantia e o recibo.
O estilo de descrio particionada tenta prover alguma estrutura descrio de casos de
uso. A sequncia de interaes entre o ator e o sistema particionada em duas colunas,
uma para o ator e outra para o sistema:

CLIENTE SISTEMA
Insere seu carto no caixa eletrnico.
Apresenta solicitao de senha.
Digita senha.
Exibe menu de operaes disponveis.
Solicita realizao de saque.
Requisita quantia a ser sacada.
Retira a quantia e o recibo.


107

CASOS de USO DETALHAMENTO
O grau de detalhamento a ser utilizado na
descrio de um caso de uso pode variar
desde o mais sucinto at a descrio
envolvendo vrios detalhes (expandido).
Um caso de uso sucinto descreve as
interaes sem muitos detalhes. Um caso
de uso expandido descreve as interaes
em detalhes.

CASOS de USO ABSTRAO
O grau de abstrao de um caso de uso diz respeito existncia ou no de meno
tecnologia a ser utilizada na descrio desse caso de uso. Em relao ao grau de abstrao,
um caso de uso pode ser real ou essencial.
Um caso de uso essencial abstrato e no faz meno tecnologia a ser utilizada. Note que
o exemplo a seguir de caso de uso essencial e numerado completamente desprovido de
caractersticas tecnolgicas. Esse caso de uso vale para a situao em que o sistema tem
mais de uma interface para a mesma funcionalidade. Por exemplo, uma interface no site na
Internet e outra interface via telefone celular.
1. Cliente fornece sua identificao.
2. Sistema identifica o usurio.
3. Sistema fornece operaes disponveis.
4. Cliente solicita o saque de uma determinada quantia.
5. Sistema fornece a quantia desejada da conta do Cliente.
6. Cliente recebe dinheiro e recibo.

108

Diferentemente, em um caso de uso real, as descries das interaes citam detalhes da
tecnologia a ser utilizada na implementao. A descrio em um grau de abstrao real se
compromete com a soluo de projeto (tecnologia) a ser utilizada para implementar o caso
de uso.
uma boa ideia utilizar a regra prtica dos 100 anos para identificar se um caso de uso
contm algum detalhe de tecnologia. Questione se a narrativa seria vlida tanto 100 anos
atrs, como daqui a 100 anos. Se a resposta for positiva, ento muito provavelmente esse
caso de uso essencial. Caso contrrio, trata-se de um caso de uso real.



Veja um bom resumo dos principais tpicos relacionados at aqui no site:
www.dimap.ufrn.br/~flavia.delicato/ModeloRequisitosCasosdeUSos.pdf



Com base no documento acima realize um resumo sinttico dos principais tpicos
abordados.



109

UNIDADE 23
Objetivo: Detalhar os diversos elementos que um Caso de Uso possui e suas definies.
Caso de Uso Atores e Relacionamentos
Na terminologia da UML, qualquer elemento externo que interage com o sistema
denominado ator. Vamos detalhar melhor essa definio. O termo externo indica que atores
no fazem parte do sistema. E o termo interage significa que um ator troca (envia e/ou
recebe) informaes com o sistema.

CATEGORIA DE ATORES EXEMPLOS
Pessoas
Empregado, cliente, gerente, almoxarife,
vendedor
Organizaes
Empresa fornecedora, Agncia de
Turismo, Administradora de Cartes
Outros Sistemas
Sistema de Cobrana, Sistema de
Estoque, Sistema de Vendas
Equipamentos
Leitora de Cdigo de Barras, Sensor,
Plotter, catraca eletrnica

Levando em conta que um ator um papel representado no sistema, o nome dado a esse
ator, portanto, deve lembrar o seu papel, em vez de lembrar quem o representa. Exemplos
de bons nomes para atores: Cliente, Estudante, Fornecedor, etc. Exemplos de nomes
inadequados para atores: J oo, Fornecedora, ACME, etc.

110

CASO de USO RELACIONAMENTOS
A UML define vrios tipos de relacionamentos no modelo de casos de uso: comunicao,
incluso, extenso e generalizao. Vamos dividir em blocos para ficar mais fcil
didaticamente:

INTERAES COMUNICAO INCLUSO EXTENSO GENERALIZAO
Caso de Uso e
Caso de Uso
* * *
Ator e Ator *
Ator e Casos de
Uso
*

Comunicao
Representa a interao do ator com o caso de uso, ou seja, a comunicao entre atores e
casos de uso, por meio de envio e recebimento de mensagens.
A comunicao entre casos de uso so sempre binrias, ou seja, envolvem apenas dois
elementos. Representam o nico relacionamento possvel entre atores e casos de uso. Por
exemplo: O ator Correntista envia e recebe mensagens do Caso de Uso Calcular
Emprstimo Pessoal, por um relacionamento de comunicao.
Generalizao
Ocorre entre Casos de Uso ou entre Atores. considerado quando temos dois elementos
semelhantes, mas com um deles realizando algo a mais. Costuma ser comparado ao
relacionamento de extenso, com uma variao do comportamento normal sendo descrita
sem muito rigor. Segue o mesmo conceito da orientao a objetos.

111

Por exemplo: num Caso de Uso no qual C2 herda de C1, significa dizer que temos C1 como
um Caso de Uso mais genrico e C2 mais especfico. Outro exemplo: podemos criar um ator
genrico Aluno e especializ-lo nos atores Aluno Matriculado e Aluno Ouvi nte.
Extenso
Um relacionamento extenso entre Casos de Uso indica que um deles ter seu procedimento
acrescido, em um ponto de extenso, de outro Caso de Uso, identificado como base.
Os pontos de extenso so rtulos que aparecem nos cenrios de Caso de Uso base.
permitido colocar diversos pontos de extenso num mesmo Caso de Uso, inclusive repetir
um mesmo ponto de extenso.
Um Caso de Uso de extenso muito utilizado para:
1. Expressar rotinas de exceo ou para expressar o desmembramento de um Caso de
Uso.
2. Separar um comportamento obrigatrio de outro opcional.
3. Separar um trecho do Caso de Uso que ser executado apenas em determinas
condies.
4. Separar trechos que dependam da interao com um determinado ator.
Incluso
Quando existem cenrios cujas aes servem a mais de um Caso de Uso deve-se utilizar um
relacionamento de incluso. Indica que um deles ter seu procedimento copiado num local
especificado no outro Caso de Uso, identificado como base.
Textualmente, um relacionamento de incluso, dentro da descrio de um Caso de Uso
base, representado com o termo Include seguido de seu nome. Mais do que evitar a cpia
de trechos idnticos ganhamos tempo de modelagem e tambm de implementao, e
consequentemente de manuteno, ao trabalhar com Casos de Uso de incluso.

112

Exemplo: Validar Matrcula til para Casos de Uso como Renovar Matrcula de Aluno,
Emitir Histrico Escolar, Lanar Notas de Provas, entre outros.



http://celodemelo.wordpress.com/2007/03/17/entendedo-o-diagrama-de-casos-de-uso/
http://www.macoratti.net/net_uml2.htm




Como voc explicaria a diferena existente entre os diversos tipos de
relacionamentos de casos de uso?



113

UNIDADE 24
Objetivo: Apresentar os Diagramas da UML, suas categorias e diferenas com verses
anteriores.
Viso Geral dos Diagramas da UML e as suas categorias
Diretamente derivada dos conceitos de programao e do projeto orientado por objeto, a
anlise orientada a objetos certamente a mais destacada das abordagens de anlise de
sistemas.

Baseada na decomposio do sistema de acordo com os objetos (entidades de dados), essa
abordagem oferece como principais benefcios os seguintes fatores:
Mantm a modelagem do sistema e, consequentemente, a automao do mesmo o mais
prximo possvel de uma viso conceitual do mundo real.
Baseia a decomposio e modelagem do sistema nos dados, que o elemento mais estvel
de todos aqueles que compem um Sistema de Informao.
Existem atualmente na UML 13 tipos de diagrama, divididos em duas categorias: Diagramas
Estruturais e Comportamentais.

114

A funo dos Diagramas Estruturais a de mostrar as caractersticas do sistema que no
mudam ao longo do tempo. J os Diagramas Comportamentais mostram como o sistema
responde s requisies ou como o mesmo evolui durante o tempo. Veja a figura a seguir:


Diagramas Estruturais (Ou Estticos)
Diagrama de classes
Diagrama de estrutura composta
Diagrama de componentes
Diagrama de implantao
Diagrama de objetos
Diagrama de pacotes


115

Diagramas Comportamentais (Ou Dinmicos)
Diagrama de atividades
Diagrama de Caso de Uso
Diagrama de mquina de estados

Diagramas De Interao Composto Por:
Diagrama de sequncia
Diagrama de comunicao ou colaborao
Diagrama de viso geral
Diagrama de temporal
Mostraremos na tabela a seguir uma relao dos diagramas da verso atual do UML
comparado com a verso 1.4:

DIAGRAMAS DA UML 1.4 UML ATUAL
Atividades Atividades
Caso de Uso Caso de Uso
Classes Classes
Colaborao Comunicao
Componentes Componentes
Grfico de Estado Mquina de Estados
Implantao Implantao

116

Objetos Objetos
Sequncia Sequncia
- Pacotes
- Estrutura Composta
- Viso Geral
- Temporal
Como o objetivo principal deste curso no ser a de Modelagem de Sistemas UML, veremos
somente os diagramas mais significativos e usados mais frequentemente na Anlise de
Sistemas.



http://www.visual-paradigm.com/VPGallery/diagrams/index.html
http://www.agilemodeling.com/artifacts/
http://en.wikipedia.org/wiki/Unified_Modeling_Language



Realize uma pesquisa na Internet e tente verificar quais os diagramas da UML so
os mais utilizados no mercado.


117

UNIDADE 25
Objetivo: Visualizar exemplos de dois dos diagramas utilizados no mercado.
Diagrama de Classes e Diagrama de Estrutura
Diagrama de Classes apresenta elementos conectados por relacionamentos. Usado para
exibir entidades do mundo real, alm de elementos de anlise e projeto. Praticamente foi
uma derivao do DER da Anlise Estruturada que vimos na Unidade 12. Podemos ver um
exemplo abaixo:


118

Diagrama de Estrutura, tambm chamado de Estrutura Composta, usado para mostrar a
composio de uma estrutura. til em estruturas compostas de estruturas complexas ou em
projetos baseados em componentes.





http://www.wthreex.com/rup/process/modguide/md_bclsd.htm
http://pt.wikipedia.org/wiki/Diagrama_de_classes
http://pt.wikipedia.org/wiki/Diagrama_de_estrutura_composta




Com base nos sites mencionados anteriormente onde voc aplicaria mais
adequadamente os diagramas desta unidade?



119

UNIDADE 26
Objetivo: Visualizar exemplos de dois dos diagramas utilizados no mercado.
Diagrama de Componentes e Diagrama de Instalao
Diagrama de Componentes mostra as dependncias entre componentes de software,
apresentando suas interfaces.

Diagrama de Instalao, tambm chamado de Diagrama de Implantao, mostra a
arquitetura do sistema em tempo de execuo, as plataformas de hardware, artefatos de
software e ambientes de software como Sistemas Operacionais e mquinas virtuais.

120






http://pt.wikipedia.org/wiki/Diagrama_de_componentes
http://pt.wikipedia.org/wiki/Diagrama_de_instala%C3%A7%C3%A3o



121




Com base nos sites mencionados anteriormente onde voc aplicaria mais
adequadamente os diagramas desta unidade?



122

UNIDADE 27
Objetivo: Visualizar exemplos de dois dos diagramas utilizados no mercado.
Diagrama de Objetos e Diagrama de Pacotes
Diagrama de Objetos apresenta objetos e valores de dados. Corresponde a uma instncia do
Diagrama de Classes, mostrando o estado de um sistema em um determinado ponto do
tempo.

Diagrama de Pacotes usado para organizar elementos de modelo e mostrar dependncias
entre eles.

123





http://pt.wikipedia.org/wiki/Diagrama_de_objetos
http://pt.wikipedia.org/wiki/Diagrama_de_pacotes



124




Com base nos sites mencionados anteriormente onde voc aplicaria mais
adequadamente os diagramas desta unidade?




125

UNIDADE 28
Objetivo: Atravs de um simples programa em Java apresentar a prtica do UML

Exemplo prtico: apresentao geral
Prtica do UML
O primeiro programa que muitos desenvolvedores escrevem ao conhecerem uma nova
linguagem um programa simples, envolvendo apenas exibir na tela a sequncia de
caracteres Hello, World !. um ponto de partida razovel, pois dominar essa aplicao
trivial proporciona uma gratificao imediata. Alm disso, manipula-se toda a infraestrutura
necessria para fazer algo ser executado.
assim que iremos mostrar a parte prtica do UML. Modelar Hello, World ! ser o uso
mais simples da UML que voc poder encontrar. Entretanto, essa aplicao apenas
aparentemente fcil, pois, subjacentes aplicao, existem alguns mecanismos
interessantes que a fazem funcionar. Esses mecanismos podem ser modelados facilmente
com a UML, proporcionando uma viso enriquecida dessa aplicao simples.
Principais Abstraes
Vamos pegar um pequeno programa em J ava para praticarmos a UML. Em J ava, para o
applet exibir Hello, World ! em um navegador da Web bastante simples:
import java.awt.Graphics;
class HelloWorld extends java.apple.Applet {
public void paint (Graphics g) {
g.drawString(Hello, World !, 10, 10);
}
}

126

A primeira linha do cdigo import java.awt.Graphics; faz com que a classe Graphics fique
diretamente disponvel ao cdigo indicado a seguir. O prefixo java.awt especifica o pacote
J ava de onde se importar a classe Graphics.
A segunda linha do cdigo class HelloWorld extends java.apple.Applet { introduz uma nova
classe chamada HelloWorld e especifica que se trata de um tipo de classe semelhante a
Applet, encontrada no pacote java.applet.
As ltimas linhas do cdigo declaram uma operao chamada paint, cuja implementao
inicia outra operao, chamada drawString, responsvel pela exibio da sequncia de
caracteres Hello, World ! nas coordenadas fornecidas. No modo orientado a objetos usual,
drawString uma operao de um parmetro chamado g, cujo tipo a classe Graphics.
simples a modelagem dessa aplicao na UML. Conforme mostra a figura a seguir a
classe HelloWorld pode ser representada graficamente como um cone retangular. A
operao paint mostrada nessa figura com todos os seus parmetros formais omitidos e
sua implementao especificada na nota anexa.


127

UNIDADE 29
Objetivo: Apresentar atravs do exemplo prtico a utilizao de um Diagrama de Classes
Exemplo prtico: Diagrama de Classes
O Diagrama de Classes a seguir capta o bsico da aplicao Hello, World !, mas no
inclui vrios itens. Conforme especifica o cdigo apresentado anteriormente, duas outras
classes Applet e Graphics esto envolvidas nessa aplicao e cada uma delas utilizada
de uma maneira diferente. A classe Applet empregada como me de HelloWorld e a classe
Graphics usada na assinatura e implementao de uma de suas operaes, paint. Voc
pode representar essas classes e seus diferentes relacionamentos com a classe HelloWorld,
usando um Diagrama de Classes, conforme a figura a seguir:

As classes Applet e Graphics so respresentadas como cones retangulares. As operaes
dessas classes no so mostradas e, portanto, seus cones esto ocultos. A linha com a seta
que vai de HelloWorld a Applet representa a generalizao, significando, nesse caso, que a
classe HelloWorld filha de Applet. A linha pontilhada que vai de HelloWorld a Graphics
representa um relacionamento de dependncia, significando que HelloWorld usa a classe
Graphics.

128

Esse no o final da estrutura a partir da qual HelloWorld construda. Pesquisando as
bibliotecas de J ava procura de Applet e Graphics, voc descobrir que essas duas classes
so parte de uma hierarquia maior. Considerando-se somente as classes que Applet estende
e implementa, possvel gerar outro Diagrama de Classes, conforme mostra a figura a
seguir:

Essa figura deixa claro que HelloWorld apenas uma ramificao em uma hierarquia de
classes muito maior. HelloWorld filha de Applet; Applet filha de Painel; Painel filha de
Container; Container filha de Component; e Component filha de Object, que a classe-
me de todas as classes em J ava. Portanto, esse modelo corresponde biblioteca de J ava -
cada classe-filha estende a classe-me imediata.
O relacionamento entre ImageObserver e Component um pouco diferente e o diagrama de
classes reflete essa diferena. Na biblioteca J ava, ImageObserver uma interface; entre
outras coisas, isso significa que no possui uma implementao e requer que outras classes
a implementem. Conforme mostra a figura, uma interface pode ser representada como um
crculo na UML. O fato de Complement implementar ImageObserver est representado pela
linha slida que vai da implementao (Component) at sua interface (ImageObserver).

129

Conforme mostram essas figuras, HelloWorld colabora diretamente apenas com duas
classes (Applet e Graphics), que, por sua vez, so apenas uma pequena parte da biblioteca
maior de classes predefinidas de J ava. Para gerenciar essa extensa coleo, a linguagem
J ava organiza suas interfaces e classes em vrios pacotes diferentes.
O pacote-raiz do ambiente J ava chamado, como era de se esperar, J ava. Aninhados nesse
pacote existem diversos outros pacotes, contendo outros pacotes, interfaces e classes.
Object se encontra no pacote lang e, portanto, seu caminho completo java.lang.Object. De
modo semelhante, Painel, Container e Component se encontram em awt; a classe Applet se
encontra no pacote applet. A interface ImageObserver est no pacote image, que, por sua
vez, pertence ao pacote awt; portanto, seu caminho completo a extensa sequncia
java.awt.lmage.ImageObserver.
Esses pacotes podem ser visualizados em um diagrama de classes, conforme a figura a
seguir:

Conforme mostra essa figura, os pacotes so representados na UML por diretrios com
guias. Os pacotes podem estar aninhados, com linhas tracejadas representando as
dependncias entre esses pacotes. Por exemplo, HelloWorld depende do pacote java.applet,
e java.applet depende do pacote java.awt.

130

UNIDADE 30
Objetivo: dar continuidade ao exemplo prtico apresentando os mecanismos e componentes
Exemplo prtico: Mecanismos e Componentes
Mecanismos
A tarefa mais difcil para se dominar uma biblioteca to rica como a da linguagem J ava
aprender como suas partes trabalham em conjunto. Por exemplo, como invocar a operao
paint de HelloWorld? Quais operaes voc deve utilizar para modificar o comportamento
desse applet, como exibir a sequncia de caracteres em outra cor? Para responder a essas e
a outras perguntas, voc precisar dispor de um modelo conceitual da maneira como essas
classes trabalham em conjunto dinamicamente.
Um estudo da biblioteca de J ava revelar que a operao paint de HelloWorld est na
relao de herana de Component. Isso ainda mantm a pergunta de como essa operao
invocada. A resposta que paint chamada como uma parte da execuo do thread que
contm o applet, conforme mostra a figura mais abaixo.
Essa figura mostra a colaborao de vrios objetos, incluindo uma instncia da classe
HelloWorld. Os demais objetos fazem parte do ambiente de J ava e assim, na maioria dos
casos, so encontrados no segundo plano dos applets que voc criar. Na UML, as instncias
so representadas da mesma forma que as classes, mas com seus nomes sublinhados para
diferenci-las. O objeto HelloWorld tem um nome (target) conhecido pelo objeto
ComponentPeer.

131


Voc pode fazer a modelagem da ordenao de eventos utilizando um Diagrama de
Seqncia, conforme mostra a figura anterior. A sequncia inicia com a execuo do objeto
Thread que, por sua vez, chama a operao run de Toolkit. O objeto Toolkit ento chama
uma de suas prprias operaes (callbackLoop) que, a seguir, chama a operao
handleExpose de ComponentPeer. O objeto ComponentPeer ento chama a operao paint
de seu alvo. O objeto ComponentPeer assume que seu atributo um Component
(denominado HelloWorld) e assim a operao paint de HelloWorld realizada
polimorficamente.
Componentes
Por ser implementado como um applet, HelloWorld ! nunca aparecer sozinho, mas
tipicamente parte de alguma pgina da Web. O applet executado quando a pgina que o
contm estiver aberta, iniciado por algum mecanismo do navegador que executa o objeto
Thread do applet. Entretanto, a classe HelloWorld no diretamente uma parte da pgina da
Web. Mais propriamente, uma forma binria dessa classe, criada por um compilador J ava
capaz de transformar o cdigo-fonte que representa a classe em um componente que possa
ser executado. Enquanto todos os diagramas apresentados anteriormente representavam
uma viso lgica do applet, agora estamos considerando uma viso dos componentes fsicos

132

do applet. Voc pode fazer a modelagem dessa viso fsica usando um Diagrama de
Componentes, conforme mostra a figura a seguir:

Cada um dos cones mostrados nessa figura representa um elemento da UML na viso da
implementao do sistema. O componente chamado hello.java representa o cdigo-fonte
para a classe lgica HelloWorld; portanto, trata-se de um arquivo que pode ser manipulado
pelas ferramentas de gerenciamento de configurao e ambientes de desenvolvimento. Esse
cdigo-fonte pode ser transformado no applet binrio hello.class por um compilador J ava,
permitindo ser executado por uma mquina virtual J ava em um determinado computador.
O cone cannico para um componente um retngulo com duas guias. O applet binrio
HelloWorld.class uma variao desse smbolo bsico, cujas linhas mais grossas indicam
que se trata de um componente executvel (assim como ocorre com uma classe ativa). O
cone para o componente hello.java foi substitudo por um cone definido pelo usurio,
representando um arquivo de texto.
O cone para a pgina da Web hello.html foi definido de maneira semelhante, como uma
extenso da notao da UML. Conforme indica a figura, essa pgina da Web contm outro
componente, hello.jpg, representado por um cone de componente definido pelo usurio,
nesse caso fornecendo uma miniatura da imagem grfica. Como esses trs ltimos

133

componentes incluem smbolos grficos definidos pelo usurio, seus nomes foram colocados
fora dos cones.
Observao: Os relacionamentos entre a classe (HelloWorld), seu cdigo-fonte (hello.java) e
seu cdigo-objeto (HelloWorld.class), raramente so modelados explicitamente, apesar de
que, de vez quando, til proceder dessa maneira para visualizar a configurao fsica do
sistema. Por outro lado, comum visualizar a organizao de um sistema baseado na Web
como esse, utilizando-se diagramas de componentes para a modelagem de suas pginas e
de outros componentes executveis.


Antes de dar incio sua Prova Online fundamental que voc acesse sua SALA
DE AULA e faa a Atividade 3 no link ATIVIDADES.



Atividade Dissertativa
Desenvolva uma pesquisa gerando um texto, de 2 a 3 folhas adicionando imagens, de uma
das unidades da nossa apostila, de sua livre escolha, permitindo a expanso da temtica
selecionada.
Ateno: Qualquer bloco de texto igual ou existente na internet ser devolvido para o aluno
realize novamente.



134

Glossrio
Abstrao A caracterstica essencial de uma entidade que a diferencia de todos os outros
tipos de entidades. Uma abstrao define uma fronteira relativa perspectiva do observador.
Ao Uma computao atmica executvel que resulta em alterao do estado do sistema
ou no retorno de um valor.
Ao assncrona Uma solicitao em que o objeto emissor no faz uma pausa para
aguardar os resultados.
Ao sncrona Uma solicitao em que o objeto emissor faz uma pausa para aguardar os
resultados.
Adorno Detalhe da especificao de um elemento, acrescentada sua notao grfica
bsica.
Agregao Uma forma especial de associao, que especifica o relacionamento parte-todo
entre o agregado (o todo) e o componente (a parte).
Agregada Uma classe que representa o todo em um relacionamento de agregao.
Argumento Um valor especfico correspondente a um parmetro.
Arquitetura O conjunto de decises significativas sobre a organizao de um sistema de
software, a seleo de elementos estruturais e suas interfaces que compem o sistema,
juntamente com seu comportamento, conforme especificado nas colaboraes entre esses
elementos, a composio desses elementos estruturais e comportamentais em subsistemas
progressivamente maiores e o estilo de arquitetura que orienta essa organizao esses
elementos e suas interfaces, suas colaboraes e sua composio. A arquitetura de software
no est relacionada somente com a estrutura e o comportamento, mas tambm com a
utilizao, funcionalidade, desempenho, flexibilidade, reutilizao, abrangncia, restries e
ajustes econmicos e tecnolgicos e questes estticas.

135

Artefato Um conjunto de informaes utilizado ou produzido por um processo de
desenvolvimento de software.
Assinatura O nome e os parmetros de uma operao.
Associao Um relacionamento estrutural que descreve um conjunto de vnculos, em que o
vnculo uma conexo entre objetos; o relacionamento semntico entre dois ou mais
classificadores que envolvem as conexes entre suas instncias.
Ativao A execuo de uma operao.
Associao binria Uma associao entre duas classes.
Associao ensima A associao entre trs ou mais classes.
Ativar Executar a transio de um estado.
Atividade Execuo no-atmica em andamento em uma mquina de estados.
Ator Um conjunto coerente de papeis que os usurios de casos de uso desempenham ao
interagir com os casos de uso.
Atributo Uma propriedade nomeada de um classificador, descrevendo uma faixa de valores
que as instncias da propriedade podero manter.
Booleano Uma enumerao cujos valores so verdadeiros ou falsos.
Caracterstica Uma propriedade, como uma operao ou um atributo, que encapsulada
em outra entidade, como uma interface, uma classe ou um tipo de dados.
Caracterstica comportamental Uma caracterstica dinmica de um elemento, como uma
operao ou um mtodo.
Caracterstica estrutural Uma caracterstica esttica de um elemento.
Cardinalidade O nmero de elementos existentes em um conjunto.
Caso de uso A descrio de um conjunto de sequncias de aes, incluindo variantes, que
um sistema realiza, fornecendo o resultado observvel do valor de um ator.

136

Cenrio Uma sequncia especfica de aes que ilustram o comportamento.
Centrado na arquitetura No contexto do ciclo de vida de desenvolvimento do software, um
processo que focaliza o desenvolvimento inicial e a linha de base da arquitetura de um
software e ento utiliza a arquitetura do sistema como um artefato primrio para
conceitualizar, construir, gerenciar e evoluir o sistema em desenvolvimento.
Classe A descrio de um conjunto de objetos que compartilham os mesmos atributos,
operaes, relacionamentos e semntica.
Classe abstrata Uma classe que no pode ser instanciada diretamente.
Classe ativa Uma classe cujas instncias so objetos ativos.
Classe concreta Uma classe que pode ser instanciada diretamente.
Classe de associao Um elemento de modelagem que tem propriedades de classe e de
associao. Uma classe de associao pode ser vista como uma associao que tambm
tem propriedades de classe ou como uma classe que tambm tem propriedades de
associao.
Classificao dinmica Uma variao semntica da generalizao em que um objeto
poder mudar de tipo ou de papel.
Classificao esttica Uma variao semntica de uma generalizao, em que um objeto
poder no alterar seu tipo, mas poder mudar de papel.
Classificao mltipla Uma variao semntica da generalizao, em que um objeto pode
pertencer diretamente a mais de uma classe.
Classificador O mecanismo que descreve caractersticas estruturais e comporta mentais.
Os classificadores incluem classes, interfaces, tipos de dados, sinais, componentes, ns,
casos de uso e subsistemas.
Cliente Um classificador que solicita servios de outro classificador.

137

Colaborao Uma sociedade de papeis e outros elementos que trabalham em conjunto para
proporcionar algum comportamento cooperativo maior do que a soma de todas as suas
partes; a especificao de como um elemento, como casos de uso ou operaes, realizado
por um conjunto de classifica dores e associaes desempenhando papeis especficos e
utilizados de uma determinada maneira.
Comentrio Uma anotao anexada a um elemento ou a uma coleo de elementos.
Componente Uma parte fsica e substituvel de um sistema com o qual est em
conformidade e proporciona a realizao de um conjunto de interfaces.
Comportamento Os efeitos observveis de um evento, incluindo seus resultados.
Composio Uma forma de agregao com propriedade bem-definida e tempo de vida
coincidente das partes pelo todo; as partes com multiplicidade no fixada podero ser
criadas aps a prpria composio, mas, uma vez criadas, vivem e morrem com ela; essas
partes tambm podem ser removidas explicitamente antes da morte do elemento composto.
Composta Uma classe que relacionada a uma ou mais classes por um relacionamento de
composio.
Concepo A primeira fase do ciclo de vida do desenvolvimento de um software, em que a
ideia bsica para o desenvolvimento conduzida ao ponto de ser suficientemente bem-
fundamentada para garantir a passagem fase de elaborao.
Concorrncia A ocorrncia de duas ou mais atividades durante o mesmo intervalo de
tempo. A concorrncia pode ser realizada com intercalao ou executada simultaneamente
por dois ou mais threads.
Condio de proteo Uma condio que precisa ser satisfeita para permitir que uma
transio associada seja ativada.
Construo A terceira fase do ciclo de vida de desenvolvimento de um software, em que o
software levado da linha de base executvel de uma arquitetura at o ponto em que est
pronto para a transio para uma comunidade de usurios.

138

Container Um objeto que existe para conter outros objetos e que proporciona operaes
para acessar ou iterar seu contedo.
Contexto Um conjunto de elementos relacionados para um determinado propsito, como
especificar uma operao.
Delegao A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a
uma mensagem.
Dependncia Um relacionamento semntico entre dois itens, em que a alterao de um item
(o item independente) poder afetar a semntica do outro item (um item dependente).
Destinatrio O objeto que manipula a instncia de uma mensagem passada pelo objeto
emissor.
Diagrama A apresentao grfica de um conjunto de elementos, em geral representada
como um grfico conectado de vrtices (itens) e arcos (relacionamentos).
Diagrama de atividades Um diagrama que mostra o fluxo de uma atividade para outra; os
diagramas de atividades abrangem a viso dinmica do sistema. Um caso especial de um
diagrama de estado, em que todos ou a maioria dos estados so estados de atividades e em
que todas ou a maioria das transies so ativadas pela concluso de atividades nos
estados de origem.
Diagrama de caso de uso Um diagrama que mostra um conjunto de casos de uso e atores
e seus relacionamentos; o diagrama de caso de uso abrange a viso esttica de caso de uso
de um sistema.
Diagrama de classes O diagrama que mostra um conjunto de classes, interfaces e
colaboraes e seus relacionamentos. Os diagramas de classes abrangem a viso esttica
de projeto de um sistema; um diagrama que mostra a coleo de elementos declarativos
(estticos).
Diagrama de colaborao Um diagrama de interao que d nfase organizao
estrutural de objetos que enviam e recebem mensagens; um diagrama que mostra as
interaes organizadas ao redor de instncias e os vnculos entre elas.

139

Diagrama de componentes Um diagrama que mostra a organizao e as dependncias
existentes em um conjunto de componentes; os diagramas de componentes abrangem a
viso esttica de implementao de um sistema.
Diagrama de grfico de estados Um diagrama que mostra uma mquina de estados; os
diagramas de grficos de estados abrangem a viso dinmica de um sistema.
Diagrama de implantao Um diagrama que mostra a configurao dos ns de
processamento em tempo de execuo e os componentes que nele existem; um diagrama
de implantao abrange a viso esttica de funcionamento de um sistema.
Diagrama de interao Um diagrama que mostra uma interao, composta por um conjunto
de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre
eles; os diagramas de interao abrangem a viso dinmica de um sistema; um termo
genrico aplicado a vrios tipos de diagramas que do nfase s interaes de objetos,
incluindo diagramas de colaborao, diagraCmas de sequncias e diagramas de atividades.
Diagrama de objetos Um diagrama que mostra um conjunto de objetos e seus
relacionamentos em um ponto no tempo; os diagramas de objetos abrangem a viso esttica
de projeto ou a viso esttica de processo de um sistema.
Diagrama de seqncia Um diagrama de interao que d nfase ordenao temporal de
mensagens.
Domnio Uma rea de conhecimento ou de atividade, caracterizada por um conjunto de
conceitos e terminologia compreendidos pelos participantes dessa rea.
Elaborao A segunda fase do ciclo de vida de desenvolvimento de um software, em que a
viso do produto e sua arquitetura so definidos.
Elemento Um constituinte atmico de um modelo.
Elemento derivado Um elemento do modelo que pode ser computado a partir de um
elemento, mas que mostrado por questo de clareza ou includo com o propsito de
projeto, ainda que no acrescente informaes semnticas.

140

Elemento parametrizado O descritor de um elemento com um ou mais parmetros no-
vinculados.
Emissor O objeto que passa a instncia de uma mensagem a um objeto destinatrio.
Engenharia de produo O processo de transformar um modelo em cdigo pelo
mapeamento para uma linguagem especfica de implementao especfica.
Engenharia reversa O processo de transformao de um cdigo em um modelo pelo
mapeamento a partir de uma linguagem de implementao especfica.
Enumerao Uma lista de valores nomeados, utilizada como a faixa de um determinado tipo
de atributo.
Enviar A passagem da instncia de uma mensagem do objeto emissor para um objeto
destinatrio.
Escopo O contexto que d significado a um nome.
Espao de nome Um escopo em que os nomes podem ser definidos e utilizados; em um
espao de nome, cada nome denota um nico elemento.
Especificao Uma declarao textual da sintaxe e da semntica de um bloco de
construo especfico; uma descrio declarativa do que alguma coisa ou faz.
Estado Uma condio ou situao durante a vida de um objeto, durante a qual ele satisfaz
alguma condio, realiza uma atividade ou aguarda algum evento.
Estado composto Um estado formado por subestados concorrentes ou subestados em
disjuno.
Estado de ao Um estado que representa a execuo de uma ao atmica, tipicamente a
chamada de uma operao.
Esteretipo Uma extenso do vocabulrio da UML, que permite a criao de novos tipos de
blocos de construo derivados dos j existentes, mas que so especficos ao seu problema.
Estmulo Uma operao ou um sinal.

141

Evento A especificao de uma ocorrncia significativa, que tem uma localizao no tempo e
no espao; no contexto de uma mquina de estados, o evento a ocorrncia de um estmulo
capaz de ativar a transio de um estado.
Evento de tempo Um evento que denota o tempo decorrido desde que se entrou no estado
atual.
Execuo A execuo de um modelo dinmico.
Exportar No contexto dos pacotes, tornar visvel um elemento fora do espao do nome que o
contm.
Expresso Uma sequncia de caracteres avaliada como um valor de um determinado tipo.
Expresso booleana Uma expresso avaliada como um valor booleano.
Expresso de ao Uma expresso que avaliada como uma coleo de aes.
Expresso de tempo Uma expresso calculada com um valor de tempo absoluto ou relativo.
Expresso de tipo Uma expresso avaliada como uma referncia a um ou mais tipos.
Extremidade da associao O ponto final de uma associao, que conecta a associao a
um classificador.
Extremidade do vnculo Uma instncia de uma extremidade de uma associao.
Fase O intervalo de tempo entre dois marcos de progresso importantes do processo de
desenvolvimento, durante o qual um conjunto bem-definido de objetivos atingido, artefatos
so concludos e decises so tomadas em relao passagem para a fase seguinte.
Filha Uma subclasse.
Filho Uma subclasse.
Foco de controle Um smbolo em um diagrama de sequncia, mostrando o perodo de
tempo durante o qual um objeto realiza uma ao diretamente ou por meio de uma operao
subordinada.

142

Fornecedor Um tipo, classe ou componente que fornece servios que podem ser chamados
por outros.
Framework Um padro de arquitetura que fornece um template extensvel para aplicaes
em um domnio.
Generalizao Um relacionamento de especializao/generalizao, em que objetos do
elemento especializado (o filho) podem ser substitudos para objetos do elemento
generalizado (o pai).
Herana O mecanismo pelo qual elementos mais especficos incorporam a estrutura e o
comportamento de elementos mais gerais.
Herana de implementao A herana da implementao de um elemento mais especfico;
tambm inclui a herana da interface.
Herana de interface A herana da interface de um elemento mais especfico; no inclui a
herana da implementao.
Herana mltipla Uma variao semntica da generalizao, em que um filho pode ter mais
de um pai.
Herana nica Uma variao semntica de uma generalizao, em que um filho pode ter
somente um pai.
Hierarquia de contedos A hierarquia de um espao de nome, formada por elementos e os
relacionamentos de agregao existentes entre eles.
Implementao Uma realizao concreta do contrato declarado por uma interface; a
definio de como algo construdo ou computado.
Import No contexto dos pacotes, uma dependncia que mostra o pacote cujas classes
podero ser referenciadas em um determinado pacote (incluindo pacotes recursivamente
nele incorporados).
Incompleto A modelagem de um elemento, em que faltam certas partes.

143

Inconsistente A modelagem de um elemento em que a integridade do modelo no
garantida.
Incremental No contexto do ciclo de vida do desenvolvimento de um software, um
processo que envolve a integrao contnua da arquitetura do sistema para a produo de
verses, cada nova verso incorporando aperfeioamentos incrementais em relao
anterior.
Instncia Uma manifestao concreta de uma abstrao; uma entidade qual um conjunto
de operaes pode ser aplicado e que tem um estado para armazenar os efeitos das
operaes.
Integridade Como as coisas se relacionam, umas com as outras, de maneira apropriada e
consistente.
Interao Um comportamento que abrange um conjunto de mensagens trocadas entre um
conjunto de objetos em um determinado contexto para a realizao de um propsito.
Interface Uma coleo de operaes utilizadas para especificar o servio de uma classe ou
de um componente.
Iterao Um conjunto distinto de atividades com um plano de linha de base e um critrio de
avaliao que resulta em uma verso, interna ou externa.
Iterativo No contexto do ciclo de vida de desenvolvimento do software, um processo que
envolve o gerenciamento de uma sequncia de verses executveis.
Linha de vida do objeto Uma linha em um diagrama de sequncias, que representa a
existncia de um objeto em um perodo de tempo.
Localizao A posio de um componente em um n.
Me Uma superclasse.
Mquina de estados Um comportamento que especifica as sequncias de estados pelas
quais um objeto passa durante seu tempo de vida como resposta a eventos, juntamente com
sua respostas a esses eventos.

144

Marca de tempo Uma denotao do tempo em que um evento ocorre.
Mecanismo Um projeto-padro que aplicado a uma sociedade de classes.
Mecanismo de extensibilidade Um dos trs mecanismos (esteretipos, valores atribudos e
restries) que permitem estender a UML de maneiras controladas.
Mensagem A especificao de uma comunicao entre objetos que contm informaes
espera de que a atividade acontecer; o destinatrio da instncia de uma mensagem
costuma ser considerado a instncia de um evento.
Metaclasse Uma classe cujas instncias so classes.
Mtodo A implementao de uma operao.
Modelo Uma simplificao da realidade, criada com a finalidade de proporcionar uma melhor
compreenso do sistema que est sendo gerado; uma abstrao semanticamente prxima
de um sistema.
Multiplicidade A especificao de uma faixa de nmeros cardinais, que um conjunto pode
assumir.
Nvel de abstrao Um lugar na hierarquia de abstraes, abrangendo desde os nveis mais
altos de abstrao (muito abstratos) at os mais baixos (muito concretos).
N Um elemento fsico existente em tempo de execuo que representa um recurso
computacional, geralmente dispondo de pelo menos alguma memria e, na maioria das
vezes, capacidade de processamento.
Nome O que voc pode usar para denominar um item, relacionamento ou dia grama; uma
sequncia de caracteres utilizada para identificar um elemento.
Nota Um smbolo grfico para a representao de restries ou de comentrios anexados a
um elemento ou a uma coleo de elementos.
Objet Constraint Language (OCL) Uma linguagem formal utilizada para expressar
restries secundrias de efeito livre.

145

Objeto Uma manifestao concreta de uma abstrao; uma entidade com uma fronteira
bem-definida e uma identidade que encapsula estado e comportamento; a instncia de uma
classe.
Objeto ativo Um objeto a que pertencem um processo ou thread e que capaz de iniciar
uma atividade de controle.
Objeto persistente Um objeto que existe depois que o processo ou o thread que o criaram
deixa de existir.
Objeto transiente Um objeto que existe somente durante a execuo do thread ou do
processo que o criou.
Ocultar A modelagem de um elemento com determinadas partes ocultas para simplificar a
exibio.
Operao A implementao de um servio que pode ser solicitado por qualquer objeto da
classe com a finalidade de afetar um comportamento.
Orientado a caso de uso No contexto do ciclo de vida do desenvolvimento de um software,
um processo em que os casos de uso so utilizados como artefatos primrios para o
estabelecimento do comportamento desejado do sistema, para verificar e validar a
arquitetura do sistema, para testar e para fazer a comunicao entre os participantes do
projeto.
Orientado a riscos No contexto do ciclo de vida de desenvolvimento de software, um
processo em que cada nova verso dedicada a atacar e reduzir os riscos mais
significativos para o sucesso do projeto.
Pacote Um mecanismo de propsito geral para a organizao de elementos em grupos.
Padro Uma soluo comum para um problema comum em um determinado contexto.
Pai Uma superclasse.
Papel O comportamento de uma entidade que participa de um determinado contexto.

146

Parmetro A especificao de uma varivel que pode ser alterada, passada ou re tornada.
Parmetro formal Um parmetro.
Parmetro real Uma funo ou argumento de procedimento.
Ps-condio Uma restrio que precisa ser verdadeira na concluso de uma operao.
Pr-condio Uma restrio que precisa ser verdadeira quando uma operao chamada.
Processo Um fluxo de controle pesado, que pode ser executado concorrentemente com
outros processos.
Produto Os artefatos de desenvolvimento, como modelos, cdigo, documentao e planos
de trabalho.
Projeo Um mapeamento a partir de um conjunto para um subconjunto dele.
Propriedade Um valor nomeado, denotando uma caracterstica de um elemento.
Pseudo-estado Um vrtice em uma mquina de estados que tem a forma de um estado,
mas no se comporta como um estado; os pseudo-estados incluem vrtices inicial, final e de
histrico.
Qualificador O atributo de uma associao cujos valores dividem o conjunto de objetos
relacionados a um objeto em uma associao.
Raia de natao A partio de um diagrama de interao para a organizao de
responsabilidades para aes.
Realizao Os relacionamentos semnticos entre os classificadores, em que um
classificador especifica um contrato cuja execuo garantida por outro classificador.
Receber A manipulao da instncia de uma mensagem passada pelo objeto emissor.
Refinamento Um relacionamento que representa a especificao completa de algo j
especificado em um determinado nvel de detalhe.
Relacionamento Uma conexo semntica entre elementos.

147

Requisito Uma caracterstica, propriedade ou comportamento desejado de um sistema.
Responsabilidade Um contrato ou obrigao em um tipo ou de uma classe.
Restrio Uma extenso da semntica de um elemento da UML, permitindo acrescentar
novas regras ou modificar as existentes.
Restrio de tempo Uma declarao semntica sobre o valor de tempo relativo ou absoluto
ou a durao.
Seqncia de caracteres Uma sequncia de caracteres de texto.
Sinal A especificao de um estmulo assncrono comunicado entre instncias.
Sistema Possivelmente decomposto em uma coleo de subsistemas, um conjunto de
elementos organizados para a realizao de um propsito especfico e descrito por um
conjunto de modelos, provavelmente sob diferentes pontos de vista.
Solicitao A especificao de um estmulo enviado a um objeto.
Subclasse Em um relacionamento de generalizao, a especializao de outra classe, a
classe, me.
Subestado Um estado que parte de um estado composto.
Subestado concorrente Um subestado ortogonal que pode ser mantido simultaneamente
com outros subestados contidos no mesmo estado composto.
Subestado disjunto Um subestado que no pode ser mantido simultaneamente com outros
subestados contidos no mesmo estado composto.
Subsistema Um agrupamento de elemento, em que alguns constituem uma especificao
do comportamento oferecido pelos outros elementos contidos nesse agrupamento.
Superciasse Em um relacionamento de generalizao, a generalizao de outra classe, a
classe filha.

148

Tarefa Um caminho nico para execuo de um programa, um modelo dinmico ou alguma
outra representao do fluxo de controle; um thread ou um processo.
Template Um elemento parametrizado.
Tempo Um valor representando um momento absoluto ou relativo.
Thread Um fluxo leve de controle que pode ser executado concorrentemente com outros
threads no mesmo processo.
Tipo de dados Um tipo cujos valores no tm identidade. Os tipos de dados incluem tipos
primitivos inerentes (como nmeros e sequncias de caracteres), alm de tipos enumerados
(como booleano).
Tipo O esteretipo de uma classe, utilizado para especificar um domnio de objetos,
juntamente com as operaes (mas no os mtodos) que podem ser aplicadas aos objetos.
Tipo primitivo Um tipo bsico, como um inteiro ou uma sequncia de caracteres.
Trace Uma dependncia que indica um relacionamento de processo ou de histrico entre
dois elementos que representam o mesmo conceito, sem regras para derivar um a partir do
outro.
Transio A quarta fase do ciclo de vida de desenvolvimento de um software, em que o
software colocado nas mos da comunidade de usurios; um relacionamento entre dois
estados indicando que um objeto no primeiro estado realizar determinadas aes e passar
ao segundo estado quando um evento especificado ocorrer e as condies forem satisfeitas.
UML (Unified Modeling Language) Linguagem de Modelagem Unificada, uma linguagem
para a visualizao, especificao, construo e documentao de artefatos de um sistema
complexo de software.
Unidade de distribuio Um conjunto de objetos ou componentes que so alocados para
um n como um grupo.
Utilizao A dependncia em que um elemento (o cliente) requer a presena de outro
elemento (o fornecedor) para seu correto funcionamento ou implementao.

149

Valor Um elemento de um domnio de tipo.
Valor atribudo Uma extenso das propriedades de um elemento da UML, que permite a
criao de novas informaes na especificao desse elemento.
Verso Um conjunto de artefatos, relativamente completo e consistente, disponvel para um
usurio interno ou externo; a prpria entrega desse conjunto.
Vinculao A criao de um elemento a partir de um template, fornecendo-se os
argumentos para os parmetros do template.
Vnculo Uma conexo semntica entre objetos; uma instncia de uma associao.
Viso A projeo em um modelo, vista a partir de uma determinada perspectiva ou ponto de
vantagem e omite as entidades que no so relevantes para essa viso.
Viso de caso de uso A viso da arquitetura de um sistema, abrangendo os casos de uso
que descrevem o comportamento do sistema, conforme visto pelos seus usurios finais,
analistas e pessoal de teste.
Viso de implantao A viso da arquitetura de um sistema, abrangendo os ns que
formam a topologia de hardware, em que o sistema executado; a viso de implantao
abrange a distribuio, entrega e instalao das partes que constituem o sistema fsico.
Viso de implementao A viso da arquitetura de um sistema, abrangendo os
componentes utilizados para montar e liberar o sistema fsico; a viso de implementao
inclui o gerenciamento da configurao das verses do sistema, compostas por
componentes de alguma forma independentes que podem ser reunidos de vrios modos
para produzir um sistema em execuo.
Viso de processo A viso da arquitetura de um sistema, abrangendo os threads e os
processos que formam a concorrncia do sistema e os mecanismos de sincronizao; a
viso de processo abrange o desempenho, a escalabilidade e o tempo de resposta do
sistema.

150

Viso de projeto A viso da arquitetura de um sistema, abrangendo as classes, interfaces e
colaboraes que formam o vocabulrio do problema e sua soluo; a viso de projeto
abrange os requisitos funcionais do sistema.
Viso dinmica Um aspecto de um sistema que d nfase ao seu comportamento.
Viso esttica Um aspecto de um sistema que d nfase sua estrutura.
Visibilidade Como um nome pode ser visto e utilizado pelos outros.

151

Referncias
BOOCH, Grady; RUMBAUGH, J ames; J ACOBSON, Ivar. UML : guia do usurio: o mais avanado
tutorial sobre Unified Modeling Language (UML). Rio de J aneiro: Campus, 2000. (traduo Fabio
Freitas da Silva).
MELO, Ana Cristina. Desenvolvendo aplicaes com UML 2.0: do conceitual implementao.
2.ed. Rio de J aneiro: Brasport, 2004.
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. 7. ed. Rio de J aneiro:
Elsevier, 2002.
OLIVEIRA, J ayr Figueiredo de. Metodologia para desenvolvimento de projetos de sistemas: guia
bsico de referncia. 2.ed. So Paulo: rica, 1997