Autor e Texto

Author - Text

Maria Rosângela Oliveira Machado Rosa de Souza*
A ENGENHARIA DE REQUISITOS NO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
The Engineering Of Conditions On The Process Of System Development

Resumo
Este trabalho destaca a importância da Engenharia de Requisitos no processo de desenvolvimento de sistemas. Apresenta os vários tipos de requisitos e formas de levantamento e análise, recursos para validação e revisão destes. Mostra uma maneira de planejar o gerenciamento de requisitos e de mudanças.

Abstract
This work mentions the importance of the Requirements Engineering in the process of development of systems. It presents the several types, elicitation and analysis forms of the requirements, the resources for validation and revision of these. This document shows a way to plan the management and changes of the requirements.

Palavras-Chave
Engenharia de Requisitos. Tipos de Requisitos. Gerenciar Requisitos. UML. Estrutura da UML

Key Words
Requirements Engineering. Types Requirements. Management Requirements. UML. Structure UML *Especialista em Análise de Sistemas pelo IFSP. Especialista em Tecnologia da Informação pelo SENAC. Mestranda em Automação e Controle de Processos pelo IFSP. Professora da Faculdade Renascença.
R.TEMA S.Paulo nº 50 jul/dez. 2007 P.  6-23

UNIESP

6

Maria Rosângela Oliveira Machado Rosa de Souza
A ENGENHARIA DE REQUISITOS NO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS**
The Engineering Of Conditions On The Process Of System Development

entro do processo de desenvolvimento de sistemas, a atividade engenharia de requisitos produz um documento que retrata de forma geral o que o sistema deve fazer. Segundo Sommerville(2003) compreender a natureza dos problemas pode ser muito difícil, especialmente se o sistema for novo. Consequentemente, é difícil estabelecer com exatidão o que o sistema vai fazer. As descrições das funções e das restrições são os requisitos para o sistema; e o processo de descobrir, analisar, documentar e verificar essas funções e restrições é chamado de engenharia de requisitos. Pressman(2006) O processo de desenvolvimento de sistemas, ilustrado na figura 1, engloba atividades como a Engenharia de Requisitos permite criar o documento de requisitos que relaciona as funções e restrições que se aplicam ao sistema a ser construído. A Análise proporciona entender as diretrizes especificadas no documento de requisitos.
** Este ensaio apresenta desdobramento na página 24 e seguintes, no artigo intitulado Uma Visão Estrutural Da Unified Modeling Language-Uml. A bibliografia de ambos está na página 37, desta edição.

D

7

TEMA

O Projeto conduz a uma solução capaz de atender às prescrições do documento produzido na atividade de análise. A Implementação leva a construir a solução definida na atividade projeto. O Teste valida a solução construída na atividade de implementação.
Engenharia de Requisitos Análise Projeto

Implementação

Teste
Fig 1 – O processo de desenvolvimento de sistemas.

2. DIFERENCIANDO REQUISITOS Apresentado a seguir a distinção que Sommerville(2003) faz para os diferentes níveis de descrição de requisitos: - Requisitos do usuário são declarações, em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar. - Requisitos de sistema estabelecem detalhadamente as funções e as restrições de sistema. Algumas vezes UNIESP 8

O padrão mais amplamente conhecido é o IEEE/ANSI 830-1993 (IEEE.Requisitos de domínio são os requisitos que se originam do domínio de aplicação do sistema e que refletem características deste domínio. . como o sistema deve reagir a entradas específicas e como dever se comportar em determinadas situações. O DOCUMENTO DE REQUISITOS Organizações de grande porte. como. Esse padrão sugere a seguinte estrutura para os documentos de requisitos: a.chamado de especificação funcional. acrônimos e abreviações Referências 9 TEMA . que é uma base para o projeto e a implementação mais detalhados.1993). Esta especificação pode servir como um contrato entre o comprador e o desenvolvedor do sistema. também. .Requisitos funcionais são declarações de funções que o sistema deve fornecer. Essa especificação acrescenta mais detalhes à especificação de requisitos do sistema. sobre o processo e padrões. 3. Podem ser requisitos funcionais ou não funcionais.Especificação de projeto de software é uma descrição abstrata do projeto de software. . Os requisitos de sistemas são classificados como: . como o Departamento de Defesa dos Estados Unidos e o IEEE definiram padrões para os documentos de requisitos. Introdução Propósito do documento de requisito Escopo do produto Definições.Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema. Destacamse restrições de tempo. o que o sistema não deve fazer.

