Cap 4 - UML - Visao Geral

Cap.
4 UML Viso Geral [Parte 2]

2
Tpicos
ENGENHARIA DE SOFTWARE
PARTE 2 LINGUAGEM DE MODELAO UML
Introduo Viso Histrica Tipos de Elementos Bsicos Tipos de Relaes Tipos de Diagramas Mecanismos Comuns
C AP. 4 U M L V I S O G E R AL
Tipos de Dados Organizao dos Artefactos/Pacotes
Engenharia de Software - 2011/2012
Carlos Barrico - DIDI-UBI
Cap. 4 UML Viso Geral [Parte 2]

3

4
Introduo
Introduo
O UML (Unified Modeling Language) uma linguagem para

especificao, construo, visualizao e Documentao de artefactos de um sistema de software.
O UML providencia as seguintes particularidades principais:

Semntica e notao para tratar um grande nmero de tpicos atuais de modelao. Semntica para tratar tpicos de modelao futura, relacionados em particular com a
tecnologia de componentes, computao distribuda, frameworks, e Internet.
O UNL promovido pelo Object Management Group (OMG), com contribuies e direitos de autoria das seguintes empresas:
Hewlett-Packard, IBM, ICON Computing, i-Logix, IntelliCorp, Electronic Data Services, Microsoft, ObjecTime, Oracle, Platinum, Ptech, Rational, Reich, Softeam, Sterling, Taskon A/S e Unisys.
Mecanismos de extenso de modo a permitir que futuras aproximaes e notaes de modelao possam continuar a ser desenvolvidas sobre o UML. Semntica e sintaxe para facilitar a troca de modelos entre ferramentas distintas.

5

6
Introduo
Introduo
O UML alarga o mbito de aplicaes alvo, pois permite, por exemplo, a modelao de sistemas
concorrentes, distribudos, para a Web, de informao geogrficos,
Objetivo do UML:
adotar diferentes processos/metodologias, mantendo-se contudo a utilizao da mesma linguagem de modelao em funo
do tipo de projeto, da ferramenta de suporte, ou da organizao envolvida.
O ponto forte do UML est na definio de uma linguagem de modelao standard, logo independente
das linguagens de programao, das ferramentas CASE, bem como dos processos de desenvolvimento.
O UML independente das ferramentas de modelao. Princpios bsicos no esforo de definio do UML:
simplicidade, coerncia na unificao de diferentes elementos existentes em vrios mtodos, e introduo de novos elementos apenas quando tal fosse absolutamente necessrio (quando tais elementos no existissem em mtodos anteriores).

7

8
Introduo
Introduo
Os novos elementos introduzidos no UML so:

Mecanismos de extenso, Elementos para modelar processos e threads, Elementos para modelar distribuio e concorrncia, Padres de desenho e colaboraes, Diagramas de atividades (para modelao de processos de negcio), Refinamento (para tratar relaes entre diferentes nveis de abstrao), Interfaces e componentes, e Linguagem de restries (Object Contraint Language).
O UML providencia os seguintes tipos de diagramas:

Diagramas de casos de uso/utilizao Diagramas de classes e diagramas de objetos Diagramas de comportamento
Diagramas de estados (statechart) Diagramas de atividades Diagramas de interao (diagramas de sequncia e diagramas de colaborao)
Diagramas de arquitetura:
Diagramas de componentes Diagramas de instalao

9

10
Viso Histrica
Viso Histrica
Viso histrica do UML
Fase da fragmentao (primeira metade da dcada de 1990):

Proliferao de mtodos e notaes para modelao segundo a abordagem orientado por objetos. Por essa altura percebeu-se a necessidade da existncia de uma linguagem
que viesse a tornar-se uma norma, que fosse aceite e utilizada quer pela indstria, quer pelos ambientes acadmicos e de investigao.
Fase da unificao (1996):

Surgiu o UML como melhor posicionado como a linguagem unificadora de notaes, diagramas e formas de representao existentes em diferentes mtodos.

