U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE...

89
UNIVERSIDADE DO MINHO ESCOLA DE ENGENHARIA 2000/01 DEP. INFORMÁTICA DESENVOLVIMENTO DE DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) (MESTRADO EM INFORMÁTICA) - SESSÃO 4: Modelação de Sistemas com Objectos - - SESSÃO 4: Modelação de Sistemas com Objectos - JOÃO MIGUEL FERNANDES JOÃO MIGUEL FERNANDES Email: [email protected] Email: [email protected] URL: http://www.di.uminho.pt/~miguel URL: http://www.di.uminho.pt/~miguel

Transcript of U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE...

Page 1: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

UNIVERSIDADE DO MINHO

ESCOLA DE ENGENHARIA 2000/01 DEP. INFORMÁTICA

DESENVOLVIMENTO DE DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS SISTEMAS EMBEBIDOS

(MESTRADO EM INFORMÁTICA) (MESTRADO EM INFORMÁTICA)

- SESSÃO 4: Modelação de Sistemas com Objectos -- SESSÃO 4: Modelação de Sistemas com Objectos -

JOÃO MIGUEL FERNANDESJOÃO MIGUEL FERNANDESEmail: [email protected]: [email protected]

URL: http://www.di.uminho.pt/~miguelURL: http://www.di.uminho.pt/~miguel

Page 2: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

2

SumárioSumário

1. Enquadramento1. Enquadramento

2. Métodos Funcionais2. Métodos Funcionais

3. Métodos OO3. Métodos OO

4. Características OO4. Características OO

5. Objectos 5. Objectos

6. UML6. UML

Page 3: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

3

1. Enquadramento 1. Enquadramento (1/2)(1/2)

Objectivos deste móduloObjectivos deste módulo– Introduzir o termo “objecto”.Introduzir o termo “objecto”.– Apresentar as características mais importantes do Apresentar as características mais importantes do

paradigma dos objectos para tratar a complexidade paradigma dos objectos para tratar a complexidade dos sistemas.dos sistemas.

– Mostrar os mecanismos de modelação disponibilizados Mostrar os mecanismos de modelação disponibilizados pela linguagem UML.pela linguagem UML.

Audiência alvoAudiência alvo– licenciados (com ou sem formação na área das TSI) licenciados (com ou sem formação na área das TSI)

com responsabilidades e experiência comprovada com responsabilidades e experiência comprovada (desejável!) na análise, concepção e implementação (desejável!) na análise, concepção e implementação de sistemas baseados em softwarede sistemas baseados em software

Page 4: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

4

1. Enquadramento 1. Enquadramento (2/2)(2/2)

Bibliografia recomendadaBibliografia recomendada– Booch G. (1994). “Booch G. (1994). “Object-Oriented Analysis and Design Object-Oriented Analysis and Design

with Applicationswith Applications”. Benjamin/Cummings, 2ª edição. ”. Benjamin/Cummings, 2ª edição. ISBN 0-8053-5340-2ISBN 0-8053-5340-2..

– Cox B.J., Novobilski A.J. (1991). “Object-Oriented Cox B.J., Novobilski A.J. (1991). “Object-Oriented Programming: An Evolutionary Approach”.Programming: An Evolutionary Approach”.Addison-Wesley. Addison-Wesley. ISBN 12667792ISBN 12667792..

– Booch G., Rumbaugh J., Jacobson I. (1999). “Booch G., Rumbaugh J., Jacobson I. (1999). “The The Unified Modeling Language User GuideUnified Modeling Language User Guide”. Object ”. Object Technology. Addison-Wesley. Technology. Addison-Wesley. ISBN 0-201-57168-4ISBN 0-201-57168-4..

– Rumbaugh J., Blaha M., Premerlani W., Eddy F., Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W. (1991). “Lorensen W. (1991). “Object-Oriented Modeling and Object-Oriented Modeling and DesignDesign”. Prentice-Hall International. ISBN 0-13-”. Prentice-Hall International. ISBN 0-13-630054-5.630054-5.

– www.omg.org/umlwww.omg.org/uml

Page 5: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

5

2. Métodos Funcionais 2. Métodos Funcionais (1/5)(1/5)

MétodosMétodos

– Os métodos a serem aplicados, no âmbito das Os métodos a serem aplicados, no âmbito das metodologias de desenvolvimento, correspondem a metodologias de desenvolvimento, correspondem a conjuntos de actividades que organizam a execução de conjuntos de actividades que organizam a execução de determinadas fases do ciclo de vida do sistema.determinadas fases do ciclo de vida do sistema.

– Se a maior parte dos métodos segue a abordagem Se a maior parte dos métodos segue a abordagem multi-vista, já o mesmo consenso não se verifica multi-vista, já o mesmo consenso não se verifica quanto à ordem de construção das vistas e dos seus quanto à ordem de construção das vistas e dos seus conteúdos.conteúdos.

Page 6: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

6

2. Métodos Funcionais 2. Métodos Funcionais (2/5)(2/5)

Métodos funcionais #1Métodos funcionais #1

– Os métodos funcionais baseiam-se fundamentalmente Os métodos funcionais baseiam-se fundamentalmente na modelação do fluxo de dados, recomendando, o na modelação do fluxo de dados, recomendando, o processo de especificação, que se inicie o processo de especificação, que se inicie o desenvolvimento do sistema pela análise dos dados.desenvolvimento do sistema pela análise dos dados.

– Esta análise inicia-se com a caracterização do ambiente Esta análise inicia-se com a caracterização do ambiente do sistema, bem como das suas entradas e saídas, o do sistema, bem como das suas entradas e saídas, o que leva à definição de um diagrama de contexto do que leva à definição de um diagrama de contexto do sistema.sistema.

– As actividades internas ao sistema são decompostas As actividades internas ao sistema são decompostas por refinamentos sucessivos de DFDs até que cada por refinamentos sucessivos de DFDs até que cada actividade acaba por ser especificada num formato actividade acaba por ser especificada num formato textual.textual.

Page 7: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

7

2. Métodos Funcionais 2. Métodos Funcionais (3/5)(3/5)

Métodos funcionais #2Métodos funcionais #2

– Uma vez que os DFDs não se adequam à especificação Uma vez que os DFDs não se adequam à especificação do comportamento temporal das actividades, podem do comportamento temporal das actividades, podem ser adicionados STDs aos DFDs para possibilitar a ser adicionados STDs aos DFDs para possibilitar a especificação dos estados de todas as actividades.especificação dos estados de todas as actividades.

– No que diz respeito à concepção, os métodos No que diz respeito à concepção, os métodos funcionais suportam a obtenção da arquitectura funcionais suportam a obtenção da arquitectura conceptual do sistema e a implementação é baseada conceptual do sistema e a implementação é baseada na transformação dos modelos em programas, na transformação dos modelos em programas, codificados à luz do paradigma da programação codificados à luz do paradigma da programação estruturada.estruturada.

Page 8: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

8

2. Métodos Funcionais 2. Métodos Funcionais (4/5)(4/5)

Métodos funcionais #3Métodos funcionais #3

– Os métodos funcionais baseiam-se numa Os métodos funcionais baseiam-se numa decomposição decomposição top-downtop-down e num refinamento e num refinamento sucessivo dos modelos do sistema, obtendo-se, em sucessivo dos modelos do sistema, obtendo-se, em cada passo do processo, uma descrição completa do cada passo do processo, uma descrição completa do sistema, com níveis de maior detalhe.sistema, com níveis de maior detalhe.

– Esta abordagem tem como principal objectivo a Esta abordagem tem como principal objectivo a redução da complexidade de sistemas de alguma redução da complexidade de sistemas de alguma dimensão a um número controlado de pequenos dimensão a um número controlado de pequenos módulos fáceis de manusear conceptualmente.módulos fáceis de manusear conceptualmente.

Page 9: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

9

2. Métodos Funcionais 2. Métodos Funcionais (5/5)(5/5)

Métodos funcionais #4Métodos funcionais #4

– A abordagem dos métodos funcionais tem, no entanto, A abordagem dos métodos funcionais tem, no entanto, duas grandes desvantagens:duas grandes desvantagens:

as decisões mais críticas relacionadas com a estrutura as decisões mais críticas relacionadas com a estrutura global do sistema têm que ser efectuadas muito cedo, no global do sistema têm que ser efectuadas muito cedo, no processo de desenvolvimento, numa altura em que o processo de desenvolvimento, numa altura em que o problema ainda não está bem percebido.problema ainda não está bem percebido.

uma vez que a decomposição é efectuada principalmente uma vez que a decomposição é efectuada principalmente no domínio funcional, as estruturas de dados mais no domínio funcional, as estruturas de dados mais importantes tendem a ser globais a todo o sistema, o que importantes tendem a ser globais a todo o sistema, o que coloca problemas significativos à fase de manutenção, coloca problemas significativos à fase de manutenção, quando as representações dos dados têm que ser quando as representações dos dados têm que ser alteradas (por alterações no ambiente ou nos requisitos alteradas (por alterações no ambiente ou nos requisitos do sistema).do sistema).

Page 10: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

10

3. Métodos OO 3. Métodos OO (1/13)(1/13)

Métodos orientados por objectos #1Métodos orientados por objectos #1

– Os métodos OO exploram uma abordagem Os métodos OO exploram uma abordagem (completamente diferente dos métodos funcionais) (completamente diferente dos métodos funcionais) inerentemente baseada no encapsulamento da inerentemente baseada no encapsulamento da informação e na abstracção dos tipos de dados.informação e na abstracção dos tipos de dados.

– A principal característica dos métodos OO é que a A principal característica dos métodos OO é que a estruturação conceptual das representações, podendo estruturação conceptual das representações, podendo ser realizada segundo uma abordagem ser realizada segundo uma abordagem bottom-upbottom-up, , deve modelar a estrutura do mundo real, no qual se deve modelar a estrutura do mundo real, no qual se baseia o problema em causa.baseia o problema em causa.