Definir o público a que se destina o documento. interfaces como outros sistemas. precisam ser compreendidos por pessoas que não são peritos técnicos. d. incluindo informações sobre a evolução prevista para o sistema. Pode incluir diferentes UNIESP 10 . Especificação de Requisitos do Sistema .Definir os termos técnicos.Apresentar uma visão geral de alto nível.Descrever os requisitos funcionais e não funcionais. por recomendação de Heninger(1980). c. Prefácio . a operação a outros sistemas. A estrutura ampliada para um documento de requisitos é apresentada a seguir: I. IV. III. VI. como. e. V. Visão geral do restante do documento Descrição Geral Perspectiva do produto Funções do produto Características do usuário Restrições gerais Suposições e dependências Requisitos específicos Apêndices Índice Sommerville(2003) amplia o padrão IEEE.Descrever a necessidade do sistema.b. Descrever o histórico da versão e sumário. Arquitetura de Sistemas . também. II. Podem ser descritos em linguagem natural. Glossário . Introdução . Padrões de produtos e de processos a serem seguidos. Os componentes reutilizados devem ser destacados. como o sistema se ajusta aos negócios e aos objetivos estratégicos da organização. suas funções.Os serviços fornecidos e os requisitos não funcionais. mostrando a distribuição de funções por meio de módulos de sistemas. Definição de Requisitos do Usuário .

de comportamento. como alfabético. Modelos de Sistema . pela evolução de equipamento ou necessidades de usuários. estrutural. VII. os modelos são freqüentemente mais compreensíveis do que as descrições detalhadas em linguagem natural dos requisitos de sistema. como hardware e bases de dados. de fluxo de dados e semânticos de dados. Um estudo de viabilidade é breve. direcionado e destinado a responder às seguintes questões: O sistema contribui para os objetivos gerais da organização? 11 TEMA . de diagramas e de funções. IX.Descrever as mudanças previstas.Incluir índices de conteúdo distintos. ESTUDO DE VIABILIDADE Segundo Sommerville(2003) o processo de engenharia de requisitos de sistema deve começar com um estudo de viabilidade. Esses modelos são representações gráficas que descrevem o problema a ser resolvido e o sistema a ser desenvolvido. a arquitetura ou estruturada de dados processados do sistema é modelada. VIII. Devido às representações gráficas utilizadas. o contexto ou o ambiente do sistema é modelado. 4. Eles são também uma importante ponte entre o processo de análise e de projeto. o comportamento do sistema é modelado. X.modelos do sistema. mostrando o relacionamento entre os componentes de sistema e o sistema e seu ambiente. Modelos de objeto. Evolução de Sistema .Estabelecer um ou mais modelos.Detalhar informações específicas da aplicação. Utilizados a partir de diferentes perspectivas: externa. Os modelos podem ser utilizados no processo de análise para desenvolver uma compreensão do sistema existente a ser substituído ou melhorado ou para especificar o sistema requerido. Índice . Apêndices .

dentro do processo de engenharia de requisitos. se o sistema não fosse implantado? Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas? Que contribuição direta o sistema trará para os objetivos da empresa? As informações podem ser transferidas para os outros sistemas organizacionais e também podem ser recebidas a partir deles? O sistema requer tecnologia que não tenha sido utilizada anteriormente na organização? O que precisa e o que não precisa ser compatível com sistema? O estudo de viabilidade deve recomendar se o desenvolvimento do sistema deve continuar ou não. Pode propor mudanças no enfoque. O sistema pode ser implantado com a utilização de tecnologia atual dentro das restrições de custo e de prazo? O sistema pode ser integrado com outros sistemas já em operação? O estudo de viabilidade envolve avaliar e coletar informações que responderão o questionário acima. além de sugerir outros requisitos de alto nível. Estas informações podem ser obtidas através de outros questionamentos: Como a organização se comportaria. LEVANTAMENTO E ANÁLISE DE REQUISITOS Seguindo os ensinamentos de Sommerville(2003) e Pressman(2006) é nesta etapa de levantamento e análise de requisitos. UNIESP 12 . no orçamento e no cronograma. 5.

fazer a classificação dos requisitos em grupos coerentes. pois os stakeholders determinam o que querem do sistema em termos muito gerais. a importância dos requisitos pode mudar em função do ambiente econômico e de negócios. onde os analistas devem procurar ter a compreensão do domínio da aplicação. pedidos em inconformidade com os custos. 13 TEMA . elaborar a definição das prioridades interagindo com os stakeholders. Stakeholder é o termo utilizado para identificar qualquer pessoa que tenha alguma influência sobre os requisitos do sistema. interagir com os stakeholders para a coleta de requisitos e desenvolvendo a compreensão do domínio da aplicação. O processo de levantamento e análise de requisitos é difícil. os usuários finais. que serviços o sistema deve fornecer o desempenho exigido e as restrições de hardware. determinar se os requisitos são completos e consistentes na verificação de requisitos. os que desenvolvem o sistema ou fazem manutenção em outros sistemas relacionados. Em uma organização os stakeholders podem ser as pessoas que venham a ser afetadas. como o domínio da aplicação. entre outros. A figura 2 será mostrada na página seguinte. através de novos stakeholders. A figura 2 apresenta um modelo para o processo de levantamento e análise de requisitos. de alguma forma. procurar a resolução de conflitos criados pelas informações vindas de diferentes stakeholders. especificam requisitos de forma a aumentar sua influência política na organização. os gerentes de negócios e os especialistas no domínio da aplicação. pelo sistema. expressam os requisitos com termos de sua área de atuação.que a equipe de desenvolvimento apura as informações. que é dinâmico.