11

12
Viso Histrica
Viso Histrica
Fase da standardizao (1997):

um esforo significativo na unificao com contributos de vrios parceiros com vista normalizao no mbito da OMG.
H dois aspetos importantes que se obtm com o UML:

(1) terminam as diferenas, geralmente inconsequentes, entre as linguagens de modelao dos anteriores mtodos; e (2) unifica as distintas perspetivas entre diferentes tipos de sistemas (e.g., modelao de negcio vs. modelao de software), fases de um processo e conceitos internos.
Fase da industrializao (a partir de 1998):

Assiste-se divulgao e adoo generalizada do UML como a linguagem de modelao de software segundo a abordagem orientada por objetos. Assiste-se ao aparecimento de
publicaes especficas sobre UML; teses, relatrios e artigos tcnico-cientficos que usam o UML; ferramentas CASE que suportam o UML:
Preocupaes mais significativos no desenho e especificao do UML:

foi torn-lo extensvel e aberto a futuras evolues.
O objetivo que seja possvel estender o UML sem ser necessrio redefinir o seu ncleo principal.

13

14
Tipos de Elementos Bsicos
A estrutura de conceitos do UML pode ser vista atravs das seguintes noes:
(1) coisas ou elementos bsicos, com base nos quais se definem os modelos; (2) relaes, que relacionam elementos; e (3) diagramas, que agrupam elementos.
Resumo dos elementos de estrutura: classes, classes ativas, interfaces, casos de uso/utilizao, atores, colaboraes, componentes e ns.
Os
elementos
encontram-se
organizados
consoante
sua
funcionalidade ou responsabilidade. Assim, h elementos:

de estrutura, de comportamento, de agrupamento, e de anotao.

15

16
Tipos de Relaes
Resumo dos elementos de

comportamento (estados e mensagens), agrupamento (pacotes), e anotao (anotaes ou notas).
As relaes so conceitos gerais que

apresentam
uma sintaxe (neste caso, uma notao), e uma semntica bem definida;
permitem
o estabelecimento de interdependncias entre os elementos bsicos.
Os principais tipos de relaes do UML so os seguintes:

associao, dependncia, realizao, generalizao, e transio de estado.

17

18
Tipos de Relaes
Tipos de Diagramas
Resumo dos tipos de relaes standard:
Diagramas
so conceitos que traduzem a possibilidade de agrupar elementos bsicos e as suas relaes de uma forma lgica ou de uma forma estrutural. proporcionam ao utilizador os meios de visualizar e manipular os elementos do modelo.
UML
Existem diferentes tipos de diagramas: para cada tipo usado
um subconjunto dos elementos bsicos, com diferentes tipos de relaes que tenha sentido existir.
Com base no princpio de modelao P4, definiu diferentes tipos de diagramas, cuja utilizao e aplicao permitem vises complementares. Os diagramas podem mostrar todas ou parte das caractersticas dos elementos do modelo, com um nvel de detalhe que seja apropriado no contexto de um tipo de diagrama.
Engenharia de Software - 2011/2012 Carlos Barrico - DIDI-UBI Engenharia de Software - 2011/2012 Carlos Barrico - DIDI-UBI

19

20
Tipos de Diagramas
Tipos de Diagramas Diagramas de Casos de Uso/Utilizao
Tipos de diagramas:
Diagramas de Casos de Uso/Utilizao:
Diagramas de Casos de Uso/Utilizao
Diagramas de Casos de Uso/Utilizao

Representam a viso do sistema na perspetiva do seu utilizador. Descrevem a relao entre atores e casos de utilizao de um dado sistema. Permitem dar uma viso global e de alto nvel do sistema, sendo fundamental a definio correta da sua fronteira. So utilizados preferencialmente na fase de especificao de requisitos e na modelao de processos de negcio.
Diagramas de Modelao da Estrutura:

Diagramas de classes, e Diagramas de objetos.
Diagramas de Modelao do Comportamento:

Diagramas de interao entre objetos: diagramas de sequncia, e diagramas de colaborao, Diagramas de transio de estados, e Diagramas de atividades.
Diagramas de Arquitetura:
Diagramas de componentes e Diagramas de instalao

21

22
Tipos de Diagramas Diagramas de Casos de Uso/Utilizao
Tipos de Diagramas Diagramas de Modelao da Estrutura
Exemplo de um diagrama de Casos de Uso/Utilizao
Diagrama de Modelao da Estrutura

Permite especificar a estrutura esttica de um sistema segundo a abordagem orientada por objetos. Pode ser de dois tipos: de classes ou de objetos.
Diagrama de Classes
Descrevem a estrutura esttica de um sistema, em particular
as entidades existentes, as suas estruturas internas, e relaes entre si.
Diagrama de Objetos
Descreve um conjunto de instncias compatveis com determinado diagrama de classes. Permite ilustrar os detalhes de um sistema em determinado momento ao providenciarem cenrios de possveis configuraes.

23

24
Tipos de Diagramas Diagramas de Modelao da Estrutura
Tipos de Diagramas Diagramas de Modelao do Comportamento
Exemplo de um diagrama de classes.
Diagramas de Modelao do Comportamento

Permitem especificar a dinmica ou o comportamento de um sistema segundo a abordagem orientada por objetos. So de 3 tipos:
Diagramas de interao entre objetos (de sequncia e de colaborao). Diagramas de transio de estados, e Diagramas de atividades.

25

26
Diagramas de Interao entre Objetos

Assumem duas formas complementares, cada uma focando um aspeto distinto:
diagramas de sequncia, e diagramas de colaborao.
Exemplo de um diagrama de Sequncia
Diagramas de Sequncia
Ilustram interaes entre objetos num determinado perodo de tempo. Os objetos
so representados pelas suas linhas de vida e interagem por troca de mensagens ao longo de um determinado perodo de tempo.

27

28
Diagramas de Colaborao
Ilustram interaes entre objetos com nfase para a representao das ligaes entre objetos. Como estes diagramas no mostram o tempo como um elemento explcito (tal como acontece nos diagramas de sequncia), a sequncia de mensagens e de atividades concorrentes determinada usando-se nmeros sequenciais, com diferentes nveis hierrquicos. Colaboraes so entidades de modelao principais e constituem
Diagramas de Atividades
So um caso particular dos diagramas de transio de estado, no qual
a maioria dos estados so substitudos pelos conceitos correspondentes a aes e/ou atividades, e as transies so desencadeadas devido concluso de aes nos estados originais.
O objetivo representar os fluxos conduzidos por processamento interno, em contraste com eventos externos representados nos diagramas de estado. Este tipo de diagramas pode ser encarados como um caso particular de diagramas de estados e inspirados nos diagramas de workflow, fluxogramas ou naqueles baseados em SDL (Specification and Description Language).
geralmente a base para a representao visual de padres de desenho.
Diagramas de Transio de Estado

Descrevem as sequncias de estados que um objeto ou uma interao pode passar ao longo da sua existncia em resposta a estmulos recebidos, conjuntamente com as suas respostas e aes.
Engenharia de Software - 2011/2012 Carlos Barrico - DIDI-UBI

29

30
Tipos de Diagramas Diagramas de Modelao de Estrutura
Exemplo de um diagrama de Atividades
Diagramas de Modelao de Estrutura

Do uma viso da disposio dos componentes fsicos (software e hardware) de um sistema. Descrevem aspetos da fase de implementao de um sistema de software, por exemplo, relativamente estrutura e dependncias de mdulos de cdigo fonte e de mdulos executveis. Apresentam-se sob duas formas:
diagramas de componentes e diagramas de instalao.

31

