Modelagem de sistemas

Prévia do material em texto

Modelagem de sistemas 
Aula 1 – Desenvolvimento de sistemas
O desenvolvimento de sistemas é um processo intelectual e progressivo, em que os profissionais envolvidos adquirem mais conhecimento do sistema à medida que avançam no entendimento da realidade em que o sistema está inserido.
Tomemos como exemplo a criação de um sistema que gerencie as atividades de um estacionamento de veículos:
No início do processo, é preciso conversar com os profissionais envolvidos no negócio em questão para compreender a realidade e o funcionamento do mesmo. No primeiro dia, nada conhecemos do negócio estacionamento, no quinto dia de estudo, por exemplo, o conhecimento da realidade é mais apurado.
Para representar a realidade e entender o que se passa no contexto do sistema a ser construído, precisamos traduzir a realidade em modelos.
No contexto de desenvolvimento de sistemas, o que são modelos?
Nada mais são que diagramas gráficos que representam a realidade e ajudam os desenvolvedores a compreendê-la. Portanto, modelar um sistema consiste em criar um conjunto de modelos sob a forma de diagramas, que representam a estrutura e o comportamento de um sistema.
Conceitos do Paradigma Orientado a Objetos
Podemos dizer que a representação da realidade ocorre por meio de paradigmas. Paradigma é uma forma de abordar um problema.
Até o final dos anos 1980, prevaleceu o paradigma imperativo ou estruturado, caracterizado pelo uso das técnicas de Análise Estruturada e Análise Essencial, que foram eficientes para sistemas de pequeno porte.
À medida que os sistemas se tornaram mais complexos e robustos, uma nova abordagem se fez necessária para estudar, entender e modelar o sistema a ser desenvolvido. Surgia o paradigma Orientado a Objetos, também chamado paradigma OO.
Na modelagem sob o enfoque da orientação a objetos (OO), a tarefa principal passa a ser a identificação dos objetos do mundo real envolvidos no contexto do sistema e a relação entre eles. Ao identificar os objetos, são identificados também os dados (atributos) e as funcionalidades (funções) inerentes àquele objeto, conforme ilustrado na equação abaixo.
OBJETO = DADOS + FUNÇÕES
Na medida em que são identificados todos os objetos pertinentes a um sistema, já teremos os dados e os procedimentos relacionados.
Orientação a Objeto (OO)
Um modelo OO tem com entidade fundamental o Objeto, que recebe e envia mensagens, executa procedimentos e possui um estado que, por proteção, apenas ele próprio pode modificar. Nesse processo, problemas são resolvidos, por meio de objetos, que enviam mensagens uns aos outros.
O Modelo OO é formado por alguns elementos básicos:
Objeto - É o principal elemento do modelo OO. Representam as “coisas” a serem modeladas do mundo real. Um objeto pode ser algo concreto como um carro, um aluno ou algo abstrato como uma disciplina, um curso. Cada objeto possui os dados inerentes a ele, como por exemplo, Nome (José) e Matrícula (201101272201) de um objeto Aluno e possui as operações que ele executa, como incluir novo aluno ou alterar dados de um aluno existente.
Mensagem - Quando um objeto deseja que seja executada uma operação de responsabilidade de outro objeto, ele manda uma mensagem a esse objeto informando o que ele deseja que seja feito. A operação desejada será implementada por meio de um método da classe que recebe a mensagem, conforme a imagem abaixo:
Atributos - São dados que caracterizam o objeto.
Métodos - É um procedimento (implementado por uma rotina ou função) que executa uma operação em um objeto, que define parte de seu comportamento.
Classes - É um conjunto de objetos com as mesmas características (atributos e métodos). Conforme ilustrado na imagem a seguir, Maria e Pedro são objetos da classe PESSOA, cujas características em comum são:
• Atributos: Nome, Endereço, Telefone, Idade e Altura.
• Métodos: Registrar( ), Matricular( ), Pagar( ), Estudar( ) e Cadastrar( ).
Os pilares do paradigma Orientado a Objetos
A orientação a objetos tem como alicerce alguns princípios fundamentais. Juntos, eles permitem que classes sejam reaproveitadas, otimizando tempo e custo de desenvolvimento, além da segurança no reuso das classes já usadas e testadas. Observe:
Encapsulamento - Encapsular significa esconder, ou seja, o objeto esconde seus dados (atributos) do acesso indevido de outros objetos. Os dados somente devem ser acessados por métodos (funcionalidades que implementam o comportamento do objeto) da própria classe, o que pode ser visualizado na figura abaixo:
Herança - Mecanismo para derivar novas classes a partir da definição de classes existentes através de um processo de refinamento.
Polimorfismo - A palavra polimorfismo, deriva do grego, e significa “muitas formas”. A partir do momento em que uma classe herda atributos e métodos de uma (herança simples) ou mais (herança múltipla) classes base, ela tem o poder de alterar o comportamento de cada um desses procedimentos (métodos).
Visibilidade - Outro conceito fundamental, é a visibilidade entre as classes. A visibilidade diz respeito ao que uma classe pode visualizar da outra. Como princípio, devemos garantir o encapsulamento, ou seja, os atributos devem ser privados (acessíveis apenas por métodos da própria classe) e determinados métodos públicos (acessíveis por todas as classes), e acessar esses dados.
Conclusões do paradigma orientado a objetos
Seguem algumas das conclusões do paradigma OO:
Conceitos de Análise e Projeto Orientado a Objeto
A orientação a objetos enfatiza a identificação, a representação e a organização dos objetos necessários a um sistema.
Antes de adentramos no universo da análise e projeto, sob o enfoque do paradigma Orientado a objeto, vamos tecer rápidos comentários acerca do que sejam as atividades de Análise e Projeto, dentro do contexto de desenvolvimento de software.
Análise de sistemas significa uma investigação dos problemas e dos requisitos de um contexto, em particular, com vistas ao desenvolvimento de um sistema automatizado. A ideia básica é identificar quais seriam as funções que esse sistema precisa ter, de forma a atender eficientemente as necessidades de seus usuários.
Atividade de análise e projeto
A atividade de análise, por ser muito abrangente, costuma ser dividida em:
Análise de requisitos (investigação dos requisitos);
Análise do domínio do problema.
No contexto específico da orientação a objetos, análise implica em identificar e descrever os conceitos no domínio do problema. Já na atividade de análise foca-se na definição dos objetos de software e como eles colaboram para que os requisitos dos usuários sejam plenamente satisfeitos.
Por outro lado, a atividade de projeto denota uma solução, voltada a atender aos requisitos, considerando aspectos de tecnologia. Em geral, o projeto enfoca a arquitetura do sistema, definindo suas partes e a relação entre elas.
Portanto, análise pode ser traduzida em “faça a coisa certa”, e projeto em “faça certo a coisa”.
A UML como uma linguagem padrão
A UML (Unified Modeling Language) é uma linguagem padrão para construção de projetos de sistemas, orientados a objeto, voltada para visualização, especificação, construção e documentação de artefatos de um sistema. A UML foi projetada para ser independente do método de desenvolvimento utilizado. Ela é uma linguagem de modelagem, não é um método de desenvolvimento, nem tão pouco um metodologia ou um processo de desenvolvimento de sistemas, uma vez que não determina a ordem e nem como os diagramas devem ser usados. Simplesmente disponibiliza os diagramas, sob as várias visões necessárias ao desenvolvimento de sistemas, e cada empresa utiliza da forma como lhe convém, ou seja, adequando a UML ao seu processo de desenvolvimento de sistema.
A UML é destinada à:
Visualização - A modelagem gráfica tende a facilitar a compreensão, permitindo sua interpretação sem ambiguidades.
Especificação - Permite aconstrução de modelos precisos, sem ambiguidades e completos. A UML atende a esses quesitos sob o ponto de vista da análise, projeto e implementação.
Construção - Os diagramas UML podem ser diretamente integrados a várias linguagens de programação tais como Java e C++.
Documentação - A UML abrange a documentação da arquitetura do sistema e de todos os seus detalhes.
Os diagramas da atual versão da UML
Os diagramas da UML são divididos em 2 grupos: Diagramas de Estruturas e Diagramas Comportamentais. No total, eles formam 14 diagramas, conforme ilustrado pela imagem:
Uso da UML
Como a UML não determina quais diagramas usar nem por onde começar, cada um começa por onde desejar. Nem mesmo os idealizadores da UML conseguem usar todos os diagramas. Geralmente, as empresas escolhem um subconjunto deles e implementam nas fases de seus processos de desenvolvimento de sistemas. O ideal é que você encontre o seu conjunto de diagramas que funcione para o tipo de sistema que desenvolve.
Por exemplo: muitos começam pelo Diagrama de classes, na medida em que o consideram o diagrama mais relevante. Porém muitos iniciam pelo Diagrama de Casos de uso, cuja finalidade é modelar as principais funcionalidades do sistema para atender às necessidades de seus usuários. Ambos estão usando a UML de forma correta e expressando como visualizam a sequência mais adequada para desenvolver sistemas.
Martin Fowler e Steve Mellor propuseram três modos pelos quais pode-se usar a UML no desenvolvimento de sistemas:
UML como esboço - O modo mais usado, onde os desenvolvedores usam a UML como forma de expressar aspectos relevantes de um sistema, esboçando ideias e alternativas do que pretende fazer. É uma possibilidade de discussão com a equipe de desenvolvedores. Seu foco é a comunicação seletiva em vez de especificação completa. Geralmente, são usados desenhos informais, sem ferramentas e cujo objetivo é a discussão de ideias visando à construção de software de forma colaborativa. O modo UML, como esboço, está mais compatível com as metodologias ágeis, que preconizam mais código e menos documentação.
UML como projeto – Foca a completeza. Aqui a ideia é construir um projeto completo para ser codificado por programadores, valendo-se de ferramentas case para melhor entendimento dos modelos pela equipe. O modo UML, como projeto, está mais alinhado com os processos de desenvolvimento mais complexos, como processos iterativos e incrementais, como o PU (processo unificado) implementado através da ferramenta RUP (Rational Unifiec Process) prototipação.
UML como linguagem de programação - Onde os desenvolvedores desenham os diagramas que são compilados para o código executável e a UML se torna o código fonte. Exige ferramentas mais sofisticadas. O modo UML, como linguagem de programação, tende a ser mais usado em modelos de desenvolvimento de prototipação.
Processos Iterativos de desenvolvimento e a UML
Um processo de desenvolvimento de software descreve uma abordagem para organizar as atividades relacionadas com a construção, a implantação e a manutenção de sistemas.
Os processos mais populares hoje são os iterativos, como: O PU (Processo Unificado), em particular o RUP (Processo Unificado da Rational); As metodologias ágeis, como o XP (eXtreming Programming) e Scrum.
Mas o que são os processos iterativos?
São processos onde o ciclo de vida do sistema é dividido em uma série de miniprojetos, curtos, preferencialmente de duração fixa (por exemplo, 3 meses), denominados iterações.
A UML e os resultados em cada fase
Usar a UML, em um processo de desenvolvimento de sistemas, não implica, necessariamente, na elaboração de documentos ou uso de uma ferramenta case.
Muitas equipes, por exemplo, usam UML para desenhos à mão em reuniões e para discussão de ideias.
Uma ferramenta case é um programa que auxilia aos membros da equipe de desenvolvimento no estudo, modelagem e construção do sistema, possibilitando que vários diagramas possam ser elaborados em conjunto, representando a estrutura e comportamento do sistema a ser desenvolvido.
Aula 2 – Requisitos de Sistema
O primeiro passo para a modelagem de um sistema é saber quais são os seus requisitos. Nesse processo, o levantamento e mapeamento adequado dos requisitos de um sistema são passos fundamentais para o sucesso do produto final a ser gerado: o software.
O software precisa ter as funcionalidades adequadas para satisfazer as necessidades de seus usuários. Portanto, durante o processo de desenvolvimento de software é preciso ter cuidado e, se possível, garantias de que os requisitos estão sendo corretamente capturados e compreendidos pelos analistas de sistemas.
A UML (linguagem unificada de modelagem) disponibiliza para esse fim o diagrama de casos de uso, cuja finalidade é mapear as funcionalidades do sistema, evidenciando os atores que com elas interagem.
Levantamento de requisitos - De uma forma geral, os requisitos são necessidades dos usuários que os sistemas precisam atender.
As atividades de levantar e identificar os requisitos são fundamentais para todo o processo de desenvolvimento de sistemas, pois uma vez conhecidas as reais necessidades de seus usuários poderemos desenvolver o sistema adequado.
Em contrapartida, se as necessidades identificadas não forem os reais, o sistema não atenderá ao que seus usuários precisam, e a tendência é que seja descartado.
Tipos de requisitos - Os requisitos funcionais representam as funcionalidades necessárias para atender as necessidades dos usuários do sistema.
Funcionais
Veja alguns exemplos de requisitos funcionais para um sistema de Folha de Pagamento:
Registro dos dados dos funcionários;
Registro do salário bruto de cada funcionário;
Cálculo da folha de pagamento;
Cadastramento da tabela de imposto de renda;
Emissão do recibo de pagamento;
Dentre outras funções necessárias ao sistema.
Não funcionais
Apresentam restrições e qualidades do sistema e suas funcionalidades.
Eles representam os atributos e propriedades do sistema. Podem ser expressos em termos do sistema como um todo, como por exemplo: o sistema deve ser operado por uma tela de toque (touch screen), denotando um requisito não funcional de usabilidade.
Os requisitos não funcionais podem representar também propriedades de uma função específica. Por exemplo: o usuário pode ter a necessidade de especificar que a impressão do boleto de venda (função) não deve demorar mais que 10 segundos (requisito não funcional), representando um requisito não funcional que visa a performance do sistema.
Diagrama de casos de uso
Como vimos, o diagrama de casos de uso tem como objetivo apresentar os requisitos funcionais do sistema. Ou seja, é um diagrama que começa a ser usado após o levantamento de requisitos, de forma a mapear as funcionalidades do sistema, documentando o que o sistema faz.
O diagrama de casos de uso é um dos mais informais e simples, dentre os diagramas propostos pela UML (Linguagem Unificada de Modelagem), e sua finalidade é apresentar as principais funcionalidades que o sistema precisa ter.
Elementos do diagrama de casos de uso - Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis de serem representados, que são:
Os atores, os casos de uso e os relacionamentos.
“Usuário” e “Atendente” são os atores.
Os casos de uso “Matricular em curso”, “Incluir Disciplina” e “Cancelar Disciplina”, estão interagindo com o ator “Usuário”. Isto significa que o Usuário é o ator que interage com essas três funcionalidades.
O caso de uso “Cancelar Matrícula em Curso”, interagindo com o ator “Atendente”, ou seja, “Atendente” é quem pode “Cancelar Matrícula de um Curso”, a quarta funcionalidade disponível no sistema.
Ator- O ator é algo com comportamento, que interage diretamente com o sistema. Um ator participa (realiza) um ou mais casos de uso do sistema. A representação do ator, no diagrama de casos de uso, é o boneco, chamado de stickman.Um ator é o papel que o agente desempenha em relação ao sistema. Ele pode representar:
Papéis internos (Gerente de Compras) ou externos (Cliente e Fornecedor)
Setores e departamentos da empresa (Contabilidade e Contas a Pagar), bem como funções desempenhadas na empresa (almoxarifado).
Dispositivos eletrônicos, como por exemplo hardware e servidores, ou dispositivos lógicos, como sistemas.
Identificando Atores - O primeiro passo para a construção do modelo de casos de uso é a identificação de atores. Algumas perguntas são úteis nesta situação, veja:
Quais órgãos, empresas ou pessoas farão uso deste sistema de informação?
Que sistemas ou equipamentos irão se comunicar com o sistema que será desenvolvido?
Quem deve ser informado de alguma ocorrência no sistema? A quem pode interessar os requisitos funcionais do sistema?
Casos de uso
Segundo Jacobson, um dos criadores da UML, um caso de uso é uma descrição narrativa de uma sequência de eventos que ocorre quando um ator usa um sistema para realizar uma tarefa.
 Os casos de uso representam, através de elipses, as funcionalidades do sistema, conforme a imagem a seguir:
Identificando casos de uso - Como já fizemos a identificação dos atores, podemos passar à identificação dos casos de uso. Esse processo deve seguir duas etapas, veja:
Em primeiro lugar, podemos pensar nos casos de uso que representam os objetivos dos atores. Estes casos de uso representam os processos da empresa, e algumas perguntas são úteis neste momento:
Quais as necessidades e objetivos de cada ator em relação ao sistema?
Que informações serão produzidas pelo sistema?
O sistema realizará alguma ação que ocorre de forma regular no tempo?
Existe um caso de uso para atender cada requisito funcional?
Em seguida, podemos pensar nos casos de uso que não representam um benefício direto para os atores, mas são necessários para o funcionamento do sistema. Tais casos de uso englobam manutenção de cadastros e de informações provenientes de outros sistemas.
Cenários - Um caso de uso é um conjunto de cenários. Descreve uma sequência de ações do ator e do sistema. Cada sequência de ações é chamada de cenário.
Portanto, um cenário é uma sequência específica de ações que ilustra o comportamento do caso de uso.
Relacionamentos ou associações - O diagrama de casos de uso possibilita, ainda, a existência de relacionamentos entre:
Atores e caso de uso, Atores entre si e Casos de uso entre si 
Relacionamentos entre atores e casos de uso - 
Esse é o relacionamento mais comum, e é indicado por uma linha sólida, que liga o ator ao caso de uso, denotando que o ator interage com o caso de uso.
Nos termos técnicos, dizemos que o ator realiza o caso de uso. A figura a seguir ilustra esse relacionamento:
A comunicação nesse relacionamento é bidirecional, ou seja, o ator informa dados ao caso de uso e recebe informações 
por ele processadas.
Relacionamentos de atores entre si - Entre atores, é possível haver o relacionamento de generalização/ especialização, representado por uma linha sólida com uma seta na extremidade que aponta para o ator geral, conforme ilustrado nesta imagem:
Observe que nesse exemplo, o ator geral é o “Funcionário” e o ator especialista, o “Gerente”. Este também exerce as atividades de um funcionário, porém como gerente tem tarefas específicas a sua função.
Vamos analisar mais um exemplo de relacionamento de generalização/ especialização entre atores. Observe a leitura desse diagrama:
O ator geral é “Usuário”.
Os atores especializados são “Aluno” e “Atendente”, que se relacionam com todos os casos de uso associados ao ator “Usuário”.
Apenas o ator “Atendente” se relaciona com “Cancelar Matrícula em Curso”, ou seja, apenas o “Atendente” realiza esse caso de uso.
Esta é uma associação útil para definir a sobreposição de papéis entre atores, na qual:
O ator especializado interage com o caso ao qual está associado diretamente e com todos os casos de uso com o qual o ator generalizado se associa;  
Já o inverso não ocorre: o ator generalizado não interage com os casos de uso associados ao ator generalizado.
Relacionamentos de Casos de uso entre si - Casos de uso podem conectar por três tipos de relacionamentos:
Inclusão (include ou uses);
Extensão (extend);
Generalização.
Relacionamentos entre Casos de uso por inclusão - Nesse tipo de relacionamento, um caso de uso (principal) incorpora, explicitamente, o comportamento de outro caso de uso (incluído).
O caso de uso incluído é parte integrante do caso de uso principal. A fatoração (separação desse caso de uso) acontece porque outros casos de uso também poderão incorporar o caso de uso incluído e, assim, evitar repetições de fluxos.
O diagrama ao lado demonstra o relacionamento de casos de uso por inclusão:
O caso de uso “Validar Disciplina” é usado por dois casos de uso: “Incluir Disciplina” e “Eliminar Disciplina”. Isso significa que o caso de uso “Validar Disciplina” está contido em ambos, ou seja, se formos descrever as interações do que acontece dentro do caso de uso, perceberemos que tanto “Incluir Disciplina” quanto “Eliminar Disciplinas” terão uma parte igual.
Esse caso de uso será obrigatoriamente executado, em algum ponto da execução do caso de uso “Incluir Disciplina”, como também em algum ponto na execução do caso de uso “Eliminar Disciplina”.
Normalmente essa percepção da necessidade de fatoração ocorre quando estamos descrevendo os casos de uso, assunto de que trataremos na próxima aula.
O cenário comum a mais de um caso de uso é capturado em outro caso de uso. No caso do exemplo anterior, “Validar Disciplina” agrega o que é comum a “Incluir Disciplina” e a “Eliminar Disciplina”.
Relacionamentos entre Casos de uso por extensão - Esse tipo de relacionamento é usado para descrever cenários opcionais em um caso de uso; uma variação do comportamento normal.
Veja a seguir uma descrição do relacionamento de casos de uso por extensão:
Um caso B (caso de uso estendido) estende A (caso de uso principal) quando alguma condição interrompe a execução do caso A (caso de uso principal) para que B (caso de uso estendido) execute e retorne, ao final, ao caso de uso A (caso de uso principal).
A interrupção é feita no chamado ponto de extensão. Esta imagem ilustra o relacionamento de extensão:
Exemplos de Casos de uso por extensão - Para que você entenda melhor como acontece o relacionamento de casos de uso por extensão, trouxemos dois exemplos que iremos analisar. Veja:
 O caso de uso “Enviar Informe de Dívida” estende o caso de uso “Cancelar Matrícula em Curso”.
