Autor e Texto

Author - Text

Maria Rosngela 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 importncia da Engenharia de Requisitos no processo de desenvolvimento de sistemas. Apresenta os vrios tipos de requisitos e formas de levantamento e anlise, recursos para validao e reviso destes. Mostra uma maneira de planejar o gerenciamento de requisitos e de mudanas.

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 Anlise de Sistemas pelo IFSP. Especialista em Tecnologia da Informao pelo SENAC. Mestranda em Automao e Controle de Processos pelo IFSP. Professora da Faculdade Renascena.
R.TEMA S.Paulo n 50 jul/dez. 2007 P. 6-23

UNIESP

Maria Rosngela 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 difcil, especialmente se o sistema for novo. Consequentemente, difcil estabelecer com exatido o que o sistema vai fazer. As descries das funes e das restries so os requisitos para o sistema; e o processo de descobrir, analisar, documentar e verificar essas funes e restries 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 funes e restries que se aplicam ao sistema a ser construdo. A Anlise proporciona entender as diretrizes especificadas no documento de requisitos.
** Este ensaio apresenta desdobramento na pgina 24 e seguintes, no artigo intitulado Uma Viso Estrutural Da Unified Modeling Language-Uml. A bibliografia de ambos est na pgina 37, desta edio.

TEMA

 O Projeto conduz a uma soluo capaz de atender s prescries do documento produzido na atividade de anlise. A Implementao leva a construir a soluo definida na atividade projeto. O Teste valida a soluo construda na atividade de implementao.
Engenharia de Requisitos Anlise Projeto

Implementao

Teste
Fig 1 O processo de desenvolvimento de sistemas.

2. DIFERENCIANDO REQUISITOS Apresentado a seguir a distino que Sommerville(2003) faz para os diferentes nveis de descrio de requisitos: - Requisitos do usurio so declaraes, em linguagem natural e tambm em diagramas, sobre as funes que o sistema deve fornecer e as restries sobre as quais deve operar. - Requisitos de sistema estabelecem detalhadamente as funes e as restries de sistema. Algumas vezes UNIESP 8

chamado de especificao funcional. Esta especificao pode servir como um contrato entre o comprador e o desenvolvedor do sistema. - Especificao de projeto de software uma descrio abstrata do projeto de software, que uma base para o projeto e a implementao mais detalhados. Essa especificao acrescenta mais detalhes especificao de requisitos do sistema. Os requisitos de sistemas so classificados como: - Requisitos funcionais so declaraes de funes que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como dever se comportar em determinadas situaes, como, tambm, o que o sistema no deve fazer. - Requisitos no funcionais so restries sobre os servios ou as funes oferecidas pelo sistema. Destacamse restries de tempo, sobre o processo e padres. - Requisitos de domnio so os requisitos que se originam do domnio de aplicao do sistema e que refletem caractersticas deste domnio. Podem ser requisitos funcionais ou no funcionais. 3. O DOCUMENTO DE REQUISITOS Organizaes de grande porte, como o Departamento de Defesa dos Estados Unidos e o IEEE definiram padres para os documentos de requisitos. O padro mais amplamente conhecido o IEEE/ANSI 830-1993 (IEEE,1993). Esse padro sugere a seguinte estrutura para os documentos de requisitos:
a. Introduo Propsito do documento de requisito Escopo do produto Definies, acrnimos e abreviaes Referncias

TEMA

b.

c. d. e.

Viso geral do restante do documento Descrio Geral Perspectiva do produto Funes do produto Caractersticas do usurio Restries gerais Suposies e dependncias Requisitos especficos Apndices ndice

Sommerville(2003) amplia o padro IEEE, por recomendao de Heninger(1980), incluindo informaes sobre a evoluo prevista para o sistema. A estrutura ampliada para um documento de requisitos apresentada a seguir: I. Prefcio - Definir o pblico a que se destina o documento. Descrever o histrico da verso e sumrio. II. Introduo - Descrever a necessidade do sistema, suas funes, a operao a outros sistemas, como o sistema se ajusta aos negcios e aos objetivos estratgicos da organizao. III. Glossrio - Definir os termos tcnicos. IV. Definio de Requisitos do Usurio - Os servios fornecidos e os requisitos no funcionais. Padres de produtos e de processos a serem seguidos. Podem ser descritos em linguagem natural, precisam ser compreendidos por pessoas que no so peritos tcnicos. V. Arquitetura de Sistemas - Apresentar uma viso geral de alto nvel, mostrando a distribuio de funes por meio de mdulos de sistemas. Os componentes reutilizados devem ser destacados. VI. Especificao de Requisitos do Sistema - Descrever os requisitos funcionais e no funcionais, como, tambm, interfaces como outros sistemas. Pode incluir diferentes UNIESP 10