Especificação de requisitos Verificação de requisitos Compreensão do domínio Definição das prioridades Documento de requisitos Coleta de requisitos Resolução de conflitos Classificação UNIESP Entrada do processo 14 Figura 2. Um modelo para o processo de levantamento e análise de requisitos Fonte: Sommerville(2003) .

um modelo de máquina de estados. 5. Um framework de representação – Diferentes pessoas devem desenvolver um modelo de relacionamento de entidades. Um ponto de vista pode ser considerado como: Um fonte ou drenos de dados – Identificar. quais os dados são produzidos ou consumidos e que processamento é realizado. é possível usar técnicas como: o levantamento orientado a pontos de vista. coletando esses serviços e resolvendo conflitos. Para trabalhar o levantamento e análise de requisitos. Cada abordagem de análise descobre diferentes aspectos sobre o sistema que está sendo analisado. Não existe uma abordagem perfeita e universalmente aplicável para a análise de requisitos. é preciso utilizar várias dessas abordagens para desenvolver compreensão e análise completas dos requisitos. Um receptor de serviços (os pontos de vista são externos) – A análise envolve examinar os serviços recebidos por diferentes pontos de vista. os cenários e a etnografia. Fonte ou drenos de dados Modelos de Pontos de vista Framework Receptor de serviços 15 TEMA . Ponto de Vista A importância da análise orientada a pontos de vista é que ele reconhece a existência de várias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders. Normalmente. Exemplo disto são os sistemas interativos que fornecem serviços aos usuários finais. como também.1. entre outros. os métodos de análise estruturada e a prototipação.

segundo uma hierarquia. Os pontos de vista devem interagir com o sistema de alguma maneira. . Vantagens desse tipo de ponto de vista: . foi projetado como um framework orientado a serviços. Os pontos de vista múltiplos permitem que o mesmo serviço tenha diferentes requisitos não funcionais em diferentes pontos de vista.os pontos de vista são externos ao sistema e. utilizando as informações de serviço que estão encapsuladas nos pontos de vista. O método Viewpoint-Oriented Requirements Definition – VORD. 4. para o levantamento e a análise de requisitos.é relativamente fácil decidir se alguma coisa é um ponto de vista válido. 2. Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior. UNIESP 16 .os pontos de vista e os serviços são um meio útil de estruturar os requisitos não funcionais. Identificar objetos em um projeto orientado a objetos. Agrupar os pontos de vista relacionados. . Cada serviço pode ter requisitos não funcionais associados. assim. 3. são uma maneira natural de estruturar o processo de levantamento de requisitos. Refinar a descrição dos pontos de vista e serviços identificados. Envolve descobrir os pontos de vista que utilizam serviços do sistema e identificar os serviços específicos fornecidos para cada ponto de vista. Kotonya (1998) Os estágios principais são: 1 identificação do ponto de vista 2 estruturação do ponto de vista 3 documentação do ponto de vista 4 mapeamento de sistema de ponto de vista 1.

de pontos de vista que recebem o serviço. Controlador de Demanda Máquina de Ar Condicionado Quadro de Iluminação Os pontos de vista recebem e fornecem entradas para serviços.2. O mesmo serviço pode estar alocado em diversos pontos de vista. a um conjunto de requisitos não funcionais que impõem restrições ao serviço. conforme definido abaixo: Modelo de ponto de vista Modelo de serviço Referência: o nome do ponto de Referência: o nome do serviço. Atributos: atributos que fornecem Razão: pela qual o serviço é informações sobre o ponto de vista. Provedores: referência a uma lista de objetos de sistema que fornecem o serviço 5. que podem ser expressas em diferentes notações. onde surgem os possíveis pontos de vista. Subpontos de vista: os nomes de Requisitos não funcionais: referência subpontos de vista. Eventos: uma referência a um conjunto de cenários de eventos que descreve como o sistema reage a eventos do ponto de vista. As informações podem ser descritas através de formulários. Especificação: referência a uma lista de especificações de serviços. As informações podem ser coletadas em uma primeira etapa através de reuniões de brainstorming com os stakeholders. vista. Estes podem ser anotados em um diagrama de bolhas. fornecido. Cenários 17 TEMA . Serviços: uma referência a um Pontos de vista: lista de nomes conjunto de descrições de serviços.