Exemplo 1 
Esse caso de uso somente será executado se o cancelamento do curso implica em pagamento de dívida do aluno; caso o aluno esteja quite com o curso, o caso de uso não será executado.
Exemplo 2 
Observe como os casos de uso “Pagar em Cheque” ou “Pagar em Cartão” estendem o caso de uso “Pagar Mensalidade”.
 
Neste caso, haverá uma condição a ser avaliada, que é a forma de pagamento e, de acordo com o valor desta, será executado um ou outro caso de uso: apenas um deles será executado, ou seja, são mutuamente exclusivos.
Relacionamentos entre Casos de uso por generalização - Esse tipo de relacionamento é usado quando um caso de uso é semelhante a outro, mas executa algumas funções a mais.
Ele é pouco usado, pois seu uso confunde-se com o extend, na medida em que este também pode resolver essa questão da variação de comportamento, neste caso um comportamento com adição de funcionalidade.
O diagrama a seguir ilustra o relacionamento de casos de uso por generalização:
 Neste exemplo existe a especialização do caso de uso “Solicitar Produtos”, que pode ser pela internet ou pelo telefone. De acordo com a forma de solicitação, o comportamento do caso de uso vai variar, porém existem partes comuns, que estão especificadas em “Solicitar Produtos” (caso mais geral).
Aula 3 – 
A importância da especificação de casos de uso
O diagrama de casode uso é útil, na medida em que nos fornece uma visão geral das funcionalidades do sistema (conjunto de casos de uso) e dos atores que com elas se relacionam. Todavia, é pobre na medida em que não entendemos como a interação ocorre em cada caso de uso.
É nesse contexto que identificamos a importância da especificação dos casos de uso. Podemos dizer, então, que o diagrama é um sumário gráfico do conjunto de casos de uso (funcionalidades) de um sistema.
O real valor da técnica de especificação de casos de uso está na adequada descrição textual de cada caso de uso, em que veremos com clareza como os atores utilizam o sistema. Mas a UML nada define sobre o texto narrativo, que descreve o caso de uso.
Se o tempo destinado ao modelo de casos de uso for pouco, concentre-se na especificação ou descrição dos casos de uso e esqueça o diagrama. Mas se tiver oportunidade, modele o diagrama, pois é uma ótima ferramenta de diálogo com usuário, pela sua simplicidade.
 Os formatos para especificar casos de uso