modelos do sistema. VII. Modelos de Sistema - Estabelecer um ou mais modelos, mostrando o relacionamento entre os componentes de sistema e o sistema e seu ambiente. Modelos de objeto, de fluxo de dados e semnticos de dados. Esses modelos so representaes grficas que descrevem o problema a ser resolvido e o sistema a ser desenvolvido. Devido s representaes grficas utilizadas, os modelos so freqentemente mais compreensveis do que as descries detalhadas em linguagem natural dos requisitos de sistema. Eles so tambm uma importante ponte entre o processo de anlise e de projeto. Os modelos podem ser utilizados no processo de anlise para desenvolver uma compreenso do sistema existente a ser substitudo ou melhorado ou para especificar o sistema requerido. Utilizados a partir de diferentes perspectivas: externa, o contexto ou o ambiente do sistema modelado; de comportamento, o comportamento do sistema modelado; estrutural, a arquitetura ou estruturada de dados processados do sistema modelada. VIII. Evoluo de Sistema - Descrever as mudanas previstas, pela evoluo de equipamento ou necessidades de usurios. IX. Apndices - Detalhar informaes especficas da aplicao, como hardware e bases de dados. X. ndice - Incluir ndices de contedo distintos, como alfabtico, de diagramas e de funes. 4. ESTUDO DE VIABILIDADE Segundo Sommerville(2003) o processo de engenharia de requisitos de sistema deve comear com um estudo de viabilidade. Um estudo de viabilidade breve, direcionado e destinado a responder s seguintes questes: O sistema contribui para os objetivos gerais da organizao? 11 TEMA

 O sistema pode ser implantado com a utilizao de tecnologia atual dentro das restries de custo e de prazo? O sistema pode ser integrado com outros sistemas j em operao? O estudo de viabilidade envolve avaliar e coletar informaes que respondero o questionrio acima. Estas informaes podem ser obtidas atravs de outros questionamentos: Como a organizao se comportaria, se o sistema no fosse implantado? Quais so os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas? Que contribuio direta o sistema trar para os objetivos da empresa? As informaes podem ser transferidas para os outros sistemas organizacionais e tambm podem ser recebidas a partir deles? O sistema requer tecnologia que no tenha sido utilizada anteriormente na organizao? O que precisa e o que no precisa ser compatvel com sistema? O estudo de viabilidade deve recomendar se o desenvolvimento do sistema deve continuar ou no. Pode propor mudanas no enfoque, no oramento e no cronograma, alm de sugerir outros requisitos de alto nvel. 5. LEVANTAMENTO E ANLISE DE REQUISITOS Seguindo os ensinamentos de Sommerville(2003) e Pressman(2006) nesta etapa de levantamento e anlise de requisitos, dentro do processo de engenharia de requisitos, UNIESP 12

que a equipe de desenvolvimento apura as informaes, como o domnio da aplicao, que servios o sistema deve fornecer o desempenho exigido e as restries de hardware. Stakeholder o termo utilizado para identificar qualquer pessoa que tenha alguma influncia sobre os requisitos do sistema. Em uma organizao os stakeholders podem ser as pessoas que venham a ser afetadas, de alguma forma, pelo sistema, os usurios finais, os que desenvolvem o sistema ou fazem manuteno em outros sistemas relacionados, os gerentes de negcios e os especialistas no domnio da aplicao, entre outros. O processo de levantamento e anlise de requisitos difcil, pois os stakeholders determinam o que querem do sistema em termos muito gerais; pedidos em inconformidade com os custos; expressam os requisitos com termos de sua rea de atuao; especificam requisitos de forma a aumentar sua influncia poltica na organizao; atravs de novos stakeholders, a importncia dos requisitos pode mudar em funo do ambiente econmico e de negcios, que dinmico. A figura 2 apresenta um modelo para o processo de levantamento e anlise de requisitos, onde os analistas devem procurar ter a compreenso do domnio da aplicao; interagir com os stakeholders para a coleta de requisitos e desenvolvendo a compreenso do domnio da aplicao; fazer a classificao dos requisitos em grupos coerentes; procurar a resoluo de conflitos criados pelas informaes vindas de diferentes stakeholders; elaborar a definio das prioridades interagindo com os stakeholders; determinar se os requisitos so completos e consistentes na verificao de requisitos. A figura 2 ser mostrada na pgina seguinte. 13 TEMA


Especificao de requisitos Verificao de requisitos Compreenso do domnio Definio das prioridades Documento de requisitos Coleta de requisitos Resoluo de conflitos Classificao

UNIESP

Entrada do processo

14

