Modelagem de Processos_Unidade II

8/19/2019 Modelagem de Processos_Unidade II

1/33

43

MODELAGEM DE PROCESSOS

Unidade II

3 MODELO CONCEITUAL DA UML

3.1 Introdução

OObject Management Group (OMG) adotou a UML em novembro de 1997. Essa adoçem um evento histórico e marcante, pois assinalou a aceitação de uma linguagem pmodelagem de sistemas baseada nas melhores práticas atuais para a análise, projeto esoftware orientado a objetos.

Saiba mais

AObject Management Group ,ou OMG, é uma organização internacionalque aprova padrões abertos para aplicações orientadas a objetos. OObjectManagement Group foi fundado em 1989. Constantemente, a OMG publicao documento dos padrões e normativos sobre a UML no seu portal cuja URLé: .

A UML é a primeira notação que atingiu o concenso entre a maioria dos pvendedores e acadêmicos como o padrão real para expressar um domínio comercidesoftware .

Grady Booch (2000) diz que a modelagem deve atingir quatro objetivos para se torum ambiente de desenvolvimento desoftware :

• ajudar a equipe de projeto a visualizar um sistema como ele é ou como ele preten

• ajudar a especicar a estrutura ou comportamento do sistema;

• proporcionar um modelo que sirva de guia na construção do sistema;