Page 11: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

11

3. Métodos OO 3. Métodos OO (2/13)(2/13)

Métodos orientados por objectos #2Métodos orientados por objectos #2

– Cada objecto é uma abstracção de uma entidade do mundo Cada objecto é uma abstracção de uma entidade do mundo real, com um estado interno e com uma interface (a única real, com um estado interno e com uma interface (a única parte do objecto visível externamente) que recebe os parte do objecto visível externamente) que recebe os estímulos do exterior e que responde segundo a dinâmica estímulos do exterior e que responde segundo a dinâmica interna do objecto.interna do objecto.

– Desta forma, uma rede de objectos cooperantes Desta forma, uma rede de objectos cooperantes conceptualiza um modelo natural do problema, estando conceptualiza um modelo natural do problema, estando todas as características dos objectos reais encapsuladas todas as características dos objectos reais encapsuladas nos seus modelos computacionais.nos seus modelos computacionais.

– Assim, qualquer alteração no ambiente só tem Assim, qualquer alteração no ambiente só tem consequências locais no interior de objectos particulares, consequências locais no interior de objectos particulares, não existindo a propagação para fora das fronteiras dos não existindo a propagação para fora das fronteiras dos objectos em causa.objectos em causa.

Page 12: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

12

3. Métodos OO 3. Métodos OO (3/13)(3/13)

Métodos orientados por objectos #3Métodos orientados por objectos #3

– Os métodos OO baseiam a especificação de sistemas Os métodos OO baseiam a especificação de sistemas nos meta-modelos orientados por objectos.nos meta-modelos orientados por objectos.

– A fase de concepção permite obter modelos A fase de concepção permite obter modelos arquitecturais menos dependentes da tecnologia de arquitecturais menos dependentes da tecnologia de implementação, sendo esta baseada no paradigma da implementação, sendo esta baseada no paradigma da programação orientada por objectos.programação orientada por objectos.

Page 13: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

13

3. Métodos OO 3. Métodos OO (4/13)(4/13)

Methods warMethods war

– A partir do início dos anos 90, iniciou-se uma A partir do início dos anos 90, iniciou-se uma verdadeira “corrida aos métodos” (verdadeira “corrida aos métodos” (methods warmethods war), ), surgindo uma quantidade enorme de métodos OO surgindo uma quantidade enorme de métodos OO como resposta ao descontentamento então existente como resposta ao descontentamento então existente relativamente aos métodos funcionais.relativamente aos métodos funcionais.

– Uma parte representativa dos métodos entretanto Uma parte representativa dos métodos entretanto propostos foi sumariamente compilada em [Hutt 1994] propostos foi sumariamente compilada em [Hutt 1994] pela pela OMGOMG ( (Object Management GroupObject Management Group). Esta ). Esta organização através do seu organização através do seu Object Analysis and Design Object Analysis and Design Special Interest GroupSpecial Interest Group dedica-se ao estudo de métodos dedica-se ao estudo de métodos orientados por objectos.orientados por objectos.

Page 14: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

14

3. Métodos OO 3. Métodos OO (5/13)(5/13)