32
Diagramas de Componentes
Descrevem as dependncias entre componentes de software, incluindo componentes de cdigo fonte, cdigo binrio e executveis. So representados na forma de tipos e no na forma de instncias.
Exemplo de um diagrama de Instalao
Diagramas de Instalao
Descrevem a configurao de elementos de suporte de processamento, e de componentes de software, processos e objetos existentes nesses elementos.

33

34
Mecanismos Comuns
Mecanismos Comuns - Notas
O UML contm um conjunto de mecanismos comuns que so aplicados de modo consistente ao longo dos seus diferentes diagramas. Os dois mecanismos comuns mais usados so os seguintes:
Notas/Anotaes, e Mecanismos de extenso.
Notas/Anotaes
So os adornos mais importantes que existem autonomamente (sem estarem diretamente associados a outros elementos). Ilustram comentrios e no tem qualquer impacto semntico, j que os seus contedos no alteram o significado do modelo no qual se encontram.
normal a utilizao de notas para se descrever informalmente:

Requisitos, Restries, Observaes, Revises, ou Explicaes.

35

36
Mecanismos Comuns - Notas
Mecanismos Comuns Mecanismos de Extenso
Observaes a serem consideradas aquando da utilizao de notas:

Localizao:
devem ser colocadas graficamente perto dos elementos que descrevem.
O UML providencia os seguintes mecanismos que permitem estender a sua linguagem de forma consistente:
Esteretipos, Marcas, e Restries.
Visibilidade:
podem-se esconder ou tornar visveis (isto dependendo das ferramentas de suporte).
Extenso:
devem-se usar referncias (nomes de documentos ou URL) caso se pretenda um comentrio mais extenso.
Alguns dos aspetos na aplicao destes mecanismos, so os seguintes:

Introduzir um nmero reduzido destes elementos. Escolher nomes curtos e com significado para esteretipos e marcas. Sempre que a preciso puder ser relaxada, usar texto livre para
Evoluo:
h medida que o modelo evolui as notas mais antigas (cuja relevncia e utilidade deixem de ter sentido) devem ser eliminadas dos modelos.
especificao das restries (caso contrrio, usar a linguagem OCL). A definio destes mecanismos de extenso do UML, em particular a introduo de esteretipos, deve ser realizada por um nmero restrito de especialistas em UML e deve ser devidamente documentado.

37

38
Esteretipos
Um esteretipo um meta-tipo (um tipo que descreve tipos). Permite definir novos tipos de elementos sem se alterar o meta-modelo do UML, e por conseguinte permite estender o UML. O nome de um esteretipo representado entre os caracteres e . Exemplos:
Na modelao de processos de negcio: trabalhador, documento, poltica. Na modelao de aplicaes especficas: classes de interface, controlo, e entidade. Na modelao de aplicaes Web, usando o Web Application Extension: classes de Server Page, Client Page, Form, Select Element.
Esteretipos (exemplo)
A figura ilustra trs formas complementares de apresentao de esteretipos:

com cone (SensorTemperatura), com nome (ModelElement), e com nome e cone (Overflow).

39

40
Esteretipos
A definio de um esteretipo tem de ter em conta os seguintes aspetos:
Propriedades (pode providenciar o seu prprio conjunto de marcas), Semntica (pode providenciar as suas prprias restries), Notao (pode providenciar o seu prprio cone), e A classe base do meta-modelo que vai ser estendida (se o esteretipo estende uma classe, uma associao, um componente, etc.)
Marcas com Valor

Cada elemento em UML tem um conjunto de propriedades; por exemplo:
as classes tm um nome, uma lista de atributos e uma lista de operaes; as associaes tm um nome e dois ou mais elementos participantes.
Permitem adicionar novas propriedades aos elementos,

quer sejam elementos j existentes no UML, quer sejam elementos definidos por recurso a novos esteretipos.
um conceito que deve ser entendido como meta-data (isto , dados que descrevem dados) pois o seu valor aplica-se ao prprio elemento e no s suas instncias. Um par marca e valor delimitado entre os caracteres { e }.

41

42
Marcas com Valor