• documentar as decisões tomadas pela equipe de desenvolvimento de projeto (REE

3.2 Visão geral da UML

A UML não é um modelo de processo/metodologia desoftware . É uma notação, um mecanismo p“mostrar o problema” de forma a expor a essência do domínio de um aplicativo.


2/33

44

Unidade II

A combinação da UML com um bom modelo de processo, tais como, o RUP (Rational Unied Process )ou o processo ágil SCRUM, resulta em uma poderosa combinação para a criação de aplsucedidos (REED JR., 2000).

A linguagem de modelos UML tem dois objetivos: um deles é proporcionar consistênco cliente ou patrocinador do projeto de que o domínio do problema está bem entendidode desenvolvedores. O outro objetivo é proporcionar um modelo de consistência paraimplementação (arquitetos e programadores), que assim poderão fazer uma implementaçdosoftware .

Lembrete

Todavia, deve car claro que somente os diagramas da UML nãoconseguem garantir o processo de desenvolvimento. Um bom modelo deprocesso e um plano adequado do projeto são fundamentais para que oprojeto não falhe.

Todos os artefatos propostos pela UML são rastreáveis e, se construídos ao longo de de desenvolvimento padronizado na empresa, os modelos podem se completar uns aoselemento da rastreabilidade é fundamental para o projeto.

Esses artefatos construídos ao longo do desenvolvimento com a UML servirão comde controle da qualidade do modelo anterior, já que se completam. Como os modelos Urelacionados na sua criação, é mais fácil identicar quando um componente está faltando ou

Todavia, a UML não resolve diretamente alguns aspectos de um projeto e, se necessutilizar outros diagramas auxiliares, como a interface gráca de usuário (GUI), a distribuiç(processamento distribuído) e a distribuição dos dados (BDs distribuídos).

3.3 Arquitetura da UML

Uma arquitetura de sistema desoftware pode ser descrita por cinco visões interconectadas. Cvisão é uma projeção na organização e estrutura do sistema, focando em um aspecto parti

As cinco visões da arquitetura UML são: visão de análise, visão dedesign, visão de implementação,visão do processo e visão da implantação. Para a UML, o modelo ou visão que interconecse dá pelo modelo decaso de uso .

A visão decaso de uso de um sistema compreende os que descrevem o comportamento do como visto pelos usuários nais, analistas e testadores.

Essa visão não especica a organização do sistema desoftware . Na UML, os aspectos estáticos dsistema são capturados no diagrama decaso de uso .


3/33

45


Os 13 diagramas da UML estão divididos em três categorias: estático, dinâmico e ar:

• Os diagramas estáticos mostram a esturutra do sistema e as responsabilidades. Esmostram a estrutura física dos elementos e não envolvem a passagem do temeles não mostram a dinâmica das coisas, simplesmente sua organização. Os trdiagramas estáticos da UML são: o modelo decaso de uso , o modelo de classes e o modede objetos.

• Um diagrama dinâmico mostra a interação ativa que o sistema suporta e detalhaentre os elementos estruturais dos diagramas estáticos.

• Essas interações dinâmicas são descobertas noscasos de uso como caminhos executadoem resposta a alguns estímulos externos ao sistema. Os diagramas dinâmicocomportamento pretendido do sistema. Os principais diagramas dinâmicos sãcomunicação, sequência e estado.

• Um diagrama arquitetural mostra a realização do sistema em componentes fexecutáveis. Eles também diferenciam a localização física da execução e os nós de e uma estrutura dentro da qual eles podem interagir.

• Os principais diagramas estruturais são: componentes e implantação.

3.4 Modelagem estrutural

Na UML, o principal diagrama que mostra a estrutura de um sistema é o diagrama d

Todavia, outros diagramas também permitem visualizar a estrutura do sistema, tais code pacotes, o diagrama de componentes, o diagrama de objetos e o diagramadeployment (implantação).

3.4.1 Classes de objetos

Uma classe de objetos é uma coleção de objetos que podem ser descritos com os mee as mesmas operações.

Representa uma idéia ou um conceito simples e categoriza objetos que possuemsimilares, congurando-se em um modelo para a criação de novas instâncias (outros ob

Uma classe de objetos na UML possui três segmentos: nome, atributos e operações.

A representação ou notação de uma classe é um retângulo com os três segmentos. Cter um nome que a distingue de outras classes. Um nome é um texto.

Uma classe possui diversos atributos. Um atributo é uma propriedade do objeto que de valores que as instâncias do objeto podem ter.


4/33

46

Unidade II

O terceiro segmento da classe são as operações. Uma operação é a implementação deou funcionalidade que pode ser requisitado de qualquer objeto da classe para afetar o comdo objeto.

3.4.2 Relacionamentos entre classes de objetos/instâncias

As classes de objetos, no modelo de classes, se relacionam ou se associam de aconecessidades do sistema. Esses relacionamentos são denominados “associação entre class

Um relacionamento dene as regras da associação que, por seu lado, são impostas pelnegócio da aplicação, sendo modelada.

A criação de um objeto, baseado em uma classe, recebe um nome especial: instâné necessário manipular um determinado objeto, a classe é carregada na memória, e os instanciados, isto é, são criados na memória e podem ser manipulados.

A instanciação de objetos depende da linguagem OO utilizada, mas, em geral, possuemespecial que cuida das instâncias dos objetos, denominada construtora.

Quando o objeto já não é mais necessário, outra função especial chamada de destrutoelimina as instâncias criadas. Por exemplo: para uma classe funcionário, o objeto tipo funCarlos da Silva” seria uma instância na memória.

3.4.3 Mecanismos comuns

A UML é feita simplesmente pela presença de mecanismos comuns que garantem a cpartir da linguagem, tais como: especicação, adornos e mecanismo de extensibilidade.

A especificação refere-se aos padrões das descrições dos componentes dos modnomear os componentes, como descrever a lógica de um cenário de umcaso de uso , e assimpor diante.

Adornos são itens grácos e textuais que são adicionados a uma notação de um elemesão usados para visualizar detalhes da especicação do elemento. Por exemplo, no símbolo de nó de umdiagrama de implantação, pode ser interessante colocar os componentes executáveis decaixa extra do desenho.

O mecanismo de extensibilidade da UML permite extender a linguagem de uma maneiEsse mecanismo inclui estereótipos, valores marcados e restrições.

Um estereótipo extende o vocabulário da UML, permitindo que se criem node blocos de construção que são derivados de outros existentes, mas especifícodeterminado problema.


5/33

47


3.4.4 Diagramas da UML

Com um modelo, é possível um melhor entendimento dos sistemas que estão em deCom a UML, pode-se construir modelos a partir de um conjunto de blocos básicos, ta

interfaces, colaborações, componentes, nós, dependências, generalizações e associaçõe

Lembrete

Quando o homem modela qualquer coisa, ele está criando umasimplicação da realidade.

A UML propõe 13 diagramas, conforme mostra a quadro 2:

Quadro 2 – Diagramas da UML

Diagramas

Número UML 1.X UML 2.31 Atividade Atividade2 Caso de uso Caso de uso 3 Classe de objetos Classe de objetos4 Objetos Objetos5 Sequência Sequência6 Colaboração Comunicação7 Estado Estado8 Componentes Componentes9 Implantação Implantação (deployment)10 ------------- Pacotes11 ------------- Interação12 ----------- Tempo13 ---------- Estrutura composta

Lembrete

Com relação ao ciclo de desenvolvimento desoftware :

• Cada diagrama da UML, ou modelo, pode ser usado em umdeterminado momento do ciclo de desenvolvimento desoftware .

• Um diagrama da UML deve ser usado para resolver ou mostraraspectos especícos do problema sendo modelado.

• Um diagrama da UML pode ser usado para especicar artefatosdiferentes em atividades diferentes do processo desoftware . Por


6/33

48

Unidade II

exemplo, o diagrama de atividade pode ser usado para detalhar umafuncionalidade, como mostrar um determinado uxo do problemaque está sendo estudado etc.

3.4.4.1 Diagrama de atividade

Os diagramas de atividades são usados para modelar o comportamento de um sistema, que esses comportamentos estão relacionados em um uxo geral desse.

O uxo mostra os caminhos de um processo lógico a seguir, com base em váriasprocessamento simultâneo, acesso a dados, interrupções e outras distinções do caminho l

São usados para construir um sistema, um processo, ou um procedimento.

3.4.4.2 Diagrama de caso de uso

Um diagrama decaso de uso captura as funcionalidades do sistema e as relações entre os atosistema. Ele descreve os requisitos funcionais do sistema, a maneira pela qual as coisas dinteragem no limite do sistema e a resposta desse aos usuários.

Lembrete

O diagrama decaso de uso , ou modelo decaso de uso , é um dos maisimportantes modelos da UML e será detalhado na Unidade 3.

3.4.4.3 Diagrama de objetos

Um diagrama de objetos está intimamente relacionado a um diagrama de classes com a distinção de que retrata instâncias de objetos das classes e seus relacionamenponto no tempo.

Isso pode parecer semelhante a um diagrama de estrutura composta, que tambémcomportamentos em tempo de execução. A diferença é que os diagramas de objetos exediagramas de classes estáticas, enquanto que os diagramas de estrutura composta reetem em tempo de execução.

Eles são úteis na compreensão de um diagrama de classes complexas, criando diferenque os relacionamentos e as classes são aplicados.

Um diagrama de objeto também pode ser uma espécie de diagrama de comunictambém modela as conexões entre os objetos, mas adiciona sequências de eventos acada caminho.


7/33

49


3.4.4.4 Diagrama de sequência

O diagrama de sequência é um dos quatro tipos de diagrama de interação. Um diagramé uma representação estruturada de comportamento com uma série de etapas sequencia

tempo.Ele é usado para descrever o uxo de trabalho, passagem de mensagens. Cada elemen

é organizado em uma sequência horizontal, com mensagens que passam para trás e paos elementos.

Um elemento de ator pode ser usado para representar o usuário que inicia o uxElementos estereotipados, como limite, controle e entidade, podem ser usados para ilucontroladores e os itens de banco de dados, respectivamente. Cada elemento tem uma ltronco chamada de linha-de-vida, na qual o elemento existe e, potencialmente, participa

3.4.4.5 Diagrama de comunicação

Um dos quatro tipos de diagrama de interação. Um diagrama de comunicação mostrentre os elementos em tempo de execução da mesma maneira que um diagrama de seq

No entanto, os diagramas de comunicação são usados para visualizar as relações entre oos diagramas de sequência são mais ecazes na visualização de processamento ao longo

Os diagramas de comunicação empregam associações rotuladas e ordenadas paprocessamento. A numeração é importante para indicar a ordem e a nodicação de pro

Um esquema de numeração pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante.

3.4.4.6 Diagrama de estado (máquina de estado)

Os diagramas de estado da máquina eram anteriormente conhecidos como diagramEsse diagrama ilustra como um elemento (geralmente uma classe) pode mover-se enclassicando o seu comportamento de acordo com gatilhos de transição ou guardas de

Outros aspectos do diagrama de máquina de estado ajudam a descrever e explicar oscomportamentos dos sistemas.

3.4.4.7 Diagrama de componentes

Um diagrama de componentes mostra os pedaços desoftware , controladores embutidos que formum sistema, sua organização e as dependências.

Um diagrama de componente tem um nível maior de abstração do que um diagrama de claum componente é implementado por uma ou mais classes (ou objetos) em tempo de execuç


8/33

50

Unidade II

Eles são blocos de construção, construídos de modo que, eventualmente, um compoabranger uma grande parte de um sistema.

3.4.4.8 Diagrama de implantação

Um diagrama de implantação (deployment ) mostra como e onde o sistema será implantado, ou sua arquitetura de execução.

Dispositivos dehardware , processadores e ambientes desoftware de execução (artefatos do sistema)são reetidos como nós, e a construção interna pode ser representada incorporando nós Como os artefatos são alocados para os nós do modelo de implantação do sistema, a alocapela utilização das especicações de implantação.

3.4.4.9 Diagrama de pacotes

O diagrama de pacotes (pakage ) mostra a organização dos elementos de um modelo em pa(agrupamentos) e as dependências entre esses pacotes, incluindo pacotes importados e epacotes.

3.4.4.10 Diagrama de interação (visão geral)

Um diagrama geral de interação visualiza a cooperação entre os diagramas de interaçãoum uxo de controle que serve a um propósito abrangente.

Como os diagramas gerais de interação são uma variante de diagramas de atividades, notação do diagrama é a mesma, como é o processo de construção do diagrama.

Pontos de decisão,forks , junções, pontos iniciais e nais são os mesmos. Em vez de elde atividade, no entanto, elementos retangulares são usados. Existem dois tipos desses elementoselementos de interação e e elementos de ocorrência.

3.4.4.11 Diagrama de tempo

Um diagrama de tempo dene o comportamento de objetos diferentes dento de umatempo. Ele fornece uma representação visual da mudança dos objetos, mudando de estado todo o tempo.

Ele pode ser usado para denir os componentes esoftwares embutidos. Também pode ser utilizadpara especicar processos de negócio orientados pelo tempo.

3.4.4.12 Diagrama estrutura composta

Um diagrama de estrutura composta reete a colaboração interna de classes, intecomponentes (e suas propriedades) para descrever a funcionalidade do sistema.


9/33

51


Eles são similares aos diagramas de classe, exceto pelo fato de que eles modelam umda estrutura. Um diagrama de estrutura composta é usado para expressar o tempo de arquiteturas, padrões e relacionamentos dos elementos participantes, que não podem semeio de diagramas estáticos.

4 DIAGRAMA DE CLASSES DE OBJETOS DA UML

Entre esses diagramas, o diagrama de classes é considerado um dos principais e seseguir.

4.1 Introdução

O diagrama de classes mostra a estrutura estática do sistema por meio de suas classtambém como eles se relacionam.

É considerado por alguns autores como o mais importante diagrama no desenvolvima objetos e, portanto, também da UML.

Observação

A meta na construção de um modelo de objetos é incorporar osconceitos do mundo real que sejam importantes para a aplicação.

A gura 12 mostra um exemplo de modelo de classes de objetos na notação da UM

Nome da classe de objetos

Mundo real

Modelo de objeto

Realidade de interesse(Observado)

Atributos

Operações ( )

Figura 12 – Visão do mundo real x a OO


10/33

52

Unidade II

A gura 13 mostra um exemplo de diagrama de objetos com um metamodelo de classee duas instâncias da classe “José da Silva” e “Maria Rodrigues”.

Nome da classe de objetos

O nome da classe (metamodelo)representa o agrupamento deobjetos do mesmo tipo.

Objetos com valores daclasse pessoa.

Pessoa

Nome dos atributos Nomeidade

Operações ( ) Mudar_endereço ( )

José da Silva32

Maria de Tal26

Figura 13 – Exemplo de uma classe e suas instâncias na notação UML

Alguns meios de implementação (linguagens de programação e sistemas gerenciadoredados) exigem que um objeto tenha um identicador explícito para cada objeto. Esses idexplícitos não são obrigatórios em um modelo de objetos.

A gura 14 mostra um uso incorreto de identicadores internos.

Pessoa

Nomeidade

Pessoa

Cod_PessoaNome

Correto

Figura 14 – Uso incorreto de identicador interno

Os identicadores internos (gerados pelas linguagens) não podem ser confundidos codo mundo real e não devem fazer parte do modelo conceitual. O “número_telefone” e “núcarro” não são identicadores internos porque têm signicado no mundo real.

Uma classe sempre deve representar um mesmo assunto, isto é, ela encapsula conhecimalgo. Não teria sentido colocarmos dados sobre a empresa em que trabalha na classe pess

Pessoa e empresa são assuntos diferentes ou objetos diferentes e, portanto, devem estadistintas. Uma classe tem responsabilidade por tudo o que lhe diz respeito. Não é de respopessoa/funcionário incluir ou manter os dados da empresa.

Uma classe poder ter visibilidade pública, protegida, privada:

• Uma classe pública indica que qualquer outra classe poderá acessar seus atributos

execução de suas operações.


11/33

53


• Uma classe é denominada de privada quando restringe totalmente o acesso a seussuas operações.

• Uma classe com visibilidade protegida somente permite a ela e aos seus herdeirosatributos e suas operações.

As operações ou comportamentos de uma classe de objetos recebem e devolvemsão passados numa lista de argumentos, dentro de um padrão específico que cadadota.

O diagrama do modelo conceitual deve ser independente da tecnologia, e quando da é que se considera os padrões especícos.

A gura 15 mostra um exemplo de chamada de uma operação com a lista de argume

Exemplo: mudar_endereço (novo_endereço, ok)

Operação Parâmetrode entrada

Parâmetrode saída

Figura 15 – Exemplo de uma operação e a lista de argumentos

Em um modelo de classes, existem diversas classes do domínio da aplicação qurelacionar dentro das regras de negócio.

Elas, quando estão relacionadas, podem trocar mensagens para que uma determinaenvolve diversos objetos possa ser realizada com sucesso.

Os relacionamentos das classes no modelo de classes podem ser de três tipos: associe composição e generalização/especialização.

4.2 Associação

Associação é uma relação semântica entre classes. Uma associação acontece determinada instância de uma classe se associa a uma ou mais instâncias de omesma classe.

Ligações e associações são os meios para estabelecermos relacionamentos entre objeligações são conexões entre instâncias de objetos.

A gura 16 mostra o metamodelo de associação de classes e um exemplo prático.


12/33

54

Unidade II

Classe A Classe BPapel 1

Papel 2

associação

João da Silva Telesp

Pessoa Empresatrabalha_para

ligação

Figura 16 – Exemplo de uma associação entre duas classes. O modelo apresentadoé o modelo de objetos no qual o objeto pessoa trabalha para uma empresa

As associações ainda podem ser binárias, unárias, ternárias e assim por diaassociação é dita binária quando duas classes estão envolvidas na associação, confoa figura 17.

Cidade

Nome

Pais tem_capital

0.1 1Nome

Figura 17 – Associação binária

Uma associação é dita unária quando o relacionamento de uma classe é consigo própr

A gura 18 mostra um exemplo de associação unária. Uma peça pode compor outras pmas também pode ser composta de outras peças menores.

0..*

1..*Componente

Composta

Peça

Figura 18 – Um exemplo de associação unária

Uma associação é dita ternária quando três classes fazem parte da associação. Na gurque um projeto tem várias pessoas trabalhando nele e pode ser implementado em váriadiferentes.

A nomeação das associações são opcionais para associações ternárias ou de orde(n-árias).


13/33

55


A gura 19 mostra um exemplo de associação ternária.

Projeto Linguagem

Pessoa

Símbolo de associação ternária ou de ordem superior

1..* 1..*

1..*

Figura 19 – Exemplo de uma associação ternária

4.3 Papéis em associação

A UML possui uma notação especíca para representar as regras de uma associação das classes.

A notação denomina-se cardinalidade ou multiplicidade e deve ser descrita no dimostra a tabela 1.

Tabela 1 – Cardinalidades ou multiplicidades das associações entre classes

Cardinalidade Descrição0..1 Opcional e único0..* Opcional e múltiplo1 Obrigatório e único

1..* Obrigatório e múltiplo* O mesmo que 0..*

2..4 De 2 a 41..2,5,7..14 1 e 2, 5 e 7 a 14

Quando se quer ressaltar que um dado elemento da associação deve estar classiutilizar a palavra-chave{ordenado}, como mostra a gura 20.

Classe A Classe BPapel 1

Papel 2{ordenado}

Figura 20 – Uso da palavra chave {ordenado}

Quando se quer declarar a visibilidade da associação, deve-se colocar os símbolos emdo papel (“+” público, ”#” protegido, “-“ privado). Isso declara a visibilidade da assoàquele papel.


14/33

56

Unidade II

Por exemplo: na gura 9, se for colocado em frente do papel 1 o símbolo “+”, está declapapel na associação é de uso público.

Quando existir a necessidade de mostrar o sentido da navegação em uma detassociação, deve-se colocar uma seta na extremidade da associação para indicar suportada pelo modelo.

A gura 21 mostra um exemplo do uso da navegação em uma associação entre duasobjetos.

Cidade

Nome

Pais tem capital

0..1 1Nome

Figura 21 – Navegação (restrição de acionamento de classes)

A seta indica o sentido em que a navegação é suportada no modelo, dessa forma nãooperações da classe cidade acessarem as operações da classe país.

4.4 Classe de associação

Em alguns modelos, devido às regras de negócio, torna-se necessária a colocação de uma determinada associação. Um atributo é uma propriedade dos objetos de uma classe.

Como uma associação também é um objeto, é perfeitamente possível colocar nela atribum atributo de ligação é uma propriedade de uma associação.

A gura 22 apresenta a classe “depto de uma empresa” e a classe funcionário, nas qufuncionários da empresa.

Funcionário

Cod_funcnome

Depto Chea10..1

Nome

Figura 22 – O uso de atributos de associação

A questão que se coloca no modelo é: onde colocar a data de posse da chefia, em deou em funcionário? Todavia, a data de posse é uma propriedade da associação “chepertencer a ela.

A data de posse não é propriedade nem do departamento e nem do funcionário.

Uma das soluções seria colocar a data em uma das classes associadas. A escolha caanalista, já que esse atributo não é natural nem para departamento e nem para funcionário


15/33

57


O problema decorrente da colocação dos atributos de ligação em uma das classeexibilidade futura do modelo. Caso haja qualquer dúvida com relação ao futuro, comuma “classe de associação”.

Como mostra a gura 23, criou-se uma classe nova denominada “classe de associaçãa colocação do atributo especíco da associação.

A classe de objetos “chea”, possui atributos próprios e provavelmente operações patributos e as associações.

Funcionário

Cod_funcnome

Depto 1

0..1

Nome

Chea

Data_posse

Figura 23 – O uso da classe de associação

A gura 24 mostra outro exemplo de classe de associação para um modelo mais so

um modelo que mostra uma empresa, seus funcionários e o grau de desempenho desses

0..*1..*Funcionário

Endereço

NomeRG

Trabalha para

Admite_funcionário ( )

SalárioCargo

Empresa

NomeEndereço

Gerencia

Grau de

desempenho

Trabalha_para

Figura 24 – Classes de associação

Note que o grau de desempenho pertence à associação, já que o atributo somenteenquanto o funcionário ocupa o cargo de gerência.

A classe “trabalha para” indica que o salário e o cargo do funcionário são atributos da empresa em que trabalha, já que o modelo permite que um funcionario trabalhe emempresa.


16/33

58

Unidade II

4.5 Agregação e composição

Agregação é um tipo especial de associação em que um objeto contém o(s) outro(s)chamado de relacionamento “todo/parte”. Agregação é um modo de associação na quaagregado é feito de componentes. Os componentes fazem parte do agregado.

A gura 25 mostra um exemplo de agregação. Uma publicação possui artigos obrigatomodelo. Isso signica que uma publicação é composta necessariamente de artigos.

O diamante vazio indica que a ligação é fraca, já que uma publicação pode existir sartigo, mas um artigo não existe sem uma publicação associada.

0..*1..*

Publicação

Artigo

Figura 25 – Exemplo de uma agregação entre classes associadas

As agregações incluem explosões das partes e expansões de um objeto em suas partes A gura 26 mostra outro exemplo de agregação entre classes de objetos.

0..*

0..1 0..*

0..*

1

1

Empresa FuncionárioTrabalha_para

Divisão

Departamento

Figura 26 – Exemplo de agregação

Uma empresa é uma agregação de suas divisões, que são, por sua vez, agregaçõdepartamentos. Uma empresa não é uma agregação de seus funcionários, uma vez quepessoa são objetos distintos e independentes.


17/33

59


Uma composição é uma agregação forte em que as partes estão sicamente contidtodo. Os componentes não podem ser compartilhados por outros compostos. Uma exdesencadeia uma exclusão em cascata das partes, portanto, o ciclo de vida das classes coincidem.

A gura 27 mostra um exemplo de composição.

0..*1

Livro

Capítulo

Figura 27 – Exemplo de composição (associação forte)

A exclusão de um livro acarreta a exclusão de todos os seus capítulos, e a exclusão dlivro implica a elimincação do livro.

4.6 Generalização/especialização

A generalização é uma forma de se estruturar a visibilidade de um elemento global mais detalhada desse. Isso é feito adicionando características especícas ao elemento nae aproveitando as características gerais.

generalização

especialização

Figura 28 – Generalização x especialização

A generalização/especialização pode ser usada para diversos outros modelos da Udiagramas de pacotes e diagramas de casos de uso.


18/33

60

Unidade II

As classes superiores são chamadas superclasses, e as inferiores subclasses. Tanto a supas subclasses referem-se às características de um único objeto.

Com a generalização, um objeto é simultaneamente instância da superclasse e insubclasse.

0..1 0..*Empresa Funcionário

Masculino Feminino

Trabalha_para

Associação degeneralização

Divisão

Departamento

Figura 29 – Exemplo de generalização

Uma árvore de generalização é composta por classes que descrevem um objeto. No exem

19, a classe funcionário foi especializada em masculino e feminimo, devido a característide cada um, mas o modelo garante que as características comuns estão representadas sovez na superclasse funcionário.

Diz-se que masculino é um “tipo_de” funcionário ou masculino “é um” funcionário. Um funcionárioou é masculino ou é feminino.

4.7 Herança

Na UML, herança é um mecanismo por meio do qual uma instância de uma classe assume os comportamentos dos objetos de outra classe (antepassados ou antecedentes).

Os objetos subordinados herdam atributos e serviços da classe superior. A propriedpermite que novas classes sejam construídas pela herança de classes existentes. A gura exemplo de herança.


19/33

61


Classe ou superclasse

Subclasse

Aeronave

Jato Planador

Figura 30 – Exemplo de aplicação do mecanismo de herança

No exemplo da gura 30, as classes jato e planador são subclasses de aeronave. As clas

podem ter atributos e ou métodos próprios. O conceito de herança reforça a extensibilidaque sempre se procurou na programação.

Uma classe descendente/subclasse não pode omitir ou suprimir um atributo da supnão seria uma instância antecessora. As subclasses também são chamadas de classeclasses-lho na hierarquia de classes.

As classes que cam mais altas na hierarquia são denominadas de superclasses.

Funcionário

Funcionáriofeminino

nome solteiraregistrar licençamaternindade

Funcionáriomasculino

Figura 31 – Exemplo de herança

Pode acontecer de uma subclasse possuir alguma operação diferente de seu anté chamado de extensão. Uma subclasse pode restringir atributos do antecessor. Isso “restrição”, pois restringe os valores que aquela instância pode assumir.

Lembrete

O mecanismo de herança se tornou sinônimo de reutilização de códigono projeto orientado a objetos.


20/33

62

Unidade II

A gura 32 mostra um exemplo completo do uso de herança.

Equipamentonomefabricantepreçopeso

Bombapressão de sucçãopressão de descargataxa de uxo

Bomba centrífugaeixo de rotação

Tanque esféricodiâmetro

Bomba de diafragmamaterial do diafragma

Tanque Volumepressão

Bomba de imersãodiâmetro de pistãonúmero de cilindros

Tanque pressurizadodiâmetroaltura

Tanque de teto utuantediâmetroaltura

Tipo de equipamento

Tipo de bomba

Tipo de tanque

Figura 32 – Exemplo completo do uso de herança

A quadro 3 mostra o conteúdo dos objetos da classe “bomba centrífuga” e da classe “tautuante” com suas características especícas apesar de serem ambas equipamento.

Diversos atributos e operações são válidos para os dois objetos e possuem atributos especícos.

Quadro 3 – Conteúdo das classes

Bomba de diafragma Tanque de teto utuanteNome = P101 Nome = T111Fabricante = Simplex Fabricante = SimplexPeso = 100 kg Peso = 10.000 kgPreço = R$ 5.000,00 Preço = R$ 50.000,00Pressão sucção = 1,1 atm Volume = 400.000 lPressão de descarga = 3,3 atm Pressão = 1,1 atmTaxa de uxo = 300 l/hora Diâmetro = 8 mMat. diafragma = teon Altura = 9 m


21/33

63


Herança é um mecanismo da OO que permite criar novas classes a partir de cexistentes, aproveitando-se das características existentes na classe a ser extendida

Este mecanismo é muito interessante, pois promove um grande reuso e reaproveide código existente. Com a herança é possível criar classes derivadas (subclasses) classes bases (superclasses). As subclasses são mais especializadas do que as suas sumais genéricas. As subclasses herdam todas as características de suas superclasssuas variáveis e métodos.

Imagine que dentro de uma organização empresarial, o sistema de RH tenhtrabalhar com os diferentes níveis hierárquicos da empresa, desde o funcionário escalão até o seu presidente.

Todos são funcionários da empresa, porém cada um com um cargo diferente. a secretária, o pessoal da limpeza, o diretor e o presidente possuem um númidenticação, além de salário e outras características em comum. Essas caracteríscomum podem ser reunidas em um tipo de classe em comum, e cada nível da hieratratado como um novo tipo, mas aproveitando-se dos tipos já criados, a partir da h

Os subtipos, além de herdarem todas as características de seus supertipos, tapodem adicionar mais características, seja na forma de variáveis e/ou métodos adbem como reescrever métodos já existentes na superclasse (polimorsmo).

A herança permite vários níveis na hierarquia de classes, podendo criar tantos quanto necessário, até se chegar no nível de especialização desejado. Podemosubtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode trinstância de presidente como se fosse um objeto do tipo funcionário, em deterfuncionalidade.

Porém, não é possível tratar um supertipo como se fosse um subtipo, a não seobjeto em questão seja realmente do subtipo desejado e a linguagem suporte este tratamento, seja por meio de conversão de tipos ou outro mecanismo.

Fonte: . Acesso em:

4.8 Conceitos avançados envolvendo classes

4.8.1 Herança múltipla

Herança múltipla é uma extensão da análise orientada a objetos que permite uma clauma superclasse e herdar todas as características (atributos e operações) de todos os seu

É considerada a mais complicada forma de generalização, e nem todas as linguagens dão suporte diretamente. A gura 33 mostra um exemplo de herança múltipla.


22/33

64

Unidade II

Janela Texto

Tela

Árvore

Figura 33 – Herança múltipla

Com a herança múltipla a classe tela herda todas as caracerísticas de suas três classes-pai oA classe janela possui as propriedades das janelas e as operações para mostrá-las e moviment

A classe texto oferece as propriedades textuais das janelas, com operações/métodos palinhas de texto etc.

A herança múltipla aumenta o potencial de uma linguagem orientada a objetos, mas a complexidade da programação, bem como umoverhead de compilação e de tempo de execução.

Uma classe com mais de uma superclasse é chamada de classe-de-junção.

Veículo

Terrestre Aquático

Carro Anfíbio Barco

Figura 34 – Classe-de-junção anfíbia

Uma característica proveniente da mesma classe ancestral encontrada em mais de umherdada apenas uma vez.

No exemplo da gura 34, a característica “cor” da classe veículo é herdada tanto por vecomo por veículo aquático, mas a subclasse veículo anfíbio, que possui herança múltcaracterística “cor” de apenas uma das suas superclasses.


23/33

65


As subclasses provenientes de generalizações podem ou não ser disjuntas. No exemas classes terrestre e aquático não são disjuntas nesse nível, porque elas se sobrepõemveículo pode andar na terra e na água.

4.8.2 Classes abstratas

Uma classe abstrata é uma classe que não possui instâncias diretamente, mas cujospossuem instâncias diretas. Esse tipo de classe é útil durante um projeto OO, para facilite a manutenção dos sistemas.

Às vezes, é útil criar superclasses abstratas para encapsular classes que participam eassociação. Algumas classes abstratas aparecem naturalmente no domínio da aplicaçarticialmente criadas como um mecanismo para permitir reuso de código.

As classes abstratas são usadas frequentemente para denir métodos para serem abordadoUma classe abstrata não é uma classe concreta já que não pode ser instanciada dire

ser instanciável a classe abstrata deve possuir descendentes concretos.

Já uma classe concreta pode ser uma classe de folhas (último nível da hierarquia). Umnão pode ser classe de folha já que precisa de descendentes para ser instanciável.

A gura 35 mostra uma hierarquia de classes concretas e dessa forma todas podem sdiretamente.

Trabalhador

CobradorPedreiro Açougueiro

{incompleto}

Figura 35 – hierarquia de classes concretas

A classetrabalhador também pode ser classe concreta, pois algumas ocupações podem estnelas. Dessa forma, a hierarquia é{incompleto}.

Todavia, uma classe concreta pode ser renada em várias subclasses concretas e se Quando isso acontece, a hierarquia passa a ser{completo}.

O exemplo da gura 36 mostra uma superclasseempregado que se tornou abstrata no momento eque foram criadas diversas subclasses concretas, que herdaram a operaçãoCalcular_Salario( ) e queserão programadas com lógicas especícas.


24/33

66

Unidade II

Trabalhador

MensalistaCalcular_Salário( )

HoristaCalcular_Salário ()

AutônomoCalcular_Salário()

{completo}

Figura 36 – Exemplo de classe abstrata

Nesse exemplo, a classeempregado não possui instâncias diretas, e a operaçãoCalcular_Salario( ) será implementada por métodos diferentes em cada subclasse. A classe de origem de qualé a classe denidora de mais alto nível.

Ela dene o “protocolo” ou “assinatura” da estrutura (tipo de um atributo, númeroargumentos e tipo de resultado de uma operação). As classes descendentes podem renarrestringindo os tipos ou refazendo a inicialização ou a codicação do método, mas não poou modicar o protocolo.

Por exemplo: se um atributo foi denido na classe de origem, as classes descenderestringir os valores que aceitam no atributo, mas não podem modicar seu tipo.

O discriminador{completo} indica que qualquer instância da superclasseempregado será umainstância de um dos seus lhos, e a superclasse se torna abstrata.

Já o discriminador{incompleto} indica que o conjunto pode esperar novas subclasses,superclasse é concreta. Dessa forma, a superclasse pode ser instanciada diretamente.

4.8.3 Polimorsmo (ocultamento de informações)

O polimorsmo implica que uma mesma operação pode comportar-se de maneira dclasses distintas, apesar de possuir o mesmo nome. É a propriedade de se utilizar um mesfazer coisas diferentes.

Observação

Por exemplo: mandar alguém correr. Se a pessoa estiver parada, irásair correndo. Se a pessoa estiver no volante de um carro, irá aumentar apressão do pé no acelerador.

O polimorsmo é estimulado pelo paradigma da hereditariedade, exclusivo da OOpolimorsmo, pode-se ter a sobreposição, a redenição(overriding) de método: o método deve ter amesma assinatura (nome, argumentos e valor de retorno) e código diferente.


25/33

67


Já na sobrecarga(overloading), usa-se o mesmo nome e mais alguma característica para semesma coisa. Dependendo dos argumentos da chamada, será chamado o método adequ

4.8.4 Interfaces tipos e papéis

A herança múltipla não é permitida em algumas de programação OO diretamente. necessidade do uso desse tipo de herança, aparece o uso da interface.

Uma interface, por exemplo, na linguagem Java não é uma classe, é um arquivo quconstantes, e as operações que outra classe deve implementar. Ela não tem operações/mseus protótipos.

Dessa forma, quando uma classe expõe apenas constantes e operações sem implemené chamada de interface.

4.8.5 Pacotes lógicos

A UML dene um diagrama de pacotes como sendo um modelo que descreve como oorganizados dentro de pacotes e suas dependências. Um pacote pode estar contido em o

Em um diagrama de pacotes, esses são ligados por setas pontilhadas, que têm sealterado de acordo com a necessidade.

Um pacote pode ter qualquer diagrama da UML, porém são mais comuns em diagcasosde uso , para ajudar a abstração do domínio do problema, e em classes, para ajudar na orclasses construídas em sistemas médios e grandes.

Uma classe também pode ser declarada com “em pacote” e, dessa forma, terá a srestrita ao pacote em que reside. Classes fora desse pacote não poderão sequer saber dee, por isso, não poderá acessar classes do pacote.

Uma classe dentro de um pacote sem visibilidade denida assume a visibilidade pad

Existe uma notação especial na UML paradesignar um pacote. Essa notação não deixa dúvidaimplementador que está usando o diagrama sobre a intenção do uso do pacote.

pktLogin

Figura 37 – Exemplo de um pacote


26/33

68

Unidade II

Nesse exemplo, todas as classes referentes aologin estão contidas nesse pacote. O acesso a essclasses internas vai depender da visibilidade do pacote.

4.8.6 Objetivos do diagrama de classes

1. Mostrar a estrutura estática do sistema.

2. Montar essa estrutura com as classes de objetos e também como seus relacionamen

3. Mapear os objetos a partir das classe de objetos com seus nomes, atributos e operaç

4. Aplicar as propriedades e características da tecnologia OO por meio dos mecanismosherança, polimorsmo e abstração.

4.9 Estudo de caso aplicando modelo de classes

Para demonstração do uso de um dos mais importantes modelos da UML, será utilizadde um sistema de vendas simples, com algumas funcionalidades fundamentais.

Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramentaCase EnterpriseArchitect (EA).

Saiba mais

O estudo de caso foi adaptado do exemplo apresentado no livroModelagem de Objetos , do autor José Davi Furlan, publicado pela editoraMakron Books (FURLAN, 1998).

4.9.1 Descrição do sistema

O sistema de vendas tem o objetivo de fornecer informações unicadas, abrangentes e

aos vendedores, incluindo a situação dos pedidos tirados, a posição de crédito dos clientes, de apresentação de produtos e a eciência de vendas.

A força de vendas está estruturada em liais, zonas e setores. Uma lial atua em uma áreOs vendedores das liais atuam em zonas de vendas e um deles é o responsável pela tal. Avisitas aos clientes pelos vendedores é denida por essas zonas de vendas e distribuída aoAs visitas ainda são organizadas semanalmente e representam períodos semanais, quinzen

A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamendiário que deve ser seguido pelo vendedor para cumprir sua programação de vendas.


27/33

69


4.9.2 Requisitos do sistema

A partir da descrição do sistema existem diversas alternativas de solução. De qualqrequisitos independem de outra solução especíca, mais simples ou mais complexa, já q

as necessidades dos clientes em forma de sentenças.A gura 38 apresenta o diagrama de requisitos do sistema a ser modelado.

Observação

Os requisitos são organizados em dois grupos ou pacotes. O pacote derequisitos funcionais e o pacote de requisitos não funcionais:

• O pacote que contém os requisitos funcionais apresentamas características que representam o comportamento dasfuncionalidades ou regras de negócio que o sistema deve apoiar.

• O pacote de requisitos não funcionais contém os requisitos condicionantes

e níveis de desempenho que o sistema deve atender. Por exemplo: tempode resposta do sistema, transações de segurança etc.

No nosso estudo, somente serão abordados os requisitos funcionais.

Requisitos funcionais

req Modelo de requisitos

RF01 – O sistema deve manter atualizada a posição do cliente

RF03 – Sistema emite informações adicionais sobre os clientes

RF06 – Análise do histórico de vendas

RF02 – O sistema deve elaborar o roteiro de visita do dia

RF05 – Analisa situação nanceira do cliente

RF04 – Gera informações sobre lial

RF07 – Registra pedido de venda

Figura 38 – Requisitos do sistema modelado na ferramenta EA


28/33

70

Unidade II

4.9.3 Modelo de classe do sistema

Após uma análise dos requisitos e reuniões com a área de vendas, o analista de sistemmodelo de requisitos e detalha as funcionalidades usando o modelo de casos de uso.

A partir dos cenários e das funcionalidades, são descobertas as entidades envolvidas coe que serão usuárias do sistema, e as entidades de dados que serão modeladas e colocadasdados desse.

As principais classes obtidas com essa análise são:

1. lial de venda;

2. zona de venda;

3. setor de venda;

4. cliente;

5. produto;

6. produto em cliente;

7. preço do produto;

8. pedido;

9. item de pedido;

10. nota scal;

11. fatura.

A gura 39 apresenta o diagrama de classes proposto para o sistema, contendo os principEsse modelo/diagrama é denominado de modelo de domínio, já que não contém as clas

da solução tecnológica do sistema, tais como: classes de interface, classes de comunicaçpadrões e classes de banco de dados.

Essas classes completarão o modelo de domínio na fase dedesign do projeto.


29/33

71


class Diagrama de Classes

Filial de venda- numero: int- nome: char

Zona de venda- numero: int- nomeDoVendedor: char

Cliente- codigo: int- nomeCompleto: char- nomeReduzido: char

- endereco: char- IRPJ: char- telefone: char- horarioDeVisita: int- CondicaoDePagamento: int- dataDaUltimaVisita: date

Pedido

- numero: int- data: date- situacao: int- tipoDePedido: int

Item de pedido- numero: int- quantidade: date- precoNegociado: int- situacao: int- condicaoDeEntrega: int

Fatura- numero: int- dataDeEmissao: date- dataDeVencimento: date- valor: int- dataEfetivaPagamento: date

Nota scal- numero: int- dataDeEmissao: date- situacao: boolean

Produto em cliente- data: date- quantidade: int- tipo: int

Produto- codigo: int- descricao: int- faixaDePreco: int- valorUnitario: int

Setor de venda- nome: char- dataDaUltimaVisita: date- periodoDeVisita: date

*

*

1

1 1

1

0..* 0..* 0..*

0..*

1

0..*

0..*

0..*0..*

0..* 0..*

0..*

Figura 39 – Diagrama de classes preliminar

Nesse diagrama, temos as principais classes juntamente com seus relacionamentos.

O modelo, nesse momento, ainda não sofreu quaisquer questionamentos conceituaismesmo foi promovida uma normalização visando à sua estabilidade e integridade.

As operações dessas classes são obtidas a partir do estudo das funcionalidades descridecaso de uso e diagramas de sequência das transações necessárias, para que o sistemarequisitos, que não serão mostrados nesse exemplo, já que se pretende apresentar somende aplicação do modelo de classes.

A gura 40 apresenta o mesmo diagrama de classes, mas com as principais operaçpara resolver o sistema.


30/33

72

Unidade II

class Diagrama de Classes

Filial de venda- numero: int- nome: char+ obter_Nome_Filial(): void

Zona de venda

- numero: int- nomeDoVendedor: char

Cliente- codigo: int- nomeCompleto: char- nomeReduzido: char- endereco: char

- IRPJ: char- telefone: char- horarioDeVisita: int- CondicaoDePagamento: int- dataDaUltimaVisita: date+ obte_Clientes_Ativos() : void+ obter_Limite_Credito() : void+ obter_Condicao_Entrega : void+ obter_Condicao_Pagamento() : void+ obter_dia_Entrega() : void

Pedido- numero: int- data: date- situacao: int- tipoDePedido: int

+ obter_Pedido() : void+ incluir_Pedido() : void

Item de pedido- numero: int- quantidade: date- precoNegociado: int- situacao: int- condicaoDeEntrega: int+ obter_Descricao_Produto() : void+ obter_Preco_Produto() : void

Fatura

- numero: int- dataDeEmissao: date- dataDeVencimento: date- valor: int- dataEfetivaPagamento: date+ obter_Faturas_Vencidas() : void+ obter_Faturas_A_Vencer

Nota scal- numero: int- dataDeEmissao: date- situacao: boolean+ obter_NF_Cliente() : void

Produto em cliente- data: date- quantidade: int- tipo: int+ registrar_Estoque_Cliente() : void+ registrr_Produto_Recolhodo() : void

Produto- codigo: int- descricao: int- faixaDePreco: int- valorUnitario: int+ obter_Descricao_Produto() : void+ obter_Preco_Produto() : void

Setor de venda- nome: char- dataDaUltimaVisita: date- periodoDeVisita: date+ atualizar_Data_Ultima_Visita() : void

*

*

1 1

1

0..* 0..* 0..*

0..*

1

0..*

0..*

0..*

0..*

0..*0..*

1

0..*

Figura 40 – Diagrama/modelo de classes com algumas operações

O modelo de classes, quando completo, incluindo atributos e operações, pode ser implum banco de dados e em uma linguagem de programação orientada a objetos.

Outras classes serão necessárias, tanto para o banco de dados, como para a implementalinguagem especíca nas próximas fases do desenvolvimento.

Para a fase dedesign, deverão ser desenvolvidos os modelos de interface homemversus máquina,que indicará as interações dos usuários com o sistema. Para isso deverão ser montados ocasos de uso com os atores e as funcionalidades.


31/33

73


Por meio do modelo decaso de uso e do protótipo, os diagramas de sequência indicarão as meque serão trocadas entre os objetos. A partir dessas mensagens, o modelo de classe sertodas as operações ou métodos deverão ser incluídos nas classes especícas.

Resumo

Esta unidade apresentou uma visão da estrutura da UML. Foi discutidoque, de acordo com os autores a UML, não é um modelo de processo/metodologia desoftware .

Ela é considerada uma linguagem padrão de modelagem de sistemas e,por isso, tem uma notação e um mecanismo para “mostrar o problema”, deforma a expor a essência do domínio de um aplicativo.

Também se detalhou os conceitos envolvidos com todos os diagramasapresentados na linguagem UML, principalmente o diagrama de classes deobjetos. O detalhamento desse modelo se justica devido à sua importânciana tecnologia orientada a objetos.

A partir desse modelo de classes detalhado, são derivadas as soluçõesde banco de dados e as classes que serão implementadas em linguagensespecícas. O diagrama de classes é a entrada para os processos dearquitetura e implentação, tanto do banco de dados como do aplicativo.

Uma das mensagens mais importantes é com relação ao reuso desoftware . Quando se trabalha com os conceitos envolvidos com o reuso desoftware , o modelo de classes é fundamental e apresenta os mecanismosde herança e polimorsmo que permite um avanço considerável em direçãoà reusabilidade.

Exercícios

Questão 1. De acordo com a IBM-Rational, aUnied Modeling Language (UML) é uma linguagemde modelagem não proprietária adotada pela OMG, e não uma metodologia de desennão diz como desenvolver ou manter um sistema ousoftware , mas auxilia a visualizar seu desene a comunicação entre os objetos envolvidos com o sistema. Também permite que dvejam os produtos de seus trabalhos em diagramas ou grácos padronizados, oferecendgráca, especicando os signicados, isto é, ela é uma liguagem com uma semânticuma notação independente de metodologias ou processos, embora muitas delas, como oRationalUnied Process ), tenham sido especicamente desenvolvidos utilizando a UML. Outro faté a diferença entre um modelo UML e um diagrama (ou conjunto de diagramas) de UMou gráco é uma representação gráca da informação de um determinado sistema, e o


32/33

74

Unidade II

existir independentemente. Considerando-se os conceitos sobre a UML, analise as armaassinale a alternativa incorreta:

A) A visão de caso de uso de um sistema descreve as fucionalidades ou o comportamenassim como os analistas e programadores de sistemas.

B) De acordo com diversos autores, o diagrama de classes de objetos é o mais impdiagramas da UML, pois uma classe de objetos é uma coleção de objetos que podemcom os mesmos atributos e as mesmas operações. Também representam as entidadeem um sistema de informação.

