UML: Uma introdução à linguagem de modelação unificada

ndice
1. 2. 3. Definio de Conceitos e Abreviaturas ....................................................................................... 1 Introduo ................................................................................................................................. 2 Objectivos.................................................................................................................................. 3 3.1. 4. 5. Objectivos Especficos ........................................................................................................ 3
Metodologia .............................................................................................................................. 4 UML (Linguagem Unificada de Modelao) ................................................................................ 5 5.1. 5.2. Definio............................................................................................................................ 6 Tipos de diagramas existentes na linguagem UML .............................................................. 8
6. 7.
Pequena Metodologia UML ....................................................................................................... 8 Notao ..................................................................................................................................... 9 7.1. Legenda ............................................................................................................................. 9
8.
Diagrama de Casos de Uso ....................................................................................................... 15 8.1. 8.2. 8.3. 8.4. 8.5. Actor ................................................................................................................................ 15 Relacionamento ............................................................................................................... 16 Pacotes ............................................................................................................................ 21 Componentes................................................................................................................... 22 Mecanismos Gerais .......................................................................................................... 22
9. 10. 11. 12. 13.
Diagrama de Classes ................................................................................................................ 23 Diagrama de Objectos .......................................................................................................... 26 Diagrama de Estado ............................................................................................................. 26 Diagrama de Actividade ....................................................................................................... 27 Diagrama de Sequncia........................................................................................................ 29 Notao UML para Diagramas de Sequncia................................................................. 29
13.1. 14. 15. 16. 17. 18.
Diagrama de Componente ................................................................................................... 34 Diagrama de Instalao ........................................................................................................ 36 Resumo Hierrquico dos Diagramas da UML ........................................................................ 36 Concluso ............................................................................................................................ 37 Bibliografia........................................................................................................................... 38
Engenharia de Software
3o ano Informtica
1. Definio de Conceitos e Abreviaturas Dados representam factos de vida real que podem ser guardados. Diagramas so os grficos que descrevem o contedo em uma viso. UML possui nove tipos de diagramas que so usados em combinao para prover todas as vises do sistema. MER Modelo Entidade-Relacionamento. UML Unified Modeling Language (Linguagem Unificada de Modelao). Orientao a objecto - um conceito que esta relacionado com a ideia de classificar , organizar e abstrair coisas. Ver a definio formal: O termo orientao a objectos significa organizar o mundo real como uma coleco de objectos que incorporam estrutura de dados e um conjunto de operaes que manipulam estes dados .
Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate
Maputo, Outubro de 2009 1
3o ano Informtica
2. Introduo O Trabalho que se prope apresentar faz parte da cadeira de Engenharia de Software leccionada para o 3o ano de curso de Bacharelato e Licenciatura em Ensino de Informtica e aborda sobre a linguagem de modelagem UML (Unified Modeling Language). O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objectos nas fases de anlise de requisitos, anlise de sistemas e design que no existe uma notao padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada simbologia existente possui seus prprios conceitos, grficos e terminologias, resultando numa grande confuso, especialmente para aqueles que querem utilizar a orientao a objectos no s sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajud-los a construir e manter sistemas cada vez mais eficazes. Quando a "Unified Modeling Language" (UML) foi lanada, muitos desenvolvedores da rea da orientao a objectos ficaram entusiasmados j que essa padronizao proposta pela UML era o tipo de fora que eles sempre esperaram. A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de novos conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da UML no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar orientao a objectos no estado da arte. UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos como "os trs amigos". Eles possuem uma extenso conhecimento na rea de modelagem orientada a objectos j que as trs mais conceituadas metodologias de modelagem orientada a objectos foi por eles desenvolvida, e a UML a juno do que havia de melhor nestas trs metodologias adicionado novos conceitos e vises da linguagem. intuito deste trabalho definir e explicar os significados de classes, objectos, relacionamentos, fluxos, mensagens e outras entidades comuns da orientao a objectos, apresentarmos como essas entidades so criadas, simbolizadas, organizadas e como sero utilizadas dentro de um desenvolvimento utilizando a UML, bem como os diferentes diagramas.
3o ano Informtica
3. Objectivos Abordar sobre as tcnicas usadas na linguagem de modelagem UML. 3.1. Objectivos Especficos - Definir a linguagem de modelagem UML e seus conceitos (Classe, Objecto, Pacotes, etc.); - Descrever as tcnicas usadas na linguagem UML.
3o ano Informtica
4. Metodologia Para realizao deste trabalho obedeceu-se a seguinte metodologia: - Reviso bibliogrfica (consulta de livros sobre Modelagem usando UML com enfoque em Engenharia de Software, trabalhos elaborados que focalizam o tema em abordagem e documentos electrnicos); - Elaborao do presente trabalho.
3o ano Informtica
5. UML (Linguagem Unificada de Modelao) Os estudos sobre a tecnologia de objectos iniciaram-se na dcada de 1980 com nfase nas linguagens de programao. No final da mesma dcada comearam a surgir os mtodos de anlise e projecto. Os principais mtodos foram :
Tabela 1. Principais propostas de tcnicas de modelagem orientada a objectos durante a dcada de 1990. Todos os mtodos eram muito similares, apesar da existncia de diferentes notaes para representar o mesmo conceito, o que na verdade, causava muita confuso entre os tcnicos e competio entre os metodologistas, o que provocou a "guerra dos mtodos". Em 1994 James Rumbaugh e Grady Booch iniciaram o trabalho de unificao dos mtodos Booch e OMT. Em 1995 no OOPSLA , Booch e Rumbaught apresentaram a documentao da verso 0.8 do mtodo unificado e anunciaram a integrao de Ivar Jacobson na equipe, formando assim o que eles denominaram de "os trs amigos". Durante 1996 eles trabalharam no mtodo que passou a chamar-se de Unified Modeling Language (UML) e a Object Management Group (OMG) iniciou um esforo para padronizao na rea de mtodos. Os esforos de Rumbaugh, Booch e Jacobson resultaram as verses 0.9 e 0.91 da UML em Junho e Outubro de 1996 respectivamente. A UML a sucessora da linguagem de modelagem encontrada nos mtodos Booch, OOSE/Jacobson, OMT e outros como Modelos de Entidades e Relacionamentos. Cada um desses mtodos era reconhecido mediante alguma forte caracterstica. O OOSE orientado a use case e prov um excelente recurso para a anlise de requisitos. A OMT foi
Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate Maputo, Outubro de 2009 5
3o ano Informtica
expressiva para anlise e sistemas centrados a dados. Booch93 foi relevante na fase de projecto e construo de sistemas voltados para Engenharia. Ainda 1996 a Rational Software Corporation contou com a participao de outras Instituies parceiras como: Hewlett-Packard, IBM, Microsoft, Oracle, Unisys, Platinum Technology, etc. Essa colaborao contribuiu para a produo da verso 1.0, uma verso bem definida, expressiva, poderosa e aplicvel, a qual foi submetida a OMG para adopo.
5.1. Definio A UML no um mtodo uma linguagem visual de modelagem designada para especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem a notao que o mtodo utiliza para expressar projectos enquanto que o processo indica quais passos seguir para desenvolver um projecto. Sendo uma linguagem visual constituda de elementos grficos para visualizao, especificao, construo e documentao de sistemas. Visualizao: - Modelos explcitos facilitam a comunicao; - Algumas estruturas transcendem a representao fornecida pelas linguagens de programao; - Cada smbolo possui associada uma semntica bem definida. Especificao: - A linguagem UML permite a especificao de todas as decises importantes na anlise, projecto e implementao de sistemas. Construo: - Permite a gerao de cdigo a partir de um modelo (forward engineering); - Permite a reconstruo de um modelo a partir de cdigo (reverse engineering) - Permite ambas as abordagens (round-trip engineering) Documentao - A modelao usando UML cria documentao do sistema no que respeita requisitos, especificaes funcionais e planos de teste.
3o ano Informtica
Cada elemento grfico possui uma sintaxe (isto, forma predeterminada de desenhar o elemento) e uma semntica que definem o que significa o elemento e para que ele deve ser utilizado. Alm disso, tanto a sintaxe quanto a semntica da UML extensvel. Essa extensibilidade permite que a UML seja adaptada s caractersticas de cada projecto de desenvolvimento. Pode-se fazer analogia da UML com uma caixa de ferramenta. Um construtor usa sua caixa de ferramentas para realizar suas tarefas. Da mesma forma a UML pode ser vista como uma caixa de ferramentas utilizada pelos desenvolvedores de sistemas para realizar a construo de modelos. A UML independente tanto de linguagens de programao quanto de processos de desenvolvimento, isso quer dizer que a UML pode ser utilizada para modelagem de sistemas, no importa qual a linguagem de programao a ser utilizada para implementao do sistema, ou qual a processo de desenvolvimento adoptado. Este um factor importante para utilizao da UML, pois diferentes sistemas de software requerem diferentes abordagens de desenvolvimento.
3o ano Informtica
5.2. Tipos de diagramas existentes na linguagem UML A linguagem UML define os seguintes tipos de diagramas: Diagramas funcionais - diagrama de casos de utilizao (casos de uso) visualiza os casos de utilizao (funcionalidades) do sistema e suas relaes; Diagramas estruturais consideram os aspectos estticos do sistema - diagramas de classes usados para modelar o vocabulrio do sistema; ou seja, quais os conceitos que fazem parte do sistema, bem como o relacionamento entre esses conceitos; - diagramas de objectos visualizam um conjunto de objectos e as suas relaes num determinado instante de tempo; - diagramas de componentes visualiza um conjunto de componentes e as suas relaes; - diagramas de instalao visualizam a configurao de um conjunto de ns de processamento e dos componentes em execuo em cada n. Diagramas de comportamento (eventos temporais) consideram aspectos dinmicos do sistema. - diagrama de sequncia um diagrama que enfatiza a ordenao temporal de mensagens trocadas entre objectos; - diagrama de colaborao um diagrama que enfatiza a organizao dos objectos que participam numa interaco; - diagrama de estados especifica a sequncia de estados pelos quais um objecto passa, em resposta a eventos, durante o seu tempo de vida; - diagrama de actividades semelhante a um fluxograma, til para modelar o fluxo e o detalhe das operaes.
6. Pequena Metodologia UML Na anlise de um problema e desenvolvimento da respectiva soluo, costume seguir-se os seguintes passos: 1. Requisitos/funcionalidades dialogando com o cliente identificar as funcionalidades de alto nvel (as grandes funes do sistema) pretendidas no sistema para cada perfil de utilizador, recorrendo a diagramas de casos de utilizao.
3o ano Informtica
2. Processos continuando o dilogo com o cliente, analisar e efectuar uma descrio de alto nvel dos processos existentes no sistema e das interaces entre os diferentes intervenientes nesses processos (workflow), recorrendo a diagramas de interaco (sequncia e colaborao). 3. Estrutura lgica partindo do diagramas de casos de utilizao e dos diagramas de interaco de alto nvel, identificar e descrever detalhadamente as diferentes entidades existentes no sistema (recorrendo a diagramas de classes), bem como detalhar os diagramas de interaco anteriores de forma a incluir as classes de implementao identificadas e respectivas operaes (diagramas de sequncia e de colaborao). 4. Estrutura fsica identificar os diferentes elementos fsicos do sistema (ex., bibliotecas de funes, executveis) recorrendo-se de diagramas de componentes, bem como identificar os recursos de hardware necessrios instalao do sistema usando para tal diagramas de instalao.
7. Notao 7.1. Legenda A tabela seguinte apresenta uma legenda dos elementos grficos utilizados nos diagramas UML. Smbolo Designao Actor Descrio Uma entidade (pessoas ou sistemas externos) que interage com o sistema a modelar. Utilizao Diagramas de casos de utilizao, de classes, de sequncia e de colaborao. Diagramas de casos de utilizao. Todos os diagramas.
Use case
<<texto>>
Esteretipo
Uma sequncia de aces executadas pelo sistema de forma a obter um resultado visvel para um actor Os esteretipos permitem a classificao de elementos. Por exemplo, as classes que representam janelas da aplicao podem ser classificadas com o esteretipo <<form>>*.
3o ano Informtica
Smbolo
Designao Associao
Relao uses
Relao extends
Package
Descrio Representa uma associao ou relao entre dois elementos num diagrama. Tipo especial de relao que indica que um caso de utilizao usa obrigatoriamente as funcionalidades de um outro caso de utilizao Tipo especial de relao que indica que um caso de utilizao pode opcionalmente estender as funcionalidades de um outro caso de utilizao Unidade lgica de agrupamento de elementos para simplificar a leitura de um diagrama. Cada elemento num modelo pertence apenas a um package. Adicionalmente, os nomes dos elementos devem ser nicops em cada package. Comentrios textuais e/ou grficos que se podem adicionar aos elementos de um diagrama para explicar/detalhar certos aspectos que possam ser dbios. Uma classe uma descrio de um conjunto de objectos que partilham os mesmos atributos, operaes, relaes e semntica. So uma forma de representar os diferentes conceitos existentes num sistema/problema. Um tipo especial de classe que no possui objectos, servindo normalmente como base para especializao de outras classes. Denotada pelo nome em itlico.
Utilizao Todos os diagramas. Diagramas de casos de utilizao.
Diagramas de casos de utilizao.
Todos os diagramas.
Comentrio ou nota
Todos os diagramas.
Classe
Diagramas de classes.
Classe abstracta
3o ano Informtica
Smbolo
Designao Objecto
Descrio Uma instncia especfica de uma classe. Corresponde atribuio de valores concretos aos atributos da classe. Denotada pelo nome sublinhado. Uma relao navegvel entre dois elementos mas apenas num sentido (ex., composio de classes). Uma relao que indica a especializao (herana) de um elemento a partir de outro. Isto , o elemento apontado pela seta um caso mais geral do outro elemento. Denota uma relao um ou do tipo. Uma relao que indica a existncia de uma dependncia entre dois elementos de tal forma que uma alterao num dos elementos pode afectar o outro . Uma associao entre n elementos.
Utilizao Diagramas de classes.
Associao unidireccional
Todos os diagramas.
Generalizao
Diagramas de classes e de casos de utilizao.
Dependncia
Diagramas de classes, casos de utilizao e de instalao.
Associao nria
Agregao
Classe de associao
Uma relao de agregao entre elementos. uma relao todo/parte onde um elemento composto por vrios outros elementos. Uma associao com as caractersticas de (e representada por) uma classe.
Restrio
Uma restrio um mecanismo que permite a criao de condies e restries booleanas a aplicar a um ou mais elementos (ex., associaes).
Todos os diagramas.
3o ano Informtica
Smbolo
Designao Interface
Interface
Utility
Estado
Estado inicial
Estado final
Actividade Transio
Descrio Este estereotipo no deve ser confundido com interface com utilizador. Interface representa uma vista sobre as operaes de uma classe. Uma interface uma coleco de especificaes de operaes para definir um servio sem ditar a sua implementao. Este estereotipo representa um agrupamento de operaes e atributos que no pertencem a nenhuma classe do problema (ex., funes de biblioteca) Representa o estado de um objecto durante o seu tempo de vida, enquanto espera por um evento ou efectua alguma aco. O estado inicial de um diagrama de estados, onde se inicia a execuo da mquina de estados. O estado final de um diagrama de estados, onde a execuo da mquina de estados finaliza. Representa uma actividade que o objecto efectua. Indica uma transio entre dois estados devido ocorrncia de determindas condies ou eventos. Elemento que permite tomar uma deciso entre dois ou mais fluxos alternativos. Permite a diviso ou reagrupamento de fluxos de controlo Representa um elemento fsico na instalao do sistema. Normalmente com capacidade de processamento.
Utilizao Diagramas de classes.
Diagramas de instalao.
Diagrama de classes.
Diagramas de estado.
Diagrama de actividades. Diagramas de estado e de actividade. Diagramas de estado e de actividade Diagramas de estados e de actividades Diagramas de instalao.
Deciso
Bifurcao ou confluncia Nodo
3o ano Informtica
Smbolo
Designao Instncia de um nodo
Descrio Representa um dispositivo concreto da rede (ex., o computador do gabinete 23). Denotado pelo nome sublinhado. Um componente uma parte fsica do sistema que corresponde realizao de um conjunto de interfaces e/ou classes. Tipo de classe de anlise usada para modelar as interaces entre um sistema e os seus actores.
Utilizao Diagramas de instalao.
Componente
Diagramas de instalao.
paginaPrincipal
boundary
Diagramas de classes de anlise.
validao
control
Representam normalmente, janelas de aplicao, APIs, etc. Tipo de classe de anlise Diagramas de usada para encapsular modelar classes de o fluxo de controlo para um anlise. dado caso de utilizao. Representam coordenao e sequenciamento de outros objectos. Tipo de classe de anlise usada para modelar informao com grande durao (possivelmente persistente)
cliente
entity
Diagramas de classes de anlise.
Linha temporal
Representa a linha temporal da existncia de um objecto. Ao longo da linha sero representadas as activaes do objecto bem como as mensagens recebidas e enviadas.
Diagramas de sequncia.
3o ano Informtica
Smbolo
Designao Mensagem sncrona
Descrio Mensagem trocada entre dois objectos que vai activar o objecto chamado. Pelo facto de ser uma mensagem sncrona, o objecto chamador fica espera que o objecto chamado termine o processamento antes de continuar. Corresponde normalmente invocao de uma operao do objecto chamado. O assincronismo permite que a mensagem seja enviada ao objecto chamado, e que o objecto chamador continue imediatamente a sua execuo (i.e., sem esperar pela resposta) Indicao explcita da invocao de um mtodo no objecto chamado. Indica o retorno de uma mensagem. omitida nas mensagens sncronas. Indica um tempo de processamento num objecto.
Utilizao Diagramas de sequncia.
Mensagem assncrona
Chamada de procedimento Mensagem de retorno Activao
Tabela 2. Elementos grficos da linguagem UML
3o ano Informtica
8. Diagrama de Casos de Uso Os casos de uso de um projecto de software so descritos na linguagem UML atravs de Diagramas de Casos de Uso (Use Case). Diagrama de "Use Case": um diagrama usado para se identificar como o sistema se comporta em vrias situaes que podem ocorrer durante sua operao. Descrevem o sistema, seu ambiente e a relao entre os dois. Os componentes deste diagrama so os actores, os "Use Case" e os relacionamentos. Ainda pode-se usar as primitivas Pacotes e Notas. 8.1. Actor Representa qualquer entidade que interage com o sistema durante sua execuo, essa inteirao se d atravs de comunicaes (troca de mensagens). Um actor pode ser uma pessoa (usurio, secretaria, aluno...), um dispositivo (impressora, mquina...), hardware (placa de modem, scaner...), softwares (sistema de base de dados, aplicativos...), etc. Algumas de suas caractersticas so descritas abaixo: - Actor no parte do sistema. Representa os papis que o usurio do sistema pode desempenhar; - Actor pode interagir activamente com o sistema; - Actor pode ser um receptor passivo de informao; - Actor pode representar um ser humano, uma mquina ou outro sistema. Representao:
Actor
Use Case
Figura 1. Representao de Actor e Use Case Nota: Actores representam, na verdade, papis desempenhados por pessoas, dispositivos ou outros quando interagem com o sistema. Um actor cujo identificador seja ALUNO no representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo com o sistema na qualidade de aluno.
3o ano Informtica
Use Case - como foi exemplificado acima, uma sequncia de aces que o sistema executa e produz um resultado de valor para o actor. Modela o dilogo entre os actores e o sistema; um fluxo de eventos completos. Algumas de suas caractersticas so: - Um "Use Case" modela o dilogo entre actores e o sistema; - Um "Use Case" iniciado por um actor para invocar uma certa funcionalidade do sistema; - Um "Use Case" fluxo de eventos completo e consistente; - O conjunto de todos os "Use Case" representa todas as situaes possveis de utilizao do sistema. 8.2. Relacionamento Os relacionamentos ligam as classes/objectos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: - Associao: uma conexo entre classes, e tambm significa que uma conexo entre objectos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objectos ligados. - Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objecto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido. Os relacionamentos em um diagrama de casos de uso podem envolver dois actores e dois casos de uso ou um actor e um caso de uso e assim sucessivamente. O relacionamento representado atravs de uma seta: Exemplo: Diagrama de "Use Cases" para um sistema informatizado de Matrcula num Curso.
3o ano Informtica
Figura 2. Exemplo de Diagrama de "Use Cases" 8.2.1. Tipo de Relacionamento 8.2.1.1. Associaes Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando, por exemplo, que elas "conhecem uma a outra", "esto conectadas com", "para cada X existe um Y" e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas complexos. 8.2.1.1.1. Associaes Normais O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos. Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um nome para cada sentido da associao. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objectos esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por
3o ano Informtica
diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrita nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).
Figura 3. Duas classes relacionando-se por associao normal (neste exemplo v-se um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associao). 8.2.1.1.2. Associao Recursiva possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objectos, mas os objectos conectados so da mesma classe. Uma associao deste tipo chamada de associao recursiva.
Figura 4. Exemplo de uma associao recursiva 8.2.1.1.3. Associao Ternria Mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes. Ela mostrada como uma grade losango (diamante) e ainda suporta uma associao de classe ligada a ela, traaria-se, ento, uma linha tracejada a partir do losango para a classe onde seria feita a associao ternria.
3o ano Informtica
Figura 5. Exemplo de uma associao ternria (no exemplo acima a associao ternria especfica que um cliente poder possuir 1 ou mais contratos e cada contrato ser composto de 1 ou vrias regras contratuais). Agregao A agregao um caso particular da associao. A agregao indica que uma das classes do relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para identificar uma agregao so: "consiste em", "contm", " parte de". - uma forma especializada de associao na qual um todo relacionado com suas partes (tambm conhecida como relao de contedo). - representada como uma linha de associao com um diamante junto Classe agregadora (Figura.6.). - A multiplicidade representada da mesma maneira que nas associaes.
Figura 6. Exemplo de agregao 8.2.1.3. Generalizaes
A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais particularidades. Um objecto mais especfico pode ser usado como uma instncia do elemento mais geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados em outros. Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta.
3o ano Informtica
8.2.1.3.1. Generalizao Normal Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdados.
Figura 7. Exemplo de uma generalizao normal Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes. A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalizao.
8.2.1.3.2. Generalizao Restrita Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem as generalizaes restritas com mais de uma subclasse: Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio significa que quando subclasses herdam de uma superclasse por sobreposio, novas subclasses destas podem herdar de mais de uma subclasse. A generalizao disjuntiva exactamente o contrrio da sobreposio e a generalizao utilizada como padro.
Figura 8. Exemplo de uma generalizao de sobreposio