Os cenários podem ser particularmente úteis para acrescentar detalhes a um esboço da descrição de requisitos. Usados para descrever modelos de sistemas orientados a objetos. Dentro da Unified Modeling Language . A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais. especificação. diagramas de seqüência podem ser utilizados para acrescentar informações a um usecase. O valor de etnografia é que ela ajuda a descobrir requisitos de sistemas implícitos. identifica os agentes envolvidos em uma interação e especifica o tipo de interação. De modo geral podem incluir uma descrição do estado do sistema no início do cenário. informações sobre outras atividades que possam estar em andamento ao mesmo tempo. e do estado do sistema no final do cenário. Etnografia Os sistemas são utilizados em um contexto social e organizacional.UML definida como uma linguagem para a visualização. 5. A etnografia é particularmente eficaz na descoberta de dois tipos de requisitos: os derivados da maneira como as pessoas realmente trabalham. os objetos dentro do sistema com os quais eles interagem e as operações que estão associadas a esses objetos. Satisfazer os requisitos sociais e organizacionais é fundamental para o sucesso do sistema. do que pode sair errado e de como lidar com isso. em vez de os processos formais. construção e documentação de artefatos de um sistema complexo de software. Esses diagramas de seqüência mostram os agentes envolvidos na interação.3. Elas compreendem seu próprio trabalho. mas podem não compreender a relação dele com outras atividades na organização. Uma abordagem mais estruturada pode ser empregada com os cenários de eventos ou use-cases. que refletem os processos reais. do fluxo normal de eventos no cenário. em que as pessoas estão envolvidas. em vez da maneira pela UNIESP 18 .

De completeza – o documento de requisitos deve incluir requisitos que definam todas as funções e restrições exigidas pelo usuário do sistema. Essas verificações devem também levar em conta o orçamento e os prazos para o desenvolvimento do sistema. resultante de um problema de requisito. No documento de requisitos. O custo de fazer uma modificação no sistema. De realismo – utilizando o conhecimento da tecnologia existente. Seu enfoque é no usuário final.qual as definições de processo dizem como elas deveriam trabalhar e os derivados da cooperação e conscientização das atividades de outras pessoas. De validade – os sistemas têm diversos usuários com necessidades diferentes e qualquer conjunto de requisitos é inevitavelmente uma solução conciliatória da comunidade de usuários. os requisitos devem ser verificados. diferentes tipos de verificação devem ser realizadas: I. quando esses erros são descobertos durante o desenvolvimento ou depois que o sistema estiver em operação. VALIDAÇÃO DE REQUISITOS A validação de requisitos é importante porque a ocorrência de erros em um documento de requisitos pode levar a grandes custos relacionados ao retrabalho. portanto. é muito maior do que reparar erros de projeto ou de codificação. de modo que um número menor de ciclos de refinamento seja necessário. A etnografia pode ser combinada com a prototipação. IV. III. De consistência – não devem existir restrições contraditórias ou descrições diferentes para uma mesma função do sistema. 6. 19 TEMA . II. Informa o desenvolvimento do protótipo. não é uma abordagem completa. a fim de assegurar que eles realmente podem ser implementados.

7. Adaptabilidade – ele pode ser modificado sem que isso provoque mudanças em outros requisitos. Existe uma série de técnicas de validação de requisitos que podem ser utilizadas em conjunto ou individualmente: a. Isso significa que um conjunto de verificações pode ser projetado para mostrar que o sistema entregue cumpre com esses requisitos. Geração de caso de testes – os requisitos deveriam ser testáveis. Análise automatizada da consistência – a ferramenta CASE deve construir uma base de dados de requisitos e. Revisão de requisitos – os requisitos são analisados sistematicamente. os requisitos do sistema devem ser sempre escritos de modo que possam ser verificados. Em uma revisão formal verificam-se as seguintes facilidades: 1. De compreensão. De verificação – para reduzir o potencial de divergências entre cliente e fornecedor. verificação do documento de requisitos com o objetivo de detectar anomalias ou omissões. V. Prototipação – experimentar o modelo para verificar se ele atende às suas necessidades. então. 2. c. que envolve cliente e fornecedor. De rastreamento – avaliar o impacto de uma mudança no restante do sistema. 3. De verificação – o requisito é passível de ser testado. d. b. uma análise de requisitos produz um relatório das inconsistências que foram descobertas. GERENCIAMENTO DE REQUISITOS UNIESP 20 . 8. REVISÕES DE REQUISITOS É um processo manual. como foi definido. 4.

evoluir.emergentes – surgem a medida que a compreensão do cliente se desenvolve. afetados por mudanças na tecnologia de hardware. criar novos meios de trabalho. novas legislações e regulamentos. Existem alguns tipos: . . .comunidade de usuários diversificada. Novos requisitos surgem pelas seguintes razões: . Os requisitos não funcionais são. e esses requisitos podem ser conflitantes com os requisitos dos usuários finais. a compreensão destes está constantemente se modificando. 21 TEMA . Ao longo do tempo de desenvolvimento. Os requisitos devem. .a empresa e o ambiente técnico do sistema se modificam. .os clientes do sistema impõem requisitos em razão de restrições organizacionais e orçamentárias. portanto. particularmente. o ambiente do sistema e os objetivos da empresa certamente deverão ser modificados. Requisitos voláteis – são os que provavelmente vão se modificar durante o desenvolvimento do sistema ou depois que o sistema estiver em operação. a fim de refletir essas mudanças. Requisitos permanentes – são os relativamente estáveis. por parte de quem desenvolve os sistemas. essas mudanças refletem nos requisitos. que derivam da atividade principal da organização e que se relacionam diretamente com o domínio do sistema.conseqüentes – a introdução do sistema de computação pode modificar os processos da organização.mutáveis – mudanças no ambiente no qual a organização está operando. Sistemas são geralmente desenvolvidos para lidar com problemas.