Figura 2. Um modelo para o processo de levantamento e anlise de requisitos Fonte: Sommerville(2003)

 Para trabalhar o levantamento e anlise de requisitos, possvel usar tcnicas como: o levantamento orientado a pontos de vista, os cenrios e a etnografia, como tambm, os mtodos de anlise estruturada e a prototipao. No existe uma abordagem perfeita e universalmente aplicvel para a anlise de requisitos. Normalmente, preciso utilizar vrias dessas abordagens para desenvolver compreenso e anlise completas dos requisitos. 5.1. Ponto de Vista A importncia da anlise orientada a pontos de vista que ele reconhece a existncia de vrias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders. Um ponto de vista pode ser considerado como: Um fonte ou drenos de dados Identificar, quais os dados so produzidos ou consumidos e que processamento realizado. Um framework de representao Diferentes pessoas devem desenvolver um modelo de relacionamento de entidades, um modelo de mquina de estados, entre outros. Cada abordagem de anlise descobre diferentes aspectos sobre o sistema que est sendo analisado. Um receptor de servios (os pontos de vista so externos) A anlise envolve examinar os servios recebidos por diferentes pontos de vista, coletando esses servios e resolvendo conflitos. Exemplo disto so os sistemas interativos que fornecem servios aos usurios finais.
Fonte ou drenos de dados Modelos de Pontos de vista Framework

Receptor de servios

15

TEMA

Vantagens desse tipo de ponto de vista:

- os pontos de vista so externos ao sistema e, assim, so uma maneira natural de estruturar o processo de levantamento de requisitos. - relativamente fcil decidir se alguma coisa um ponto de vista vlido. Os pontos de vista devem interagir com o sistema de alguma maneira. - os pontos de vista e os servios so um meio til de estruturar os requisitos no funcionais. Cada servio pode ter requisitos no funcionais associados. Os pontos de vista mltiplos permitem que o mesmo servio tenha diferentes requisitos no funcionais em diferentes pontos de vista. O mtodo Viewpoint-Oriented Requirements Definition VORD, foi projetado como um framework orientado a servios, para o levantamento e a anlise de requisitos. Kotonya (1998) Os estgios principais so:
1
identificao do ponto de vista

2
estruturao do ponto de vista

3
documentao do ponto de vista

4
mapeamento de sistema de ponto de vista

1. Envolve descobrir os pontos de vista que utilizam servios do sistema e identificar os servios especficos fornecidos para cada ponto de vista. 2. Agrupar os pontos de vista relacionados, segundo uma hierarquia. Servios comuns esto localizados nos nveis mais altos da hierarquia e herdados por pontos de vista de nvel inferior. 3. Refinar a descrio dos pontos de vista e servios identificados. 4. Identificar objetos em um projeto orientado a objetos, utilizando as informaes de servio que esto encapsuladas nos pontos de vista.

UNIESP

16

 As informaes podem ser coletadas em uma primeira etapa atravs de reunies de brainstorming com os stakeholders, onde surgem os possveis pontos de vista. Estes podem ser anotados em um diagrama de bolhas.
Controlador de Demanda Mquina de Ar Condicionado Quadro de Iluminao

Os pontos de vista recebem e fornecem entradas para servios. O mesmo servio pode estar alocado em diversos pontos de vista. As informaes podem ser descritas atravs de formulrios, conforme definido abaixo:
Modelo de ponto de vista Modelo de servio

Referncia: o nome do ponto de Referncia: o nome do servio. vista. Atributos: atributos que fornecem Razo: pela qual o servio informaes sobre o ponto de vista. fornecido. Eventos: uma referncia a um conjunto de cenrios de eventos que descreve como o sistema reage a eventos do ponto de vista. Especificao: referncia a uma lista de especificaes de servios, que podem ser expressas em diferentes notaes.

Servios: uma referncia a um Pontos de vista: lista de nomes conjunto de descries de servios. de pontos de vista que recebem o servio. Subpontos de vista: os nomes de Requisitos no funcionais: referncia subpontos de vista. a um conjunto de requisitos no funcionais que impem restries ao servio. Provedores: referncia a uma lista de objetos de sistema que fornecem o servio