3o ano Informtica
Generalizaes Completa e Incompleta: Uma restrio simbolizando que uma generalizao completa significa que todas as subclasses j foram especificadas, e no existe mais possibilidade de outra generalizao a partir daquele ponto. A generalizao incompleta exactamente o contrrio da completa e assumida como padro da linguagem.
Figura 9. Exemplo de uma generalizao de completa 8.3. Pacotes Um pacote um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados. Em UML, um pacote definido como: "Um mecanismo de propsito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que so ligados ou referenciados por um pacote so chamados de "Contedo do pacote". Um pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em outros pacotes.
Figura 10. Exemplo de pacotes em Use Case
3o ano Informtica
Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de elemento importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes no possuam semnticas definidas para suas instncias. Os relacionamentos permitidos entre pacotes so de dependncia, refinamento e generalizao (herana). O pacote tem uma grande similaridade com a agregao (relacionamento visto anteriormente). O fato de um pacote ser composto de modelos de elementos cria uma agregao de composio. Se este for destrudo, todo o seu contedo tambm ser. 8.4. Componentes Um componente pode ser tanto um cdigo em linguagem de programao como um cdigo executvel j compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo.Java ou.Class um componente do sistema, e ser mostrado no diagrama de componentes que os utiliza.
Figura 11. Exemplo de Componentes 8.5. Mecanismos Gerais A UML utiliza alguns mecanismos em seus diagramas para tratar informaes adicionais. Ornamentos: Ornamentos grficos so anexados aos modelos de elementos em diagramas e adicionam semnticas ao elemento. Um exemplo de um ornamento o da tcnica de separar um tipo de uma instncia. Quando um elemento representa um tipo, seu nome mostrado em negrito. Quando o mesmo elemento representa a instncia de um tipo, seu nome escrito sublinhado e pode significar tanto o nome da instncia quanto o nome do tipo. Outros ornamentos so os de especificao de multiplicidade de relacionamentos, onde a multiplicidade um nmero ou um intervalo que indica quantas instncias de um tipo conectado pode estar envolvido na relao.
3o ano Informtica
Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem importar o quanto extensa ela seja. Para permitir adicionar informaes a um modelo no poderia ser representado de outra forma, UML oferece a capacidade de adicionar Notas. Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informao.
Figura 12. Exemplo de Nota
9. Diagrama de Classes O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas representam as "coisas" que so geridas pela aplicao modelada. Classes podem se relacionar com outras atravs de diversas maneiras: associao (conectadas entre si), dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma especializao de outra classe), ou em pacotes (classes agrupadas por caractersticas similares). Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas estruturas internas, que so os atributos e operaes. O diagrama de classes considerado esttico j que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes que esto inseridas em um nico diagrama e uma certa classe pode participar de vrios diagramas de classes. Uma classe num diagrama pode ser directamente implementada utilizando-se uma linguagem de programao orientada a objectos que tenha suporte directo para construo de classes. Para criar um diagrama de classes, as classes tm que estar identificadas, descritas e relacionadas entre si. Uma classe representada por um rectngulo. Internamente deve constar seu nome, em negrito com primeira letra em maiscula, geralmente um substantivo.
3o ano Informtica
Uma classe possui atributos, que so exibidos em sesso inferior ao nome da classe:
Atributos e operadores possuem uma visibilidade, que pode ser: ~: de pacote: significa que as classes de um pacote podem ser usadas +: publico #: protegido -: Privado Atributos tm um tipo de dado e podem ainda apresentar um valor padro, note que na classe abaixo, o atributo Nome do tipo String o valor padro, representado pelo smbolo de igual, Fernando:
As operaes so representadas em uma terceira sesso do rectngulo, abaixo dos atributos. No diagrama abaixo temos as operaes Andar e Dormir:
Operadores podem ter direco: in, out, inout. isQuery: indica que a operao no altera o valor de nenhum atributo. Um operador pode ter uma pr-condio, por exemplo, ser verdadeiro antes da execuo. As operaes podem ainda demonstrar sua assinatura, que so os parmetros que so passados para a operao, bem como seus tipos e possveis tipos de dados de valores de retorno. Na
3o ano Informtica
classe abaixo, a operao andar recebe como parmetros um tipo direco, e retorna um valor booleano:
Um artifcio no muito utilizado adicionar uma quarta sesso ao diagrama contendo a responsabilidade da classe, ou seja, o que ela deve fazer:
Tambm se podem colocar restries para a classe, que normalmente so indicadas entre chaves, na lateral da classe, e utilizam expresses booleanas comuns.
Figura 13. Diagrama de Classes
3o ano Informtica
10.
Diagrama de Objectos
O diagrama de objectos uma variao do diagrama de classes e utiliza quase a mesma notao. A diferena que o diagrama de objectos mostra os objectos que foram instanciados das classes. O diagrama de objectos como se fosse o perfil do sistema em um certo momento de sua execuo. A mesma notao do diagrama de classes utilizada com 2 excepes: os objectos so escritos com seus nomes sublinhados e todas as instncias num relacionamento so mostradas. Os diagramas de objectos no so to importantes como os diagramas de classes, mas eles so muito teis para exemplificar diagramas complexos de classes ajudando muito em sua compreenso. Diagramas de objectos tambm so usados como parte dos diagramas de colaborao, onde a colaborao dinmica entre os objectos do sistema so mostrados.
Figura 14. Diagrama de Objectos
11.
Diagrama de Estado
O diagrama de estado tipicamente um complemento para a descrio das classes. Este diagrama mostra todos os estados possveis que objectos de uma certa classe podem se encontrar e mostra tambm quais so os eventos do sistema que provocam tais mudanas. Os diagramas de estado no so escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um nmero definido de estados conhecidos e onde o comportamento das classes afectado e modificado pelos diferentes estados. Diagramas de estado capturam o ciclo de vida dos objectos, subsistemas e sistemas. Eles mostram os estados que um objecto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condies sendo satisfeitas) afectam estes estados ao passar do tempo.
3o ano Informtica
Figura 15. Diagrama de Estado Diagramas de estado possuem um ponto de incio e vrios pontos de finalizao. Um ponto de incio (estado inicial) mostrado como um crculo todo preenchido, e um ponto de finalizao (estado final) mostrado como um crculo em volta de um outro crculo menor preenchido. Um estado mostrado como um rectngulo com cantos arredondados. Entre os estados esto as transies, mostrados como uma linha com uma seta no final de um dos estados. A transio pode ser nomeada com o seu evento causador. Quando o evento acontece, a transio de um estado para outro executada ou disparada. Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um evento ligado a ela, a mesma ocorrer quando a aco interna do cdigo do estado for executada (se existir aces internas como entrar, sair, fazer ou outras aces definidas pelo desenvolvedor). Ento quando todas as aces forem executadas pelo estado, a transio ser disparada e sero iniciadas as actividades do prximo estado no diagrama de estados. 12. Diagrama de Actividade
Diagramas de actividade capturam aces e seus resultados. Eles focam o trabalho executado na implementao de uma operao (mtodo), e suas actividades numa instncia de um objecto. O diagrama de actividade uma variao do diagrama de estado e possui um propsito um pouco diferente do diagrama de estado, que o de capturar aces (trabalho e actividades que sero executados) e seus resultados em termos das mudanas de estados dos objectos. Os estados no diagrama de actividade mudam para um prximo estgio quando uma aco executada (sem ser necessrio especificar nenhum evento como no diagrama de estado). Outra diferena entre o diagrama de actividade e o de estado que podem ser colocadas
3o ano Informtica
como "swimlanes". Uma swimlane agrupa actividades, com respeito a quem responsvel e onde estas atividades residem na organizao, e representada por rectngulos que englobam todos os objectos que esto ligados a ela (swimlane). Um diagrama de actividade uma maneira alternativa de se mostrar interaces, com a possibilidade de expressar como as aces so executadas, o que elas fazem (mudanas dos estados dos objectos), quando elas so executadas (sequncia das aces), e onde elas acontecem (swimlanes). Um diagrama de actividade pode ser usado com diferentes propsitos inclusive: Para capturar os trabalhos que sero executados quando uma operao disparada (aces). Este o uso mais comum para o diagrama de actividade; Para capturar o trabalho interno em um objecto; Para mostrar como um grupo de aces relacionadas podem ser executadas, e como elas vo afectar os objectos em torno delas; Para mostrar como uma instncia pode ser executada em termos de aces e objectos; Para mostrar como um negcio funciona em termos de trabalhadores (atores), fluxos de trabalho, organizao, e objectos (factores fsicos e intelectuais usados no negcio). O diagrama de actividade mostra o fluxo sequencial das actividades, normalmente utilizado para demonstrar as actividades executadas por uma operao especfica do sistema. Consistem em estados de aco, que contm a especificao de uma actividade a ser desempenhada por uma operao do sistema. Decises e condies, como execuo paralela, tambm podem ser mostradas no diagrama de actividade. O diagrama tambm pode conter especificaes de mensagens enviadas e recebidas como partes de aces executadas.
Figura 16. Diagrama de Actividade
3o ano Informtica
13.
Diagrama de Sequncia
Em um sistema computacional orientado a objecto os servios (casos de uso) so fornecidos atravs da colaborao de grupos. Os objectos interagem atravs de comunicaes de forma que juntos, cada um com suas responsabilidades, realizem os casos de uso. O Diagrama de sequncia uma ferramenta importante no projecto de sistemas orientados a objectos. Embora a elaborao dos diagramas possa consumir um tempo considervel para sistemas maiores ou mais complexos, eles oferecem a seguir as bases para a definio de uma boa parte do projecto como: os relacionamentos necessrios entre as classes, mtodos e atributos das classes e comportamento dinmico dos objectos. Um diagrama de sequncia um diagrama de objectos, ou seja, ele contm como primitiva principal um conjunto de objectos de diferentes classes. O objectivo dos diagramas de sequncia descrever as comunicaes necessrias entre objectos para a realizao dos processos em um sistema computacional. Os diagramas de sequncia tm este nome porque descrevem ao longo de uma linha de tempo a sequncia de comunicaes entre objectos. Como podem existir muitos processos em um sistema computacional, sugere-se proceder construo dos diagramas de sequncia por caso de uso. Assim, tomar-se-a separadamente cada caso de uso para a construo de seus diagramas de sequncia. De uma forma geral, para cada caso de uso constri-se um diagrama de sequncia principal descrevendo as sequncias normais de comunicao entre objectos e diagramas complementares descrevendo sequncias alternativas e tratamento de situaes de erro. Utiliza-se tambm o termo cenrio associado com os diagramas de sequncia. Um cenrio uma forma de ocorrncia de um caso de uso. Como o processo de um caso de uso pode ser realizado de diferentes formas, para descrever a realizao de um caso de uso pode ser necessrio estudar vrios cenrios. Cada cenrio pode ser descrito por um diagrama de sequncia. No exemplo do caso de uso Cadastrar Aluno do sistema de controlo acadmico, podem-se considerar os cenrios de incluso, alterao e excluso de aluno.
13.1. Notao UML para Diagramas de Sequncia A notao UML para descrio de diagramas de sequncia envolve a indicao do conjunto de objectos envolvidos em um cenrio e a especificao das mensagens trocadas entre estes objectos ao longo de uma linha de tempo. Os objectos so colocados em linha na parte superior do diagrama. Linhas verticais tracejadas so traadas da base dos objectos at a
3o ano Informtica
parte inferior do diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante inicial e, medida que se avana para baixo evolui-se o tempo. Rectngulos colocados sobre as linhas de tempo dos objectos indicam os perodos de activao do objecto. Durante um perodo de activao, o objecto respectivo esta em execuo realizando algum processamento. Nos perodos em que o objecto no esta activo, ele esta alocado (ele existe), mas no esta executando nenhuma instruo. A figura abaixo ilustra a estrutura bsica de um diagrama de sequncia para o cenrio Incluso de Aluno do caso de uso Cadastrar Aluno.
Figura 17. Exemplo de estrutura bsica de um diagrama de sequncia para o cenrio Incluso de Aluno Outra primitiva importante dos diagramas de sequncia a troca de mensagem. Esta primitiva utilizada para indicar os momentos de inteirao ou comunicao entre os objectos. Utiliza-se como notao para trocas de mensagens segmentos de rectas direccionadas da linha de tempo de um objecto origem para a linha de tempo de um objecto destino. Uma seta colocada na extremidade do objecto destino. As linhas representando troca de mensagens so desenhadas na horizontal, pois se presume que a troca de uma mensagem consome um tempo desprezvel. O objecto destino de uma mensagem deve receber a mensagem e processa-la. Desta forma, no recebimento de uma mensagem o objecto destino activado para tratamento da mensagem.
3o ano Informtica
Figura 18. Troca de mensagens entre objectos e entre actores e objectos em um diagrama de sequncia. As mensagens trocadas entre um objecto ou entre um objecto e um actor podem ter trs significados: - Chamada de Funo ou Procedimento Uma das inteiraes mais frequentes entre objectos a chamada de funo. Uma chamada de funo significa que um objecto esta solicitando a execuo de uma funo (um mtodo) de um outro objecto. Este conceito segue estritamente o processo de chamada de fu no ou de procedimento utilizado nas linguagens de programao. Obviamente, para que um objecto possa chamar um mtodo de outro objecto necessrio que o mtodo seja declarado como publico na classe respectiva. A sintaxe, no caso de mensagens que representem chamadas de funo, semelhante quela das linguagens de programao. - Envio de Mensagem Objectos tambm podem comunicar-se com outros objectos atravs do envio explcito de uma mensagem. O envio de uma mensagem, ao contrrio da chamada de funo, no uma inteirao directa entre dois objectos. Na verdade, quando um objecto envia uma mensagem a outro objecto, a mensagem roteada ou encaminhada por algum mecanismo de entrega de mensagens. Normalmente, este servio prestado pelo sistema operativo atravs de mecanismos como Message Queries (filas de mensagens) ou servios de notificao. - Ocorrncia de Evento Existem tambm outras formas de inteirao entre objectos atravs de eventos. Esta tambm a forma padro de inteirao entre objectos e actores. Basicamente, um evento
3o ano Informtica
algum acontecimento externo ao software, mas que a ele notificado, pois lhe diz respeito. A notificao, ou seja, a indicao de que um determinado evento ocorreu , na maioria dos casos, feita pelo sistema operativo. Eventos podem tambm ser gerados pelo software para o sistema operativo. Exemplos so as sadas para dispositivos (monitor, porta serial, disco) feitos atravs de servios do sistema operativo. Alguns exemplos de eventos so:
Evento
Origem
Destino
Clique do mouse Movimentao do mouse Dados no buffer do teclado Dados no buffer da serial Projeo de dados no monitor. Bip do alto-falante. Colocao de dados no buffer da serial Interrupo Eventos do sistema operacional (timer)
mouse mouse teclado porta serial Algum objecto Algum objecto Algum objecto Dispositivo de hardware Sistema operacional
Algum objecto Algum objecto Algum objecto Algum objecto monitor alto-falante Porta serial Algum objecto Algum objecto
Tabela 3. Exemplos de eventos Tipos de Mensagens Nos exemplos das figuras utilizou-se como notao grfica para as trocas de mensagens segmentos de recta com uma seta aberta em uma das extremidades. Esta a notao genrica para mensagens que pode ser utilizada nas primeiras verses dos diagramas de sequncia. Em diagramas mais detalhados, entretanto, ser utilizada outra notao deforma a indicar tambm o tipo das mensagens. Existem dois tipos de mensagens chamadas mensagens sncronas e assncronas.
3o ano Informtica
- Mensagens Sncronas Mensagens sncronas so mensagens que implicam um sincronismo rgido entre os estados do objecto que envia a mensagem e os do objecto de destino da mensagem. Um sincronismo entre objectos pode ser entendido, de uma forma geral, como uma dependncia na evoluo de estado de um objecto sobre o estado de um segundo objecto. De uma forma mais directa, pode-se dizer que uma mensagem sncrona implica que o objecto que enviou a mensagem aguarde a concluso do processamento da mensagem (entendida como um sinal de sincronismo) feito pelo objecto destino, para ento prosseguir seu fluxo de execuo. O exemplo mais comum de mensagem sncrona a chamada de funo. Em uma chamada de funo o objecto que faz a chamada empilhado e fica neste estado at a concluso do processamento da funo chamada. Trata-se, portanto, de um sincronismo rgido entre o objecto que faz a chamada chamador e o objecto chamado. Alguns sistemas operativos oferecem tambm mecanismos de troca de mensagens sncronas de forma que o objecto que envia a mensagem fique em estado de espera at a concluso do tratamento da mensagem. A notao UML para uma mensagem sncrona a de um segmento de recta com uma seta cheia em uma das extremidades -Mensagens Assncronas Mensagens assncronas so mensagens enviadas de um objecto a outro sem que haja uma dependncia de estado entre os dois objectos. O objecto de origem envia a mensagem e prossegue seu processamento independentemente do tratamento da mensagem feita no objecto destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais so o exemplo mais comum deste tipo de mensagem. Alm disso, de uma forma geral, todas as comunicaes entre actores e objectos representam trocas de mensagem assncronas. Considere, por exemplo, uma operao para apresentao de uma mensagem no monitor. Um objecto executa uma instruo print (ou print ou write) e o sistema despacha a mensagem para o actor (o monitor). O objecto prossegue seu processamento independentemente do desfecho na operao. Observe que os softwares no bloqueiam quando o monitor no apresenta alguma informao. A notao UML para uma mensagem assncrona a de um segmento de recta com uma meia seta em uma das extremidades. Autodelegao Um objecto pode enviar mensagens para outros objectos e pode tambm enviar mensagens para ele prprio. Uma mensagem enviada de um objecto para ele prprio chama-se uma
3o ano Informtica
Autodelegao. Mensagens de Autodelegao podem ser sncronas ou assncronas. O caso mais comum de mensagens assncronas o envio de uma mensagem de um objecto para ele mesmo atravs de mecanismos de envio de mensagens do sistema operacional. O caso mais comum de mensagens de Autodelegao sncronas a chamada de funo de um objecto pelo prprio objecto.
Figura 19. Exemplo de autodelegao
14.
Diagrama de Componente
O diagrama de componente e o de execuo so diagramas que mostram o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante sua execuo. O diagrama de componente descreve os componentes de software e suas dependncias entre si, representando a estrutura do cdigo gerado. Os componentes so a implementao na arquitectura fsica dos conceitos e da funcionalidade definidos na arquitectura lgica (classes, objectos e seus relacionamentos). Eles so tipicamente os arquivos implementados no ambiente de desenvolvimento. Um componente mostrado em UML como um rectngulo com uma elipse e dois rectngulos menores do seu lado esquerdo. O nome do componente escrito abaixo ou dentro de seu smbolo. Componentes so tipos, mas apenas componentes executveis podem ter instncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instncias de
3o ano Informtica
componentes, deve ser usado um diagrama de execuo, onde as instncias executveis so alocadas em nodes. A dependncia entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definio completa. Com o diagrama de componentes facilmente visvel detectar que arquivos .dll so necessrios para executar a aplicao.
Figura 20. Exemplo de Diagrama de Componentes Componentes podem definir interfaces que so visveis para outros componentes. As interfaces podem ser tanto definidas ao nvel de codificao (como em Java) quanto em interfaces binrias usadas em run-time (como em OLE). Uma interface mostrada como uma linha partindo do componente e com um crculo na outra extremidade. O nome colocado junto do crculo no final da linha. Dependncias entre componentes podem ento apontar para a interface do componente que est sendo usada.
3o ano Informtica
15.
Diagrama de Instalao
Figura 21. Exemplo de diagrama de instalao. 16. Resumo Hierrquico dos Diagramas da UML
Tabela 4. Hierarquia de Diagramas da UML
3o ano Informtica
17.
Concluso
A organizao da modelagem em vises e a diviso dos diagramas especificando caractersticas estticas e dinmicas do sistema tornou a UML fcil de ser utilizada e fez com que qualquer tipo de comportamento possa ser visualizado em diagramas. A modelagem visual orientada a objectos agora possui um padro, e esse padro extremamente simples de ser escrito a mo, sendo robusto para especificar e descrever a grande parte das funes, relacionamentos e tcnicas de desenvolvimento orientado a objectos que hoje so utilizados. Novas tcnicas iro surgir e a UML tambm estar preparada j que tudo estar baseado nas ideias elementares da orientao a objectos. Tanto o modelo ER assim como a UML, apresentam muitos conceitos semelhantes (relacionamento, objectos, associao) entre si, embora alguns casos com certa especificidade. A UML apresentasse como uma evoluo de diferentes mtodos e modelos como o caso do prprio modelo MER, dai que se nota a presena de alguns conceitos do MER na UML. Importa salientar que a UML apresentar vrios diagramas pelo facto de cada diagrama fornecer uma perspectiva parcial sobre o sistema sendo modelado, consistente com as demais perspectivas. Apesar da versatilidade da UML na orientao a objectos, o MER ainda continua sendo utilizada.
3o ano Informtica
18.
Bibliografia
- FELIPE, M., Maurcio, A., Projecto de Banco de Dados: uma viso pratica, 11aEdio, Editora rica Ltda, So Paulo, 2004. - BEZERRA, E., Princpios de Anlise e Projectos de Sistemas com UML, 3aEdio, Editora Campus. - BOOCH, G., Rumbaugh, J., Jacobson, I., UML Guia do Usurio 11 a Edio, Editora Campus, Rio de Janeiro, 2000. - Scott, Kendall (URL). Dicionrio UML. http://www.usecasedriven.com/UML.htm