a medida que eles se modificam.1. para que possa ser utilizado nas avaliações de facilidade de rastreamento. Devem ser registradas e mantidas. Da origem – vinculam os requisitos aos stakeholders que os propuseram. Existem três tipos de informações importantes sobre a facilidade de rastreamento: 1.. Políticas de facilidade de rastreamento – definem as relações entre os requisitos e entre os requisitos e o projeto de sistema. 2. que reflete a facilidade de se encontrar requisitos relacionados. Identificação de requisitos – identificado de modo único. o sistema encomendado pode também ter que evoluir. Os seguintes aspectos devem ser considerados: 1. Suporte de ferramentas Case – envolve processar uma grande quantidade de informações sobre os requisitos. para que possa ser feita a referência cruzada. Planejamento do Gerenciamento de Requisitos O planejamento estabelece o nível de detalhes exigido para o gerenciamento de requisitos. 3. Processo de gerenciamento de mudanças – atividades que avaliam o impacto e o custo das mudanças. 2.compatibilidade – dependem de sistemas ou processos de negócios específicos. 8. A facilidade de rastreamento é uma propriedade geral de uma especificação de requisito. 4. UNIESP 22 . De requisitos – vinculam requisitos dependentes.

com uma proposta específica de mudança. planilhas de cálculo e banco de dados de PCs. Gerenciamento de mudanças de requisitos Problema identificado Análise do problema Análise e custo e especificação da da mudança mudança Implementação de mudanças Requisitos Revisados A vantagem de utilizar um processo formal para o gerenciamento de mudanças é que todas as propostas de mudanças são tratadas de modo consistente e que as mudanças no documento de requisitos são feitas de maneira controlada. Há três estágios principais neste gerenciamento de mudanças: 1. Sistemas pequenos podem utilizar recursos de processadores de texto. Análise de custo de mudança – o efeito da mudança proposta é avaliada. o projeto e a implementação são modificados. 3. 3. 23 TEMA . De projeto – vinculam os requisitos aos módulos de projeto em que esses são implementados. O apoio de ferramenta é necessário para: armazenamento. Implementação de mudanças – o documento de requisitos. gerenciamento de mudanças e facilidade de rastreamento. utilizando-se informações sobre a facilidade de rastreamento e o conhecimento geral dos requisitos do sistema.2. 8. Análise do problema e especificação da mudança – o processo começa com a identificação de um problema com os requisitos ou. algumas vezes. 2.

Text Maria Rosângela Oliveira Machado Rosa de Souza* UMA VISÃO ESTRUTURAL DA UNIFIED MODELING LANGUAGE . Especialista em Tecnologia da Informação pelo SENAC.Uml Resumo Este trabalho apresenta um desenho estrutural da UML que complementa as descrições dos recursos e permite entender a formação do modelo conceitual.TEMA S. Key Words Uml.Autor e Texto Author .  24-37 UNIESP 24 . Structure Of The Uml.UML A Structural Vision Of The Unified Modeling Language .Paulo nº 50 jul/dez 2007 P. Estrutura da UML. Abstract This essay presents a structural design of UML which completes the descriptions of resources and allows to learn the formation of a conceptual modeling. Mestranda em Automação e Controle de Processos pelo IFSP. Palavras-Chave UML. Professora da Faculdade Renascença. R. **Especialista em Análise de Sistemas pelo IFSP.

. A figura 1 apresenta um desenho estrutural da UML que auxilia na compreensão do texto abaixo. construção e documentação de artefatos de um sistema complexo de software. a escolha da UML explica-se por ser uma linguagem de modelagem que possui recursos que permitem visualizar. as regras e os mecanismos. construir e documentar os elementos. que reúnem os itens (b1). constituem os blocos de construção básicos orientados a objetos da UML. Os BLOCOS DE CONSTRUÇÃO (a1) são de três tipos: .UML A Structural Vision Of The Unified Modeling Language .itens (b1) são as identificações das abstrações. Aprender a formação do modelo conceitual da UML implica em entender três elementos principais: (a) os blocos de construção.Uml a literatura a UML era definida como uma linguagem para a visualização. seus relacionamentos e a comunicação com dispositivos externos ao sistema. de qualquer tipo de sistema.Maria Rosângela Oliveira Machado Rosa de Souza UMA VISÃO ESTRUTURAL DA UNIFIED MODELING LANGUAGE . especificação. Hoje. 25 TEMA N . especificar.relacionamentos (b2) são blocos relacionais básicos de construção.

