8 Analiseoo

Engenharia de Software
AnIIse DrIentada a Dbjetos

Pablo 0all'DglIo
Introduo UhL
DrIgens da modeIagem orIentada a objetos
LInguagens para modeIagem dependem muIto do paradIgma;
A prImeIra IInguagem D.D. reconhecIda como o SImuIa-67;
Seus conceItos InspIraram o SmaIItaIk(80's), C++ e EIffel;
LInguagens para modeIagem de sIstemas orIentados a objetos

surgIram no fInal dos anos 80. Entre 1989 e 1994, a quantIdade
de mtodos DD subIu de 10 para maIs de 50;
HavIa dIfIculdade de encontrar um mtodo compIeto;
SurgIu a gerra dos mtodos. Alguns se destacavam: ooch,

DDSE (Dbject DrIented Software EngIneerIng) de Jacobson e
D|T (Dbject |odelIng TechnIque) de Pumbaugh;
Todos mtodos tentavam abordar todo o cIcIo de

desenvolvImento, mas alguns eram melhores em alguns
aspectos.
A guerra dos mtodos
ooch era bom em projeto e desenvolvImento, mas fraco em

anlIse. DDSE era bom em casos de uso (Interaes com o
usurIo) e DhT era bom em anIIse, mas fraco em desIgn;
Ds anos 80 e 90 presencIvam uma guerra de metodologIas e

uma unIfIcao parecIa ImprovveI devIdo InflexIbIlIdade dos
metodologIstas;
Tudo comeou a mudar com a Ida de Fumbaugh para a PatIonaI

em outubro de 1994, onde j trabalhava 8ooch. Em 1995 a
FatIonal adquIre a Dbjectory, empresa de Jacobson;
ooch, Jacobson e Pumbaugh apresentaram o prImeIro esboo

da U|L 0.8 em outubro de 1995;
A verso 0.9 foI lanada em junho de 1996 e a UhL 1.0 em

janeIro de 17.
Ds trs amIgos
|uItas vezes tambm so

chamados de "os ex
amIgos";
A DhC
A U|L teve um grande crescImento desde

que fora crIada, tornandose um padro de fato;
Para que a U|L no fIcasse nas mos de uma nIca empresa,

prejudIcando a concorrncIa e a InteroperabIlIdade,
fornecedores acIonaram a DhC para que padronIzasse a UhL;
A D|C (Dbject |anagement Croup) um grupo formado em

18 por empresas como (HP, 8|, |Icrosoft, Dracle) conhecIdo
por prezar pela InteroperabIIIdade e por padres como CDPA;
A verso 1.1 j sob a D|C, foI publIcada em novembro de 1997;
0e 2000 200J, um grupo maIor de parceIros envolvIdos

trabalhou na especIfIcao da U|L 2.0, publIcada em 2005;
Atualmente a UhL mantIda peIa DhC, que estabeIece

padres e defIne quaIs as meIhorIas que sero adIcIonadas.
D que a UhL
A U|L um conjunto de notaes grfIcas voltado para o

projeto de sIstemas de software DD;
Notaes grfIcas para projetos de software j exIstem h

bastante tempo na IndustrIa;
Seu uso vem do fato de que IInguagens de programao no

possuem um nveI de abstrao sufIcIentemente alto;
Um bom dIagrama pode transmItIr uma IdIa melhor do que

muItas palavras (comunIcao). Um dIagrama auxIlIa no
entendImento de um sIstema e do processo de negocIo;
Um dIagrama auxIlIa no processo de comunIcao e

compartIlhamento do conhecImento;
Entender um dIagrama maIs fcII do que entender um

codIgofonte;
0Iagramas
A U|L 2 defIne 1J dIagramas, que podem ser vIstos na tabela a

seguIr:
AtIvIdades, Estados;
Classes, Dbjetos
Casos de Uso;
ComunIcao;
Componentes, 0IstrIbuIo ou Implantao, Pacotes;
Estruturas compostas;
7Iso geral da Interao
SequncIa;
TemporIzao ou SIncronIsmo;
0Iagramas
0Iagramas
hodo esboo
Conforme Fowler, a U|L pode ser utIIIzada como notao para

esboo, para projeto e tambm como lInguagem de
programao;
Como esboo, a U|L utIlIzada de maneIra coIaboratIva em

rascunhos, quadros brancos e documentos para construIr uma
conceItualIzao de algo que ser construido;
No modo esboo, no h necessIdade de um rIgor quanto aos

formaIIsmos da lInguagem e o foco dos dIagramas a
comunIcao cIara e no a especIfIcao completa;
No modo esboo, no h a necessIdade de utIIIzar uma

ferramenta CASE robusta para expressar os dIagramas;
Ferramentas sImples de desenho vetorIal so sufIcIentes.

hodo esboo
hodo projeto
J a UhL para projetos tem o objetIvo de ser compIeta e

precIsa. Nesta abordagem exIste o papeI do projetIsta, cuja
tarefa construIr uma especIfIcao completa e detalhada para
que o programador possa desenvolver a aplIcao a partIr dela;
A UhL como projeto deve transmItIr para o programador

detaIhes a respeIto de decIses de projeto de maneIra que o
mesmo possa desenvoIver a apIIcao de maneIra dIreta, sem
muItas dvIdas que faam o mesmo recorrer ao
analIsta/projetIsta;
Este tIpo de abordagem orIunda da engenharIa cIvII

tradIcIonal, na qual pontes e edIfIcaes podem ser construIdas
estrItamente a partIr de projetos mInucIosos.
hodo projeto
No modo projeto, exIste a necessIdade da

utIlIzao de ferramentas CASE robustas
especIalIzadas na construo destes tIpos
de dIagramas, dando um suporte completo
a projetIsta;
No modo projeto, devemos ter em mente

que as Interfaces projetadas sofrero
aIteraes na medIda em que o sIstema for
desenvolvIdo;
Estas aIteraes tornaro o projeto

rapIdamente uItrapassado e dIficIl de ser
mantIdo.
hodo projeto
ExempIos de dIagramas
hodeIo de domnIo
ConsIderaes
Um modelo de dominIo construido aps a construo dos

casos de uso do sIstema e se utIlIza de muItos conceItos
descobertos pelos casos de uso;
D modelo de dominIo utIlIzado nas etapas posterIores de

projeto de software como entrada () para uma srIe de
outros dIagramas;
D dIagrama que maIs se benefIcIar com as IdIas, conceItos e

entIdades coletadas pelo modelo de dominIo ser o dIagrama
de cIasses.
Para que serve o modeIo
Para Larman, a construo de um modelo conceItual uma

atIvIdade fundamentaI na anIIse de sIstemas orIentados a
objetos;
A construo de um modelo conceItual permIte regIstrarmos

conceItos, atIvIdades, funes, atores e entIdades que muItas
vezes no encontram espao em dIagramas posterIores de
projeto por serem consIderados Irrelevantes para a aplIcao;
Este tIpo de Informao levantada na anlIse, permItenos

muItas vezes regIstrar e entender com cIareza o por que
determInadas opes de projeto foram tomadas;
ExIstem conceItos, como "regIstradora" (Larman), que no IrIa

constar no dIagrama de classes, mas no modelo de dominIo
permIte entender meIhor o funcIonamento do negcIo.
Abstrao
Um modelo de dominIo busca a representao de elementos

(objetos) exIstente no mundo reaI e que so pertInentes ao
sIstema que est sendo desenvolvIdo;
Um modelo conceItual comporta classes sem atrIbutos ou

classes comportamentaIs que no possuem necessarIamente
necessIdade de terem Informaes regIstradas futuramente
pelo sIstema (serem persIstIdas).
0escoberta das cIasses
A crIao de um modelo de dominIo InIcIa com a descoberta

das classes conceItuaIs. Uma das formas de proceder com a
descoberta das cIasses por meIo da IdentIfIcao de
sujeItos, objetos e substantIvos nos casos de uso;
No muIto efIcIente tentar automatIzar a IdentIfIcao de

conceItos a partIr de descrIes textuaIs de casos de uso. Esta
IdentIfIcao um processo bastante subjetIvo e fortemente
dependente do estIIo de quem escreveu;
Dutra forma por meIo da reutIIIzao de modeIos de

domnIo sImIlares j desenvolvIdos pela organIzao e que
possuem algum tIpo de IIgao conceItuaI com o projeto que
est sendo desenvolvIdo.
CIassIfIcao das cIasses
AssIm como podemos classIfIcar conceItos em uma mapa

conceItual, tambm podemos classIfIcar uma classe conceItual,
que pode ser:
entIdades do mundo reaI: turma, dIscIplIna, um produto;
objetos fsIcos: um lIvro, uma bIcIcleta, um celular;
IocaIs: uma escola, uma loja, uma bIblIoteca;
operaes: compra, venda, matricula, trancamento;
papIs: professor, aluno, atendente;
outras organIzaeslsIstemas: banco, sIstema de crdIto.

CIasse ou atrIbuto
A partIr da lIsta de candIdatos a classes conceItuaIs, precIsamos

tomar outras decIses com escolher se determInado conceIto
ser representado como uma cIasse ou como um atrIbuto de
uma classe;
Em lInhas geraIs, quando um conceIto puder ser defInIdo por

um dado escalar (nmero, texto, booIeano) ele poder ser
representado por um atrIbuto de uma outra classe. Exemplo:
nome, telefone, salrIo;
Quando um conceIto for maIs compIexo e composto de maIs

Informaes, dever ser representado como uma cIasse. Por
exemplo: pessoa, lIvro, produto.
AssocIaes
A fIgura a seguIr demonstra uma assocIao, que

representada por uma reta nomeada e possuI a representao
de muItIpIIcIdade em seus extremos.
A assocIao geralmente expressa por um verbo que conecta

as duas classes conceItuaIs.
AssIm como um mapa conceItual deve ser lIdo do topo para

baIxo, as assocIaes geralmente possuem alguma seta que
IndIcam a dIreo da IeItura.
huItIpIIcIdade
A multIplIcIdade representada por nmeros e sInaIs nos

extremos de uma assocIao que representam quantas
InstncIas de uma classe conceItual podero estar relacIonadas
com outra classe conceItual.
Por exemplo: Uma turma ter um nIco professor, mas ter

muItos alunos.
TIpos de assocIao
ExIstem dIversos tIpos de assocIaes que podem se estabelecer

entre classes conceItuaIs. A seguIr algumas categorIas:
AssocIao sImpIes: [Turma] possuI um [Professor]
0esempenhar papIs: [ClIente] efetua [Compra]
Aes sobre objeto: [Compra] realIzada sobre [Produto]
PeIao TodolParte: [Turma] composta de [Aluno]

AtrIbutos
Uma classe conceItual ter um ou maIs atrIbutos na maIorIa

das vezes;
Um atrIbuto representa uma Informao Importante ao

contexto do dominIo de negocIos que est sendo modelado.
Ceralmente um atrIbuto representado por uma Informao

escaIar: texto, numero, logIco;
No h necessIdade de Informar o tIpo de um atrIbuto no

modelo de dominIo. D tIpo ser necessrIo no dIagrama de
classes;
As classes conceItuaIs devem ser relacIonadas somente por

meIo da assocIao, no como atrIbutos como permItIdo pelo
dIagrama de classes.
0Iagrama de atIvIdades
0efInIo
0Iagramas de atIvIdade so utIlIzados para representar o

fIuxo de um processo de negcIo, ou seja, a ordem e
organIzao de um conjunto de atIvIdades;
0Iagramas de atIvIdades mostram uma vIso dInmIca do

sIstema;
Frequentemente teremos em um dIagrama de atIvIdades,

atIvIdades que so reaIIzadas por dIferentes casos de uso;
Um dIagrama de atIvIdades permIte que se reaIIze uma

IeItura sImpIes e cIara de um processo, representando
caracteristIcas como a ordem de execuo de atIvIdades e
at mesmo a tomada de decIses em um processo.
0efInIo
0Iagramas de atIvIdades so utIIIzados para demonstrar

como processos de negcIo so reaIIzados, ou seja,
demonstram fluxos de trabalho (workflows);
0Iagramas de atIvIdades so baseados nos antIgos dIagramas

de fIuxos de dados (0F0's) orIundos da modelagem
estruturada nos anos 70;
D foco dos dIagramas de fIuxos de dados no era tanto

mostrar o processo do negocIo, mas sIm, a passagem de
dados peIo sIstema.
0efInIo
0IvIso (separao) e juno (unIo)
Uma separao permIte dIvIdIrmos um processo e

execues concorrentes, ou seja, a partIr de um fluxo de
entrada, crIar vrIos fluxos de saida;
A partIr de uma separao, podemos escolhar por executar

os processos de dIferentes lInhas de maneIra concorrente
ou IntercaIada;
Aps a execuo de atIvIdades em paralelo, necessrIo

sIncronIzar o processo;
A sIncronIzao do processo representada peIa juno,

que unIfIca o fIuxo de sada a partIr de vrIos fluxos de
entrada.
0IvIso (separao) e juno (unIo)
As barras de dIvIso e juno so utIlIzadas quando um

processo de negocIo possuI atIvIdades que podem ser
desempenhadas em paraIeIo ou de maneIra IntercaIada;
As barras de dIvIso e juno (ou barras de sIncronIzao)

so IInhas que podem ser representadas na horIzontaI ou
vertIcaI;
Uma dIvIso ter um fIuxo de entrada e um doIs ou maIs

fIuxos de sada;
Uma unIo ter doIs ou maIs fIuxos de entrada e um fluxo

de saida;
A unIo s ocorre apos todos os fIuxos de entrada serem

concIudos.
Separaes e junes
Separaes e junes
0ecIses
Uma decIso em um dIagrama de atIvIdades permItenos

escoIher um camInho a seguIr a partIr de uma determInada
condIo;
Uma decIso tem um fIuxo de entrada nIco, mas pode

apresentar vrIos fIuxos de sada a partIr da condIo
avalIada;
Cada fIuxo de saIda apresenta uma condIo IgIca,

portanto, a partIr de uma condIo, somente um dos
camInhos de sada deve ser seguIdo, ou seja, as condIes
so mutuamente excIusIvas.
0ecIses
0ecIses (ou ramIfIcaes) permItem defInIr camInhos

aIternatIvos ao processo, com base em condIes logIcas;
Em uma decIso, a sada no pode ser ambgua, ou seja,

apresentar duas possiveIs saidas. Cada sada precIsa ser
excIusIva. As saidas devem oferecer tdoas possIbIlIdades de
resposta;
A U|L no especIfIca uma IInguagem para construIr as

expresses condIcIonaIs. PermItese utIlIzar a proprIa
IInguagem de programao aIvo;
D Iosango tambm utIlIzado para representar fuso de

dIferentes camInhos.
0ecIses
0ecIses
0ecIses (IF e WhIIe)
PartIes (ou raIas)
As partIes (ou raIas) em um dIagrama de atIvIdades

IndIcam de quem a responsabIIIdade peIa execuo das
aes;
As partIes ou raIas permItem dIvIdIr as atIvIdades em

grupos de conforme o papeI dentro da organIzao
responsvel por sua execuo;
A responsabIIIdade representada por um papeI da

organIzao responsvel por realIzar as aes;
Para Fowler, uma responsabIIIdade (em programao) pode

ser representada tambm por uma cIasse.
PartIes (ou raIas)
PartIes
(ou raIas)
0Iagrama de estados
0efInIo
utIIIzado para descrever o comportamento de um

sIstema;
Cada dIagrama de estados utIlIzado para modeIar o

comportamento de Uh objeto do sIstema;
D objetIvo demonstrar o cIcIo de vIda de um objeto, ou

seja, as transIes de estado pelas quaIs ele passa ao Iongo
de sua exIstncIa;
No necessrIo crIar um dIagrama de estados para cada

cIasse do sIstema, mas para aquelas que possuem um
comportamento reIevante;
0Iagramas de estados mostram uma vIso dInmIca do

sIstema.
0efInIo
Um estado corresponde uma sItuao vIvencIada pelo

objeto. Esta sItuao pode representar a espera peIa
reaIIzao de um evento ou o resuItado de uma atIvIdade;
Ds estados de um objeto so aIterados por meIo de

transIes ou eventos que ocorrem no sIstema. Um evento
pode ser dIsparado por uma atIvIdade;
Uma transIo o reIacIonamento entre doIs estados e

dIsparada na ocorrncIa de um evento que faz um objeto
alternar entre os estados;
D evento um estmuIo que pode ser orIgInado por uma

atIvIdade que faz o objeto alterar de estado.
ExempIos
ExempIos
ExempIos
Superestados e subestados

8 Analiseoo

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

8 Analiseoo

Hochgeladen von

Copyright:

Verfügbare Formate

Engenharia de Software

AnIIse DrIentada a Dbjetos

LInguagens para modeIagem dependem muIto do paradIgma;

A prImeIra IInguagem D.D. reconhecIda como o SImuIa-67;

Seus conceItos InspIraram o SmaIItaIk(80's), C++ e EIffel;

LInguagens para modeIagem de sIstemas orIentados a objetos

HavIa dIfIculdade de encontrar um mtodo compIeto;

SurgIu a gerra dos mtodos. Alguns se destacavam: ooch,

Todos mtodos tentavam abordar todo o cIcIo de

ooch era bom em projeto e desenvolvImento, mas fraco em

Ds anos 80 e 90 presencIvam uma guerra de metodologIas e

Tudo comeou a mudar com a Ida de Fumbaugh para a PatIonaI

ooch, Jacobson e Pumbaugh apresentaram o prImeIro esboo

A verso 0.9 foI lanada em junho de 1996 e a UhL 1.0 em

|uItas vezes tambm so

A U|L teve um grande crescImento desde

Para que a U|L no fIcasse nas mos de uma nIca empresa,

A D|C (Dbject |anagement Croup) um grupo formado em

A verso 1.1 j sob a D|C, foI publIcada em novembro de 1997;

0e 2000 200J, um grupo maIor de parceIros envolvIdos

Atualmente a UhL mantIda peIa DhC, que estabeIece

A U|L um conjunto de notaes grfIcas voltado para o

Notaes grfIcas para projetos de software j exIstem h

Seu uso vem do fato de que IInguagens de programao no

Um bom dIagrama pode transmItIr uma IdIa melhor do que

Um dIagrama auxIlIa no processo de comunIcao e

Entender um dIagrama maIs fcII do que entender um

A U|L 2 defIne 1J dIagramas, que podem ser vIstos na tabela a

Componentes, 0IstrIbuIo ou Implantao, Pacotes;

7Iso geral da Interao

Conforme Fowler, a U|L pode ser utIIIzada como notao para

Como esboo, a U|L utIlIzada de maneIra coIaboratIva em

No modo esboo, no h necessIdade de um rIgor quanto aos

No modo esboo, no h a necessIdade de utIIIzar uma

Ferramentas sImples de desenho vetorIal so sufIcIentes.

J a UhL para projetos tem o objetIvo de ser compIeta e

A UhL como projeto deve transmItIr para o programador

Este tIpo de abordagem orIunda da engenharIa cIvII

No modo projeto, exIste a necessIdade da

No modo projeto, devemos ter em mente

Estas aIteraes tornaro o projeto

Um modelo de dominIo construido aps a construo dos

D modelo de dominIo utIlIzado nas etapas posterIores de

D dIagrama que maIs se benefIcIar com as IdIas, conceItos e

Para Larman, a construo de um modelo conceItual uma

A construo de um modelo conceItual permIte regIstrarmos

Este tIpo de Informao levantada na anlIse, permItenos

ExIstem conceItos, como "regIstradora" (Larman), que no IrIa

Um modelo de dominIo busca a representao de elementos

Um modelo conceItual comporta classes sem atrIbutos ou

A crIao de um modelo de dominIo InIcIa com a descoberta

No muIto efIcIente tentar automatIzar a IdentIfIcao de

Dutra forma por meIo da reutIIIzao de modeIos de

AssIm como podemos classIfIcar conceItos em uma mapa

entIdades do mundo reaI: turma, dIscIplIna, um produto;

objetos fsIcos: um lIvro, uma bIcIcleta, um celular;

IocaIs: uma escola, uma loja, uma bIblIoteca;

operaes: compra, venda, matricula, trancamento;

papIs: professor, aluno, atendente;

outras organIzaeslsIstemas: banco, sIstema de crdIto.

A partIr da lIsta de candIdatos a classes conceItuaIs, precIsamos

Em lInhas geraIs, quando um conceIto puder ser defInIdo por

Quando um conceIto for maIs compIexo e composto de maIs