Exemplos (OMT #1)Exemplos (OMT #1)

– O método O método object modeling techniqueobject modeling technique, concebido pela equipa , concebido pela equipa de J. Rumbaugh na de J. Rumbaugh na General ElectricGeneral Electric, define quatro fases para , define quatro fases para chegar à implementação do sistema, tipicamente em chegar à implementação do sistema, tipicamente em CC++ ++ ..

– A primeira fase gera uma especificação do sistema recorrendo A primeira fase gera uma especificação do sistema recorrendo a três vistas ortogonais:a três vistas ortogonais: o o modelo dos objectosmodelo dos objectos que corresponde a uma vista estática do que corresponde a uma vista estática do

sistema e que recorre aos conceitos de generalização, sistema e que recorre aos conceitos de generalização, especialização, classe, herança, agregação, decomposição e especialização, classe, herança, agregação, decomposição e relações para estruturar os objectos e definir as interdependências relações para estruturar os objectos e definir as interdependências entre elesentre eles

o o modelo dinâmicomodelo dinâmico que descreve o comportamento de cada objecto que descreve o comportamento de cada objecto recorrendo à linguagem recorrendo à linguagem StateChartsStateCharts

o o modelo funcionalmodelo funcional que recorre a DFDs para descrever as que recorre a DFDs para descrever as transformações de dados efectuadas pelos objectos, bem como as transformações de dados efectuadas pelos objectos, bem como as suas dependências funcionais e restriçõessuas dependências funcionais e restrições

Page 15: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

15

3. Métodos OO 3. Métodos OO (6/13)(6/13)

Exemplos (OMT #2)Exemplos (OMT #2)

– O modelo funcional realiza a integração das três vistas, uma O modelo funcional realiza a integração das três vistas, uma vez que as funções que representam as transformações dos vez que as funções que representam as transformações dos dados são invocadas como acções no modelo dinâmico e dados são invocadas como acções no modelo dinâmico e correspondem às operações dos objectos no modelo dos correspondem às operações dos objectos no modelo dos objectos.objectos.

– As três fases seguintes definem a arquitectura conceptual As três fases seguintes definem a arquitectura conceptual do sistema, refinam a concepção de cada tipo de objecto e do sistema, refinam a concepção de cada tipo de objecto e finalmente chegam à implementação dos objectos por finalmente chegam à implementação dos objectos por aplicação dos princípios da programação orientada por aplicação dos princípios da programação orientada por objectos.objectos.

– Este método garante uma boa continuidade dos modelos, Este método garante uma boa continuidade dos modelos, consegue controlar adequadamente a complexidade e consegue controlar adequadamente a complexidade e suporta objectos intrinsecamente concorrentes.suporta objectos intrinsecamente concorrentes.

Page 16: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

16

3. Métodos OO 3. Métodos OO (7/13)(7/13)

Exemplos (OOD #1)Exemplos (OOD #1)

– O método O método object-oriented designobject-oriented design, desenvolvido por , desenvolvido por Grady Booch na Grady Booch na RationalRational, não aborda a fase da análise, , não aborda a fase da análise, pelo que a definição do problema e a especificação dos pelo que a definição do problema e a especificação dos requisitos deverão ser efectuados recorrendo, por requisitos deverão ser efectuados recorrendo, por exemplo, a um outro método (funcional ou orientado exemplo, a um outro método (funcional ou orientado por objectos).por objectos).

– Após a fase de análise, este método realiza a Após a fase de análise, este método realiza a identificação dos objectos existentes no problema, bem identificação dos objectos existentes no problema, bem como as suas propriedades.como as suas propriedades.

– Esta fase é particularmente difícil e é muito dependente Esta fase é particularmente difícil e é muito dependente da forma como foi realizada a fase de análise.da forma como foi realizada a fase de análise.

Page 17: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

17

3. Métodos OO 3. Métodos OO (8/13)(8/13)

Exemplos (OOD #2)Exemplos (OOD #2)

– Segue-se a identificação das operações realizadas por cada Segue-se a identificação das operações realizadas por cada objecto e das relações com os outros objectos, integrando objecto e das relações com os outros objectos, integrando cada objecto na estrutura da soluçãocada objecto na estrutura da solução

– Seguidamente define-se a especificação para cada objecto, Seguidamente define-se a especificação para cada objecto, através da caracterização da sua interface com o ambiente.através da caracterização da sua interface com o ambiente.

– Por último, implementam-se os objectos codificando os Por último, implementam-se os objectos codificando os seus comportamento e os seus estados internosseus comportamento e os seus estados internos

– Por vezes, considera-se o Por vezes, considera-se o OOD OOD como um conjunto de como um conjunto de técnicas e notações, em vez de uma metodologia, uma vez técnicas e notações, em vez de uma metodologia, uma vez que não é fácil identificar qual o modelo do processo que que não é fácil identificar qual o modelo do processo que lhe está subjacente.lhe está subjacente.

Page 18: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

18

3. Métodos OO 3. Métodos OO (9/13)(9/13)

Exemplos (OOSE #1)Exemplos (OOSE #1)

– O método O método object-oriented software engineeringobject-oriented software engineering (também (também designado de designado de ObjectoryObjectory), concebido pela equipa de Ivar ), concebido pela equipa de Ivar Jacobson na Jacobson na Objective SystemsObjective Systems, baseia todo o seu , baseia todo o seu processo de desenvolvimento nas funcionalidades processo de desenvolvimento nas funcionalidades oferecidas pelo sistema através da sua interface com o oferecidas pelo sistema através da sua interface com o mundo envolvente (mundo envolvente (use case-driven approachuse case-driven approach))

– Como o Como o OOSEOOSE define os modelos de análise e de define os modelos de análise e de concepção com base em sequências de interacção que os concepção com base em sequências de interacção que os utilizadores estabelecem com o sistema, organizadas em utilizadores estabelecem com o sistema, organizadas em cenários típicos de utilização (cenários típicos de utilização (usage scenariosusage scenarios), são ), são produzidos sistemas mais robustos e adaptativos.produzidos sistemas mais robustos e adaptativos.

Page 19: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

19

3. Métodos OO 3. Métodos OO (10/13)(10/13)

Exemplos (OOSE #2)Exemplos (OOSE #2)

– Este método define cinco fases:Este método define cinco fases: análise de requisitosanálise de requisitos, em que se caracteriza a utilização do , em que se caracteriza a utilização do

sistema e se identificam os vários actores que com ele se sistema e se identificam os vários actores que com ele se relacionamrelacionam

análise de robustezanálise de robustez, em que se constrói o primeiro modelo OO do , em que se constrói o primeiro modelo OO do sistema baseado em objectos do tipo controlo, interface e sistema baseado em objectos do tipo controlo, interface e entidadeentidade

concepçãoconcepção, em que se definem as interfaces dos objectos e a , em que se definem as interfaces dos objectos e a semântica das operações, refinando os modelos anteriores no semântica das operações, refinando os modelos anteriores no sentido da plataforma de implementação através da definição de sentido da plataforma de implementação através da definição de packagespackages

implementaçãoimplementação, em que se sintetizam os , em que se sintetizam os packagespackages para a para a plataforma de implementação recorrendo a linguagens, plataforma de implementação recorrendo a linguagens, normalmente, OO;normalmente, OO;

testeteste, em que se validam permanentemente todas as decisões , em que se validam permanentemente todas as decisões tomadas ao longo do processo de desenvolvimentotomadas ao longo do processo de desenvolvimento

Page 20: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

20

3. Métodos OO 3. Métodos OO (11/13)(11/13)

Outros exemplosOutros exemplos

– OOA/D:OOA/D:  object-oriented analysis and designobject-oriented analysis and design da da Object Object InternationalInternational [Coad  [Coad et al.et al. 1991a, Coad  1991a, Coad et al.et al. 1991b] 1991b]

– Fusion: object-oriented developmentFusion: object-oriented development da da Hewlett-Hewlett-PackardPackard [Coleman  [Coleman et al.et al. 1994] 1994]

– SOMA: semantic object modeling approachSOMA: semantic object modeling approach dada BIS BIS Information SystemsInformation Systems [Graham 1993][Graham 1993]

– OOIEOOIE  object-oriented information engineeringobject-oriented information engineering dada James James Martin and Co.Martin and Co. e e dada IntellicorpIntellicorp [Martin  [Martin et al.et al. 1993] 1993]

– Shlaer/MellorShlaer/Mellor: : object-oriented analysisobject-oriented analysis dada Project Project TechnologyTechnology [Shlaer  [Shlaer et al.et al. 1992] 1992]

– OO/SSADM: object oriented SSADMOO/SSADM: object oriented SSADM dada CCTACCTA [Robinson [Robinson et al.et al. 1994] 1994]

Page 21: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

21

3. Métodos OO 3. Métodos OO (12/13)(12/13)

UML #1UML #1

– Os métodos Os métodos OMTOMT, , OODOOD e e OOSEOOSE foram destacados por se foram destacados por se terem tornado inequivocamente os mais conhecidos a nível terem tornado inequivocamente os mais conhecidos a nível mundial e como tal terem estado na base duma notação mundial e como tal terem estado na base duma notação unificada, normalizada pela unificada, normalizada pela OMGOMG, designada de , designada de UMLUML: : unified modeling language.unified modeling language.

– a linguagem a linguagem UMLUML:: suporta objectos e classes e muitos tipos de associações entre suporta objectos e classes e muitos tipos de associações entre

eles, como a agregação, dependência, herança, instanciação e eles, como a agregação, dependência, herança, instanciação e outrasoutras

permite a modelação de cenários para descrever, de uma permite a modelação de cenários para descrever, de uma forma detalhada, os requisitos comportamentais do sistemaforma detalhada, os requisitos comportamentais do sistema

recorre a recorre a StateChartsStateCharts para modelar o ciclo de vida dos objectos para modelar o ciclo de vida dos objectos dá acesso à meta-classificação de elementos para definir novos dá acesso à meta-classificação de elementos para definir novos

tipos a incorporar no modelotipos a incorporar no modelo

Page 22: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

22

3. Métodos OO 3. Métodos OO (13/13)(13/13)

UML #2UML #2

– Desta forma, a linguagem Desta forma, a linguagem UMLUML não define um método, não define um método, mas “limita-se” a disponibilizar uma notação mas “limita-se” a disponibilizar uma notação normalizada que qualquer método OO pode utilizar, normalizada que qualquer método OO pode utilizar, podendo ser a solução para a aborrecida confusão de podendo ser a solução para a aborrecida confusão de notações e linguagens próprias resultantes da enorme notações e linguagens próprias resultantes da enorme quantidade de métodos OO existentes actualmente.quantidade de métodos OO existentes actualmente.

– Uma vez que a empresa Uma vez que a empresa RationalRational foi a grande promotora foi a grande promotora da definição da linguagem da definição da linguagem UMLUML, é frequente designar , é frequente designar numericamente a versão numericamente a versão RationalRational da linguagem da linguagem UMLUML, em , em vez da correspondente versão numérica definida pela vez da correspondente versão numérica definida pela OMG OMG (a versão (a versão RationalRational UML v 1.1UML v 1.1 corresponde à versão corresponde à versão OMGOMG UML v 1.0UML v 1.0).).

Page 23: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

23

4. Características OO 4. Características OO (1/24)(1/24)

Principais conceitos associados aos objectosPrincipais conceitos associados aos objectos– Identidade,Identidade,– Classificação,Classificação,– Abstracção,Abstracção,– Encapsulamento, Encapsulamento, – Mensagens,Mensagens,– Polimorfismo,Polimorfismo,– Herança e hierarquia,Herança e hierarquia,– Agregação e composição.Agregação e composição.

Page 24: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

24

4. Características OO 4. Características OO (2/24)(2/24)

- simplicidade na interface -- simplicidade na interface -

Page 25: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

25

4. Características OO 4. Características OO (3/24)(3/24)

- abstracção -- abstracção -

Page 26: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

26

4. Características OO 4. Características OO (4/24) (4/24)

AbstracçãoAbstracção– A abstracção consiste na selecção dos aspectos essenciais A abstracção consiste na selecção dos aspectos essenciais

duma entidade, ignorando aqueles tidos por irrelevantes.duma entidade, ignorando aqueles tidos por irrelevantes.– O analista do sistema deve ter conhecimento dos vários O analista do sistema deve ter conhecimento dos vários

aspectos duma dada entidade, para depois escolher aspectos duma dada entidade, para depois escolher aqueles que lhe pareçam importantes para o sistema a aqueles que lhe pareçam importantes para o sistema a desenvolver.desenvolver.

– A escolha de quais as propriedades essenciais depende do A escolha de quais as propriedades essenciais depende do propósito do sistema. Aquilo que numa situação pode ser propósito do sistema. Aquilo que numa situação pode ser relevante, pode noutras ser completamente indiferente.relevante, pode noutras ser completamente indiferente.

– Quando se usa abstracção, está a admitir-se que o objecto Quando se usa abstracção, está a admitir-se que o objecto em causa é complexo. Não se pretende modelar esse em causa é complexo. Não se pretende modelar esse sistema na totalidade, mas antes escolher parte das suas sistema na totalidade, mas antes escolher parte das suas características. características.

– Trata-se duma técnica muito importante para permitir Trata-se duma técnica muito importante para permitir lidar com a complexidade dos sistemas.lidar com a complexidade dos sistemas.

Page 27: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

27

4. Características OO 4. Características OO (5/24)(5/24)

- encapsulamento -- encapsulamento -

Page 28: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

28

4. Características OO 4. Características OO (6/24)(6/24)

EncapsulamentoEncapsulamento– O encapsulamento consiste em separar o comportamento O encapsulamento consiste em separar o comportamento

externo dum objecto dos seus pormenores de externo dum objecto dos seus pormenores de implementação.implementação.

– A abstracção permite que o projectista se concentre naquilo A abstracção permite que o projectista se concentre naquilo que deve ser feito. O encapsulamento possibilita que se que deve ser feito. O encapsulamento possibilita que se façam alterações num objecto, sem interferência nos façam alterações num objecto, sem interferência nos restantes.restantes.

– Cada classe deve ser composta por duas partes: uma Cada classe deve ser composta por duas partes: uma interface e uma implementação.interface e uma implementação.

– O encapsulamento é o processo de esconder as propriedades O encapsulamento é o processo de esconder as propriedades dum objecto que não contribuem para a sua caracterização. dum objecto que não contribuem para a sua caracterização.

– O encapsulamento evita que sejam criadas O encapsulamento evita que sejam criadas interdependências num programa, que depois obrigariam a interdependências num programa, que depois obrigariam a grandes reformulações, quando se pretendesse proceder a grandes reformulações, quando se pretendesse proceder a alterações, nos requisitos do sistema.alterações, nos requisitos do sistema.

Page 29: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

29

4. Características OO 4. Características OO (7/24)(7/24)

- mecanismos de interacção -- mecanismos de interacção -

Page 30: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

30

4. Características OO 4. Características OO (8/24)(8/24)

Agregação e composiçãoAgregação e composição– As relações inter-objectos que se expressam, durante a As relações inter-objectos que se expressam, durante a

utilização do sistema, através da troca de mensagens entre utilização do sistema, através da troca de mensagens entre eles, designam-se por eles, designam-se por associaçõesassociações..

– Quando um objecto recorre aos serviços dum outro, deve Quando um objecto recorre aos serviços dum outro, deve estabelecer-se entre eles uma associação.estabelecer-se entre eles uma associação.

– A agregação (composição) representa uma forma especial A agregação (composição) representa uma forma especial de associação, que se verifica quando um objecto contém, de associação, que se verifica quando um objecto contém, física ou logicamente, outros. física ou logicamente, outros.

– Um agregado é mais do que a simples soma das suas Um agregado é mais do que a simples soma das suas partes.partes.

– Um agregado tem os seus próprios atributos e operações Um agregado tem os seus próprios atributos e operações que não têm de estar directamente relacionados com as que não têm de estar directamente relacionados com as partes. partes.

– Apesar de ser um conceito intuitivo, a agregação nem Apesar de ser um conceito intuitivo, a agregação nem sempre é bem utilizada na modelação de sistemas. sempre é bem utilizada na modelação de sistemas.

Page 31: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

31

4. Características OO 4. Características OO (9/24)(9/24)

- classificação -- classificação -

Page 32: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

32

4. Características OO 4. Características OO (10/24)(10/24)

- classe -- classe -

Page 33: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

33

4. Características OO 4. Características OO (11/24)(11/24)

- critério de classificação -- critério de classificação -

Page 34: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

34

4. Características OO 4. Características OO (12/24)(12/24)

ClassificaçãoClassificação– A classificação significa que os objectos com a mesma A classificação significa que os objectos com a mesma

estrutura de dados e o mesmo comportamento são estrutura de dados e o mesmo comportamento são agrupados numa mesma classe. agrupados numa mesma classe.

– Um atributo é um elemento de modelação que descreve Um atributo é um elemento de modelação que descreve uma instância, caracterizando algo de importante e uma instância, caracterizando algo de importante e significativo acerca da natureza dessa instância. significativo acerca da natureza dessa instância.

– Uma operação é uma acção ou transformação Uma operação é uma acção ou transformação desempenhada por um objecto ou a que o objecto se desempenhada por um objecto ou a que o objecto se sujeita. sujeita.

– Uma Uma classeclasse (de objectos) é uma abstracção que, para uma (de objectos) é uma abstracção que, para uma dada aplicação, define apenas as propriedade mais dada aplicação, define apenas as propriedade mais relevantes e ignora as restantes. relevantes e ignora as restantes.

– A escolha de quais as classes com relevância para uma A escolha de quais as classes com relevância para uma determinada aplicação é arbitrária e depende fortemente determinada aplicação é arbitrária e depende fortemente desta.desta.

Page 35: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

35

4. Características OO 4. Características OO (13/24)(13/24)

- herança -- herança -

Page 36: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

36

4. Características OO 4. Características OO (14/24)(14/24)

- hierarquia -- hierarquia -

Page 37: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

37

4. Características OO 4. Características OO (15/24)(15/24)

Herança e hierarquiaHerança e hierarquia– A herança é definida como o mecanismo que facilita a A herança é definida como o mecanismo que facilita a

construção de novas classes (subclasses) a partir de construção de novas classes (subclasses) a partir de outras classes (superclasses) e permite a outras classes (superclasses) e permite a especialização e a generalização de componentes.especialização e a generalização de componentes.

– A herança é um mecanismo valioso e poderoso que A herança é um mecanismo valioso e poderoso que facilita a reutilização e permite expressar os aspectos facilita a reutilização e permite expressar os aspectos comuns entre classes.comuns entre classes.

– A herança inclui quatro aspectos principais:A herança inclui quatro aspectos principais: Uma subclasse herda os atributos das suas superclasses.Uma subclasse herda os atributos das suas superclasses. Uma subclasse herda as operações das suas superclasses.Uma subclasse herda as operações das suas superclasses. Uma subclasse pode adicionar novos atributos àqueles Uma subclasse pode adicionar novos atributos àqueles

existentes nas superclasses.existentes nas superclasses. Uma subclasse, relativamente aos métodos definidos nas Uma subclasse, relativamente aos métodos definidos nas

superclasses, pode reescrevê-los ou adicionar novos.superclasses, pode reescrevê-los ou adicionar novos.

Page 38: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

38

4. Características OO 4. Características OO (16/24)(16/24)

- objecto -- objecto -

Page 39: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

39

4. Características OO 4. Características OO (17/24)(17/24)

IdentidadeIdentidade– A identidade significa que os dados do sistema podem A identidade significa que os dados do sistema podem

ser quantificados em entidades discretas, a que se dá ser quantificados em entidades discretas, a que se dá o nome de objectos.o nome de objectos.

– Cada objecto tem a sua própria identidade, o que Cada objecto tem a sua própria identidade, o que significa que dois objectos são distintos, mesmo que significa que dois objectos são distintos, mesmo que tenham todos os seus atributos iguais. tenham todos os seus atributos iguais.

– O termo identidade pressupõe que cada objecto é O termo identidade pressupõe que cada objecto é distinto pela sua própria existência e não pelo valor distinto pela sua própria existência e não pelo valor dos seus atributos.dos seus atributos.

– Os objectos podem ser coisas reais (tangíveis), como Os objectos podem ser coisas reais (tangíveis), como maçãs, cães, televisores, impressoras, ou máquinas, maçãs, cães, televisores, impressoras, ou máquinas, mas também podem ser entidades puramente mas também podem ser entidades puramente conceptuais como contas bancárias, casamentos, ou conceptuais como contas bancárias, casamentos, ou listas.listas.

Page 40: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

40

4. Características OO 4. Características OO (18/24)(18/24)

- modularidade -- modularidade -

Page 41: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

41

4. Características OO 4. Características OO (19/24)(19/24)

- persistência -- persistência -

Page 42: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

42

4. Características OO 4. Características OO (20/24)(20/24)

- concorrência -- concorrência -

Page 43: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

43

4. Características OO 4. Características OO (21/24)(21/24)

- tipos -- tipos -

Page 44: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

44

4. Características OO 4. Características OO (22/24)(22/24)

- classe vs. objecto -- classe vs. objecto -

Page 45: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

45

4. Características OO 4. Características OO (23/24)(23/24)

MensagensMensagens– Uma acção é iniciada, em linguagens orientadas ao objecto, Uma acção é iniciada, em linguagens orientadas ao objecto,

através da transmissão duma mensagem ao objecto através da transmissão duma mensagem ao objecto responsável por essa acção. responsável por essa acção.

– Se um objecto aceita uma mensagem que lhe é enviada, Se um objecto aceita uma mensagem que lhe é enviada, está a assumir o compromisso de desempenhar essa está a assumir o compromisso de desempenhar essa operação.operação.

– Todos os objectos duma determinada classe, como resposta Todos os objectos duma determinada classe, como resposta a uma mensagem do mesmo tipo, usam o mesmo método. a uma mensagem do mesmo tipo, usam o mesmo método. 

– Os sistemas orientados ao objecto pressupõem um modelo Os sistemas orientados ao objecto pressupõem um modelo de comunicação do tipo cliente/servidor. de comunicação do tipo cliente/servidor.

– Este modelo de comunicação pressupõe uma dependência Este modelo de comunicação pressupõe uma dependência reduzida entre o cliente e o servidor, no sentido deste não reduzida entre o cliente e o servidor, no sentido deste não precisar dum conhecimento prévio de quais os clientes que precisar dum conhecimento prévio de quais os clientes que a ele recorrem para desempenhar uma operação em que é a ele recorrem para desempenhar uma operação em que é especialista. especialista.

Page 46: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

46

4. Características OO 4. Características OO (24/24)(24/24)

PolimorfismoPolimorfismo– O polimorfismo significa que a mesma operação pode O polimorfismo significa que a mesma operação pode

apresentar comportamentos distintos para classes apresentar comportamentos distintos para classes diferentes. diferentes.

– Se uma dada operação é polimórfica, então existe mais Se uma dada operação é polimórfica, então existe mais do que um método que a implementa. do que um método que a implementa.

– Em termos práticos, e segundo uma outra perspectiva, Em termos práticos, e segundo uma outra perspectiva, o polimorfismo significa também que o emissor duma o polimorfismo significa também que o emissor duma dada mensagem não precisa de conhecer a classe a dada mensagem não precisa de conhecer a classe a que pertence o objecto receptor.que pertence o objecto receptor.

– Outro conceito relacionado com o polimorfismo é a Outro conceito relacionado com o polimorfismo é a sobreposição de operadoressobreposição de operadores (operator overloading) (operator overloading) que se refere à possibilidade de se usar o mesmo que se refere à possibilidade de se usar o mesmo símbolo para propósitos distintos, consoante o símbolo para propósitos distintos, consoante o contexto de utilização.contexto de utilização.

Page 47: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

47

5. Objectos 5. Objectos (1/11)(1/11)

Visão informal dos objectosVisão informal dos objectos– A orientação ao objecto é uma técnica para modelação A orientação ao objecto é uma técnica para modelação

de sistemas, que faculta um conjunto significativo de de sistemas, que faculta um conjunto significativo de conceitos e mecanismos para esse fim.conceitos e mecanismos para esse fim.

– Quando se recorre ao paradigma dos objectos para Quando se recorre ao paradigma dos objectos para modelar um dado sistema, passa-se a olhar para este modelar um dado sistema, passa-se a olhar para este como um conjunto de objectos que interagem entre si.como um conjunto de objectos que interagem entre si.

– Uma vez que, no dia-a-dia, as pessoas também lidam Uma vez que, no dia-a-dia, as pessoas também lidam com objectos, é relativamente simples pensar de com objectos, é relativamente simples pensar de forma semelhante quando se pretende construir um forma semelhante quando se pretende construir um modelo. modelo.

– Um sistema, no âmbito da modelação por objectos, é Um sistema, no âmbito da modelação por objectos, é composto por vários objectos, que correspondem a composto por vários objectos, que correspondem a entidades reais. entidades reais.

Page 48: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

48

5. Objectos 5. Objectos (2/11)(2/11)

Visão informal dos objectosVisão informal dos objectos– Um objecto contém um conjunto de dados Um objecto contém um conjunto de dados

(informação), que se designam atributos, que o (informação), que se designam atributos, que o descrevem de alguma forma. descrevem de alguma forma.

– Para manipular estes atributos, devem definir-se as Para manipular estes atributos, devem definir-se as operações que afectam ou permitem usar aqueles. operações que afectam ou permitem usar aqueles.

– A única parte do objecto visível do exterior são as suas A única parte do objecto visível do exterior são as suas operações, mais propriamente as respectivas operações, mais propriamente as respectivas interfaces, estando todo o resto escondido. interfaces, estando todo o resto escondido.

– A relação ou associação entre os objectos também tem A relação ou associação entre os objectos também tem de ser modelada. de ser modelada.

– Podem existir outros tipos de relação entre os Podem existir outros tipos de relação entre os objectos, nomeadamente a composição ou a objectos, nomeadamente a composição ou a agregação. agregação.

Page 49: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

49

5. Objectos 5. Objectos (3/11)(3/11)

Visão informal dos objectosVisão informal dos objectos– O comportamento temporal do modelo dos objectos é O comportamento temporal do modelo dos objectos é

conseguido, devido às relações dinâmicas entre conseguido, devido às relações dinâmicas entre objectos, pois estas permitem que os objectos enviem objectos, pois estas permitem que os objectos enviem estímulos (mensagens) uns aos outros. estímulos (mensagens) uns aos outros.

– Um objecto, ao receber uma mensagem, realiza uma Um objecto, ao receber uma mensagem, realiza uma determinada operação e pode provocar novas determinada operação e pode provocar novas mensagens em outros objectos. mensagens em outros objectos.

– Os objectos só respondem às mensagens para as quais Os objectos só respondem às mensagens para as quais estão preparados. estão preparados.

– Os pedidos que são feitos a um objecto podem ou não Os pedidos que são feitos a um objecto podem ou não ser satisfeitos, dependendo este facto das operações ser satisfeitos, dependendo este facto das operações que aquele está habilitado a desempenhar.que aquele está habilitado a desempenhar.

Page 50: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

50

5. Objectos 5. Objectos (4/11)(4/11)

Definição formal de objectoDefinição formal de objecto– ObjectoObjecto: Tudo aquilo que se apresenta aos sentidos; : Tudo aquilo que se apresenta aos sentidos;

aquilo que se apresenta à vista. (...) Em sentido geral, aquilo que se apresenta à vista. (...) Em sentido geral, qualquer coisa; peça, artigo (...).qualquer coisa; peça, artigo (...).Grande Enciclopédia Portuguesa e Brasileira (1975). EGrande Enciclopédia Portuguesa e Brasileira (1975). Editorial Enciclopédia, Lisboa e Rio ditorial Enciclopédia, Lisboa e Rio de Janeiro.de Janeiro.

– ObjectoObjecto: Do latim : Do latim objectumobjectum, do verbo , do verbo objicereobjicere (lançar (lançar ou pôr em frente, propor, expor, opor). ou pôr em frente, propor, expor, opor). Etimologicamente, objecto é o que está à frente a, o Etimologicamente, objecto é o que está à frente a, o que se opõe ao sujeito. Por extensão, significa o que é, que se opõe ao sujeito. Por extensão, significa o que é, as coisas. Palavra do vocabulário comum que se as coisas. Palavra do vocabulário comum que se restringe em sentidos muito precisos nas diversas restringe em sentidos muito precisos nas diversas disciplinas científicas e filosóficas (...).disciplinas científicas e filosóficas (...).Enciclopédia Luso-Brasileira de Cultura (1973).Enciclopédia Luso-Brasileira de Cultura (1973).Verbo Editora, Lisboa, Portugal.Verbo Editora, Lisboa, Portugal.

Page 51: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

51

5. Objectos 5. Objectos (5/11)(5/11)

Definição formal de objectoDefinição formal de objecto– O conceito de objecto, no projecto de software, surgiu, O conceito de objecto, no projecto de software, surgiu,

pela primeira vez, num construtor da linguagem de pela primeira vez, num construtor da linguagem de programação Simula, nos anos 60.programação Simula, nos anos 60.

– Mais recentemente, este conceito serviu de base a Mais recentemente, este conceito serviu de base a diversas linguagens de programação orientadas ao diversas linguagens de programação orientadas ao objecto (SmallTalk, ObjectiveC, Eiffel, C++ e Java), bem objecto (SmallTalk, ObjectiveC, Eiffel, C++ e Java), bem como a outras linguagens não orientadas ao objecto (Ada como a outras linguagens não orientadas ao objecto (Ada e Modula-2). e Modula-2).

– Diversos métodos de análise e concepção fizeram também Diversos métodos de análise e concepção fizeram também uso, como elemento basilar, do conceito de objecto.  uso, como elemento basilar, do conceito de objecto.  

– Um objecto pode ser visto como uma entidade, cujo Um objecto pode ser visto como uma entidade, cujo comportamento se caracteriza pelo conjunto de acções comportamento se caracteriza pelo conjunto de acções que executa e que requer a outros objectos.que executa e que requer a outros objectos.

Page 52: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

52

5. Objectos 5. Objectos (6/11)(6/11)

Definição formal de objectoDefinição formal de objecto– We defined an object as a concept, abstraction or thing We defined an object as a concept, abstraction or thing

with crisp boundaries and meaning for the problem at with crisp boundaries and meaning for the problem at hand. Objects serve two purposes: They promote hand. Objects serve two purposes: They promote understanding of the real world and provide a practical understanding of the real world and provide a practical basis for computer implementation. Decomposition of a basis for computer implementation. Decomposition of a problem into objects depends on judgment and the problem into objects depends on judgment and the nature of the problem.nature of the problem.James Rumbaugh, 1991.James Rumbaugh, 1991.

– An object represents an individual, identifiable item, unit An object represents an individual, identifiable item, unit or entity, either real or abstract, with a well defined role or entity, either real or abstract, with a well defined role in the problem domain. An object may be recognized by in the problem domain. An object may be recognized by the data it carries, by its behavior (i.e. how it responds the data it carries, by its behavior (i.e. how it responds to events in its environment), and by the processing that to events in its environment), and by the processing that it performs.it performs.Mark M.Mark M. Smith e Stephen R.Smith e Stephen R. TockeyTockey, 1988., 1988.

Page 53: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

53

5. Objectos 5. Objectos (7/11)(7/11)

Definição formal de objectoDefinição formal de objecto– An object has state, behavior, and identity; the structure An object has state, behavior, and identity; the structure

and behavior of similar objects are defined in their and behavior of similar objects are defined in their

common class.common class.GradyGrady Booch, 1991.Booch, 1991.

– An object is a model of a real-world entity or a software An object is a model of a real-world entity or a software

solution entity that combines data and operations in such solution entity that combines data and operations in such

a way that data are encapsulated in the object and are a way that data are encapsulated in the object and are

accessed through the operations. An object thus provides accessed through the operations. An object thus provides

operations for other objects, and may in turn also require operations for other objects, and may in turn also require

operations of another object. An object may have state, operations of another object. An object may have state,

either explicitly to provide control or implicitly in terms of either explicitly to provide control or implicitly in terms of

the value of the internal data. An object may be a class or the value of the internal data. An object may be a class or

an instance created as a parameterisation of a class.an instance created as a parameterisation of a class.PeterPeter J. J. Robinson, 1992.Robinson, 1992.

Page 54: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

54

5. Objectos 5. Objectos (8/11)(8/11)

Características dos objectosCaracterísticas dos objectos– Encapsula informação.Encapsula informação.– Indica o tipo dos seus atributos.Indica o tipo dos seus atributos.– Disponibiliza operações a outros objectos.Disponibiliza operações a outros objectos.– Pode requerer e usar operações doutros objectos.Pode requerer e usar operações doutros objectos.– Tem visibilidade reduzida dos outros objectos.Tem visibilidade reduzida dos outros objectos.– Pode decompor-se noutros (sub-)objectos que, Pode decompor-se noutros (sub-)objectos que,

conjuntamente, exibem o mesmo comportamento.conjuntamente, exibem o mesmo comportamento.– É um modelo duma entidade real ou uma entidade É um modelo duma entidade real ou uma entidade

relevante para a solução final em software (ou relevante para a solução final em software (ou hardware).hardware).

– É referido pelo seu nome.É referido pelo seu nome.– Pode ser uma instância duma classe.Pode ser uma instância duma classe.– Pode implementar-se com um tipo abstracto de dados.Pode implementar-se com um tipo abstracto de dados.– Pode ter estado (visto como uma máquina de estados).Pode ter estado (visto como uma máquina de estados).

Page 55: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

55

5. Objectos 5. Objectos (9/11)(9/11)

Perspectivas de modelação dos objectosPerspectivas de modelação dos objectos

comportamento

(quando)

processos

(como)

dados

(o quê)

– Um objecto inclui, Um objecto inclui, em em simultâneosimultâneo, as três , as três perspectivas fundamentais sob perspectivas fundamentais sob as quais um sistema é, as quais um sistema é, actualmente, modelado:actualmente, modelado:

– os dadosos dados que incorpora, que incorpora, – o comportamentoo comportamento dinâmico dinâmico

que exibe, eque exibe, e– os processosos processos que realiza que realiza..

Page 56: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

56

5. Objectos 5. Objectos (10/11)(10/11)

Relação entre perspectivas de modelaçãoRelação entre perspectivas de modelação

comportamento processos

dadosNúmeroSérie

EmPausa

PapelDisponívelTipoDePapel

ImprimirFolha

ColocarPapelCancelarImpressão

Page 57: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

57

5. Objectos 5. Objectos (11/11)(11/11)

Aspectos dum objecto (sistema)Aspectos dum objecto (sistema)– Dados ou estruturaDados ou estrutura: Descrevem as características : Descrevem as características

estáticas do objecto, nomeadamente os seus atributos estáticas do objecto, nomeadamente os seus atributos relevantes para a aplicação em causa.relevantes para a aplicação em causa.

– Controlo ou comportamento globalControlo ou comportamento global: Indica as : Indica as dependências temporais e dinâmicas entre a ocorrência dependências temporais e dinâmicas entre a ocorrência de eventos (externos) e a execução das acções internas, de eventos (externos) e a execução das acções internas, o que implica alterações no estado e nos dados do o que implica alterações no estado e nos dados do objecto.objecto.

– Processos ou comportamento localProcessos ou comportamento local: Descrevem as : Descrevem as actividades internas do objecto, em função dos actividades internas do objecto, em função dos estímulos externos a que está sujeito.estímulos externos a que está sujeito.

Os dados dum objecto são, normalmente, a primeira Os dados dum objecto são, normalmente, a primeira perspectiva a ser considerada, pois são considerados perspectiva a ser considerada, pois são considerados mais estáveis que as funções ou o comportamento.mais estáveis que as funções ou o comportamento.

Page 58: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

58

6. UML 6. UML (1/32)(1/32)

O que é UMLO que é UML– UML é uma linguagem para expressar UML é uma linguagem para expressar

a funcionalidade, a estrutura e as a funcionalidade, a estrutura e as relações de sistemas complexos. relações de sistemas complexos.

– Standard OMG (Object Modeling Standard OMG (Object Modeling Group) para modelação de sistemas.Group) para modelação de sistemas.

– Em 2001, era previsível que se tornasse um standard Em 2001, era previsível que se tornasse um standard ISO.ISO.

– A definição de UML inclui o respectivo meta-modelo, o A definição de UML inclui o respectivo meta-modelo, o que permite conhecer, caso se use uma linguagem que permite conhecer, caso se use uma linguagem formal para o definir, a respectiva semântica. formal para o definir, a respectiva semântica.

– O meta-modelo UML não está definido de forma formal, O meta-modelo UML não está definido de forma formal, pois a sintaxe dos construtores está especificada numa pois a sintaxe dos construtores está especificada numa linguagem precisa, mas a respectiva semântica só foi linguagem precisa, mas a respectiva semântica só foi descrita em inglês. descrita em inglês.

– UML pode classificar-se, actualmente, como semi-UML pode classificar-se, actualmente, como semi-formal.formal.

Page 59: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

59

6. UML 6. UML (2/32)(2/32)

Origem e evolução da notação UMLOrigem e evolução da notação UML

OMT (Rumbaugh et al.)

Booch

OOSE(Jacobson et al.)

UML0.9

1996

Catalysis ROOM etc.

UML1.1

Nov. 1997

UML2.0

2001?

Page 60: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

60

6. UML 6. UML (3/32)(3/32)

DiagramasDiagramas– A notação UML é composta por diversos diagramas que A notação UML é composta por diversos diagramas que

permitem descrever os aspectos mais relevantes dos permitem descrever os aspectos mais relevantes dos sistemas a implementar segundo a abordagem orientada ao sistemas a implementar segundo a abordagem orientada ao objecto. objecto.

– Cada um dos diagramas foca uma dada vista do sistema e Cada um dos diagramas foca uma dada vista do sistema e propositadamente enfatiza alguns aspectos e negligencia propositadamente enfatiza alguns aspectos e negligencia outros.outros.

– A notação UML é independente da linguagem de A notação UML é independente da linguagem de programação e do processo de desenvolvimento adoptados.programação e do processo de desenvolvimento adoptados.

– UML está dotada dum mecanismo de extensão UML está dotada dum mecanismo de extensão (estereótipos) que facilita a sua adaptação a situações que (estereótipos) que facilita a sua adaptação a situações que apresentem mecanismos não previstos inicialmente na apresentem mecanismos não previstos inicialmente na notação. notação.

– Um Um estereótipoestereótipo é a classe duma entidade no meta-modelo é a classe duma entidade no meta-modelo UML.UML.

Page 61: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

61

6. UML 6. UML (4/32)(4/32)

DiagramasDiagramas– No contexto dos sistemas embebidos, os seguintes No contexto dos sistemas embebidos, os seguintes

diagramas UML foram considerados indispensáveis diagramas UML foram considerados indispensáveis para especificar e documentar os vários aspectos que para especificar e documentar os vários aspectos que importa considerar na modelação dum sistema importa considerar na modelação dum sistema complexo:complexo:

Diagramas de casos de uso (use case diagrams).Diagramas de casos de uso (use case diagrams). Diagramas de classes (class diagrams).Diagramas de classes (class diagrams). Diagramas de objectos (object diagrams).Diagramas de objectos (object diagrams). Diagramas de interacção (interaction diagrams).Diagramas de interacção (interaction diagrams). Diagramas de estados (state diagrams).Diagramas de estados (state diagrams).

Page 62: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

62

6. UML 6. UML (5/32)(5/32)

Propósitos dos diagramasPropósitos dos diagramas– Diagrama de casos de usoDiagrama de casos de uso: Mostrar um conjunto de casos de : Mostrar um conjunto de casos de

uso e de actores e as respectivas relações. São importantes uso e de actores e as respectivas relações. São importantes para organizar e modelar as funcionalidades do sistema.para organizar e modelar as funcionalidades do sistema.

– Diagrama de classesDiagrama de classes: Apresentar um conjunto de conceitos, : Apresentar um conjunto de conceitos, tipos e classes e respectivas relações. tipos e classes e respectivas relações.

– Diagrama de objectosDiagrama de objectos: Exibir um conjunto de instâncias e a : Exibir um conjunto de instâncias e a forma como elas se relacionam. Como sucede com os forma como elas se relacionam. Como sucede com os diagramas de classes, a estrutura estática do sistemas é diagramas de classes, a estrutura estática do sistemas é mostrada, mas a ênfase é colocada em configurações mostrada, mas a ênfase é colocada em configurações estáticas num dado instante.estáticas num dado instante.

– Diagrama de interacçãoDiagrama de interacção: Revelar como vários objectos : Revelar como vários objectos colaboram (trocam mensagens) num dado caso de uso.colaboram (trocam mensagens) num dado caso de uso.

– Diagrama de estadosDiagrama de estados: Especificar o comportamento dum : Especificar o comportamento dum objecto, englobando, potencialmente, muitos casos de uso. objecto, englobando, potencialmente, muitos casos de uso.

Page 63: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

63

6. UML 6. UML (6/32)(6/32)

Diagramas de casos de usoDiagramas de casos de uso– Elementos básicos: Elementos básicos:

casos de usocasos de uso (as funcionalidades que esse sistema deve (as funcionalidades que esse sistema deve desempenhar)desempenhar)

actoresactores (o que existe fora do sistema). (o que existe fora do sistema).

nome do casode uso

Page 64: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

64

6. UML 6. UML (7/32)(7/32)

Diagramas de casos de usoDiagramas de casos de uso

Page 65: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

65

6. UML 6. UML (8/32)(8/32)

Diagramas de casos de usoDiagramas de casos de uso– Um Um caso de usocaso de uso é uma típica interacção entre um é uma típica interacção entre um

utilizador e um sistema computacional. utilizador e um sistema computacional. – Os casos de uso permitem captar, junto dos clientes, os Os casos de uso permitem captar, junto dos clientes, os

requisitos do utilizador, dado que o vocabulário usado é requisitos do utilizador, dado que o vocabulário usado é o dos clientes e não o dos projectistas. o dos clientes e não o dos projectistas.

– Os casos de uso dum sistema constituem uma Os casos de uso dum sistema constituem uma decomposição funcional do comportamento desse decomposição funcional do comportamento desse sistema, sem lhe impor qualquer estrutura interna.sistema, sem lhe impor qualquer estrutura interna.

– UML dá uma grande importância aos diagramas de casos UML dá uma grande importância aos diagramas de casos de uso, uma vez que é com base neles que, segundo os de uso, uma vez que é com base neles que, segundo os seus proponentes, se pode planear e sustentar todo o seus proponentes, se pode planear e sustentar todo o desenvolvimento do sistema em causa.desenvolvimento do sistema em causa.

– Devem usar-se verbos para caracterizar os casos de uso, Devem usar-se verbos para caracterizar os casos de uso, o que indica que há uma dada operacionalidade o que indica que há uma dada operacionalidade associada.associada.

Page 66: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

66

6. UML 6. UML (9/32)(9/32)

Diagramas de casos de usoDiagramas de casos de uso– Um Um actoractor representa um papel que um dado utilizador representa um papel que um dado utilizador

pode ter em relação a um determinado sistema, quando pode ter em relação a um determinado sistema, quando com ele interactua. com ele interactua.

– Os casos de uso são realizados por actores, podendo um Os casos de uso são realizados por actores, podendo um mesmo actor desempenhar vários casos de uso e sendo mesmo actor desempenhar vários casos de uso e sendo também possível que um dado caso de uso seja também possível que um dado caso de uso seja executado por vários actores. executado por vários actores.

– Note-se que várias pessoas podem ser representadas Note-se que várias pessoas podem ser representadas pelo mesmo actor no diagrama.pelo mesmo actor no diagrama.

– Um actor é assim uma representação abstracta dum tipo Um actor é assim uma representação abstracta dum tipo de pessoa que interage com o sistema. de pessoa que interage com o sistema.

– Note-se também que a mesma pessoa pode Note-se também que a mesma pessoa pode desempenhar vários papéis relativamente ao mesmo desempenhar vários papéis relativamente ao mesmo sistema, papéis esses que darão origem a actores sistema, papéis esses que darão origem a actores distintos no respectivo diagrama. distintos no respectivo diagrama.

Page 67: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

67

6. UML 6. UML (10/32)(10/32)

Diagramas de casos de usoDiagramas de casos de uso– A identificação dos actores do sistema facilita a A identificação dos actores do sistema facilita a

definição das funcionalidades do sistema, feita através definição das funcionalidades do sistema, feita através da especificação dos casos de uso. da especificação dos casos de uso.

– Um caso de uso consiste numa forma particular de Um caso de uso consiste numa forma particular de usar o sistema, representando parte da sua usar o sistema, representando parte da sua funcionalidade total. funcionalidade total.

– Cada caso de uso constitui um conjunto completo de Cada caso de uso constitui um conjunto completo de eventos, iniciado por um actor, e explicita a interacção eventos, iniciado por um actor, e explicita a interacção que se pode observar entre esse actor, o sistema e, que se pode observar entre esse actor, o sistema e, eventualmente, outros actores. eventualmente, outros actores.

– O conjunto de todos os casos de uso permite O conjunto de todos os casos de uso permite especificar todas as formas distintas de interagir com especificar todas as formas distintas de interagir com o sistema.o sistema.

Page 68: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

68

6. UML 6. UML (11/32)(11/32)

Diagramas de classesDiagramas de classes– Para sistemas OO, são necessários diagramas de Para sistemas OO, são necessários diagramas de

classes, para indicar as classes existentes e as suas classes, para indicar as classes existentes e as suas relações. relações.

– Este tipo de diagrama é sempre contemplado por Este tipo de diagrama é sempre contemplado por todas as metodologias OO, uma vez que o conceito de todas as metodologias OO, uma vez que o conceito de classe é fundamental neste paradigma. classe é fundamental neste paradigma.

– Um diagrama de classes tem por objectivo evidenciar a Um diagrama de classes tem por objectivo evidenciar a estrutura estática de conceitos, tipos e classes. estrutura estática de conceitos, tipos e classes.

– Os conceitos mostram como os utilizadores vêem o Os conceitos mostram como os utilizadores vêem o domínio da aplicação, independentemente da forma domínio da aplicação, independentemente da forma como eles são, na prática, implementados. como eles são, na prática, implementados.

– Estes diagramas permitem também descrever os tipos Estes diagramas permitem também descrever os tipos de objectos (as classes) que o sistema pode de objectos (as classes) que o sistema pode contemplar e as formas de inter-relação entre eles. contemplar e as formas de inter-relação entre eles.

Page 69: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

69

6. UML 6. UML (12/32)(12/32)

Diagramas de classesDiagramas de classes– Podem ainda ser mostrados os atributos e as Podem ainda ser mostrados os atributos e as

operações de cada uma das classes, caso tal seja operações de cada uma das classes, caso tal seja relevante para o nível de abstracção em causa.relevante para o nível de abstracção em causa.

Page 70: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

70

6. UML 6. UML (13/32)(13/32)

Diagramas de classesDiagramas de classes– Em UML, existem 4 tipos de relações entre objectos, que Em UML, existem 4 tipos de relações entre objectos, que

podem ser mostradas entre as classes:podem ser mostradas entre as classes: AssociaçãoAssociação: Relação entre objectos que se manifesta em : Relação entre objectos que se manifesta em

tempo de execução através da troca de mensagens entre eles. tempo de execução através da troca de mensagens entre eles. Quando um objecto usa os serviços dum outro, devem ligar-se Quando um objecto usa os serviços dum outro, devem ligar-se estes com uma associação. estes com uma associação.

AgregaçãoAgregação: Forma especial de associação, que se verifica : Forma especial de associação, que se verifica quando um objecto contém, física ou logicamente, outros. Os quando um objecto contém, física ou logicamente, outros. Os componentes podem ser partilhados por vários agregados.componentes podem ser partilhados por vários agregados.

ComposiçãoComposição: Forma mais restrita de agregação, pois os : Forma mais restrita de agregação, pois os componentes dum agregado por composição não podem ser componentes dum agregado por composição não podem ser partilhados por outros agregados. O agregado é responsável partilhados por outros agregados. O agregado é responsável pela criação/destruição dos seus componentes.pela criação/destruição dos seus componentes.

GeneralizaçãoGeneralização: Verifica-se quando uma classe é uma : Verifica-se quando uma classe é uma especialização duma outra. A subclasse herda todas as especialização duma outra. A subclasse herda todas as características da superclasse, podendo adicionar novos características da superclasse, podendo adicionar novos atributos ou operações.atributos ou operações.

Page 71: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

71

6. UML 6. UML (14/32)(14/32)

Diagramas de classesDiagramas de classes

Page 72: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

72

6. UML 6. UML (15/32)(15/32)

Diagramas de objectosDiagramas de objectos– Para documentar os objectos concretos que compõem o Para documentar os objectos concretos que compõem o

sistema, bem como as suas inter-relações, são usados sistema, bem como as suas inter-relações, são usados diagramas de objectos. diagramas de objectos.

– Estes são, por natureza, estáticos, pois apenas mostram Estes são, por natureza, estáticos, pois apenas mostram um conjunto de objectos que trocam mensagens entre um conjunto de objectos que trocam mensagens entre si, omitindo o fluxo de controlo e a ordem dos eventos.si, omitindo o fluxo de controlo e a ordem dos eventos.

– Os diagramas de objectos são idênticos aos diagramas Os diagramas de objectos são idênticos aos diagramas de classes, exceptuando o facto de mostrarem de classes, exceptuando o facto de mostrarem instâncias (ou objectos) em vez de classes. instâncias (ou objectos) em vez de classes.

– Os objectos são desenhados como rectângulos, sendo os Os objectos são desenhados como rectângulos, sendo os nomes sublinhados para mais facilmente os distinguir de nomes sublinhados para mais facilmente os distinguir de classes.classes.

Page 73: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

73

6. UML 6. UML (16/32)(16/32)

Diagramas de objectosDiagramas de objectos

Page 74: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

74

6. UML 6. UML (17/32)(17/32)

Diagramas de interacçãoDiagramas de interacção– São também necessárias representações gráficas que São também necessárias representações gráficas que

permitam captar os aspectos dinâmicos relativos à troca de permitam captar os aspectos dinâmicos relativos à troca de mensagens entre objectos, a que se chamam diagramas de mensagens entre objectos, a que se chamam diagramas de interacção. interacção.

– Os diagramas de estado associados a classes não servem para Os diagramas de estado associados a classes não servem para este efeito, pois descrevem as mudanças internas de estado este efeito, pois descrevem as mudanças internas de estado das instâncias dessas classes e não entre um conjunto de das instâncias dessas classes e não entre um conjunto de objectos.objectos.

– Um diagrama de interacção representa uma instância dum Um diagrama de interacção representa uma instância dum caso de uso. caso de uso.

– Os diagramas de interacção descrevem a forma como um Os diagramas de interacção descrevem a forma como um grupo de objectos comunica entre si. grupo de objectos comunica entre si.

– Tipicamente, um diagrama de interacção capta o Tipicamente, um diagrama de interacção capta o comportamento dum dado cenário, mostrando os objectos e comportamento dum dado cenário, mostrando os objectos e as mensagens que são trocadas entre eles, nesse caso de uso.as mensagens que são trocadas entre eles, nesse caso de uso.

Page 75: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

75

6. UML 6. UML (18/32)(18/32)

Diagramas de interacçãoDiagramas de interacção– Existem dois tipos diferentes de diagramas de interacção: Existem dois tipos diferentes de diagramas de interacção:

diagramas de sequênciadiagramas de sequência e e diagramas de colaboraçãodiagramas de colaboração..

– Estes diagramas permitem captar os requisitos do sistema, Estes diagramas permitem captar os requisitos do sistema, podendo portanto ser utilizados na fase de análise. podendo portanto ser utilizados na fase de análise.

– Podem também usar-se, durante o teste do sistema, para Podem também usar-se, durante o teste do sistema, para comparar o funcionamento real do sistema (ou do comparar o funcionamento real do sistema (ou do protótipo, ou do modelo executável) com aquele que foi protótipo, ou do modelo executável) com aquele que foi especificado.especificado.

– Um diagrama de sequência mostra a sequência de Um diagrama de sequência mostra a sequência de mensagens trocadas entre objectos.mensagens trocadas entre objectos.

Page 76: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

76

6. UML 6. UML (19/32)(19/32)

Diagramas de Diagramas de interacçãointeracção– diagrama de diagrama de

sequênciasequência

Page 77: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

77

6. UML 6. UML (20/32)(20/32)

Diagramas de interacçãoDiagramas de interacção– Um diagrama de colaboração também pode ser usado Um diagrama de colaboração também pode ser usado

para descrever possíveis cenários dum sistema.para descrever possíveis cenários dum sistema.– Os diagramas de colaboração podem ser vistos como Os diagramas de colaboração podem ser vistos como

diagramas de objectos que apresentam as mensagens que diagramas de objectos que apresentam as mensagens que circulem entre eles e por que ordem.circulem entre eles e por que ordem.

– O mesmo tipo de informação é mostrado pelos diagramas O mesmo tipo de informação é mostrado pelos diagramas de sequência e de colaboração. de sequência e de colaboração.

– A diferença reside no facto de os primeiros focaram a A diferença reside no facto de os primeiros focaram a sequência de mensagens, enquanto que os últimos sequência de mensagens, enquanto que os últimos enfatizam a estrutura dos objectos que interactuam entre enfatizam a estrutura dos objectos que interactuam entre si.si.

– Nos diagramas de colaboração, identificar a sequência de Nos diagramas de colaboração, identificar a sequência de mensagens não é tão óbvio como sucede nos diagramas mensagens não é tão óbvio como sucede nos diagramas de sequência.de sequência.

Page 78: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

78

6. UML 6. UML (21/32)(21/32)

Diagramas de Diagramas de interacçãointeracção– diagrama de diagrama de

colaboraçãocolaboração

Page 79: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

79

6. UML 6. UML (22/32)(22/32)

Diagramas de estadosDiagramas de estados– Um diagrama de classes não permite determinar o Um diagrama de classes não permite determinar o

comportamento dinâmico das instâncias dessas classescomportamento dinâmico das instâncias dessas classes– Para as classes mais complexas, o uso duma notação que Para as classes mais complexas, o uso duma notação que

tenha subjacente um meta-modelo baseado em estados é tenha subjacente um meta-modelo baseado em estados é crucial. crucial.

– O uso de diagramas de estado, para definir o comportamento O uso de diagramas de estado, para definir o comportamento dum sistema, popularizou-se no domínio do hardware, mas a dum sistema, popularizou-se no domínio do hardware, mas a sua capacidade de modelação é útil noutras disciplinas sua capacidade de modelação é útil noutras disciplinas (software, compilação, comunicações, sistemas operativos, (software, compilação, comunicações, sistemas operativos, simulação, multimédia, interfaces homem-máquina, etc.).simulação, multimédia, interfaces homem-máquina, etc.).

– Os diagramas de estados definem o comportamento dinâmico Os diagramas de estados definem o comportamento dinâmico duma classe, explicitando todos os estados em que cada um duma classe, explicitando todos os estados em que cada um desses objectos se pode encontrar e as transições entre desses objectos se pode encontrar e as transições entre estados provocadas por condições a que esse objecto é estados provocadas por condições a que esse objecto é sensível. sensível.

Page 80: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

80

6. UML 6. UML (23/32)(23/32)

Diagramas de estadosDiagramas de estados– Num diagrama de estados convencional, em cada instante, Num diagrama de estados convencional, em cada instante,

um e um só estado está activo. um e um só estado está activo. – Um estado dum sistema é representado por um conjunto de Um estado dum sistema é representado por um conjunto de

variáveis, cujos valores contêm toda a informação necessária variáveis, cujos valores contêm toda a informação necessária sobre o passado do sistema e que, simultaneamente, sobre o passado do sistema e que, simultaneamente, condicionam o comportamento futuro do sistema.condicionam o comportamento futuro do sistema.

– Um estado representa um período de tempo durante o qual o Um estado representa um período de tempo durante o qual o sistema exibe um tipo específico de comportamento. sistema exibe um tipo específico de comportamento.

– Uma definição de estado é a seguinte:Uma definição de estado é a seguinte: ““A state is an A state is an ontological condition that persists for a significant period of ontological condition that persists for a significant period of time, is distinguishable from other such conditions, and is time, is distinguishable from other such conditions, and is disjoint with them. A distinguishable state means that it disjoint with them. A distinguishable state means that it differs from other states in the events it accepts, the differs from other states in the events it accepts, the transitions it takes as a result of accepting those events, or transitions it takes as a result of accepting those events, or the actions it performsthe actions it performs.”.”

Page 81: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

81

6. UML 6. UML (24/32)(24/32)

Diagramas de estadosDiagramas de estados– Em UML, existem dois formalismos diferentes para especificar Em UML, existem dois formalismos diferentes para especificar

máquinas de estados: state-charts e diagramas de máquinas de estados: state-charts e diagramas de actividades.actividades.

– Os state-charts são usados quando a transição entre estados Os state-charts são usados quando a transição entre estados dispara devido principalmente à ocorrência dum evento dispara devido principalmente à ocorrência dum evento significativo. significativo.

– Os diagramas de actividades mostram-se apropriados quando Os diagramas de actividades mostram-se apropriados quando a transição de estados ocorre, sobretudo, por causa da a transição de estados ocorre, sobretudo, por causa da conclusão da actividade executada no estado e não devido à conclusão da actividade executada no estado e não devido à ocorrência de eventos, sejam eles síncronos ou assíncronos. ocorrência de eventos, sejam eles síncronos ou assíncronos.

– Uma vez que os sistemas de interesse neste trabalho incluem Uma vez que os sistemas de interesse neste trabalho incluem sistemas reactivos, restringir-se-á a discussão aos sistemas reactivos, restringir-se-á a discussão aos statecharts.statecharts.

Page 82: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

82

6. UML 6. UML (25/32)(25/32)

Diagramas de estadosDiagramas de estados– Os state-charts estendem os diagramas de estados mais Os state-charts estendem os diagramas de estados mais

convencionais em três vertentes relacionadas com convencionais em três vertentes relacionadas com hierarquia, concorrência e comunicação.hierarquia, concorrência e comunicação.

– Apesar destas extensões permitirem obter modelos mais Apesar destas extensões permitirem obter modelos mais simples, compactos e legíveis, os state-charts são simples, compactos e legíveis, os state-charts são matematicamente equivalentes a máquinas de estados.matematicamente equivalentes a máquinas de estados.

Page 83: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

83

6. UML 6. UML (26/32)(26/32)

Diagramas Diagramas de estadosde estados– statechartstatechart

Page 84: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

84

6. UML 6. UML (27/32)(27/32)

Diagramas de estadosDiagramas de estados– statechartstatechart

Page 85: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

85

6. UML 6. UML (28/32)(28/32)

Outros mecanismos de modelaçãoOutros mecanismos de modelação– A definição de UML baseou-se, em forte medida, nas A definição de UML baseou-se, em forte medida, nas

notações associadas às metodologias de Booch, Objectory notações associadas às metodologias de Booch, Objectory e OMT. e OMT.

– Houve, na sua definição, a preocupação de consolidar Houve, na sua definição, a preocupação de consolidar essas notações, mas também de introduzir alguns essas notações, mas também de introduzir alguns mecanismos avançados de modelação. mecanismos avançados de modelação.

– Nesse sentido, foram adicionados a UML, entre outros, os Nesse sentido, foram adicionados a UML, entre outros, os estereótipos, os valores etiquetados e as restrições. estereótipos, os valores etiquetados e as restrições.

– Estes conceitos unificam uma série de características das Estes conceitos unificam uma série de características das notações daquelas três metodologias e permitem estender notações daquelas três metodologias e permitem estender a notação UMLa notação UML..

Page 86: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

86

6. UML 6. UML (29/32)(29/32)

Outros mecanismos de modelaçãoOutros mecanismos de modelação– Uma Uma nota de textonota de texto ( (text notetext note) é um elemento gráfico que ) é um elemento gráfico que

pode ser colocado em qualquer tipo de diagrama e que pode ser colocado em qualquer tipo de diagrama e que não tem qualquer valor semântico.não tem qualquer valor semântico.

– A sua utilização reduz-se à colocação de comentários e A sua utilização reduz-se à colocação de comentários e notas para aumentar a legibilidade dos modelos. notas para aumentar a legibilidade dos modelos.

– Por exemplo, relativamente a uma classe, é conveniente Por exemplo, relativamente a uma classe, é conveniente introduzir uma nota de texto onde se indicam comentários introduzir uma nota de texto onde se indicam comentários relativos àquela, incluindo, por exemplo, relativos àquela, incluindo, por exemplo, responsabilidades, propósito, restrições (pré e pós-responsabilidades, propósito, restrições (pré e pós-condições) e regras.condições) e regras.

Page 87: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

87

6. UML 6. UML (30/32)(30/32)

Outros mecanismos de modelaçãoOutros mecanismos de modelação– Um Um estereótipoestereótipo ( (stereotypestereotype) é um mecanismo que permite ) é um mecanismo que permite

estender a notação UML, por forma a incluir elementos não estender a notação UML, por forma a incluir elementos não previstos na notação base.previstos na notação base.

– Os estereótipos permitem rotular uma dada classe, tratando-Os estereótipos permitem rotular uma dada classe, tratando-se duma forma de classificar as classes (meta-classificação).se duma forma de classificar as classes (meta-classificação).

– Cada classe pode ter associados zero ou mais estereótipos. Cada classe pode ter associados zero ou mais estereótipos. – Os estereótipos duma classe são listados por cima do nome.Os estereótipos duma classe são listados por cima do nome.– Os estereótipos são indicados entre aspas.Os estereótipos são indicados entre aspas.– Exemplos: <<control>>, <<uses>> e <<extends>>. Exemplos: <<control>>, <<uses>> e <<extends>>. – Todos os mecanismos de modelação definidos em UML podem Todos os mecanismos de modelação definidos em UML podem

ser estereotipados, sendo, por ventura, o exemplo mais óbvio ser estereotipados, sendo, por ventura, o exemplo mais óbvio as mensagens. as mensagens.

Page 88: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

88

6. UML 6. UML (31/32)(31/32)

Outros mecanismos de modelaçãoOutros mecanismos de modelação– Um Um valor etiquetadovalor etiquetado ( (tagged valuetagged value) é uma par ) é uma par

(etiqueta,valor) que se associa a qualquer elemento de (etiqueta,valor) que se associa a qualquer elemento de modelação para guardar informação.modelação para guardar informação.

– Os valores etiquetados constituem uma forma simples de Os valores etiquetados constituem uma forma simples de estender o meta-modelo UML e podem ser usados, por estender o meta-modelo UML e podem ser usados, por exemplo, para passar informação aos utilitários de geração exemplo, para passar informação aos utilitários de geração automática de código. automática de código.

– É uma possibilidade a explorar no desenvolvimento de É uma possibilidade a explorar no desenvolvimento de sistemas embebidos (fases de concepção e sistemas embebidos (fases de concepção e implementação), sobretudo durante a partição implementação), sobretudo durante a partição hardware/software.hardware/software.

– Cada valor etiquetado é composto por uma etiqueta e por Cada valor etiquetado é composto por uma etiqueta e por um valor, com a seguinte forma: {etiqueta = valor}. um valor, com a seguinte forma: {etiqueta = valor}.

– Exemplo: {autor = Miguel}. Exemplo: {autor = Miguel}.

Page 89: U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2000/01 D EP. I NFORMÁTICA DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS (MESTRADO EM INFORMÁTICA) - SESSÃO 4:

© 2

001

UM

/EE

/DI/

JMF

89

6. UML 6. UML (32/32)(32/32)

Outros mecanismos de modelaçãoOutros mecanismos de modelação– Uma Uma restriçãorestrição é uma condição adicional que se aplica é uma condição adicional que se aplica

a um dado elemento de modelação e é sempre a um dado elemento de modelação e é sempre indicada entre chavetas “{}”. indicada entre chavetas “{}”.

– Por exemplo, a restrição {abstract} é usada numa Por exemplo, a restrição {abstract} é usada numa classe para indicar que se trata duma classe abstractaclasse para indicar que se trata duma classe abstracta

– A restrição {instantiable} é usada para indicar que a A restrição {instantiable} é usada para indicar que a classe é concreta. classe é concreta.

– Nos diagramas de sequência, podem usar-se Nos diagramas de sequência, podem usar-se restrições para explicitar marcas temporais.restrições para explicitar marcas temporais.

– A linguagem OCL (formal) pode ser usada para definir A linguagem OCL (formal) pode ser usada para definir as restrições nos modelos UML.as restrições nos modelos UML.