Exemplos de aplicaes usuais:
Para gerao de cdigo: {language=Java}, {linker=Blinker}. Na produo automtica de documentao. Na gesto de configuraes: {autor=AMRS}, {data=...}.
Restries (constraints)
Permitem adicionar ou alterar a semntica assumida por omisso de qualquer elemento UML. Consistem na especificao de uma condio delimitada pelos caracteres { e } (a condio pode ser especificada numa linguagem formal (OCL) ou informal texto em portugus). Permitem especificar condies que tm de ser validadas para que o modelo esteja bem definido.
Conforme ilustrado no exemplo:

pode-se especificar o nmero de processadores instalados em cada tipo de n, ou pode-se especificar se um determinado componente para ser instalado/usado com perfil de cliente, servidor, ou ambos.

43

44
Tipos de Dados
Restries (constraints)
Um tipo de dados uma abstrao utilizada de forma implcita no UML. Os tipos de dados no so elementos do modelo e por conseguinte no lhe so associados esteretipos, marcas com valor ou restries. Exemplos de tipos de dados:
Primitivos: Integer, String, Time Enumerados: Boolean, AggregationKind, VisibilityKind Outros: Expression, Mapping, Name, Multiplicity
Os conceitos de nomes, expresses ou multiplicidade so tipos de

Exemplo 1 (especificao em OCL):
que uma pessoa pode estar casada apenas com outra pessoa do sexo oposto
dados UML, definidos informalmente custa de outros tipos primitivos:

Exemplo: o tipo Multiplicity definido como o conjunto no vazio de inteiros (Integer) positivos, estendido com o caracter * ; Exemplo: o tipo Expression definido como uma sequncia de caracteres (String) cuja sintaxe no definida, propositadamente, pelo UML.
Exemplo 2 (especificao atravs da restrio {subset} predefinida em UML):

que os elementos da associao gerir tem de existir obrigatoriamente na associao trabalhar, ou seja, especifica-se que uma pessoa para ser gestor de um departamento tem tambm de ser, necessariamente, membro desse departamento.

45

46
Organizao dos Artefactos/Pacotes
Organizao dos Artefactos/Pacotes Representao Grfica
Pacote (package):
um elemento meramente organizacional. Permite agregar diferentes elementos de um sistema em grupos de forma que semntica ou estruturalmente faa sentido. Pode conter outros elementos, incluindo: classes, interfaces, componentes, ns, casos de utilizao, e mesmo outros pacotes. Um elemento encontra-se definido em apenas um nico pacote.
Os pacotes so representados por uma pasta (tabbed folder) com duas zonas complementares:
um pequeno retngulo (tabulador ou tab), com o nome do pacote; e um retngulo maior onde se especificam os elementos constituintes desse pacote ou, pelo menos, os seus elementos pblicos.
Exemplos de pacotes:
A necessidade da existncia de pacotes na modelao de sistemas de mdia/grande dimenso: impossvel modeliz-los de uma s vez. Os principais benefcios da utilizao de Pacotes so:
(1) facilitar a gesto e procura de artefactos; (2) evitar os conflitos de nomes (X::A diferente X::Y:A diferente Z::A); e (3) providencia um mecanismo de controlo de acessos (visibilidade).

47

48
Organizao dos Artefactos/Pacotes Representao Grfica
Organizao dos Artefactos/Pacotes Relaes entre Pacotes
Exemplos de pacotes (figura anterior):

Exemplo 1:
o pacote tem o nome Utilizadores e descreve os seus elementos. Os smbolos +, - e # representam informao de visibilidade, respetivamente visibilidade pblica, privada e protegida.
Os pacotes apresentam entre si diferentes tipos de relaes de