5.2. Cenrios 17 TEMA

 Os cenrios podem ser particularmente teis para acrescentar detalhes a um esboo da descrio de requisitos. De modo geral podem incluir uma descrio do estado do sistema no incio do cenrio, do fluxo normal de eventos no cenrio, do que pode sair errado e de como lidar com isso; informaes sobre outras atividades que possam estar em andamento ao mesmo tempo, e do estado do sistema no final do cenrio. Uma abordagem mais estruturada pode ser empregada com os cenrios de eventos ou use-cases. Usados para descrever modelos de sistemas orientados a objetos, identifica os agentes envolvidos em uma interao e especifica o tipo de interao. Dentro da Unified Modeling Language - UML definida como uma linguagem para a visualizao, especificao, construo e documentao de artefatos de um sistema complexo de software; diagramas de seqncia podem ser utilizados para acrescentar informaes a um usecase. Esses diagramas de seqncia mostram os agentes envolvidos na interao, os objetos dentro do sistema com os quais eles interagem e as operaes que esto associadas a esses objetos. 5.3. Etnografia Os sistemas so utilizados em um contexto social e organizacional. Satisfazer os requisitos sociais e organizacionais fundamental para o sucesso do sistema. A etnografia uma tcnica de observao que pode ser utilizada para compreender os requisitos sociais e organizacionais. O valor de etnografia que ela ajuda a descobrir requisitos de sistemas implcitos, que refletem os processos reais, em vez de os processos formais, em que as pessoas esto envolvidas. Elas compreendem seu prprio trabalho, mas podem no compreender a relao dele com outras atividades na organizao. A etnografia particularmente eficaz na descoberta de dois tipos de requisitos: os derivados da maneira como as pessoas realmente trabalham, em vez da maneira pela UNIESP 18

qual as definies de processo dizem como elas deveriam trabalhar e os derivados da cooperao e conscientizao das atividades de outras pessoas. A etnografia pode ser combinada com a prototipao. Informa o desenvolvimento do prottipo, de modo que um nmero menor de ciclos de refinamento seja necessrio. Seu enfoque no usurio final, portanto, no uma abordagem completa. 6. VALIDAO DE REQUISITOS A validao de requisitos importante porque a ocorrncia de erros em um documento de requisitos pode levar a grandes custos relacionados ao retrabalho, quando esses erros so descobertos durante o desenvolvimento ou depois que o sistema estiver em operao. O custo de fazer uma modificao no sistema, resultante de um problema de requisito, muito maior do que reparar erros de projeto ou de codificao. No documento de requisitos, diferentes tipos de verificao devem ser realizadas: I. De validade os sistemas tm diversos usurios com necessidades diferentes e qualquer conjunto de requisitos inevitavelmente uma soluo conciliatria da comunidade de usurios. II. De consistncia no devem existir restries contraditrias ou descries diferentes para uma mesma funo do sistema. III. De completeza o documento de requisitos deve incluir requisitos que definam todas as funes e restries exigidas pelo usurio do sistema. IV. De realismo utilizando o conhecimento da tecnologia existente, os requisitos devem ser verificados, a fim de assegurar que eles realmente podem ser implementados. Essas verificaes devem tambm levar em conta o oramento e os prazos para o desenvolvimento do sistema. 19 TEMA

 V. De verificao para reduzir o potencial de divergncias entre cliente e fornecedor, os requisitos do sistema devem ser sempre escritos de modo que possam ser verificados. Isso significa que um conjunto de verificaes pode ser projetado para mostrar que o sistema entregue cumpre com esses requisitos. Existe uma srie de tcnicas de validao de requisitos que podem ser utilizadas em conjunto ou individualmente: a. Reviso de requisitos os requisitos so analisados sistematicamente. b. Prototipao experimentar o modelo para verificar se ele atende s suas necessidades. c. Gerao de caso de testes os requisitos deveriam ser testveis. d. Anlise automatizada da consistncia a ferramenta CASE deve construir uma base de dados de requisitos e, ento, uma anlise de requisitos produz um relatrio das inconsistncias que foram descobertas. 7. REVISES DE REQUISITOS

um processo manual, que envolve cliente e fornecedor, verificao do documento de requisitos com o objetivo de detectar anomalias ou omisses. Em uma reviso formal verificam-se as seguintes facilidades: 1. De verificao o requisito passvel de ser testado, como foi definido. 2. De compreenso. 3. De rastreamento avaliar o impacto de uma mudana no restante do sistema. 4. Adaptabilidade ele pode ser modificado sem que isso provoque mudanas em outros requisitos. 8. GERENCIAMENTO DE REQUISITOS

UNIESP

20

 Sistemas so geralmente desenvolvidos para lidar com problemas, a compreenso destes est constantemente se modificando, por parte de quem desenvolve os sistemas, essas mudanas refletem nos requisitos. Novos requisitos surgem pelas seguintes razes:

- comunidade de usurios diversificada, - os clientes do sistema impem requisitos em razo de restries organizacionais e oramentrias, e esses requisitos podem ser conflitantes com os requisitos dos usurios finais, - a empresa e o ambiente tcnico do sistema se modificam, novas legislaes e regulamentos. Os requisitos no funcionais so, particularmente, afetados por mudanas na tecnologia de hardware. Ao longo do tempo de desenvolvimento, o ambiente do sistema e os objetivos da empresa certamente devero ser modificados. Os requisitos devem, portanto, evoluir, a fim de refletir essas mudanas. Requisitos permanentes so os relativamente estveis, que derivam da atividade principal da organizao e que se relacionam diretamente com o domnio do sistema. Requisitos volteis so os que provavelmente vo se modificar durante o desenvolvimento do sistema ou depois que o sistema estiver em operao. Existem alguns tipos: - mutveis mudanas no ambiente no qual a organizao est operando. - emergentes surgem a medida que a compreenso do cliente se desenvolve. - conseqentes a introduo do sistema de computao pode modificar os processos da organizao, criar novos meios de trabalho. 21 TEMA