As REGRAS (a2) especificam o que deverá ser um modelo bem formado. A UML dispõe de regras semânticas (b4) para: os nomes que podem ser atribuídos aos itens. Os blocos de construção da UML não podem ser simplesmente combinados de uma forma aleatória. geralmente representados como gráficos e vértices (itens b1) e arcos (relacionamentos b2). UNIESP 26 . Um diagrama é a apresentação gráfica de um conjunto de elementos. -um escopo que determina um significado específico para um nome. -a visibilidade dos nomes permitindo que estes sejam vistos e utilizados. -a integridade de como os itens se relacionam entre si de forma adequada e consistente. -a execução ou simulação de um modelo dinâmico. que mostra um desenho estrutural da UML. um diagrama constitui uma projeção de um determinado sistema. Nesse sentido.diagramas (b3) agrupam coleções de itens. . A seguir será apresentada a figura 1. relacionamentos e diagramas. Os diagramas são desenhados para permitir a visualização de um sistema sob diferentes perspectivas.

27 TEMA .

será possível construir modelos de maneira incremental. adornos. O mesmo se aplica a UML. RUMBAUGH. UNIESP 28 . Uma interface declara um contrato e a implementação representa uma realização completa desse contrato. p. desenhando diagramas e depois acrescentando uma semântica às especificações do modelo ou diretamente pela criação de uma especificação. Outra divisão é entre interface e implementação. A UML é aberta-fechada. BOOCH. a especificação determina os detalhes do sistema.MECANISMOS (a3) Qualquer construção se torna mais simples e harmoniosa devido à adequação a um padrão de características básicas. responsável pela manutenção fiel da semântica completa da interface. que se torna mais simples pela presença de quatro mecanismos básicos (Cf. A especificação é capaz de fornecer uma declaração textual da sintaxe e da semântica do respectivo bloco de construção. permite ampliar a linguagem de maneira controlada.28): especificações. divisões comuns e mecanismos de extensão (b5). Há divisões comuns na modelagem de sistemas orientados a objetos. onde novos tipos de blocos de construção são criados a partir dos já existentes. O vocabulário da UML pode ser ampliado através de um estereótipo.. Levando em consideração esses dois aspectos. onde uma classe é uma abstração e um objeto é uma manifestação concreta dessa abstração. Os mecanismos de extensibilidade incluem as seguintes características: estereótipos. JACOBSON. Os adornos são itens gráficos ou visuais. adicionados à notação básica de um elemento e empregados para a visualização de detalhes a partir da especificação do elemento. A notação gráfica da UML permite visualizar um sistema. como a divisão de classes e objetos. 2000. valores atribuídos e restrições (c7).

casos de uso. CLASSE – são descrições de conjuntos de objetos que compartilham os mesmos atributos. ou seja. ESTRUTURAIS (c1) São os substantivos. comportamentais. C1. classes ativas. são as partes mais estáticas do modelo. relacionamentos e semântica. operações. interface. componentes e nó (d1). representando elementos conceituais ou físicos. colaborações. modificar as regras já existentes ou acrescentar. de agrupamentos e anotações. Nome da Classe Atributos Operações SensorTemperatura setPointTemperatura : Float reset( ) setAlarm(t : Temperatura) valor( ) : Temperatura 29 TEMA . As classes implementam uma ou mais interfaces. ITENS (b1) Itens são recursos que identificam as abstrações. As propriedades dos blocos de construção podem ser estendidas através de um valor atribuído. Ao todo são sete: classe. As semânticas dos blocos de construção podem ser ampliadas por uma restrição. criando novas informações na especificação de um elemento. Existem quatro tipos de itens (b1): estruturais.1.

O atributo pode ter a indicação de um valor padrão. Estereótipos são utilizados para indicar grupos. Uma classe pode ter qualquer número de operações ou nenhuma. O primeiro caractere de cada palavra existente no nome deve estar em maiúsculo. representando algum comportamento da classe. A existência de mais atributos ou propriedades pode ser indicada terminando cada lista com reticências (. O nome de um atributo é um substantivo ou expressão que. Uma classe pode ter qualquer número de atributos ou nenhum. O nome de uma operação é um verbo ou uma locução verbal. O NOME de uma classe pode ser um texto composto por qualquer número de caracteres e determinados sinais de pontuação. por exemplo. Um ATRIBUTO é. breve. definidos a partir do vocabulário do sistema cuja modelagem está sendo feita.. utilizados para separar o nome da classe e o nome do pacote que a contém e pode se estender por várias linhas. setPointTemperatura : Float. exceto alguns sinais. portanto. O primeiro caractere de cada palavra existente no nome do atributo deve estar em maiúsculo. como os dois pontos. exceto a primeira letra. representa alguma propriedade da classe correspondente. uma abstração do tipo de dados ou estados que os objetos da classe podem abranger.). Uma OPERAÇÃO é uma abstração de algo que pode ser feito com um objeto e que é compartilhado por todos os objetos dessa classe. organizando listas extensas de atributos e operações.. Os nomes das classes são substantivos ou expressões breves. UNIESP 30 .