Formato Resumido - Corresponde ao resumo de um parágrafo, geralmente contendo o cenário principal do caso de uso e o cenário de sucesso.
Você deve utilizá-lo na análise inicial de requisitos, para obter uma ideia do assunto e o escopo do caso de uso.
Formato Informal - Refere-se aos múltiplos parágrafos que cobrem vários cenários de uso.
Você deve utilizá-lo na mesma condição do formato resumido.
Formato Completo - Nesse formato, todos os cenários (principal e alternativos) são descritos em detalhes, com seções adicionais, complementando a especificação, com elementos que definem os pré e pós-condições.
Você deve utilizá-lo depois que muitos casos de uso tiverem sido descritos no formato resumo ou informal, geralmente durante a fase de análise de requisitos e de sistemas. Para os casos de uso relevantes, tende a ser o formato mais adequado.
Exemplo de descrição textual de um caso de uso
Para mostrar a diferença entre os três tipos de especificação, vamos usar como exemplo o caso de uso “Registrar Venda”, com o trecho de diagrama de casos de uso, a seguir.
Observe que neste diagrama foram considerados atores tanto o caixa como o cliente. O motivo é que o cliente também interage com o sistema, quando o pagamento é em cartão, por exemplo.
FORMATO RESUMIDO
Caso de uso: “Registrar Venda”
O cliente chega a um ponto de pagamento da loja com os itens que deseja adquirir. O caixa registra cada item desejado. Ao final, o sistema apresenta o total a pagar e a relação de itens comprados.
O cliente informa e o caixa registra os dados do pagamento, que são validados e registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras e sai com os itens adquiridos.
FORMATO INFORMAL
Caso de uso: “Registrar Venda”
- Cenário principal (de sucesso): Cliente chega ao ponto de pagamento da loja com os itens a serem adquiridos. Caixa usa o sistema PDV para registrar todos os itens comprados. Ao final, sistema apresenta o total a pagar e a relação de itens comprados.
Cliente informa e caixa registra os dados do pagamento, que são validados e registrados pelo sistema. Sistema atualiza o estoque. Cliente recebe o recibo das compras e sai com os itens adquiridos.
- Cenários alternativos: Se o identificador do item adquirido não for encontrado no sistema, este notifica o caixa e sugere que entre manualmente com a identificação do item (que talvez esteja corrompido).
Se o cliente informou o pagamento em cartão e a operadora não aprova a transação, informa o cliente e solicita uma nova forma de pagamento.
Se o sistema não consegue atualizar o estoque, sugere que o caixa registre no formulário de problemas do dia, para o balanço ao final do dia.
FORMATO COMPLETO
Vários gabaritos e padrões de formatos estão disponíveis para casos de uso relevantes que precisam de especificações detalhadas.
Especificação de casos de uso que contenham Include
Considere o trecho de diagrama a seguir, de um sistema de locadora de DVDs, no qual os dependentes podem ser incluídos e eliminados do plano de sociedade com a locadora:
Especificação de casos de uso que contenham extends
Para explicar como é especificado o uso de casos de extensão (extends), vamos usar diagrama a seguir. Observe:
Temos três extends no diagrama, porém dois deles estão relacionados entre si e o terceiro não.
O caso de uso “Calcular Multa por Atraso” será usado se e apenas se (condição) a entrega estiver sendo feita com atraso.
Já os casos de uso “Pagar em Dinheiro” e “Pagar em cartão” são mutuamente exclusivos, ou seja, apenas um deles será executado, de acordo com a forma de pagamento (condição) escolhida pelo cliente.
Considerações finais sobre especificações
Conforme já mencionamos, a UML não descreve nada a respeito de especificações textuais de casos de uso, limitando-se a especificar os elementos e uso do diagrama de casos de uso.
Porém, como também já mencionamos, a especificação de casos de uso é extremamente relevante para o entendimento dos requisitos para futura implementação de outros modelos e dos códigos fontes dos programas que vão compor o sistema.
Desse modo, existem várias formas e padrões para especificar casos de uso. O que descrevemos anteriormente não é o melhor e nem tampouco o mais completo, porém vemos muito seu uso na vida profissional.
Escolha o seu padrão, o seu formato e vá em frente. O importante é que seja algo que sua equipe saiba ler e escrever e a comunicação entre vocês possa ser clara e efetiva.
Aula 4 – 
Conceitos de diagrama de classes - O diagrama de classes é considerado por muitos o principal diagrama da UML, sendo também o mais amplamente usado por aqueles que usam a UML na modelagem de seus sistemas orientados a objetos.
Existem vários níveis de diagramas de classes, que são usados no nível de domínio — conceitual — e de projeto.
Nesta aula, vamos inicialmente abordar o diagrama de classes a partir da observação do mundo real para um determinado contexto. Vamos construir o diagrama em nível de domínio, ou ainda, o chamado modelo conceitual de classes.
Para começarmos, atente-se para a seguinte informação, referente ao diagrama conceitual de classes:
Não se devem representar estruturas de projeto (interfaces, chaves, arquivos, campos etc.). O foco da análise é o negócio.
Modelo conceitual de classes - Com base no que vimos, podemos conhecer o modelo conceitual de classes.
Esse modelo usa os elementos mais básicos do diagrama de classes, pois a finalidade é representar os objetos tal qual existem no mundo real, sem inserir aspectos de projeto ou de implementação no modelo.
Assim, o diagrama de classes descreve, de forma gráfica, os tipos de objetos que interagem para realizar as funcionalidades previstas em um sistema, bem como os vários tipos de relacionamentos estáticos entre eles. O diagrama de classes mostra, ainda, as propriedades e operações de uma classe e as restrições relacionadas à forma como os objetos se relacionam.
A evolução do diagrama de classes - O diagrama de classes evolui à medida que o projeto avança. Observe esse processo através do esquema a seguir:
Fase do Projeto - Nessa fase, o mesmo diagrama de classes pode ser refinado com a inserção de:
Multiplicidades e papéis;
Relacionamento entre as classes;
Novos métodos (como, por exemplo, get, set e formatações);
Novos atributos;
Parâmetros nas chamadas dos métodos;
Visibilidade dos atributos e métodos;
Novas classes, chamadas de classes de projeto (como representação de persistência)
Fase de Implementação - Durante a implementação (codificação na linguagem), novas classes podem surgir, como classes que implementem determinada característica da linguagem de programação ou determinada forma de programar. É o diagrama de classes de implementação.
Fase de Análise – 1º Momento - Inicialmente, em sua primeira versão, na fase de análise, o diagramaapresenta as classes do negócio (também chamada de entidades) e chama-se diagrama de classes conceitual.
Esse é um diagrama compatível com as funcionalidades dos casos de uso, ou seja, mostra a modelagem em classes dos requisitos essenciais do sistema.
Fase de Análise – 2º Momento Num segundo momento, ainda na fase de análise, novas classes podem ser inseridas no diagrama de classes, como as de controle e as de interface (ou fronteira).
Classe de fronteira (boundary) ou interface: responsável pela interação com os atores. Exemplo: para representar um formulário, para representar a interface com outro equipamento (um acionador de cancelas de entrada e saída de veículos, por exemplo);
Classes de controle: responsável pela coordenação da interação entre os objetos, na realização de um caso de uso. A princípio, cada caso de uso teria uma classe de controle.
Na verdade, embora com diferentes nomenclaturas, o diagrama de classes é um só, que vai crescendo e sendo alterado a cada fase do ciclo de desenvolvimento. Algumas equipes de projeto podem optar por guardar as versões finais de cada diagrama, mas a última versão guarda todas as alterações feitas
A classe - Uma classe é uma abstração da realidade, na qual representamos algo do mundo real. Se, por exemplo, em um contexto de sistema, identificarmos que desejamos armazenar os dados de um determinado elemento, estamos diante de uma candidata à classe do sistema.
Na UML, uma classe é representada por um compartimento contendo três partes, conforme ilustra a figura a seguir:
Classe x Objeto
Classe - É o molde de um conjunto de objetos afins, ou seja, com as mesmas características (atributos e métodos).
Objeto - É uma instância de uma classe.
Na imagem, a seguir, você pode visualizar o exemplo de um objeto específico pertencente à classe cliente. O objeto é como se fosse um elemento específico do conjunto (classe) cliente:
Visão geral do diagrama de classes e seus elementos
A figura abaixo ilustra um diagrama conceitual de classes, contendo apenas classes de negócio (entidades) que são modeladas, bem como apresenta comentários dos principais elementos do diagrama de classes.
Por meio do exemplo de diagrama, podemos observar que um diagrama de classes possui os seguintes elementos básicos:
1. Classes, com atributos e operações (métodos) de cada uma;
2. Relacionamentos entre as classes;
3. Multiplicidade dos relacionamentos;
4. Visibilidade de atributos e métodos;
5. Nome dos relacionamentos e papel nos relacionamentos;
6. Navegabilidade nos relacionamentos;
7. Notas e comentários.
Classes com seus atributos e operações
Atributo - O conceito de atributo remete ao conjunto de características (estado) dos objetos da classe.
Ele descreve uma propriedade estrutural da classe, um dado relevante que desejamos armazenar daquela classe. Segundo a UML, forma mínima de representar um atributo é: visibilidade Nome: tipo.
Operações - O conceito de método remete ao conjunto de operações (comportamento) que a classe fornece.
A operação de uma classe é representada por um método, que é um procedimento ou função da classe. Segundo a UML, a forma mínima de representar um método é: visibilidade Nome (Lista de parâmetros) : tipo.
Associação entre classes
O relacionamento de associação é o mais simples e comum relacionamento entre classes. Ocorre entre uma, duas ou mais classes distintas, não correlatas e independentes. Ao final do relacionamento, as classes permanecem com suas vidas próprias.	
A associação entre classes pode acontecer das seguintes maneiras, veja:
Associação binária - É a associação mais comum, também chamada de associação entre duas classes.
Autoassociação - Também chamada de associação unária, corresponde à associação que ocorre com a mesma classe, na qual uma classe se relaciona com ela própria.
Associação exclusiva - É uma restrição em duas ou mais associações. Ela indica que objetos de uma determinada classe podem participar de no máximo uma das associações, em determinado momento.
Ela é representada por uma linha tracejada, entre as associações, com a especificação {ou}, denotando que o relacionamento é exclusivo a somente uma das duas classes.
Multiplicidade nos relacionamentos
A multiplicidade é um conceito extremamente relevante nos relacionamentos. De uma forma bem simples, ela indica quantos objetos de cada classe podem estar envolvidos no relacionamento.
Visibilidade de atributos e métodos
Diz respeito a quais classes podem ver (visualizar) o que de outra classe. A ideia é que cada classe tenha elementos privados e públicos. Observe:
O que for público pode ser visualizado e usado por qualquer outra classe.
O que for privado só pode ser usado pela classe proprietária.
No entanto, ao saímos da modelagem e passarmos para a implementação, temos que observar as particularidades de cada um no tocante à visibilidade.
A UML aborda o tema sem entrar nessa confusão e deixa a cargo da equipe de desenvolvimento esses aspectos de compatibilidade. Basicamente, a UML permite que se rotule todo atributo e método de uma classe com um indicador de visibilidade.
Preparamos algumas diretrizes relevantes sobre visibilidade que você deve estar atento. Veja:
O encapsulamento, um dos princípios básicos da orientação a objetos, diz que os atributos de uma classe não devem ser usados por outras classes, e sim apenas por métodos da própria classe. A conclusão é que os atributos devem ser classificados com visibilidade privada (-);
Uma classe deve prestar serviço às demais, através de seus métodos. Assim sendo, pelo menos um dos métodos da classe deve ter visibilidade pública, para que as demais classes possam usá-lo;
Num relacionamento de generalização/ especialização, todos os atributos e métodos que desejar que sejam herdados pela classe especializada (subclasse) devem ter visibilidade protegida na classe geral (superclasse).
Outros relacionamentos entre classes
Os relacionamentos representam os mais relevantes elementos de um diagrama de classes. Por isso, agora estudaremos os relacionamentos mais usados na modelagem de classes.
Além das associações, são possíveis os seguintes relacionamentos:
Navegabilidade nos relacionamentos de associação
Notas e comentários no diagrama de classes e UML
Notas são comentários nos diagramas. Elas podem ser isoladas ou vinculadas, por linha tracejada, a um dos elementos do diagrama. Podem ainda ser usadas em qualquer diagrama.
A figura a seguir, ilustra as duas possibilidades: notas associadas a um elemento, no caso à classe endereços e nota associada ao diagrama, de uma forma geral.
Aula 5 – 
Diagramas de interação
Os sistemas orientado a objetos implementam as funcionalidades que oferecem, pela troca de mensagens entre os objetos, ou seja, um objeto envia uma mensagem a outro quando deseja que este realize uma tarefa. 
Baseado nesse contexto, podemos entender de que forma os diagramas de interação atuam. Vamos entender isso partindo do conceito de diagrama de casos de uso e diagrama de classes. Veja:
Os diagramas de casos de uso apresentam as funcionalidades. 
O diagrama de classes mostra a estrutura (nome, atributos e métodos) e relacionamentos entre as classes necessárias ao sistema.
Os diagramas de interação mostram como as classes (na verdade, os objetos) trocam mensagens, ou seja, interagem para oferecer uma funcionalidade (ou realizar um caso de uso).
Tipos de diagramas de interação
Os diagramas de interação, de uma forma geral, mostram como as classes colaboram em determinados comportamentos. Visam ilustrar como os objetos interagem, por meio de mensagens. São dois tipos de diagramas de interação: o diagrama de sequência e o diagrama de comunicação.
Veja algumas características desses dois tipos de diagramas de interação:
De uma forma genérica, o diagrama de sequência é o mais rico dos dois, mas o diagrama de comunicação também tem sua finalidade, na medidaem que é mais flexível quanto ao desenho. Cada um dos diagramas de interação tem suas vantagens e desvantagens que os tornam úteis em diferentes situações.
De uma forma geral, ambos visam estabelecer a integração entre o diagrama de classes e o diagrama de especificações textuais dos casos de uso, mostrando como as classes colaboram na realização de um cenário de uso (um caso de uso é um conjunto de cenários de uso).
Uma das grandes contribuições dos diagramas de interação é a identificação de novos métodos para as classes e ainda a ajuda na identificação de qual classe deve conter um determinado método.
A UML, em sua versão 2.0, oferece algumas formas de modelar interações, e o diagrama de sequência é o mais usado deles. O outro é o diagrama de comunicação, que nas versões anteriores à 2.0 da UML era chamado de diagrama de colaboração. A seguir, veja algumas diretrizes sobre os diagramas de interação:
Num mesmo projeto, podemos até usar os dois diagramas de interação, mas para representar interações ou comportamentos diferentes.
Não faz sentido usar ambos, por exemplo, para representar um mesmo cenário de uso, pois eles têm o mesmo objetivo, porém focos diferentes.
Para cenários, casos de uso ou comportamentos diferenciados, podemos optar por um dos dois. Mas em geral, usa-se apenas um deles por todo o projeto.
Comparativo entre os diagramas de interação
Como vimos, os diagramas de interação podem ser de dois tipos: diagrama de sequência e diagrama de comunicação. Cada um tem sua vantagem, que por sua vez atua como desvantagem para o outro. Veja, a seguir, um comparativo das vantagens, quando usar, pontos fortes e fracos de cada tipo de diagrama:
O tripé da análise
Do ponto de vista da fase de análise de sistemas, existem três modelos que se integram e formam uma base mínima para a modelagem e documentação de sistemas. São eles:
Diagrama de casos de uso e especificações de casos de uso;
Diagrama de classes;
Diagrama de sequência ou diagrama de colaboração.
Esses três diagramas formam o chamado tripé da análise. Veja essa relação na figura ao lado:
Casos de uso (em suas especificações) — Especificam o comportamento do sistema (ou parte dele), descrevendo as funcionalidades deste. O caso de uso é um conjunto de cenários, no qual:
O cenário é uma sequência de passos que descreve uma interação entre o sistema e um usuário;
Todo caso de uso tem o cenário principal, que é o “caminho sem erros”, ou seja, tudo acontece sem nenhum problema ou exceção;
A cada problema ou exceção, pode-se derivar um novo cenário, mostrando como o sistema vai se comportar.
O diagrama conceitual de classes mostra as classes do domínio do problema.
O diagrama de sequência ou comunicação mostra a interação (como trocam mensagens) entre os objetos (classes) de um determinado cenário (caso de uso).
O Diagrama de Sequência - A partir de agora vamos conhecer as especificidades do diagrama de sequência.
Você já sabe que o diagrama de sequência visa mostrar como as classes envolvidas interagem (trocam mensagens) para a realização de um caso de uso, mais especificamente de um cenário de uso (parte de um caso de uso), ao longo da linha do tempo. O foco aqui é a sequência da troca de mensagens.
Assim, o diagrama de sequência mostra o passo a passo da especificação do cenário de uso, evidenciando as classes relacionadas e como elas trocam mensagens entre si, conforme ilustra a imagem (trecho de diagrama de sequência) a seguir:
O objeto Controlador envia uma mensagem de nome Procurar Cliente () ao objeto Cliente.
O Diagrama de Sequência e seus Elementos
Dentre os elementos principais de um diagrama de sequência, podemos destacar:
Os objetos participantes da interação são organizados na horizontal;
Abaixo de cada objeto, existe uma linha pontilhada (linha de vida);
Cada linha de vida possui o seu foco de controle (caixa de ativação);
O foco de controle indica que o objeto está fazendo algo;
As mensagens entre objetos são representadas com linhas horizontais rotuladas, partindo da linha de vida do objeto remetente e chegando à linha de vida do objeto receptor.
Representando decisões no diagrama de sequência
Muitas vezes, precisamos representar que determinadas mensagens serão enviadas ou não de acordo com a chamada condição de guarda; ou ainda representar um conjunto de mensagens mutuamente exclusivas (no qual, dentre várias mensagens possíveis, apenas uma delas é enviada). Na imagem a seguir, vemos um trecho de diagrama de sequência, no qual representamos a decisão. 
Observe que temos o retângulo, com uma linha tracejada dentro, com o rótulo de nome “alt”, indicando um fragmento alternativo para a lógica condicional de exclusão mútua, expresso em guardas. Na parte de cima, inicial do retângulo, temos a condição de guarda [Tipo Cliente =F] e na parte de baixo, após a linha tracejada, temos outra condição de guarda [Tipo Cliente = J].
Descrição:
O ator informa o tipo de cliente, que pode ser F (física) ou J (jurídica);
Se o Tipo Cliente = F (primeira condição de guarda) = VERDADE, executa-se as mensagens que estão associadas a essa condição, ou seja, as mensagens que estão antes da linha tracejada;
Ator informa os dados da pessoa física (dados cliente físico);
Ocorre a inserção desses dados, através da chamada ao método Inserir CliFis(), que está na classe Pessoa Física;
Se o Tipo Cliente = F = FALSO, desvia-se para a execução das mensagens que estão após a linha tracejada, na qual temos outra condição de guarda a ser avaliada;
Se Tipo Cliente = J (segunda condição de guarda) = VERDADE, executa-se as mensagens que estão associadas a essa condição, ou seja, as mensagens que estão após a linha tracejada;
Ator informa os dados da pessoa jurídica (Dados Jur);
Ocorre a inserção desses dados, através da chamada ao método Inserir CliJur(), que está na classe Pessoa Jurídica.
Representando repetições no diagrama de sequência
Além dos elementos já discutidos, o diagrama de sequência possibilita que especifiquemos repetições, ou seja, uma ou mais mensagens que são enviadas repetidas vezes. Veja um exemplo:
Esse trecho de diagrama de sequência representa a repetição, na caixa LOOP, chamada de quadro de interação, com a condição de guarda [Para cada item de venda], ou seja, enquanto houver item na venda e o caixa (ator) digitar um cod produto, as mensagens e interações contidas na caixa LOOP serão executadas (ProcurarProd(), Inserir Novo Item() e Incluir Item() ).
O retângulo que representa a repetição tem o rótulo “Loop”, indicando fragmento de repetição enquanto a condição de guarda for verdadeira.
Observe que os métodos Inserir Novo Item () e Incluir Item () serão executadas se a condição [Se produto Exists) for verdadeira. E tal condição varia em função do resultado do método ProcurarProd(), contido na classe Produto.
Criação e destruição de objetos
O diagrama de sequência dispõe de duas notações extras para representar, respectivamente, a criação (<<Create>>) e a destruição (<<Destroy>>) de objetos participantes da interação. A seguir, veja exemplos das duas notações:
Uso da criação - Na figura a seguir, vemos o uso da criação do participante (Objeto Criado). Depois de criado, quando recebe a mensagem <<CREATE>>, representado pelo método (CriaObjeto()), o Objeto Criado pode receber e enviar mensagens normalmente.
Uso da destruição - Na figura a seguir, temos o exemplo da destruição de objetos, quando o objeto destruidor envia a mensagem <<destroy>>, representado pela execução do método DestroyMessage(). O elemento, representado pelo X, no objeto destruído representa o seu fim.
Um objeto pode se autodestruir, o que é representado por um X ao final da linha de vida de um objeto (neste caso, é como se o objeto enviasse uma destruição a si próprio).
Tipos de Mensagens: Síncronas e Assíncronas
Os exemplos aplicados sobre o diagrama de sequência, até aqui, usaramapenas a mensagem síncrona, ou seja, aquela que uma vez enviada, aguarda o retorno (seta pontilhada na direção contrária) com a sua conclusão (tal qual uma chama de rotina em um programa).
O outro tipo é a mensagem assíncrona, ou seja, a que uma vez enviada não necessita esperar por uma resposta e pode continuar o fluxo do processamento.
Responsabilidade das Classes
Quando definimos uma mensagem no modelo de interações, estamos atribuindo uma responsabilidade a uma classe.
A modelagem de interações é um procedimento cuja finalidade é decompor as responsabilidades do sistema e alocá-las a classes.
Exemplo -Se partimos do princípio que um sistema terá N responsabilidades, podemos pensar em algumas soluções de divisões de responsabilidades entre as classes desse sistema. As soluções extremas seriam: uma classe contendo as N responsabilidades ou N classes contendo uma responsabilidade cada. Claro que essas duas soluções são inviáveis na prática, mas entre elas existem outras possibilidades.
A tarefa de identificação de classes e atribuição de responsabilidades é complexa e existem várias formas para realizá-la. A melhor solução dependerá, obviamente, da expertise do modelador e da correta aplicação de alguns princípios básicos de desenvolvimento de software. A coesão e o acoplamento são dois desses princípios. Ela é uma medida que indica o quão relacionado (afins) são as responsabilidades de uma classe. Um bom projeto indica uma alta coesão, ou seja, as responsabilidades de uma classe devem ser fortemente relacionadas entre si. Ao modelarmos classes, uma questão de relevância surge. Veja:
Qual classe deve ser responsável por um determinado método?
Ou seja, em qual classe devemos alocar esse método?
Para tal decisão, devemos levar em consideração volume, desempenho, segurança e outros aspectos físicos, inerentes à implementação. Existe um conjunto de critérios que devem ser avaliados, e nosso foco aqui não é nos estendermos nesse assunto, mas alertar da preocupação. Apenas para citar, devemos alocar os métodos de forma que tenhamos um baixo acoplamento e alta coesão entre as classes.
Classes de Interface e Controle
 