- compatibilidade dependem de sistemas ou processos de negcios especficos, a medida que eles se modificam, o sistema encomendado pode tambm ter que evoluir. 8.1. Planejamento do Gerenciamento de Requisitos O planejamento estabelece o nvel de detalhes exigido para o gerenciamento de requisitos. Os seguintes aspectos devem ser considerados: 1. Identificao de requisitos identificado de modo nico, para que possa ser feita a referncia cruzada, para que possa ser utilizado nas avaliaes de facilidade de rastreamento. 2. Processo de gerenciamento de mudanas atividades que avaliam o impacto e o custo das mudanas. 3. Polticas de facilidade de rastreamento definem as relaes entre os requisitos e entre os requisitos e o projeto de sistema. Devem ser registradas e mantidas. 4. Suporte de ferramentas Case envolve processar uma grande quantidade de informaes sobre os requisitos.

A facilidade de rastreamento uma propriedade geral de uma especificao de requisito, que reflete a facilidade de se encontrar requisitos relacionados. Existem trs tipos de informaes importantes sobre a facilidade de rastreamento: 1. Da origem vinculam os requisitos aos stakeholders que os propuseram. 2. De requisitos vinculam requisitos dependentes. UNIESP 22

 3. De projeto vinculam os requisitos aos mdulos de projeto em que esses so implementados. O apoio de ferramenta necessrio para: armazenamento, gerenciamento de mudanas e facilidade de rastreamento. Sistemas pequenos podem utilizar recursos de processadores de texto, planilhas de clculo e banco de dados de PCs. 8.2. Gerenciamento de mudanas de requisitos
Problema identificado Anlise do problema Anlise e custo e especificao da da mudana mudana Implementao de mudanas Requisitos Revisados

A vantagem de utilizar um processo formal para o gerenciamento de mudanas que todas as propostas de mudanas so tratadas de modo consistente e que as mudanas no documento de requisitos so feitas de maneira controlada. H trs estgios principais neste gerenciamento de mudanas: 1. Anlise do problema e especificao da mudana o processo comea com a identificao de um problema com os requisitos ou, algumas vezes, com uma proposta especfica de mudana. 2. Anlise de custo de mudana o efeito da mudana proposta avaliada, utilizando-se informaes sobre a facilidade de rastreamento e o conhecimento geral dos requisitos do sistema. 3. Implementao de mudanas o documento de requisitos, o projeto e a implementao so modificados. 23 TEMA

Autor e Texto
Author - Text

Maria Rosngela Oliveira Machado Rosa de Souza*

UMA VISO ESTRUTURAL DA UNIFIED MODELING LANGUAGE - UML A Structural Vision Of The Unified Modeling Language - Uml

Resumo
Este trabalho apresenta um desenho estrutural da UML que complementa as descries dos recursos e permite entender a formao do modelo conceitual.

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.

Palavras-Chave
UML. Estrutura da UML.

Key Words
Uml. Structure Of The Uml.

**Especialista em Anlise de Sistemas pelo IFSP. Especialista em Tecnologia da Informao pelo SENAC. Mestranda em Automao e Controle de Processos pelo IFSP. Professora da Faculdade Renascena.
R.TEMA S.Paulo n 50 jul/dez 2007 P. 24-37

UNIESP

24

Maria Rosngela Oliveira Machado Rosa de Souza

UMA VISO ESTRUTURAL DA UNIFIED MODELING LANGUAGE - UML A Structural Vision Of The Unified Modeling Language - Uml