FraudAgent <<constructor>> new ( ) new (p : Policy) <<process>> processo (o : Order) … <<query>> isSuspect (o : Order) isFruadulento (o : Order) <<helper>> validateOrder (o : Order) Uma responsabilidade é um contrato ou obrigação de uma determinada classe. atributos e operações são características com as quais as responsabilidades das classes são executadas. 31 TEMA estereótipos . c1. Geralmente é anexada à classe ou ao componente. Define um conjunto de especificações operacionais (suas assinaturas). Atributos. operações e responsabilidades são características mais comuns para criar as abstrações.é uma coleção de operações que especificam serviços de uma classe ou componente. Descreve o comportamento externamente visível desse elemento. Raramente aparece sozinha. Em um nível mais abstrato.2. INTERFACE . mas nunca um conjunto de implementações de operações. Praticamente todas as abstrações criadas são algum tipo de classe. Poderá representar todo o comportamento de parte de uma classe ou componente.

c1.4. COMPONENTES – são as partes físicas e substituíveis de um sistema. São semelhantes a uma Classe. UNIESP 32 . encontram-se diferentes tipos de componentes próprios da implantação. c1. c1.6. que proporciona a realização de um conjunto de interfaces. Realiza-se por uma colaboração. interfaces e colaborações.3..Nome do pacote que a contém Networking : : IRouter Nome da interface. Uma determinada classe poderá participar de várias colaborações. Representam o pacote físico de elementos lógicos diferentes.que podem iniciar um controle de atividade. COLABORAÇÕES – definem interações e são sociedades de regras e outros elementos que funcionam em conjunto para proporcionar a soma de comportamentos cooperativos. Em um sistema. precedido pela letra l. c1. daí o seu caráter ativo. Representam a implementação de padrões que formam um sistema. como os componentes COM+ OU JAVABEANS. CLASSES ATIVAS – são classes que possuem objetos que têm um ou mais processos. Apresentam dimensões estruturais e comportamentais. como classes.é a descrição de um conjunto de seqüência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. CASO DE USO .5. É utilizado para estruturar o comportamento de itens em um modelo. exceto que seus objetos representam elementos cujo comportamento é concorrente com os outros elementos (atributos e operações).

relacionamentos e semânticas. INTERAÇÃO (d2) é um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos de determinado contexto para a realização de propósitos específicos. inclusive mensagens. Descrevem conjunto de objetos que compartilham os mesmos atributos. COMPORTAMENTAIS (c2) São as partes dinâmicas dos modelos UML. São suficientemente diferentes e necessários para a modelagem de certos aspectos de sistemas orientados a objetos. Costumam estarem conectados. 33 TEMA . O comportamento de uma sociedade de objetos ou de uma operação individual poderá ser especificado por meio de uma interação.1. freqüentemente. Existem variações desses sete elementos como atores: sinais e utilitários (tipos de classes). Geralmente. Um conjunto de componentes poderá estar contido em um nó e também poderá migrar de um nó para outro. c1. páginas e tabelas (tipos de componentes). São os verbos de um modelo. são semelhantes às Classes. processos e threads (tipos de classes ativas). classes principais. arquivos. componentes e nós. conforme a semântica. aplicações. a vários elementos estruturais.7. colaborações e objetos. Existem dois tipos básicos: interação e máquina de estado (d2). capacidade de processamento. documentos. NÓ – é o elemento físico existente em tempo de execução que representa um recurso computacional. Envolve outros elementos. representando comportamentos no tempo e no espaço. operações. c2. seqüências de ações (comportamentos chamados pelas mensagens) e ligações (conexões entre os objetos). bibliotecas. com alguma memória e. As classes ativas.

MÁQUINA DE ESTADO (d2) é um comportamento que especifica as seqüências de estados. apenas um símbolo para representar restrições e explicações anexadas a um elemento ou a uma coleção de elementos. comentários incluídos para descrever.2. AGRUPAMENTO (c3) São as partes organizacionais dos modelos UML. associação. Especifica o comportamento de uma classe individual ou de uma colaboração de classes. DEPENDÊNCIA (c5) – é um relacionamento semântico entre dois Itens. generalização e realização. incluindo estados. eventos (itens que ativam uma transição). Abrange outros elementos. b2. Itens estruturais. Existe um tipo primário de item de anotação chamado Nota. UNIESP 34 .1. fazer alguma observação sobre qualquer elemento do modelo. podem ser colocados em pacotes. comportamentais e outros. ANOTAÇÕES (c4) São as partes explicativas dos modelos UML. c2. Um tipo importante de agrupamento é o mecanismo de propósito geral para a organização de elementos em grupo. os blocos em que os modelos podem ser decompostos. transições ( fluxo de um estado a outro). RELACIONAMENTOS (b2) É a vinculação dos blocos de construção da UML. bem como suas respostas a esses eventos. Esta ligação pode ser de quatro tipos: dependência. nos quais a alteração de um item independente pode afetar a semântica de outro item dependente. denominado pacote. pelas quais objetos de interações passam durante sua existência em resposta a eventos. atividades (respostas às transições). esclarecer.

