ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML CAP. 4 UML VISÃO GERAL Tópicos Introdução Visão Histórica Tipos de Elementos Básicos Tipos de Relações Tipos de Diagramas Mecanismos Comuns TiposdeDados Organização dos Artefactos/Pacotes 2 Introdução 3 Introdução 4 O UML(Unified Modeling Language) é uma linguagem para especificação, construção, visualização e Documentação de artefactos de um sistema de software. O UNL é promovido pelo Object Management Group (OMG), com contribuições 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. O UML providencia as seguintes particularidades principais: Semântica e notação para tratar um grande número de tópicos atuais de modelação. Semântica para tratar tópicos de modelação futura, relacionados em particular com a tecnologia de componentes, computação distribuída, frameworks, e Internet. Mecanismos de extensão de modo a permitir que futuras aproximações e notações de modelação possam continuar a ser desenvolvidas sobre o UML. Semântica e sintaxe para facilitar a troca de modelos entre ferramentas distintas.
Introdução 5 Introdução 6 OUMLalargaoâmbitodeaplicaçõesalvo,poispermite,porexemplo, a modelação de sistemas concorrentes, distribuídos, paraaweb, de informação geográficos, O ponto forte do UML está na definição de uma linguagem de modelação standard, logo é independente das linguagens de programação, das ferramentas CASE, bem como dos processos de desenvolvimento. ObjetivodoUML: adotar diferentes processos/metodologias, mantendo-se contudo a utilização da mesma linguagem de modelação em função dotipodeprojeto, daferramentadesuporte,ou da organização envolvida. O UML é independente das ferramentas de modelação. Princípios básicos no esforço de definição do UML: simplicidade, coerência na unificação de diferentes elementos existentes em vários métodos, e introdução de novos elementos apenas quando tal fosse absolutamente necessário(quando tais elementos não existissem em métodos anteriores). Introdução 7 Introdução 8 Os novos elementos introduzidos no UML são: O UML providencia os seguintes tipos de diagramas: Mecanismos de extensão, Diagramas de casos de uso/utilização Elementos para modelar processos e threads, Diagramas de classes e diagramas de objetos Elementos para modelar distribuição e concorrência, Diagramas de comportamento Padrões de desenho e colaborações, Diagramas de estados(statechart) Diagramas de atividades(para modelação de processos de negócio), Refinamento(para tratar relações entre diferentes níveis de abstração), Interfaces e componentes, e Linguagem de restrições(object Contraint Language). Diagramas de atividades Diagramas de interação(diagramas de sequência e diagramas de colaboração) Diagramas de arquitetura: Diagramas de componentes Diagramas de instalação
Visão Histórica 9 Visão Histórica 10 VisãohistóricadoUML Fase da fragmentação(primeira metade da década de 1990): Proliferação de métodos e notações para modelação segundo a abordagem orientado por objetos. Por essa altura percebeu-se a necessidade da existência de uma linguagem queviesseatornar-seumanorma, que fosse aceite e utilizada quer pela indústria, quer pelos ambientes académicos e de investigação. Fase da unificação(1996): Surgiu o UML como melhor posicionado como a linguagem unificadora de notações, diagramas e formas de representação existentes em diferentes métodos. Visão Histórica 11 Visão Histórica 12 Fase da standardização(1997): um esforço significativo na unificação com contributos de vários parceiros comvistaànormalizaçãonoâmbitodaomg. Fase da industrialização(a partir de 1998): Assiste-se à divulgação e adoção generalizada do UML como a linguagem de modelação de software segundo a abordagem orientada por objetos. Assiste-se ao aparecimento de publicações específicas sobre UML; teses, relatórios e artigos técnico-científicos que usam o UML; ferramentas CASE que suportam o UML: HádoisaspetosimportantesqueseobtêmcomoUML: (1) terminam as diferenças, geralmente inconsequentes, entre as linguagens de modelação dos anteriores métodos; e (2) unifica as distintas perspetivas entre diferentes tipos de sistemas (e.g., modelação de negócio vs. modelação de software), fases de um processo e conceitos internos. Preocupações mais significativos no desenho e especificação do UML: foi torná-lo extensível e aberto a futuras evoluções. O objetivo é que seja possível estender o UML sem ser necessário redefinir o seu núcleo principal.
Tipos de Elementos Básicos 13 Tipos de Elementos Básicos 14 AestruturadeconceitosdoUMLpodeservistaatravésdasseguintes noções: (1) coisas ou elementos básicos, com base nos quais se definem os modelos; (2) relações, que relacionam elementos; e (3) diagramas, que agrupam elementos. Os elementos encontram-se organizados consoante a sua funcionalidade ou responsabilidade. Assim, há elementos: de estrutura, de comportamento, de agrupamento, e de anotação. Resumo dos elementos de estrutura: classes, classes ativas, interfaces, casos de uso/utilização, atores, colaborações, componentes e nós. Tipos de Elementos Básicos 15 Tipos de Relações 16 Resumo dos elementos de comportamento(estados e mensagens), agrupamento(pacotes), e anotação(anotações ou notas). As relações são conceitos gerais que apresentam uma sintaxe(neste caso, uma notação), e uma semântica bem definida; permitem o estabelecimento de interdependências entre os elementos básicos. OsprincipaistiposderelaçõesdoUMLsãoosseguintes: associação, dependência, realização, generalização, e transição de estado.
Tipos de Relações 17 Tipos de Diagramas 18 Resumo dos tipos de relações standard: Diagramas são conceitos que traduzem a possibilidade de agrupar elementos básicos e assuasrelaçõesdeumaformalógicaoudeumaformaestrutural. 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 básicos, com diferentes tipos de relações que tenha sentido existir. Com base no princípio de modelação P4, definiu diferentes tipos de diagramas, cuja utilização e aplicação permitem visões complementares. Os diagramas podem mostrar todas ou parte das características dos elementos do modelo, com um nível de detalhe que seja apropriado no contexto de um tipo de diagrama. Tipos de Diagramas 19 Tipos de Diagramas Diagramas de Casos de Uso/Utilização 20 Tipos de diagramas: Diagramas de Casos de Uso/Utilização: Diagramas de Casos de Uso/Utilização Diagramas de Modelação da Estrutura: Diagramas de classes, e Diagramas de objetos. Diagramas de Modelação do Comportamento: Diagramas de interação entre objetos: diagramas de sequência, e diagramas de colaboração, Diagramas de transição de estados, e Diagramas de atividades. Diagramas de Arquitetura: Diagramas de componentes e Diagramas de instalação Diagramas de Casos de Uso/Utilização Representam a visão do sistema na perspetiva do seu utilizador. Descrevemarelaçãoentreatoresecasosdeutilizaçãodeumdadosistema. Permitem dar uma visão global e de alto nível do sistema, sendo fundamental a definição correta da sua fronteira. São utilizados preferencialmente na fase de especificação de requisitos e na modelação de processos de negócio.
Tipos de Diagramas Diagramas de Casos de Uso/Utilização 21 Tipos de Diagramas Diagramas de Modelação da Estrutura 22 Exemplo de um diagrama de Casos de Uso/Utilização Diagrama de Modelação da Estrutura Permite especificar a estrutura estática de um sistema segundo a abordagem orientada por objetos. Podeserdedoistipos:declassesoudeobjetos. Diagrama de Classes Descrevem a estrutura estática de um sistema, em particular as entidades existentes, as suas estruturas internas, e relações entre si. Diagrama de Objetos Descreve um conjunto de instâncias compatíveis com determinado diagrama de classes. Permite ilustrar os detalhes de um sistema em determinado momento ao providenciarem cenários de possíveis configurações. Tipos de Diagramas Diagramas de Modelação da Estrutura 23 Tipos de Diagramas Diagramas de Modelação do Comportamento 24 Exemplodeumdiagramadeclasses. Diagramas de Modelação do Comportamento Permitem especificar a dinâmica ou o comportamento de um sistema segundo a abordagem orientada por objetos. Sãode3tipos: Diagramas de interação entre objetos(de sequência e de colaboração). Diagramas de transição de estados, e Diagramas de atividades.
Tipos de Diagramas Diagramas de Modelação do Comportamento 25 Tipos de Diagramas Diagramas de Modelação do Comportamento 26 Diagramas de Interação entre Objetos Assumem duas formas complementares, cada uma focando um aspeto distinto: diagramas de sequência, e diagramas de colaboração. Diagramas de Sequência Ilustram interações entre objetos num determinado período de tempo. Osobjetos são representados pelas suas linhas de vida e interagem por troca de mensagens ao longo de um determinado período de tempo. Exemplo de um diagrama de Sequência Tipos de Diagramas Diagramas de Modelação do Comportamento 27 Tipos de Diagramas Diagramas de Modelação do Comportamento 28 Diagramas de Colaboração Ilustram interações entre objetos com ênfase para a representação das ligações entre objetos. Como estes diagramas não mostram o tempo como um elemento explícito (tal como acontece nos diagramas de sequência), a sequência de mensagens e de atividades concorrentes é determinada usando-se números sequenciais, com diferentes níveis hierárquicos. Colaborações são entidades de modelação principais e constituem geralmente a base para a representação visual de padrões de desenho. Diagramas de Transição de Estado Descrevemassequênciasdeestadosqueumobjetoouumainteraçãopode passar ao longo da sua existência em resposta a estímulos recebidos, conjuntamente com as suas respostas e ações. Diagramas de Atividades Sãoumcasoparticulardosdiagramasdetransiçãodeestado,noqual a maioria dos estados são substituídos pelos conceitos correspondentes a ações e/ou atividades, e as transições são desencadeadas devido à conclusão de ações 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).
Tipos de Diagramas Diagramas de Modelação do Comportamento 29 Tipos de Diagramas Diagramas de Modelação de Estrutura 30 Exemplo de um diagrama de Atividades Diagramas de Modelação de Estrutura Dão uma visão da disposição dos componentes físicos(software e hardware) de um sistema. Descrevem aspetos da fase de implementação de um sistema de software, por exemplo, relativamente à estrutura e dependências de módulos de código fonte e de módulos executáveis. Apresentam-se sob duas formas: diagramas de componentes e diagramas de instalação. Tipos de Diagramas Diagramas de Modelação de Estrutura 31 Tipos de Diagramas Diagramas de Modelação de Estrutura 32 Diagramas de Componentes Descrevem as dependências entre componentes de software, incluindo componentes de código fonte, código binário e executáveis. Sãorepresentadosnaformadetiposenãonaformadeinstâncias. Diagramas de Instalação Descrevem a configuração de elementos de suporte de processamento, e de componentes de software, processos e objetos existentes nesses elementos. Exemplo de um diagrama de Instalação
Mecanismos Comuns 33 Mecanismos Comuns - Notas 34 OUMLcontémumconjuntodemecanismoscomunsquesãoaplicados de modo consistente ao longo dos seus diferentes diagramas. Os dois mecanismos comuns mais usados são os seguintes: Notas/Anotações, e Mecanismos de extensão. Notas/Anotações São os adornos mais importantes que existem autonomamente (sem estarem diretamente associados a outros elementos). Ilustram comentários e não tem qualquer impacto semântico, já que os seus conteúdos não alteram o significado do modelo no qual se encontram. É normal a utilização de notas para se descrever informalmente: Requisitos, Restrições, Observações, Revisões, ou Explicações. Mecanismos Comuns - Notas 35 36 Observações a serem consideradas aquando da utilização de notas: Localização: devem ser colocadas graficamente perto dos elementos que descrevem. Visibilidade: podem-se esconder ou tornar visíveis(isto dependendo das ferramentas de suporte). Extensão: devem-se usar referências (nomes de documentos ou URL) caso se pretenda um comentário mais extenso. Evolução: há medida que o modelo evolui as notas mais antigas (cuja relevância e utilidade deixem de ter sentido) devem ser eliminadas dos modelos. O UML providencia os seguintes mecanismos que permitem estender a sua linguagem de forma consistente: Estereótipos, Marcas,e Restrições. Alguns dos aspetos na aplicação destes mecanismos, são os seguintes: Introduzir um número reduzido destes elementos. Escolher nomes curtos e com significado para estereótipos e marcas. Sempre que a precisão puder ser relaxada, usar texto livre para especificação das restrições(caso contrário, usar a linguagem OCL). A definição destes mecanismos de extensão do UML, em particular a introdução de estereótipos, deve ser realizada por um número restrito de especialistas em UML e deve ser devidamente documentado.
37 38 Estereótipos Um estereótipo é 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. Onomedeumestereótipoérepresentadoentreoscaracteres «e». Exemplos: Na modelação de processos de negócio:«trabalhador»,«documento»,«política». Na modelação de aplicações específicas: classes de «interface», «controlo», e «entidade». Na modelação de aplicações Web, usando o Web Application Extension: classes de «Server Page»,«Client Page»,«Form»,«Select Element». Estereótipos (exemplo) A figura ilustra três formas complementares de apresentação de estereótipos: com ícone(sensortemperatura), com nome(modelelement), e comnomeeícone(overflow). 39 40 Estereótipos Adefiniçãodeumestereótipotemdeteremcontaosseguintesaspetos: Propriedades(pode providenciar o seu próprio conjunto de marcas), Semântica(pode providenciar as suas próprias restrições), Notação(pode providenciar o seu próprio ícone), e Aclassebasedometa-modeloquevaiserestendida(seoestereótipoestendeuma classe, uma associação, um componente, etc.) Marcas com Valor Cada elemento em UML tem um conjunto de propriedades; por exemplo: asclassestêmumnome,umalistadeatributoseumalistadeoperações; as associações têm 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 estereótipos. É um conceito que deve ser entendido como meta-data (isto é, dados que descrevem dados) pois o seu valor aplica-se ao próprio elemento e não às suas instâncias. Umpar marca e valor édelimitadoentreoscaracteres { e }.
41 42 Marcas com Valor Exemplos de aplicações usuais: Para geração de código:{language=java},{linker=blinker}. Na produção automática de documentação. Na gestão de configurações:{autor=amrs},{data=...}. Conforme ilustrado no exemplo: pode-se especificar o número 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. Restrições (constraints) Permitem adicionar ou alterar a semântica assumida por omissão de qualquer elemento UML. Consistem na especificação de uma condição delimitada pelos caracteres { e } (a condição pode ser especificada numa linguagem formal (OCL) ou informal texto em português). Permitem especificar condições que têm de ser validadas para que o modelo esteja bem definido. 43 Tipos de Dados 44 Restrições (constraints) Exemplo 1(especificação em OCL): que umapessoapodeestarcasadaapenascomoutrapessoadosexooposto Exemplo 2(especificação através da restrição{subset} predefinida em UML): que os elementos da associação gerir tem de existir obrigatoriamente na associação trabalhar, ou seja, especifica-se que uma pessoa para ser gestor de um departamento tem também de ser, necessariamente, membro desse departamento. UmtipodedadoséumaabstraçãoutilizadadeformaimplícitanoUML. Ostiposdedadosnãosãoelementosdomodeloeporconseguintenão lhe são associados estereótipos, marcas com valor ou restrições. Exemplosdetiposdedados: Primitivos: Integer, String, Time Enumerados: Boolean, AggregationKind, VisibilityKind Outros: Expression, Mapping, Name, Multiplicity Os conceitos de nomes, expressões ou multiplicidade são tipos de dados UML, definidos informalmente à custa de outros tipos primitivos: Exemplo: o tipo Multiplicity é definido como o conjunto não vazio de inteiros (Integer) positivos, estendido com o caracter * ; Exemplo: o tipo Expression é definido como uma sequência de caracteres (String) cuja sintaxe não é definida, propositadamente, pelo UML.
Organização dos Artefactos/Pacotes 45 Organização dos Artefactos/Pacotes Representação Gráfica 46 Pacote(package): É um elemento meramente organizacional. Permite agregar diferentes elementos de um sistema em grupos de forma que semântica ou estruturalmente faça sentido. Pode conter outros elementos, incluindo: classes, interfaces, componentes, nós, casos de utilização, e mesmo outros pacotes. Um elemento encontra-se definido em apenas um único pacote. A necessidade da existência de pacotes na modelação de sistemas de média/grande dimensão: impossível modelizá-los de uma só vez. Os principais benefícios da utilização de Pacotes são: (1) facilitar a gestão 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). Os pacotes são representados por uma pasta(tabbed folder) com duas zonas complementares: umpequenoretângulo(tabuladoroutab),comonomedopacote;e um retângulo maior onde se especificam os elementos constituintes desse pacote ou, pelo menos, os seus elementos públicos. Exemplos de pacotes: Organização dos Artefactos/Pacotes Representação Gráfica 47 Organização dos Artefactos/Pacotes Relações entre Pacotes 48 Exemplos de pacotes(figura anterior): Exemplo1: opacotetemonomeutilizadoresedescreveosseuselementos. Os símbolos +, - e # representam informação de visibilidade, respetivamente visibilidade pública, privada e protegida. Exemplo2: uma forma alternativa de representar um pacote em que não são apresentados os seuselementos:onomedopacoteéregrasdenegócioeencontra-secolocadono meio do retângulo maior. Exemplo3: (1) Possibilidade de relações de hierarquia ou de inclusão entre pacotes: o pacote Docentes está contido no pacote DEI e pode ser identificado univocamente pela concatenação dos vários nomes separados pelo símbolo ::. (2) Possibilidade de caracterizar o pacote através dos mecanismos comuns, tais como especificação de marcas({version=1.4}), estereótipos ou restrições. Os pacotes apresentam entre si diferentes tipos de relações de Importação, Exportação, e Generalização. Visibilidade Os símbolos +, - e # permitem indicar o tipo de visibilidade que os elementos constituintes de um pacote apresentam: Um elemento com visibilidade pública(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 especialização(através da relação de herança) do primeiro.
Organização dos Artefactos/Pacotes Relações entre Pacotes 49 Organização dos Artefactos/Pacotes Relações entre Pacotes 50 Visibilidade(cont) É possível definir-se uma relação de friend entre dois pacotes (é uma relação de dependência entre pacotes, com estereótipo«friend»). Nestecaso,umpacotequeéfrienddeoutropodeaceder/referenciartodososseus elementos independentemente da sua visibilidade. Contudo este tipo de dependência deve ser evitado sempre que possível pois viola os princípios do encapsulamento e da minimização de dependências. Importação e Exportação Um pacote faz a exportação, por definição, de todos os seus elementos públicos. Mas tal facto não implica que um elemento definido noutro pacote possa aceder/referenciar um elemento exportado num outro pacote(para que tal ocorresse deveria existir explicitamente uma relação de importação entre esses dois pacotes). A relação de importaçãoé uma relação de dependência entre pacotes, especificando que o pacote base importa todos os elementos públicos definidos no pacote destino (os elementos públicos definidos no pacote destino podem ser usados por elementos no pacote base). representada graficamente através de uma linha dirigida, a tracejado, com estereótipo«import». Organização dos Artefactos/Pacotes Relações entre Pacotes 51 Organização dos Artefactos/Pacotes Relações entre Pacotes 52 Exemplos de relações de importação/exportação entre pacotes. o elemento DataBase exportado no pacote DataServer não pode ser referenciado por qualquer elemento definido em WebDEI. WebDEI importa todos os elementos públicos definidos em DEIServlets, e este importa todos os elementos públicos definidos em javax::serlets::http. Importação e Exportação A relação de importação não é transitiva. Exemplo da figura: WebDEI importa DEIServlets, e este importa javax::serlets::http; no entanto, WebDEI não importa o javax::serlets::http. Isto é, os elementos definidos em WebDEI podem aceder aos elementos públicos de DEIServlets, mas não aos de javax::serlets::http; para tal acontecer, dever-se-ia definir explicitamente uma relação de importação entre esses dois pacotes. Arelaçãodeimportaçãonãoésimétrica. Exemplo da figura: o fato dos elementos definidos em WebDEI poderem aceder aos elementos públicos de DEIServlets não implica que o inverso seja verdade. Os elementos exportados por cada pacote devem ser do tipo interface, uma vez que providenciam uma interface de programação sem revelarem os detalhes de implementação e as relações de classes definidas internamente no respetivo pacote.
Organização dos Artefactos/Pacotes Relações entre Pacotes 53 Organização dos Artefactos/Pacotes Relações entre Pacotes 54 Generalização A relação de generalização entre pacotes é semelhante à homóloga existente entre classes, e é usada para a especificação de famílias de pacotes, típicas em sistemas complexos ou flexíveis(significativamente parametrizáveis, multi-plataforma, multi-linguagem). Exemplo(figura seguinte): opacotewebservertem duas classes públicas(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). Exemplos de relações de generalização entre pacotes. Organização dos Artefactos/Pacotes Tipos de Pacotes 55 Organização dos Artefactos/Pacotes Tipos de Pacotes 56 Nos exercícios académicos a dimensão e/ou a simplicidade do problema faz com que um pacote seja simplesmente um pacote. Em situações reais de modelação de sistemas de média/grande dimensão, realizada por equipas de vários indivíduos, torna-se necessário tipificar os próprios pacotes. A especificação atual do UML propõe 5 estereótipos standard aplicados a pacotes:«system»,«subsystem»,«facade»,«framework» e«stub». Emgeralospacotesmaisusadossãodotipo«system»e«subsystem» Poromissãoassume-sequeumpacoteédotipo«system»(seforde primeiro nível) e«subsystem»(se for de segundo ou mais nível). «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. «facade»: Pacote com elementos (tipicamente classes e interfaces) que constituem a fachada (ou a interface de programação) providenciada conjunta e coerentemente por outros pacotes. A fachada permite esconder os detalhes de arquitetura e de implementação de vários elementos eventualmente organizados em distintos pacotes. Os elementos definidos numa fachada apenas referem outros elementos definidos noutros pacotes.
Organização dos Artefactos/Pacotes Tipos de Pacotes 57 Organização dos Artefactos/Pacotes Modelação de Grupos de Elementos 58 «framework»: Um framework é uma arquitetura de classes e interfaces com inúmeros pontos de variabilidade ou de extensão e com estruturas de objetos padronizadas, conhecidas por padrões de desenho. O desenvolvimento de sistemas baseados em frameworks e em componentes «stub»: de software é um tópico emergente extremamente atual. É usado quando se pretende partir um sistema em diferentes pacotes por motivos de divisão de trabalho, quer em termos físicos/espaciais, quer em termos temporais. Permite que duas equipas consigam trabalhar paralelamente em diferentes locais, mas mantendo algum nível de interdependência. Compete a cada processo de desenvolvimento de software formalizar ou dar sugestões relativamente à forma de organizar todo o processo através de uma estrutura adequada de pacotes. Algumas das formas clássicas de organização dos artefactos de projetos em termos de pacotes, são as seguintes: Organização por casos de utilização: Aproximação em que o sistema e respetivos modelos se encontram distribuídos por pacotes, consoante os vários casos de utilização. Organização por tipos de modelos: Aproximação em que o sistema se encontra dividido por diferentes pacotes consoante as diferentes vistas, ou tipos de modelos produzidos. Porexemplo,háumpacote(comumaeventualhierarquiadepacotes)paraomodelo de casos de utilização; outro para o modelo de análise; outro para o modelo de desenho; e outro ainda para o modelo de implementação.