a literatura a UML era definida como uma linguagem para a visualizao, especificao, construo e documentao de artefatos de um sistema complexo de software. Hoje, a escolha da UML explica-se por ser uma linguagem de modelagem que possui recursos que permitem visualizar, especificar, construir e documentar os elementos, de qualquer tipo de sistema, seus relacionamentos e a comunicao com dispositivos externos ao sistema. A figura 1 apresenta um desenho estrutural da UML que auxilia na compreenso do texto abaixo. Aprender a formao do modelo conceitual da UML implica em entender trs elementos principais: (a) os blocos de construo, as regras e os mecanismos. Os BLOCOS DE CONSTRUO (a1) so de trs tipos: - itens (b1) so as identificaes das abstraes; constituem os blocos de construo bsicos orientados a objetos da UML. - relacionamentos (b2) so blocos relacionais bsicos de construo, que renem os itens (b1). 25 TEMA

 - diagramas (b3) agrupam colees de itens. Um diagrama a apresentao grfica de um conjunto de elementos, geralmente representados como grficos e vrtices (itens b1) e arcos (relacionamentos b2). Os diagramas so desenhados para permitir a visualizao de um sistema sob diferentes perspectivas. Nesse sentido, um diagrama constitui uma projeo de um determinado sistema. As REGRAS (a2) especificam o que dever ser um modelo bem formado. Os blocos de construo da UML no podem ser simplesmente combinados de uma forma aleatria. A UML dispe de regras semnticas (b4) para: os nomes que podem ser atribudos aos itens, relacionamentos e diagramas. -um escopo que determina um significado especfico 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 execuo ou simulao de um modelo dinmico.

A seguir ser apresentada a figura 1, que mostra um desenho estrutural da UML.

UNIESP

26

27

TEMA

MECANISMOS (a3) Qualquer construo se torna mais simples e harmoniosa devido adequao a um padro de caractersticas bsicas. O mesmo se aplica a UML, que se torna mais simples pela presena de quatro mecanismos bsicos (Cf., BOOCH, RUMBAUGH, JACOBSON, 2000, p.28): especificaes, adornos, divises comuns e mecanismos de extenso (b5). A especificao capaz de fornecer uma declarao textual da sintaxe e da semntica do respectivo bloco de construo. A notao grfica da UML permite visualizar um sistema; a especificao determina os detalhes do sistema. Levando em considerao esses dois aspectos, ser possvel construir modelos de maneira incremental, desenhando diagramas e depois acrescentando uma semntica s especificaes do modelo ou diretamente pela criao de uma especificao. Os adornos so itens grficos ou visuais, adicionados notao bsica de um elemento e empregados para a visualizao de detalhes a partir da especificao do elemento. H divises comuns na modelagem de sistemas orientados a objetos, como a diviso de classes e objetos, onde uma classe uma abstrao e um objeto uma manifestao concreta dessa abstrao. Outra diviso entre interface e implementao. Uma interface declara um contrato e a implementao representa uma realizao completa desse contrato, responsvel pela manuteno fiel da semntica completa da interface. A UML aberta-fechada, permite ampliar a linguagem de maneira controlada. Os mecanismos de extensibilidade incluem as seguintes caractersticas: esteretipos, valores atribudos e restries (c7). O vocabulrio da UML pode ser ampliado atravs de um esteretipo, onde novos tipos de blocos de construo so criados a partir dos j existentes. UNIESP 28

 As propriedades dos blocos de construo podem ser estendidas atravs de um valor atribudo, criando novas informaes na especificao de um elemento. As semnticas dos blocos de construo podem ser ampliadas por uma restrio, ou seja, modificar as regras j existentes ou acrescentar. ITENS (b1) Itens so recursos que identificam as abstraes. Existem quatro tipos de itens (b1): estruturais, comportamentais, de agrupamentos e anotaes. ESTRUTURAIS (c1) So os substantivos, representando elementos conceituais ou fsicos, so as partes mais estticas do modelo. Ao todo so sete: classe, interface, colaboraes, casos de uso, classes ativas, componentes e n (d1). C1.1. CLASSE so descries de conjuntos de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. As classes implementam uma ou mais interfaces. Nome da Classe Atributos Operaes SensorTemperatura setPointTemperatura : Float reset( ) setAlarm(t : Temperatura) valor( ) : Temperatura

29

TEMA

 O NOME de uma classe pode ser um texto composto por qualquer nmero de caracteres e determinados sinais de pontuao; exceto alguns sinais, como os dois pontos, utilizados para separar o nome da classe e o nome do pacote que a contm e pode se estender por vrias linhas. Os nomes das classes so substantivos ou expresses breves, definidos a partir do vocabulrio do sistema cuja modelagem est sendo feita. O primeiro caractere de cada palavra existente no nome deve estar em maisculo. Um ATRIBUTO , portanto, uma abstrao do tipo de dados ou estados que os objetos da classe podem abranger. Uma classe pode ter qualquer nmero de atributos ou nenhum. O nome de um atributo um substantivo ou expresso que, breve, representa alguma propriedade da classe correspondente. O primeiro caractere de cada palavra existente no nome do atributo deve estar em maisculo, exceto a primeira letra. O atributo pode ter a indicao de um valor padro, por exemplo, setPointTemperatura : Float. Uma OPERAO uma abstrao de algo que pode ser feito com um objeto e que compartilhado por todos os objetos dessa classe. Uma classe pode ter qualquer nmero de operaes ou nenhuma. O nome de uma operao um verbo ou uma locuo verbal, representando algum comportamento da classe. A existncia de mais atributos ou propriedades pode ser indicada terminando cada lista com reticncias (...). Esteretipos so utilizados para indicar grupos, organizando listas extensas de atributos e operaes.

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 obrigao de uma determinada classe. Em um nvel mais abstrato, atributos e operaes so caractersticas com as quais as responsabilidades das classes so executadas. Atributos, operaes e responsabilidades so caractersticas mais comuns para criar as abstraes. Praticamente todas as abstraes criadas so algum tipo de classe. c1.2. INTERFACE - uma coleo de operaes que especificam servios de uma classe ou componente. Descreve o comportamento externamente visvel desse elemento. Poder representar todo o comportamento de parte de uma classe ou componente. Define um conjunto de especificaes operacionais (suas assinaturas), mas nunca um conjunto de implementaes de operaes. Geralmente anexada classe ou ao componente. Raramente aparece sozinha. 31 TEMA esteretipos