DIAGRAMAS (b3) b3. os pais. b3.1.2.é um relacionamento estrutural que descreve um conjunto de ligações. interfaces e colaborações.3. DIAGRAMA DE CLASSES (c6) – exibe conjunto de classes. DIAGRAMA DE CASO DE USO (c6) – exibe um conjunto de Caso de Uso e Atores (um tipo especial de classe) e seus relacionamentos. b3. ASSOCIAÇÃO (c5) . 35 TEMA .4. e entre Casos de Usos e as Colaborações.3. São importantes para a organização e a modelagem de comportamentos do sistema. nos quais os objetos dos elementos especializados. b2. são substituíveis por objetos do elemento generalizado. bem como seus relacionamentos. Os diagramas de classes que incluem classes ativas e direcionam a perspectiva do processo estático do sistema. Dessa forma. b2. os filhos. Os vínculos de realizações serão encontrados em dois lugares: entre Interfaces e as Classes ou Componentes. GENERALIZAÇÃO (c5) – é um relacionamento de especialização ou generalização. b2. Representa retratos estáticos de instâncias de itens encontrados em diagramas de classes. os filhos compartilham a estrutura e o comportamento dos pais. DIAGRAMA DE OBJETOS (c6) – exibe conjunto de objetos e seus relacionamentos. REALIZAÇÃO (c5) – é um relacionamento semântico entre classificadores.2. Um classificador especifica um contrato que outro classificador garante executar. Um tipo especial de associação é a agregação. que representa um relacionamento estrutural entre o todo e suas partes. em que as ligações são conexões entre objetos.

DIAGRAMA DE ATIVIDADE (c6) – é um tipo especial de diagrama de gráfico de estado. b3. DIAGRAMA DE IMPLANTAÇÃO (c6) – mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes.6. pois os componentes são mapeados para uma ou mais classes. b3.8. É importante para a modelagem da função de um sistema e dá ênfase ao fluxo de controle entre objetos. Exibe o fluxo de uma atividade para outra no sistema diagrama de atividade. DIAGRAMA DE SEQÜÊNCIA - 5. incluindo as mensagens que podem ser trocados entre eles. Também para dar ênfase a comportamentos de um objeto.4. Os diagramas de Seqüência e Colaboração são isomórficos. transições. interfaces ou colaborações. isto é transformam o diagrama de um tipo em outro. Está relacionado ao diagrama de classes. ordenados por evento. No diagrama de Seqüência a ênfase está na ordenação temporal da mensagem. É de grande ajuda para modelagem de sistemas reativos. DIAGRAMA DE COLABORAÇÃO (c6) São tipos de diagramas de interação. Está UNIESP 36 . b3.7. eventos e atividades. É importante para modelagem de comportamentos de uma Interface. DIAGRAMA DE GRÁFICO DE ESTADO (c6) – exibe uma máquina de estados.9. A ênfase do Diagrama de Colaboração está na organização de estrutura dos objetos que enviam e recebem mensagens. formada por estados. b3. Composto de um conjunto de objetos e seus relacionamentos. DIAGRAMA DE COMPONENTE (c6) – exibe as organizações e as dependências existentes em um conjunto de componentes. b3. Classe ou Colaboração.

Specifying Software Requirements for Complex Systems: New Techniques and Their Application. Craig. Ian.UK: John Wiley and Sons. 2000. James.. RUMBAUGH. Makron Books. CONSIDERAÇÕES FINAIS Este trabalho procurou mostrar que a UML possui recursos específicos para analisar a estrutura de um sistema. 2006. PAGE-JONES. Requirements Engineering: Processes and Techniques. The Unified Modeling Languague User Guide. Roger S. REFERÊNCIAS BIBLIOGRÁFICAS (Segundo Texto) Páginas 24-37 BOOCH. Engenharia de Software. IEEE Transactions on Software Engineering. Fundamentos do Desenho Orientado a Objeto com UML. São Paulo: Makron Books. FURLAN. 1998. Ivar. 6ed. no. Chichester. vol. Addison Wesley. São Paulo: Addison Wesley. pois um nó inclui um ou mais componentes. SOMMERVILLE. PRESSMAN. Modelagem de Objetos através da UML – the Unified Modeling Language. Porto Alegre: Bookman. Ian. january 1980. REFERÊNCIAS BIBLIOGRÁFICAS (Primeiro Texto) Páginas 6-23 HENINGER. JACOBSON. Kathryn L. 2003. determinar seu comportamento e modelar a topologia de dispositivos que o executarão. 1. SOMMERVILLE. Utilizando UML e Padrões. 6ed. José Davi. Meilir. Gerald. Grady.relacionado ao diagrama de componentes. 37 TEMA . 1998. Engenharia de Software. KOTONYA. 1999. LARMAN. São Paulo: McGraw-Hill. 2001. se-6.