C) Para que um sistema seja executado, as classes de objetos precisam estar relacassociadas no modelo de classes. Esse relacionamento ou associação deve estar de as necessidades do sistema e deve cobrir as regras de negócio envolvidas com as funque o sistema executará.

D) Sistema é a representação abstrata do mundo real; quanto mais complexo, mais ndescrições de seus vários aspectos. Ele deve mostrar: a estrutura estática dos objetos dinâmica entre eles; as características do tipo de tempo de processamento, de conausabilidade etc.; e, por último, o mapeamento do modelo organizacional em termos dado trabalho, mapeamento e os códigos.

E) Herança é o mecanismo de reutilização de atributos e operações denidos em supclasses mais especícas, podendo ser usada para expressar tanto generalização como

Resposta: Alternativa A.

De acordo com a OMG, a UML apresenta 4 grandes objetivos: especicação de documentação de todos os artefatos produzidos no processo, estruturação para subve maior visão lógica do desenvolvimento completo de um sistema de informação. A linguagem padronizada de se modelar sistemas de informação desenvolvidos na tecOrientação a Objetos.

Análise das alternativas

A) Incorreta. A visão de caso de uso de um sistema realmente descreve as funcionacomportamento de um sistema, mas tem como princípio fundamental entender os resistema e interpretá-los gracamente. Outro fator fundamental é que os Casos de Usuma linguagem de comunicação entre os usuários e os desenvolvedores de um dsistema.