UML: Uma introdução à linguagem de modelação unificada

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UML: Uma introdução à linguagem de modelação unificada

Загружено:

Авторское право:

Доступные форматы

ndice

9. 10. 11. 12. 13.

13.1. 14. 15. 16. 17. 18.

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 1

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 2

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 3

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 4

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 6

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 7

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 9

Utilizao Todos os diagramas. Diagramas de casos de utilizao.

Diagramas de casos de utilizao.

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 10

Utilizao Diagramas de classes.

Diagramas de classes e de casos de utilizao.

Diagramas de classes, casos de utilizao e de instalao.

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 11

Utilizao Diagramas de classes.

Bifurcao ou confluncia Nodo

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 12

Designao Instncia de um nodo

Utilizao Diagramas de instalao.

Diagramas de classes de anlise.

Diagramas de classes de anlise.

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 13

Designao Mensagem sncrona

Utilizao Diagramas de sequncia.

Chamada de procedimento Mensagem de retorno Activao

Tabela 2. Elementos grficos da linguagem UML

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 14

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 16

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 18

Figura 6. Exemplo de agregao 8.2.1.3. Generalizaes

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 19

Figura 8. Exemplo de uma generalizao de sobreposio

Figura 10. Exemplo de pacotes em Use Case

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 21

Figura 12. Exemplo de Nota

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 23

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 24

Figura 13. Diagrama de Classes

Elaborado por: M. Cunha, A. Maxalhaieie e G.Sacate

Maputo, Outubro de 2009 25

Figura 14. Diagrama de Objectos