Nome do pacote que a contm Networking : : IRouter

Nome da interface, precedido pela letra l.

c1.3. COLABORAES definem interaes e so sociedades de regras e outros elementos que funcionam em conjunto para proporcionar a soma de comportamentos cooperativos. Apresentam dimenses estruturais e comportamentais. Uma determinada classe poder participar de vrias colaboraes. Representam a implementao de padres que formam um sistema. c1.4. CASO DE USO - a descrio de um conjunto de seqncia de aes realizadas pelo sistema que proporciona resultados observveis de valor para um determinado ator. utilizado para estruturar o comportamento de itens em um modelo. Realiza-se por uma colaborao. c1.5. CLASSES ATIVAS so classes que possuem objetos que tm um ou mais processos,.que podem iniciar um controle de atividade. So semelhantes a uma Classe, exceto que seus objetos representam elementos cujo comportamento concorrente com os outros elementos (atributos e operaes), da o seu carter ativo. c1.6. COMPONENTES so as partes fsicas e substituveis de um sistema, que proporciona a realizao de um conjunto de interfaces. Em um sistema, encontram-se diferentes tipos de componentes prprios da implantao, como os componentes COM+ OU JAVABEANS. Representam o pacote fsico de elementos lgicos diferentes, como classes, interfaces e colaboraes.

UNIESP

32

 c1.7. N o elemento fsico existente em tempo de execuo que representa um recurso computacional. Geralmente, com alguma memria e, freqentemente, capacidade de processamento. Um conjunto de componentes poder estar contido em um n e tambm poder migrar de um n para outro. As classes ativas, componentes e ns, so semelhantes s Classes. Descrevem conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semnticas. So suficientemente diferentes e necessrios para a modelagem de certos aspectos de sistemas orientados a objetos. Existem variaes desses sete elementos como atores: sinais e utilitrios (tipos de classes), processos e threads (tipos de classes ativas), aplicaes, documentos, arquivos, bibliotecas, pginas e tabelas (tipos de componentes). COMPORTAMENTAIS (c2) So as partes dinmicas dos modelos UML. So os verbos de um modelo, representando comportamentos no tempo e no espao. Costumam estarem conectados, conforme a semntica, a vrios elementos estruturais, classes principais, colaboraes e objetos. Existem dois tipos bsicos: interao e mquina de estado (d2). c2.1. INTERAO (d2) um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos de determinado contexto para a realizao de propsitos especficos. O comportamento de uma sociedade de objetos ou de uma operao individual poder ser especificado por meio de uma interao. Envolve outros elementos, inclusive mensagens, seqncias de aes (comportamentos chamados pelas mensagens) e ligaes (conexes entre os objetos). 33 TEMA

 c2.2. MQUINA DE ESTADO (d2) um comportamento que especifica as seqncias de estados, pelas quais objetos de interaes passam durante sua existncia em resposta a eventos, bem como suas respostas a esses eventos. Especifica o comportamento de uma classe individual ou de uma colaborao de classes. Abrange outros elementos, incluindo estados, transies ( fluxo de um estado a outro), eventos (itens que ativam uma transio), atividades (respostas s transies). AGRUPAMENTO (c3) So as partes organizacionais dos modelos UML, os blocos em que os modelos podem ser decompostos. Um tipo importante de agrupamento o mecanismo de propsito geral para a organizao de elementos em grupo, denominado pacote. Itens estruturais, comportamentais e outros, podem ser colocados em pacotes. ANOTAES (c4) So as partes explicativas dos modelos UML; comentrios includos para descrever, esclarecer, fazer alguma observao sobre qualquer elemento do modelo. Existe um tipo primrio de item de anotao chamado Nota, apenas um smbolo para representar restries e explicaes anexadas a um elemento ou a uma coleo de elementos. RELACIONAMENTOS (b2) a vinculao dos blocos de construo da UML. Esta ligao pode ser de quatro tipos: dependncia, associao, generalizao e realizao. b2.1. DEPENDNCIA (c5) um relacionamento semntico entre dois Itens, nos quais a alterao de um item independente pode afetar a semntica de outro item dependente.