B) Correta. Uma classe de objetos representa uma ideia ou um conceito simples e categque possuem propriedades similares, congurando-se em um modelo para a criaçãinstâncias. Exemplo: uma classe que represente um Cliente pode ser instanciada para


33/33


um cliente pessoa física ou um cliente pessoa jurídica, os quais possuem característie especícas.

C) Correta. Esses relacionamentos ou associações denem as regras que são impostanegócio da aplicação sendo modelada.

D) Correta. Cada visão apresentada em um diagrama da UML é descrita por um ou que contêm informações referentes a um aspecto especíco do sistema sendo mod

E) Correta. Quando se usa o paradigma da herança na OO, uma classe de menor né considerada uma classe especializada ou uma classe de extensão da classe d(superclasse).

Questão 2. Dentro da UML, o diagrama de classe de objetos tem por objetivo descrede objetos com propriedades similares, relacionamentos comuns com outros objetos ecomum. As propriedades são: os atributos e as operações. Estas são encapsuladas no oem um sistema ERP, o cliente e o fornecedor são classes de objetos. Cada cliente teum endereço; estes seriam os atributos comuns da classe cliente. Fornecedores tambémmesmos atributos, nomes e endereços denidos. Entretanto, elas podem não estar demesma estrutura de objetos devido à distinção semântica. Como se pode observar, o agclasses não leva em conta apenas o compartilhamento de propriedades, senão essas clser sempre agrupadas na mesma estrutura. Considerando-se os conceitos apresentadonesta unidade, examine as armações a seguir e assinale a alternativa incorreta:

A) Com a hierarquia de classes de objetos que são apresentadas no diagrama de cmecanismo de herança, o modelo de classes de objetos potencializa o reuso no dedesoftware OO.

B) Para se ter herança múltipla em um modelo de classes, necessita-se que uma suatributos e operações de mais de uma superclasse.

C) Quando um modelo de classes apresenta herança múltipla e vai ser implemenlinguagem de programação OO e em banco de dados, pode-se ter problemas na traa que esses ambientes podem não suportar a herança múltipla.

D) O uso de herança múltipla deve ser evitado a todo custo nos projetos de sistema Onunca aparecer na modelagem do mundo real.

E) Uma classe abstrata possui a mesma estrutura de uma classe concreta, a única dtem um modicadorabstract em sua denição de atributo ou de operação. Ela não pinstanciada, ou seja, não é possível obter objetos. Classes abstratas podem ser herdclasses abstratas ou concretas e isso possibilita o polimorsmo

Documents

Modelagem de Processos_Unidade II