Importao, Exportao, e Generalizao.
Exemplo 2:
uma forma alternativa de representar um pacote em que no so apresentados os seus elementos: o nome do pacote Regras de Negcio e encontra-se colocado no meio do retngulo maior.
Visibilidade
Os smbolos +, - e # permitem indicar o tipo de visibilidade que os elementos constituintes de um pacote apresentam:
Um elemento com visibilidade pblica (prefixo +) pode ser usado/referenciado por qualquer outro elemento independentemente do local onde definido. Um elemento com visibilidade privada (prefixo -) pode ser usado/referenciado por elementos definidos no mesmo pacote. Um elemento com visibilidade protegida (prefixo #) pode ser usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote que seja uma especializao (atravs da relao de herana) do primeiro.
Exemplo 3:
(1) Possibilidade de relaes de hierarquia ou de incluso entre pacotes: o pacote Docentes est contido no pacote DEI e pode ser identificado univocamente pela concatenao dos vrios nomes separados pelo smbolo ::. (2) Possibilidade de caracterizar o pacote atravs dos mecanismos comuns, tais como especificao de marcas ({version=1.4}), esteretipos ou restries.

49

50
Visibilidade (cont)
possvel definir-se uma relao de friend entre dois pacotes ( uma relao de dependncia entre pacotes, com esteretipo friend).
Neste caso, um pacote que friend de outro pode aceder/referenciar todos os seus elementos independentemente da sua visibilidade. Contudo este tipo de dependncia deve ser evitado sempre que possvel pois viola os princpios do encapsulamento e da minimizao de dependncias.
Importao e Exportao
Um pacote faz a exportao, por definio, de todos os seus elementos pblicos.
Mas tal facto no implica que um elemento definido noutro pacote possa aceder/referenciar um elemento exportado num outro pacote (para que tal ocorresse deveria existir explicitamente uma relao de importao entre esses dois pacotes).
A relao de importao
uma relao de dependncia entre pacotes, especificando que o pacote base importa todos os elementos pblicos definidos no pacote destino (os elementos pblicos definidos no pacote destino podem ser usados por elementos no pacote base). representada graficamente atravs de uma linha dirigida, a tracejado, com esteretipo import.

51

52
Exemplos de relaes de importao/exportao entre pacotes.

o elemento DataBase exportado no pacote DataServer no pode ser referenciado por qualquer elemento definido em WebDEI. WebDEI importa todos os elementos pblicos definidos em DEIServlets, e este importa todos os elementos pblicos definidos em javax::serlets::http.
Importao e Exportao
A relao de importao no transitiva.
Exemplo da figura: WebDEI importa DEIServlets, e este importa javax::serlets::http; no entanto, WebDEI no importa o javax::serlets::http. Isto , os elementos definidos em WebDEI podem aceder aos elementos pblicos de DEIServlets, mas no aos de javax::serlets::http; para tal acontecer, dever-se-ia definir explicitamente uma relao de importao entre esses dois pacotes.
A relao de importao no simtrica.

Exemplo da figura: o fato dos elementos definidos em WebDEI poderem aceder aos elementos pblicos de DEIServlets no implica que o inverso seja verdade.
Os elementos exportados por cada pacote devem ser do tipo interface, uma vez que providenciam uma interface de programao sem revelarem os detalhes de implementao e as relaes de classes definidas internamente no respetivo pacote.

53

54
Generalizao
A relao de generalizao entre pacotes
semelhante homloga existente entre classes, e usada para a especificao de famlias de pacotes, tpicas em sistemas complexos ou flexveis (significativamente parametrizveis, multi-plataforma, multi-linguagem).
Exemplos de relaes de generalizao entre pacotes.
Exemplo (figura seguinte):

o pacote WebServer tem duas classes pblicas (Page e Form) e uma protegida (EventHandler) e especializado por dois pacotes distintos: Servlets, especializa o pacote de topo segundo a tecnologia da Sun (Java Servlets); e ASP, providencia a mesma funcionalidade segundo a tecnologia da Microsoft (Active Server Pages).

55

56
Organizao dos Artefactos/Pacotes Tipos de Pacotes
Nos exerccios acadmicos a dimenso e/ou a simplicidade do problema faz com que um pacote seja simplesmente um pacote. Em situaes reais de modelao de sistemas de mdia/grande dimenso, realizada por equipas de vrios indivduos, torna-se
system:
Pacote que representa o sistema inteiro; tipicamente este pacote agrega pacotes dos restantes tipos (subsistema, ).
subsystem:
Pacote que representa uma parte constituinte do sistema inteiro.
necessrio tipificar os prprios pacotes. A especificao atual do UML prope 5 esteretipos standard aplicados a pacotes: system, subsystem, facade, framework e stub. Em geral os pacotes mais usados so do tipo system e subsystem Por omisso assume-se que um pacote do tipo system (se for de primeiro nvel) e subsystem (se for de segundo ou mais nvel).
facade:
Pacote com elementos (tipicamente classes e interfaces) que constituem a fachada (ou a interface de programao) providenciada conjunta e
coerentemente por outros pacotes. A fachada permite esconder os detalhes de arquitetura e de implementao de vrios elementos eventualmente organizados em distintos pacotes. Os elementos definidos numa fachada apenas referem outros elementos definidos noutros pacotes.

57

58
Organizao dos Artefactos/Pacotes Modelao de Grupos de Elementos
framework:
Um framework uma arquitetura de classes e interfaces com inmeros pontos de variabilidade ou de extenso e com estruturas de objetos padronizadas, conhecidas por padres de desenho. O desenvolvimento de sistemas baseados em frameworks e em componentes de software um tpico emergente extremamente atual.
Compete a cada processo de desenvolvimento de software formalizar ou dar sugestes relativamente forma de organizar todo o processo atravs de uma estrutura adequada de pacotes. Algumas das formas clssicas de organizao dos artefactos de projetos em termos de pacotes, so as seguintes:
Organizao por casos de utilizao:
Aproximao em que o sistema e respetivos modelos se encontram distribudos por pacotes, consoante os vrios casos de utilizao.
stub:
usado quando se pretende partir um sistema em diferentes pacotes por motivos de diviso de trabalho, quer em termos fsicos/espaciais, quer em termos temporais. Permite que duas equipas consigam trabalhar paralelamente em diferentes locais, mas mantendo algum nvel de interdependncia.
Organizao por tipos de modelos:

Aproximao em que o sistema se encontra dividido por diferentes pacotes consoante as diferentes vistas, ou tipos de modelos produzidos. Por exemplo, h um pacote (com uma eventual hierarquia de pacotes) para o modelo de casos de utilizao; outro para o modelo de anlise; outro para o modelo de desenho; e outro ainda para o modelo de implementao.

Cap 4 - UML - Visao Geral

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cap 4 - UML - Visao Geral

Enviado por

Direitos autorais:

Formatos disponíveis

Cap.

4 UML Viso Geral [Parte 2]

Tipos de Dados Organizao dos Artefactos/Pacotes

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

O UML (Unified Modeling Language) uma linguagem para

O UML providencia as seguintes particularidades principais:

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

Os novos elementos introduzidos no UML so:

O UML providencia os seguintes tipos de diagramas:

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

Viso histrica do UML

Fase da fragmentao (primeira metade da dcada de 1990):

Fase da unificao (1996):

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

Fase da standardizao (1997):

H dois aspetos importantes que se obtm com o UML:

Fase da industrializao (a partir de 1998):

Preocupaes mais significativos no desenho e especificao do UML:

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

Tipos de Elementos Bsicos

Tipos de Elementos Bsicos

funcionalidade ou responsabilidade. Assim, h elementos:

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Engenharia de Software - 2011/2012

Carlos Barrico - DIDI-UBI

Cap. 4 UML Viso Geral [Parte 2]

Cap. 4 UML Viso Geral [Parte 2]

Tipos de Elementos Bsicos

Resumo dos elementos de

As relaes so conceitos gerais que

Os principais tipos de relaes do UML so os seguintes:

Engenharia de Software - 2011/2012