UNIESP

34

 b2.2. ASSOCIAO (c5) - um relacionamento estrutural que descreve um conjunto de ligaes, em que as ligaes so conexes entre objetos. Um tipo especial de associao a agregao, que representa um relacionamento estrutural entre o todo e suas partes. b2.3. GENERALIZAO (c5) um relacionamento de especializao ou generalizao, nos quais os objetos dos elementos especializados, os filhos, so substituveis por objetos do elemento generalizado, os pais. Dessa forma, os filhos compartilham a estrutura e o comportamento dos pais. b2.4. REALIZAO (c5) um relacionamento semntico entre classificadores. Um classificador especifica um contrato que outro classificador garante executar. Os vnculos de realizaes sero encontrados em dois lugares: entre Interfaces e as Classes ou Componentes; e entre Casos de Usos e as Colaboraes. DIAGRAMAS (b3)

b3.1. DIAGRAMA DE CLASSES (c6) exibe conjunto de classes, interfaces e colaboraes, bem como seus relacionamentos. Os diagramas de classes que incluem classes ativas e direcionam a perspectiva do processo esttico do sistema. b3.2. DIAGRAMA DE OBJETOS (c6) exibe conjunto de objetos e seus relacionamentos. Representa retratos estticos de instncias de itens encontrados em diagramas de classes. b3.3. DIAGRAMA DE CASO DE USO (c6) exibe um conjunto de Caso de Uso e Atores (um tipo especial de classe) e seus relacionamentos. So importantes para a organizao e a modelagem de comportamentos do sistema. 35 TEMA

b3.4. DIAGRAMA DE SEQNCIA -

5. DIAGRAMA DE COLABORAO (c6) So tipos de diagramas de interao. Composto de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocados entre eles. No diagrama de Seqncia a nfase est na ordenao temporal da mensagem. A nfase do Diagrama de Colaborao est na organizao de estrutura dos objetos que enviam e recebem mensagens. Os diagramas de Seqncia e Colaborao so isomrficos, isto transformam o diagrama de um tipo em outro. b3.6. DIAGRAMA DE GRFICO DE ESTADO (c6) exibe uma mquina de estados, formada por estados, transies, eventos e atividades. importante para modelagem de comportamentos de uma Interface, Classe ou Colaborao. Tambm para dar nfase a comportamentos de um objeto, ordenados por evento. de grande ajuda para modelagem de sistemas reativos. b3.7. DIAGRAMA DE ATIVIDADE (c6) um tipo especial de diagrama de grfico de estado. Exibe o fluxo de uma atividade para outra no sistema diagrama de atividade. importante para a modelagem da funo de um sistema e d nfase ao fluxo de controle entre objetos. b3.8. DIAGRAMA DE COMPONENTE (c6) exibe as organizaes e as dependncias existentes em um conjunto de componentes. Est relacionado ao diagrama de classes, pois os componentes so mapeados para uma ou mais classes, interfaces ou colaboraes. b3.9. DIAGRAMA DE IMPLANTAO (c6) mostra a configurao dos ns de processamento em tempo de execuo e os componentes neles existentes. Est UNIESP 36

relacionado ao diagrama de componentes, pois um n inclui um ou mais componentes. CONSIDERAES FINAIS Este trabalho procurou mostrar que a UML possui recursos especficos para analisar a estrutura de um sistema, determinar seu comportamento e modelar a topologia de dispositivos que o executaro.
REFERNCIAS BIBLIOGRFICAS (Primeiro Texto) Pginas 6-23 HENINGER, Kathryn L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application. IEEE Transactions on Software Engineering, vol. se-6, no. 1, january 1980. KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering: Processes and Techniques. Chichester,UK: John Wiley and Sons, 1998. PRESSMAN, Roger S. Engenharia de Software. 6ed., So Paulo: McGraw-Hill, 2006. SOMMERVILLE, Ian. Engenharia de Software. 6ed. So Paulo: Addison Wesley, 2003. REFERNCIAS BIBLIOGRFICAS (Segundo Texto) Pginas 24-37 BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. The Unified Modeling Languague User Guide. Addison Wesley, 1999. FURLAN, Jos Davi. Modelagem de Objetos atravs da UML the Unified Modeling Language. So Paulo: Makron Books, 1998. LARMAN, Craig. Utilizando UML e Padres. Porto Alegre: Bookman, 2000. PAGE-JONES, Meilir. Fundamentos do Desenho Orientado a Objeto com UML. Makron Books, 2001.

37

TEMA