No conceito do desenvolvimento em camadas, devemos separar as classes em:
Interface - É a classe de interface, cujo estereótipo é <<boundary>>, que identifica uma classe que serve de comunicação entre os atores e o sistema.
Controle - É a classe de controle, com o estereótipo de <<Control>>, que serve de intermediação entre a classe de interface e as demais classes. Fica responsável por interpretar eventos ocorridos sobre os objetos <<boundary>> (eventos de mouse e teclado) e encaminhar a classe correta que precisa receber aquele evento.
Entidade - São as classes de entidade, com o estereótipo <<entity>>, que representam as classes do domínio do problema, que contém o conhecimento do negócio.
Em geral, temos uma classe de interface por cenário de uso e uma classe de controle por caso de uso.
Tipicamente a sequência entre as classes ocorre conforme o procedimento descrito na imagem a seguir:
O ator solicita a ação desejada, pela interface do cenário de uso;
A classe de interface encaminha o pedido a classe de controle;
A classe de controle traduz o pedido e solicita à respectiva entidade que execute determinada operação;
A sequência de retornos acontece, até que pela interface com o usuário tem a sua resposta.
A seguir, você pode visualizar o diagrama equivalente, alterando apenas a forma de apresentar a classe de entidade:
Aula 6 – 
Minimundo do Estudo de Caso
Iniciaremos nossa aula com um Estudo de Caso. Observe o minimundo descrito, a seguir.
A empresa fictícia Faixa Amarela Ltda. confecciona faixas de anúncios por encomenda. Como os pedidos vêm crescendo, Seu Pereira, proprietário da gráfica de faixas, encomendou um sistema que controle suas atividades, que basicamente compreendem: Controle e acompanhamento dos pedidos e Cadastramento de clientes.
O cliente, geralmente indicado por um amigo satisfeito com os serviços da gráfica, faz seu pedido; Seu Pereira (o diretor) ou a atendente faz o atendimento e registra no caderno de pedidos:
Cliente: nome, cpf, endereço completo, tel_fixo, Tel_cel;
Pedido: data do pedido, tamanho da faixa (altura e largura), texto a ser escrito, cor (amarela, preta ou branca), cor do texto (branco, preto, azul ou vermelho), previsão de entrega, valor do serviço e do sinal (50% do valor total do serviço).
No levantamento de requisitos foi decidido que o sistema deve possuir as seguintes funcionalidades:
Valor - O valor do serviço é calculado com base na seguinte fórmula: 
Valor da faixa = Custo_Material + Custo_desenho + % Lucro
Custo_Material = área x 20,00
Custo_Desenho = número de letras * 0,70
% de Lucro = 20 % (Custo_Material + Custo_desenho)
Prazo - O prazo de entrega deve ser calculado levando-se em consideração a produção diária de faixas, que não deve ultrapassar oito. Considere cinco dias úteis por semana, para fins do cálculo da data de entrega.
O prazo deve começar a ser contabilizado após a confirmação do pagamento do sinal. O sistema deve calcular o prazo de entrega e o valor do serviço.
Recibo - Para cada encomenda, deve ser emitido um recibo, em duas vias, contendo os dados do pedido e pagamento (valor do sinal e valor a pagar na entrega).
Controle de pagamento - O sistema deve controlar o pagamento do sinal, quando o serviço é iniciado e a data de entrega calculada. Apenas a diretoria deve ter acesso a essa funcionalidade.
O sistema deve controlar o pagamento da parcela a ser paga na entrega. O pagamento do sinal deve ser feito por depósito bancário, e o pagamento do saldo deve ser pago contra entrega, em dinheiro, cheque ou cartão de débito.
O produto somente é entregue mediante o pagamento do saldo. A entrega deve ser controlada pelo sistema.
Consulta - O sistema deve prover uma consulta (disponível apenas a diretoria), de cada pedido feito no período, informando: data do pedido, data de entrega, valor do serviço, valor do sinal, sinal pago (S/N), serviço finalizado (S/N), serviço pago (S/N) e status do pedido (S/N).
Mudança de estados - O pedido, ao longo do seu ciclo de vida, pode ter vários estados e o sistema deve controlar os eventos que geram mudança de estado. Vejamos:
Ao ser inserido, o status é “Em espera”;
Assim que o sinal for pago, o status passa a ser “Pronto para produção”;
Quando o responsável técnico da fábrica inicia a produção da faixa, o status passa a ser “Em produção”;
Ao ser finalizado, o status passa a ser “Pronto”;
Ao ser entregue, o status passa a ser “Entregue”. Para ser considerado entregue, o pedido tem que ter o saldo de pagamento confirmado.
Informe ao cliente - O sistema deve emitir um informe a todo cliente que não faz pedidos há mais de seis meses (com base na data corrente).
Unidades por pedido - Recentemente, foi feita uma modificação no sistema de pedidos, e agora em um mesmo pedido pode ser encomendada mais de uma faixa, até cinco no máximo (mas esta regra pode alterar a qualquer momento).
Seguiremos o seguinte procedimento para a modelagem desse sistema com base em UML:
Diagramação da 1ª versão do diagrama de casos de uso; Identificação das principais funcionalidades do sistema;
Especificação textual de casos de uso de relevância;
Refinamento do diagrama de casos de uso; Identificação de includes ou extends que otimizem a solução;
Identificação das classes do negócio;
Diagrama conceitual de classes;
Diagrama de sequência dos casos de uso de relevância.
Veremos cada passo, a seguir.
1ª versão do diagrama de casos de uso - Observe, ao lado, uma primeira versão do diagrama de casos de uso, no qual figuram as grandes funcionalidades do sistema:
Especificações de casos de uso
A seguir, temos uma breve descrição da finalidade de cada caso de uso modelado na 1ª versão do diagrama de sequência.
Versão refinada do diagrama de casos de uso
Umadas formas de identificarmos otimizações de casos de uso, com base em includes, é através da observação de repetições de trechos nas descrições de casos de uso.
Observe que, nos casos de uso Confirmar Recebimento do Sinal, Registrar Início da Produção, Registrar Fim da Produção e Registrar Entrega do Pedido, temos os dois trechos a seguir repetidos: o primeiro no cenário principal e todo o cenário alternativo.
A otimização que pode ser feita seria a inclusão do caso de uso «Pesquisar Pedido» é relacioná-lo, através do relacionamento «include», aos casos de uso anteriormente citados.
A seguir, uma versão refinada, com as considerações anteriores:
As especificações dos casos de uso também precisam ser modificadas para refletir as alterações representadas no diagrama.
Observe que, no local das três linhas que havia anteriormente na especificação do caso de uso “Confirmar Recebimento do Sinal”, passamos a ter uma única linha com a inclusão do novo caso de uso («Include» Pesquisar Pedido), que também precisa ser especificado.
E o cenário alternativo de “Confirmar Recebimento de Sinal” passa a ser o cenário alternativo do «include» Pesquisar Pedido.
Caso de uso: Confirmar Recebimento do Sinal
Pré-condição: pedido registrado, cliente registrado e pedido pago.
Pós-condição: data de entrega do pedido definida.
Diagrama Conceitual de Classes
O diagrama conceitual de classes pode ser extraído dos casos de uso. De uma forma simplificada, a extração ocorre:
Casos de uso podem ser classes;
Casos de uso podem ser métodos.
Assim, temos:
Diagrama de Sequência - Agora passemos aos diagramas de interação, especificamente o diagrama de sequência, que nos dará maior clareza dos métodos das classes.
Vamos elaborar o diagrama de sequência dos casos de uso: Registrar Pedido, Consultar pedidos do período e Consultar Clientes sem Pedido, posto que os demais são muito diretos e não modificarão nem a alocação de atributos nem a de métodos já alocados, conforme a imagem do diagrama anterior.
Caso de uso: Registrar Pedido - Cenário: Principal
Este diagrama de sequência cria um conjunto de métodos, nas diversas classes envolvidas na interação. Conforme regra já explicada, toda seta que chega em uma classe é um método dessa classe.
Caso de uso: Consultar Pedidos no Período - Cenário: Principal
Caso de uso: Consultar Clientes em Pedido - Cenário: Principal
Modelo Conceitual - Após toda a análise das interações, o modelo conceitual de classes ficará conforme o exemplo.
Observe que tal modelo ainda não dispõe de visibilidade de atributos e métodos, bem como parâmetros e tipos de dados de retorno dos métodos, propositalmente, pois em geral esses dados são inseridos no modelo de classes de projeto, que discutiremos na continuidade, que se dará na aula 10.
Aula 7 – 
Estado de um objeto
O estado de um objeto compreende todas as suas propriedades associadas aos valores correntes de cada uma delas. Tais propriedades compreendem os atributos de uma classe. Ou seja, o estado de um objeto é determinado pelos valores de seus atributos, em um determinado momento.
Para garantir a propriedade do encapsulamento, é salutar que apenas os métodos que denotam o comportamento da classe à qual o objeto pertence alterem os seus respectivos atributos.
O período de tempo em que o objeto permanece vivo e ativo, chamamos de ciclo de vida, ou seja, o tempo que decorre desde a sua criação até sua destruição. Durante o ciclo de vida, o objeto pode ter finitos estados, caracterizados por determinados valores de alguns de seus atributos
Um objeto muda de um estado para outro na medida em que eventos (internos ou externos) acontecem. Quando ocorre uma mudança de estados, dizemos que houve uma transição entre estados.
Assim sendo, temos que: eventos acarretam a transição entre estados de um objeto. No momento da transição, o objeto realiza determinadas ações dentro do sistema.
Pela análise das transições de estados, é possível identificar as operações que precisam ser realizadas para responder aos eventos. Tais operações estarão mapeadas em métodos da classe a que o objeto pertence.
O diagrama da UML que ajuda na análise das transições entre os estados de um objeto é o diagrama de transição de estados, ou simplificadamente, diagrama de estados.
O Diagrama de Transição de Estados – DTE
O diagrama de transição de estados - DTE apresenta os possíveis estados de um objeto e demonstra, por meio das transições, os eventos que geram as mudanças de um estado para outro(s), durante todo o ciclo de vida do objeto.
Em outras palavras, o DTE descreve o ciclo de vida de objetos de uma classe, os eventos que causam as transições entre estados e as operações resultantes.
Diferentemente dos diagramas de interação (que descrevem o comportamento de objetos de diferentes classes, mostrando a interação entre elas), o DTE mostra o comportamento de objetos de uma única classe.
Conceitos Básicos: Estado, Evento e Transição
Estado - O estado de um objeto é a sua condição específica, em algum momento em que ele está sendo usado no sistema.
Segundo a definição de Booch, Rumbauch e Jaconson (2006), estado é uma condição ou situação na vida de um objeto durante o qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento.
Um objeto permanece em um estado por um tempo finito. Cada estado de um objeto é, em geral, determinado pelos valores de seus atributos.
Esta imagem mostra a representação de um estado, segundo a UML — um retângulo com bordas arredondadas:
Evento - Um evento é a ocorrência (interna ou externa) de um estímulo gerado para o objeto, capaz de mudar o seu estado atual.
Transição - Uma transição indica um movimento de um estado para o outro, pela ocorrência de um evento.
A imagem a seguir mostra o evento e a consequente transição de estado, onde a ocorrência do evento faz com que haja a transição (representada pela seta) entre o “estado UML 1” para o “estado UML 2”. A seta indica a direção da transição. Observe:
Os estados podem ser classificados em dois tipos, que são chamados de pseudoestados. São eles:
Estado inicial - O estado inicial é representado pelo círculo preenchido e denota o pseudoestado de um objeto no momento de sua criação, quando ele é instanciado na memória. Só há um estado inicial em um DTE, mostrando o início de sua leitura. Veja o exemplo: 
Estado final - O estado final é representado pelo círculo preenchido com outro círculo em volta e denota o pseudoestado do fim do ciclo de vida de um objeto. É um estado opcional, no DTE, e também pode haver mais um. Veja o exemplo:
A figura a seguir mostra um exemplo simples de diagrama de estados que contempla os elementos básicos, que foram explicados anteriormente. Veja:
Vamos identificar os elementos do diagrama de estados, analisando a figura a seguir, que apresenta o diagrama de estado (DTE) de uma classe Quarto de um sistema de gestão hoteleira:
O início ocorre no pseudoestado inicial que é a bola preta, cuja seta aponta para o estado Disponível, efetivamente o estado em que fica o quarto inicialmente.
Ou seja, assim que o objeto é criado (estado inicial), ele já entra no estado Disponível. Imagine um quarto sendo criado (novo quarto) que, ao ser inserido no sistema (estado inicial), entra no estado Disponível.
Estando no estado Disponível, o estado pode transitar para o estado Reservado quando ocorre o evento “Cliente faz Reserva”.
Ou seja, assim que um cliente confirma uma reserva, o estado do objeto quarto transita (muda) para reservado.
Estando no estado de Reservado, pode haver duas transições distintas:
Transição (de volta) para o estado Disponível se ocorrer o evento “Reserva é cancelada”;
Transição para o estado Ocupado, se ocorrer o evento “Cliente fazcheck-in” (chega ao hotel para hospedar-se).
Do estado Ocupado, só pode haver transição para o estado Em Limpeza, na medida em que ocorre o evento “Cliente faz check-out” (deixa o hotel).
Estando no estado Em Limpeza, o quarto voltará ao estado Disponível na ocorrência do evento “Atendente libera Quarto”.
Estando no estado Disponível, o Quarto pode mudar também para o estado Final, quando for excluído do sistema (quarto deixa de existir para hospedagem).
Exemplo de diagrama de estados
Os estados determinam e delimitam as operações que podem ser realizadas com aquele objeto. Veja um exemplo:
Pela análise do DTE, um hóspede não pode chegar ao hotel e hospedar-se sem que tenha feito uma reserva: isto é interpretado pela ausência de transição entre os estados Disponível e Ocupado. Somente existe transição para o estado Ocupado, estando no estado Reservado.
Para que seja possível a ocupação de quarto sem a devida reserva, o DTE deveria ser como o representado na imagem a seguir, em que, pela transição de Disponível para Ocupado, acabamos com a obrigação de reservar um quarto para poder ocupá-lo.
A representação das transições entre os estados Disponível e Reservado foi feita por uma seta dupla (nas duas direções).
Na seta que representa a transição do estado Disponível para Reservado, temos a ocorrência do evento “Cliente Faz Reserva”;
Na seta que representa a transição de Reservado para Disponível, temos a ocorrência do evento “Reserva é cancelada”.
Detalhando a Transição
A transição, em um diagrama de estados, indica um movimento de um estado para outro. Cada transição possui um rótulo que possui três partes. Veja: 
Assinatura do gatilho - Via de regra, é um único evento que demanda a mudança de estado. No exemplo inicial, sobre os estados do Quarto do hotel, usamos apenas a assinatura do gatilho (Cliente Faz Reserva, Cliente Faz Check-in etc.), ou seja, o evento que ocasiona a transição de estado.
É raro que esteja ausente, mas pode ocorrer e denota que a transição é feita imediatamente.
Sentinela - Quando estiver presente, corresponde a uma condição que deve ser verdadeira para que a transição ocorra. Se ausente, indica que a transição sempre acontece. É representada entre colchetes [..], com a condição dentro.
Atividade - É um comportamento executado durante a transição. A ausência de atividade diz que nada é feito durante a transição.
Exemplo de transição completa
O trecho de DTE a seguir mostra uma transição completa. Veja a descrição:
Assinatura do gatilho: Saque de R$
Sentinela: [Saldo ˂ 0]
Atividade: Aguardar depósito
Ações de Entrada e Saída, Transições internas e Atividades
Seguem algumas características avançadas do DTE, que ajudam a otimizá-lo, a reduzir a quantidade de estados e a sua complexidade:
Exemplo de ações de Entrada e Saída, Transições internas e Atividades
Veja, agora, um exemplo de como declarar no estado ações de entrada (Entry), de saída (Exit) e atividaes (do):
Acrescentando uma transição interna, temos:
Retornando ao exemplo do DTE referente à classe Quarto do sistema Hotel, poderíamos eliminar o estado Em limpeza, fazendo com que a Limpeza seja uma ação de saída (Exit) do estado Ocupado, e assim, reduziremos o número de estados. Ou seja, quando o cliente fizer o check-in, evento que ocasiona a transição de Ocupado, em vez de ir para o estado Em limpeza, iria direto para Disponível e acrescentaríamos uma ação de saída (Exit), de nome Limpeza, ao estado Ocupado.
O diagrama de estado alterado para atender ao especificado, é representado na imagem a seguir:
Observe que:
Desaparece o estado em limpeza;
A limpeza passa a ser uma atividade que será realizada antes do estado transitar para disponível;
Entre Disponível e Ocupado, a transição pode acontecer nos dois sentidos: de Disponível para Ocupado, quando ocorrer o evento “Cliente Faz Check-in”; e de Ocupado para Disponível, quando ocorrer o evento “Cliente faz Check-out”.
Superestados
Um superestado, também chamado de estado composto, ajuda a simplificar a modelagem de comportamentos complexos, sendo composto de vários estados ou subestados.
Um estado composto pode ser sequencial ou concorrente. Segue um exemplo de superestado sequencial, ilustrado em duas imagens:
O primeiro diagrama é o principal e tem um superestado, de nome Ativo. Observe que ele tem um símbolo dentro, que mostra que contém em si outros estados.
O estado Cancelado tem uma transição do estado Ativo, denotando que pode haver uma transição de qualquer estado do superestado Ativo para o estado Cancelado. Se não fosse assim, haveria uma transição de cada estado para cancelado, o que não estaria errado, mas tornaria o desenho mais complexo.
A segunda imagem mostra o desdobramento do estado Ativo, composto dos subestados Solicitado, Em produção, Embalando e Entregue.
Passo a Passo para a Construção do DTE
O DTE (diagrama de transição de estado) deve ser elaborado para classes cujos objetos tenham dois ou mais estados. Veja o passo a passo para a construção do DTE:
Contribuições do DTE ao Diagrama de Classes
Para finalizarmos esta aula, veja algumas contribuições do DTE ao Diagrama de Classes:
O DTE pode ser construído com base nas especificações de casos de uso, nos diagramas de interação e nos diagramas de classes;
Novas propriedades (atributos e métodos) podem ser descobertos ao elaboramos o DTE e devem ser incorporados ao diagrama de classes;
Pode ser necessária a atualização de um ou mais métodos de uma classe, para refletir o comportamento dos objetos nos respectivos estados. Por exemplo: o comportamento do método sacar() da classe ContaBancária varia em função do estado no qual esta classe se encontra. Saques, por exemplo, não podem ser realizados em uma conta que esteja no estado Bloqueada.
Aula 8 – Diagrama de atividades
O diagrama de atividades tem por objetivo apresentar, de forma gráfica, a lógica de procedimentos, de processos, de fluxos de trabalho ou de métodos complexos de uma classe.
O diferencial do diagrama de atividades, em comparação a ferramentas de apresentação da lógica, como por exemplo fluxogramas, é a possibilidade de representar o processamento paralelo, útil especialmente na modelagem de processos, que em geral possui atividades concomitantes.
Fluxograma, o precursor do diagrama de atividades - Quem programava lá pelo final dos anos 1970 e início dos 1980 vai se lembrar de uma ferramenta muito usada para especificação da lógica de programas: o fluxograma.
Antes de escrever o código na linguagem de programação, os programadores pensavam na lógica do programa e, através do fluxograma, modelavam graficamente (através de formas geométricas) os fluxos de controle desse programa. Foi uma das primeiras ferramentas de modelagem gráfica usadas.
Em tese, o fluxograma pode ser usado para representar o fluxo de procedimentos ou processos das empresas, conforme ilustra a imagem a seguir.
Os primeiros elementos do diagrama de atividades - Os elementos do diagrama de atividades diferem daqueles usados nos fluxogramas, mas sua essência é bem próxima. Os principais elementos do diagrama de atividades são:
Atividade - Retângulo com bordas arredondadas.
Transição - Setas contínuas que representam o fluxo de trabalho entre atividades.
Decisões - Losango, usados para controlar os desvios (caminhos) do fluxo de controle.
Condição de guarda - São condições associadas a transições entre uma atividade e outra, indicando que a atividade que sucede somente será executada se a condição de guarda for verdadeira. 
Ponto de merge – 
Desvios: a decisão, que divide em dois ou mais caminhos (fluxos de atividades). Tem um fluxo de entrada e N fluxos de saída;
Intercalações: local onde dois ou mais caminhos (fluxos de atividades) se juntam e continuam como apenas um fluxo. É usado o mesmo losango da decisão.
Os caminhos que se juntam foram separadosanteriormente pelo elemento desvio. Tem N fluxos de entrada e um fluxo de saída.
Processamento em paralelo - Bifurcação e união (ou junção): barras horizontais que sincronizam atividades que vão ocorrer em paralelo. No caso, as atividades que ocorrem em paralelo são processar pedido e faturar pedido.
Representando o fluxo de controle paralelo - A UML dotou o diagrama de atividades de dois elementos que operam em conjunto, que permitem expressar o comportamento paralelo, ou seja, uma ou mais atividades que podem acontecer ao mesmo tempo. Muitos afirmam ser esse o grande diferencial do diagrama de atividades da UML para outras ferramentas gráficas, como o fluxograma, que se atem apenas a representar o processamento sequencial.
A programação em paralelo em algoritmos concorrentes não é muito comum no mundo comercial, sendo mais usada em software básico (como por exemplo, em sistemas operacionais).
O poder do paralelismo do diagrama de atividade é mais comumente usado para representar processos de negócio ou fluxos de trabalho.
Para iniciar ou sincronizar dois ou mais fluxos de trabalho em paralelo, são usados dois tipos de barras de sincronização: bifurcação (fork) e junção (joint).
Raias de natação - Para entender melhor o particionamento do diagrama de atividades, vamos pensar nas raias de natação, que exibem os agentes que realizam cada atividade no diagrama.
O diagrama de atividades também é dividido em compartimentos, nos quais cada um será executado por um agente, que poderá ser:
Departamentos ou setores da empresa (financeiro, contabilidade, criação, propaganda etc.),
Funções ou cargos de pessoas nas empresas (gerente, operação, atendente etc.),
Papéis nas empresas (fornecedor, cliente, segurado, seguradora etc.).
O diagrama de atividades representa, ainda, a lógica de casos de uso ou de métodos complexos de uma classe. Já as raias podem representar: objetos, componentes e atores.
Observe o diagrama de atividades a seguir, com o uso de raias de natação, com as 4 entidades envolvidas no pedido: o cliente faz o pedido, o departamento de vendas processa o pedido, o estoquista separa os produtos do pedido e o setor de distribuição despacha os produtos ao cliente.
Para que usar o diagrama de atividades? - Muitos autores (Eduardo Bezerra, Martin Fowler, dentre outros) já destacaram o pouco uso dos diagramas de atividades em projetos de desenvolvimento de software. Mesmo que voltados para as utilidades descritas a seguir, o uso de diagrama de atividades não ocorre em larga escala, e os principais motivos são:
Documentar sistemas não é uma prática usual no Brasil, em função de vários motivos que não cabem discutir aqui.
Em sistemas desenvolvidos sob o paradigma da orientação a objetos, o particionamento do sistema é por classes, e não por funcionalidades (como seria nos paradigmas estruturado e essencial); como o diagrama de atividades descreve um comportamento, estaria, pela lógica, mais relacionado a funcionalidades.
As aplicações mais usuais para diagramas de atividades são:
Modelagem de processos de negócios e fluxos de trabalho - Essa utilização é que mais tira proveito do fato de o diagrama de atividades permitir representar fluxos de controle paralelos, já que em muitos processos de negócio e em fluxos de trabalho, as sequências de atividades costumam acontecer em paralelo.
Modelagem da lógica de um caso de uso complexo - Muitas vezes, a especificação textual de casos de uso complexos demanda muito esforço e, por vezes, por sua extensão, é difícil de ser visualizada como um todo (ocupando mais de uma folha de papel ou de editor de texto).
Modelagem da lógica de uma operação complexa - Embora não seja muito usual, os métodos de classes podem ter uma lógica complexa, especialmente em classes de controle; neste caso, o diagrama de atividades pode ser útil para representar a lógica desse método.
Modelar a lógica de algoritmos paralelos para programas concorrentes - Pode-se valer dos elementos (separações e junções) usados pelo diagrama de atividades para representar o processamento paralelo em programas concorrentes.
Subatividades no diagrama de atividades - As atividades, quando complexas, podem ser decompostas em subatividades. Neste caso, tal atividade decomposta terá um diagrama especificando suas subatividades e o diagrama principal terá uma representação diferenciada — com símbolo do ancinho, conforme esta imagem:
Aplicando diagrama de atividades - Vamos observar uma aplicação do diagrama de atividades. Para isso, observe as informações abaixo: 
Modelagem da lógica de um caso de uso complexo
act Caso de Uso Registra Pedido
Segue uma das possíveis soluções do diagrama de atividades:
Observe que os passos do caso de uso, como exibir dados (passo 3) e alteração de status (passo3), por serem ações simples, podem ser omitidos do diagrama de atividades. Representá-los não seria um erro, mas detalhes que podem ser omitidos.
Observe que o extends do caso de uso (cadastrar cliente) é considerado uma atividade e representado no diagrama de atividades, dando a visão do cenário principal e do alternativo.
Aula 9 – 
Diagrama de Componentes - O diagrama de componentes mostra os componentes de um sistema e suas dependências. São úteis para a modelagem da arquitetura física de um software, apresentando os componentes físicos, suas interfaces e dependências. Esse diagrama permite o desenvolvimento baseado em componentes, em que um software é dividido em componentes e interfaces reutilizáveis e substituíveis. Veja um exemplo:
Imagine um sistema de home theater, composto por componentes que podem ser facilmente conectados uns aos outros e substituídos a qualquer momento: projetor, receiver, caixas de som (frontal, lateral, subwoofer). Se qualquer elemento queimar, poderemos substituí-lo por um igual ou equivalente (com as mesmas interfaces).
A ideia do uso de componentes em software é a mesma: conjunto de componentes, com interfaces bem definidas, que podem ser integrados a qualquer sistema e substituídos sempre que necessário.
Componentes - A UML define componente da seguinte forma:
Assim, um componente pode ser definido como uma caixa preta, em que são especificadas suas interfaces para que outros componentes possam usar seus serviços, sem conhecer detalhes de como esses serviços estão sendo implementados. Ou seja, o componente encapsula (protege) o seu conteúdo, e seu comportamento é definido em função de prover e requerer serviços, através de suas interfaces.
O desejo é que o componente possa ser independente e intercambiável. Em um sistema baseado em componentes, cada componente tem uma finalidade, ou seja, presta um serviço, e para tal, demanda o uso de outros componentes.
Esta imagem mostra a representação do componente na UML por nome “Componente”. Veja:
Interfaces - Interfaces são elementos que definem um conjunto de operações que outros elementos, como classes ou componentes, devem implementar. Um mesmo componente pode tanto fornecer como requerer interfaces. O relacionamento entre os componentes e as interfaces é a essência dos sistemas.
Em diagramas de componentes, existem dois tipos de interfaces. Veja:
Interfaces fornecidas - Descrevem os serviços oferecidos a outros componentes. Um componente pode declarar quantas interfaces fornecidas forem necessárias.
O símbolo de uma interface fornecida é o círculo apresentado à esquerda do componente, conforme a imagem:
Interfaces requeridas - São as interfaces usadas pelo componente, quando solicita serviços de outros componentes. Um componente pode ter várias interfaces requeridas.
O símbolo da interface requerida é um semicírculo apresentado à direita do componente, conforme a imagem:
Componentes e Interfaces - O usuário do serviço de um componente deve conhecer bem a sintaxe das interfaces do componente. Analogamente ao exemplo dado de início, as interfaces são as conexões possíveis entre o receiver do home theather e os dispositivos