PARTE I

CAP. 1 – ENQUADRAMENTO E CONCEITOS GERAIS

1.1. Introdução
O objectivo deste livro é apresentar a linguagem de modelação UML e demonstrar a sua aplicação
de forma a facilitar todo o desenvolvimento de software, quer seja directamente como técnica de
modelação de software quer seja na sua utilização em metodologias de desenvolvimento ou em
ferramentas de apoio.

1.2. O Impacto das Tecnologias de Informação

Actualmente, as tecnologias de informação encontram-se na origem de mudanças significativas
ao nível dos modelos de negócio das empresas, e constituem um elemento fundamental para a
obtenção de vantagens estratégicas e competitivas.
A implementação de sistemas de informação requer um investimento significativo (financeiro,
tecnológico e de recursos humanos), pelo que estas intervenções deverão merecer apoio e
comprometimento das administrações.
Muito gestores não percebem por questões de formação e os técnicos de informática criaram
imagem muito técnica. Isto contribui para a não consideração da informática como uma área
estratégica dentro da empresa.
A progressiva importância que os sistemas de informação têm nas organizações pode ser
constatada através de diversas situações:
- No passado era comum o responsável da informática depender hierarquicamente do director
financeiro. Actualmente a área de informática está ao mesmo nível que os restantes
departamentos.
- A indústria de software é actualmente uma das mais importantes de todo o planeta
- A crescente importância das empresas relacionadas com a Nova Economia levou ao Nasdaq
- A importância destas empresas tem motivado a crescente preocupação dos governos em
garantir o acesso livre ao mercado e a tentar evitar posições monopolistas.

1.3. Produto e Processo

A importância das tecnologias de informação na nossa vida é sobretudo concretizada pelas
funcionalidades que são implementadas ao nível do software, e que são disponibilizadas com o
suporte de um conjunto de dispositivos diversos (hardware). O primeiro pode ser considerado o
componente lógico dos sistemas de informação, o segundo o componente físico.
Não existe uma definição rigorosa e inequívoca de software. para alguns é o resultado final de um
processo, ao qual designam por “Engenharia de Software”.
Se pensarmos que o desenvolvimento do software é um processo que deve ser baseado na
aplicação de técnicas e práticas rigorosas, sistemáticas, eficientes e controláveis, é como nas
outras engenharias. Pressupõe também a utilização de ferramentas de apoio a todo o processo.
As características destas ferramentas podem ter um impacto apreciável no produto final.
No entanto é de referir que a produção de software encerra em si mesma alguma subjectividade.
Neste aspecto o processo mais de uma actividade artística. Podemos considerar pois que o ponto
de equilíbrio correcto depende de cada caso, mas deve-se encontrar a meio caminho entre a
aplicação de técnicas estruturadas (Engenharia) e introdução de factores de criatividade.
São características fundamentais do software:
- Flexibilidade: capacidade de evolução face aos requisitos de negócio
- Fiabilidade
- Implementação das necessidades das organizações
- Nível de desempenho adequado
- Facilidade de utilização

1.4. Sistemas de Informação

A visão mais tradicional é que software é um conjunto de programas mais a respectiva
documentação.
O conceito mais abrangente de sistemas de informação é um conjunto integrado de recursos
(humanos e tecnológicos) cujo objectivo é satisfazer adequadamente a totalidade das
necessidades de informação de uma organização e os respectivos processos de negócio
(pretende representar uma sequência de actividades, que processam vários inputs e produzem
vários outputs e que possuem objectivos – compras de matérias primas - )
É objectivo fundamental dos sistemas de informação garantir o alinhamento das tecnologias da
informação com os objectivos estratégicos do negócio.
Uma das mais antigas classificações dos SI é de Anthony – 1965, que os classifica em função do
nível das actividades de gestão dentro da organização no qual o software tem impacto:
- Operacional: operações do dia-a-dia e que implicam alterações na informação (facturação,
controlo de encomendas, contabilidade geral, salários)
- Táctico: análise da informação para suportar o processo de tomada de decisão e com impacto a
curto prazo (análise de vendas, controle orçamental, contabilidade analítica, análise de qualidade)
- Estratégico: questões de planeamento e com efeitos a médio e longo prazo (Previsão de vendas,
Planeamento de recursos humanos, previsão de receitas e custos, modelação financeira).

1.5. Arquitectura de Sistemas de Informação

Para facilitar a apresentação dos SI cada vez mais complexos.
Em 1987 Zachman diz que arquitectura é o conjunto de representações descritivas (modelos)
relevantes para a descrição de um objecto, de forma a que este possa ser construído de acordo
com os requisitos (de qualidade) e mantido ao longo da sua vida útil.
A framework de Zachman é uma estrutura lógica de classificação e apresentação dos modelos de
uma organização relevantes para a respectiva gestão bem como para o desenvolvimento dos SI.
Nesta perspectiva, modelar um sistema significa determinar e representar um conjunto de
informação, sobre vários tópicos (colunas da matriz) relevante para vários intervenientes (linhas
da matriz). São considerados 5 perfis:
- Planner
- Owner
- Designer
- Builder
- Sub-contractor
Os 2 primeiros são de cariz relacionado com as áreas de negócio e os outros de cariz informático.
À medida que se desce aumenta o nível de detalhe. Cada perfil tem uma visão sobre os factores
analisados:
- Qual a constituição do sistema (What) – os dados?
- Como é que o sistema funciona (How) – as funções?
- Onde está localizado o sistema (Where) – as relações e as redes?
- Quem são os interessados no sistema (Who) – as pessoas?
- Quando ocorrem facto relevantes no sistema (When) – o tempo?
- Porque é que o sistema funciona assim (Why) – as motivações?
Uma outra abordagem alternativa baseia-se no framework de Index [Wurman97], e considera que
a arquitectura de SI é um conjunto integrado e consistente de componentes, que são definidos de
forma a garantir o respectivo alinhamento com os objectivos do negócio. Em blocos:
- Arquitectura Aplicacional: sistema e aplicações
- Arquitectura Tecnológica: infra-estrutura e máquinas
- Arquitectura de Dados: conceitos e entidades
- Arquitectura Organizacional: recursos humanos
A definição destes componentes deve obedecer a uma sequência lógica. Como o componente
que suporta os objectivos do negócio são as aplicações, estas devem ser escolhidas em primeiro
lugar em paralelo com os dados.

1.6. Objectivos do Desenvolvimento de Sistemas de Informação

Em 1983, Robert Block definiu um SI bem sucedido como aquele que é produzido dentro do prazo
e nos custos estimados; é fiável e pode ser mantido facilmentea baixo custo; responde
adequadamente aos requisitos definidos e satisfaz os utilizadores.
Ao longo do tempo:
1970 – Automatização – computação mainframe; processamento Batch
1980 – Redução de custos – sistemas departamentais; procesaamento online; bases de dados
relacionais
1985 – Autonomização do utilizador – computador pessoal; ferramentas de produtividade pessoal
1995 – Vantagem competitiva – Tecnologias OO; suporte À decisão; gestão do conhecimento
2000 – Driver do negócio – Internet; computação ubíqua
Existe um conjunto de razões que levam as organizações a investir em SI:
- Reduzir custos operacionais
- Satisfazer requisitos de informação dos utilizadores
- Contribuir para a criação de novos produtos e serviços
- Melhorar o nível de serviço prestado
- Melhorar e automatizar a relação com os parceiros de negócio
- melhorar o desempenho de pessoas e máquinas

1.7. Problemas no Desenvolvimento de Sistemas de Informação

Historicamente, o software tem apresentado de forma sistemática e contínua os mesmos
problemas. Se pensarmos no impacto nas organizações temos 3 níveis:
- Falta de qualidade: satisfação incompleta dos requisitos e problemas pós instalação
- Desvios nos Prazos
- Custos previamente definidos ultrapassados
Daqui nasceu a famosa “crise no software” da década de 70 que foi reforçada por Fred Brooks no
célebre artigo “No Silver Bullets”.
Os problemas referidos são durante o processo de desenvolvimento, mas igualmente graves são
os que acontecem após a instalação e entrada em produção.
Podem ter impacto em 2 áreas críticas: questões financeiras e vidas humanas.
Diversas causas estão na origem deste crónico falhanço:
- Falta de empenhamento dos órgãos de topo
- Falta de comprometimento e empenhamento dos utilizadores
- Incompreensão do valor dos SI
- Falta de entendimento e de sintonia entre informáticos e clientes utilizadores no âmbito dos
requisitos do mesmo
- Deficiências várias no processo de desenvolvimento
- Falhas na coordenação do projecto
- falta de qualidade e inadequação dos recursos envolvidos
- Mudanças frequentes dos requisitos do negócio
- Dificuldades na integração de componentes
- Qualidade e desempenho deficientes do software
- Incapacidade de identificar e controlar os riscos do projecto

1.8. Planeamento Estratégico de Sistemas de Informação

No passado os SI eram só para melhorar eficiência. Hoje concentram-se na obtenção de
vantagens competitivas.
Um dos objectivos dos SI é a satisfação adequada dos requisitos de negócio, garantindo assim o
correcto alinhamento com a estratégia da organização.
É esse o âmbito do Planeamento Estratégico de SI, que define componentes e funciona como
guia. aqui devem ser identificadas e prioritizadas as acções a desencadear para atingir a situação
futura proposta. Só depois se avança para a Engenharia de Software.
Podemos definir o PESI como um processo cuja finalidade é garantir o alinhamento dos SI com os
objectivos do negócio. Este processo tem fases:
Levantamento dos Objectivos Estratégicos --> Análise detalhada do negócio --> Análise da
situação actual dos SI --> Proposta de situação futura dos SI --> Planeamento da Implementação.

1.9. Engenharia De Software

Uma das primeiras definições foi dada por Fritz Bauer nos finais da década de 60 como sendo “ a
definição e utilização de princípios de engenharia sólidos, de modo a desenvolver software
económico, fiável e que trabalha eficientemente em máquinas reais. Inclui pois um conjunto de
métodos, de ferramentas e procedimentos”.
Uma das mais usadas é a do IEEE: é a aplicação de um processo sistemático, disciplinado, e
quantificado ao desenvolvimento, operação e manutenção de software.
As actividades associadas à Engenharia do Software podem ser agrupadas em 3 grandes fases:
- Concepção
- Implementação
- Manutenção
Conceitos a saber: sistemas de informação; arquitecturas; planeamento estratégico; engenharia
do software.
CAP. 2 – O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
2.1. Introdução
A produção de software é frequentemente uma actividade não estruturada, por vezes caótica, sem
orientações de natureza estratégica e sem planos de gestão e controle (build and fix – programar
e corrigir).
Roger Pressman apelidou de 4 Ps associados ao desenvolvimento de software:
- Pessoas motivadas e comprometidas
- Processo com técnicas e regras bem definidas
- Produto de qualidade respondendo às necessidades dos utilizadores.
- Projecto credível e controlado
Em 1996 Barry Boehm identificou 7 questões que qualquer projecto deve responder (W5H2):
- Porque é que o sistema vai ser desenvolvido (Why)?
- O que vai/deve ser feito (What)?
- Quando é que vai se feito (When)?
- Quem é o responsável (Who)?
- Onde é que as responsabilidades estão localizadas (Where)?
- Como é que vai ser feito (How)?
- Quanto vai custar em termos de recursos (How much)?

2.2. Processos e Metodologias

O processo de desenvolvimento de software é um conceito de âmbito muito vasto e pretende
designar uma sequência de actividades, normalmente agrupadas em fases e tarefas, que são
executadas de forma sistemática e uniformizada, por intervenientes com responsabilidades bem
definidas e que a partir de um conjunto de inputs produzem um conjunto de outputs. Tem 4
objectivos fundamentais:
- Providenciar orientação sobre a sequência de actividades
- Especificar os modelos descritivos do sistema que devem ser desenvolvidos
- Dirigir as tarefas dos participantes/equipa
- Providenciar critérios para monitorização.
O conceito de metodologia acrescenta a esta definição a utilização de um conjunto de
ferramentas, técnicas e notações, para além de diversos princípios e regras mais práticas:
- Regras de elaboração de estimativas (custos, prazos)
- Técnicas para efectuar medições
- Procedimentos a seguir de forma a garantir qualidade
- Programas de formação
- Modelos de documentação
O conceito de ciclo de vida pode ser encarada como sinónimo de processo.
No UML e outras processo é afinal metodologia.
Em meados da década de 90 havia mais de 1000 metodologias.
As metodologias actualmente existentes tiveram essencialmente 2 origens distintas:
- Evoluíram de experiências práticas
- Resultaram de esforços de investigação

2.3. Modelos e Modelação

Um modelo consiste na interpretação de um dado domínio do problema segundo uma
determinada estrutura de conceitos.
Um esquema é a especificação de um modelo usando uma determinada linguagem. quando é
gráfica chamamo-lhe diagrama.
Um modelo é sempre uma interpretação simplificada da realidade.
Um modelo apresenta apenas uma visão ou cenário de um fragmento do mundo real --> vários
modelos para compreender o sistema correspondente.

2.3.1. Importância da Modelação

A modelação (ou modelização) é a arte e ciência de criar modelos de uma determinada realidade;
facilita e promove a comunicação entre todos.
A informática como as outras engenharias precisa também de adoptar notações e linguagens para
representar os seus modelos. Os benefícios da modelização são:
- Ajudam a visualizar o sistema
- Permitem especificar a estrutura ou o comportamento
- Permitem controlar e guiar o processo de construção
- Documentam as decisões tomadas

2.3.2. Princípios da modelação

P1 – A escolha dos modelos a criar tem uma profunda influência no modo como o problema é
encarado e consequentemente como a solução é obtida
P2 – cada modelo deve poder ser expresso em diferentes níveis de precisão/abstracção
P3 – Os melhores modelos reflectem a realidade
Este princípio é um dos “calcanhares de Aquiles” das técnicas de modelação pois muitas vezes
existe uma manifesta separação entre os modelos usados para descrever “o que o sistema faz” e
outros que detalham a forma “como o sistema faz”.
P4 – Nenhum modelo é suficiente por si só. Qualquer sistema não trivial é representado de forma
mais adequada através de pequeno número de modelos, razoavelmente independentes (mas
mantendo nível de integração).
O UML baseia-se significativamente neste princípio.

2.4. Boas Práticas no Desenvolvimento de Software

A complexidade do software é uma propriedade essencial, intrínseca à própria natureza do
software e tem origem em 4 factores:
- A complexidade do domínio do problema
- A dificuldade de gerir o processo de desenvolvimento
- A flexibilidade que é possível (ou não) implementar através do software
- Os problemas de caracterizar o comportamento de sistemas discretos
Assim, normalmente, os projectos ultrapassam custos e prazos.
Há vários atributos de um sistema complexo:
- É composto por outros subsistemas relacionados, e assim sucessivamente (hierarquia de
elementos)
- A selecção dos componentes elementares é arbitrária e depende de quem a efectua
- Com muitos elementos, as relações intracomponentes são mais fortes do que as
intercomponentes
- Cada subsistema é normalmente composto por poucos componentes diferentes
- Um sistema complexo que funciona é invariavelmente uma evolução de um sistema simples que
já funcionou.
Existe uma limitação natural da capacidade humana em lidar com a complexidade. Por isso
Dijkstra sugeriu a aplicação do famoso princípio da decomposição hierárquica (divide and
conquer)
Também a aplicação de um mecanismo de abstracção favorece a eliminação da complexidade: o
ser humano opta por “esquecer” os detalhes menos importantes.
Outros princípios para lidar com a complexidade e obter software de qualidade são:
- Desenvolvimento de forma iterativa
- Efectuar gestão integrada dos requisitos
- Utilizar arquitecturas baseadas em componentes reutilizáveis
- Modelar o sistema através de diagramas gráficos
- Efectuar a verificação sistemática da qualidade
- Implementar um processo sistemático de controlo de alterações
Cada uma destas melhores práticas tem impacto nas outras.
Ainda há mais princípios:
- Conseguir promover o envolvimento dos utilizadores
- Utilizar abordagem orientada para a resolução de problemas
- Definir e utilizar standards para o desenvolvimento e documentação
- Justificar o desenvolvimento do software com actividade estratégica e investimento financeiro
- Conceber sistemas de modo a facilitar a sua expansão e alteração

2.5. fases do Desenvolvimento de Software

Necessidade de aplicar um processo com fases bem definidas, que se subdividem em conceitos
mais elementares (tarefas e actividades), isto desde que se verificou que a programação
estruturada não era suficiente.
A natureza sequencial obriga a que uma fase (ou tarefa ou actividade) tenha de estar terminada
antes de outra começar.
Nesta perspectiva, uma fase é constituída por uma sequência de tarefas, e estas por sua vez são
formadas por actividades. Os 2 primeiros são abstractos e as actividades correspondem de facto a
trabalho realizado, sendo pois a unidade mais elementar.-
Um processo divide-se em três grandes fases:
- Concepção: identificar “o que é que o sistema deve fazer”. Inclui Planeamento e Análise
- Implementação: identificar “o como fazer o sistema”. Inclui Desenho, Desenvolvimento, Testes e
Integração e Instalação
- Manutenção. Inclui Operação e Manutenção
Há quem considere que o levantamento dos requisitos do sistema e a respectiva especificação
são tarefas distintas, enquanto outros autores juntam ambas na tarefa de análise e consideram-na
como duas actividades da referida tarefa (nossa opção).
Há quem considere que o desenho é uma tarefa da concepção uma vez que as actividades são
de definição e não de implementação. A nossa visão é que é definição do que se vai fazer, logo
fica na implementação.
As fases podem ser divididas em tarefas mais específicas:
- Planeamento: identificação geral das necessidades e selecção de alternativas
- Análise: Identificação detalhada das funcionalidades (Levantamento de Requisitos) e respectiva
descrição (Especificação do Sistema)
- Desenho: Definição detalhada da arquitectura global (módulos, tabelas, interface, máquinas,
etc.)
- Desenvolvimento: Programação
- Testes (ou Integração): O sistema no seu global é verificado para obter aceitação do utilizador
- Instalação: Disponibilização dos sistema para os seus utilizadores finais
- Manutenção: O momento que corresponde ao tempo de vida útil do sistema e durante o qual são
efectuadas todas as alterações.
A manutenção sempre foi a tarefa que maior esforço e custos relativos apresenta. Mesmo com as
melhores técnicas actuais continuamos quase na mesma (67%)

2.5.1. Tarefas Transversais

- Gestão do Projecto
Gestão dos recursos humanos, financeiros, controle de prazos. É este o nível que funciona como
interface oficial para fora da equipa de projecto --> “gestor de projecto”
- Gestão de Alterações
É fundamental que estejam previstos mecanismos de controle das alterações

2.5.2. Planeamento
Alguns autores não consideram no âmbito da Engenharia de Software. Outros consideram-na
como transversal. A nossa perspectiva é que só temos um projecto depois do seu plano estar
aprovado, e é esse o objectivo dessa tarefa.
Existem várias circunstâncias particulares em que esta tarefa deve ser efectuada:
- Num projecto que envolve a selecção de entidades para posterior implementação do software, a
elaboração de cadernos de encargos e a avaliação de propostas
- Apenas investigação inicial
A grande preocupação desta fase é que a partir de um levantamento de alto nível das
necessidades do negócio seja possível elaborar um plano de projecto. Para isso existem um
conjunto de actividades que deverão ser realizadas:
- Compreender a missão e organização da empresa
- Identificar e envolver todos os interessados e afectados pela introdução do sistema
- Obter uma visão de alto nível do funcionamento do sistema actual (caso exista)
- Definir o âmbito do sistema
- Elaboração de uma descrição de alto nível do problema
- Identificar restrições, problemas e riscos do projecto
- Identificar alternativas de implementação, avaliá-las e seleccionar
- Apresentar resultados e recomendações, com justificação técnica funcional e financeira
- Elaborar e obter aprovação de um plano de projecto
- Definir o processo de controlo do projecto
O principal output desta tarefa será um plano de projecto, que deverá reflectir sustentadamente a
visão que se tem nesta fase.

2.5.3. Análise
Efectua o estudo detalhado do domínio do problema, e culmina na elaboração de um documento
onde os requisitos funcionais da solução a implementar e outras questões relevantes (restrições,
âmbito, fluxos de informação) são enumerados. Tem, normalmente dois grandes momentos ou
sub-tarefas (realizados em simultâneo):
- Levantamento de Requisitos
Um requisito é uma funcionalidade ou condição que o sistema deverá possuir. Reuniões,
observações, protótipos,...
- Especificação do Sistema
Não é tarefa fácil. As interpretações são subjectivas. O objectivo geral desta subtarefa é expressar
sem ambiguidades o que os sistema deve fazer e não como fazer o sistema.
A “Especificação de Requisitos” é um documento que deve ser visto como um contrato.

2.5.4. Desenho
Pretende efectuar a definição do domínio da solução, com base na análise. Procede-se à
especificação formal ou informal das características que a implementação do sistema deverá
apresentar. Inclui arquitectura de computadores, tecnologias de bases de dados, etc., bem como
ambiente e linguagem de programação a usar.
Diz-se por vezes que é a fase de especificação técnica pois aqui se definem componentes
aplicacionais, tecnológicos e dados.
Factores como o desempenho, a segurança e a operacionalidade, custos e prazos, deverão se
critérios para seleccionar alternativas. Planos de testes e de migração deverão ser previstos.

2.5.5. Implementação
É a concretização do modelo do desenho.
Os componentes aplicacionais são codificados e testados de forma isolada (testes unitários).
Actualmente assiste-se, no contexto dos sistemas de informação cliente/servidor, à crescente
utilização de ambientes de desenvolvimento bastante produtivos (designados por ambientes RAID
– Rapid Application Development), baseados em infra-estruturas de objectos/componentes
evoluídos, complexos e providenciando paradigmas de prototipagem de desenvolvimento visual
(ex. ferramentas CASE).
Cada vez mais as organizações compram produtos previamente desenvolvidos mais ou menos
uniformizados funcionalmente (pacotes), o que levou a que a programação pura cedeu uma parte
da sua importância em favor de esforços de integração (entre os diverso componentes “pré-
fabricados”), sua parametrização e configuração.

2.5.6. Testes
Os testes deverão ser executados em condições idênticas aquelas que o sistema real irá possuir.
Podem ser classificados em diferentes categorias, segundo as características do sistema que
avaliam:
- Testes de carga: avaliam o sistema perante a utilização intensiva e aferem as capacidades de
escalabilidade
- Testes de desempenho: Analisam o tempo de resposta do sistema e verificam o nível de
utilização dos recursos disponíveis
- Testes de usabilidade: analisam a adequabilidade do desenho das interfaces homem-máquina
- Testes funcionais: se os requisitos são satisfeitos
Outra classificação é segundo o âmbito dos componentes do sistema:
- Testes unitários
- Testes de integração
- Testes de sistema
- Testes de aceitação
No caso de substituição de sistemas muitas vezes usa-se a estratégia do paralelo de sistemas
(repetição das actividades do antigo sistema, no novo).
A verificação deve ser acompanhada a diferentes níveis por ferramentas de debugging.

2.5.7. Instalação
Envolve um conjunto de tarefas:
- Configuração e parametrização do sistema
- Instalação dos componentes aplicacionais necessários
- Definição de perfis, de utilizadores e de níveis de segurança
- Formação dos utilizadores do sistema
- Elaboração de documentação de operação, administração e utilização do sistema
- Definição e implementação de políticas de segurança (ex. backups)

2.5.8. Manutenção
Com o tempo aparecem os bugs, para além de solicitações externas e internas relativamente a
pedidos de alteração de requisitos.
Novos requisitos (60%); Erros (18%); Melhorias (18%).
É possível ver a tarefa de manutenção desencadeia uma nova iteração de todo o processo.

2.6. Processos de Desenvolvimento de Software

Podemos distinguir genericamente duas grandes aproximações:
- modelo em cascata
- aproximação iterativa

2.6.1. Processos em Cascata

São os mais tradicionais, em que as actividades a executar são agrupadas em tarefas,
executadas sequencialmente, de forma a que uma tarefa só tem início quando a tarefa anterior
tiver terminado.
Baseia-se no pressuposto que o cliente participa activamente (e vai validando as várias tarefas)
no projecto e que sabe muito bem o que quer. Mas, infelizmente, a salvaguarda não evita que o
cliente fique desapontado.
O modelo apresenta ainda outras limitações, como a compartimentação de esforços, o
desencorajamento de comunicação, não se pode voltar atrás mesmo que as conclusões
anteriores sejam modificadas com o evoluir do processo.
De forma a evitar este problema foi criado o modelo em cascata revisto (ciclo).
O risco desta abordagem é que, na ausência de um processo de gestão e controle bem definido,
podemos passar o tempo num ciclo sem fim.
Ambos os modelos anteriores apresentam o problema da extensão do período de tempo que
decorre entre o início do projecto e a entrega do produto.
Uma solução consiste na aplicação de técnicas de prototipagem logo no início do processo
(prototipagem rápida). Não elimina a necessidade de todas as tarefas sequenciais, mas permite
que o cliente veja e valide um modelo da interface (e das funcionalidades) que irá ter disponível,
reduzindo também os problemas de comunicação. Aqui é preciso cuidado e saber resistir à
pressão do cliente que quer passar a utilizar de imediato o protótipo. Além de se poder perder a
visão global face ao imediatismo dos écrans.

2.6.2. Processos Iterativos e Incrementais

São mais recentes e pretendem encorajar a comunicação.
Iterativo
Corresponde à ideia de melhorar (ou refinar) pouco-a-pouco (ex. trabalho artístico).
Vantagens:
- Os riscos e as dúvidas com maior importância são identificados no início do processo, nas
primeiras iterações, quando é possível tomar medidas para os corrigir.
- Encoraja a participação activa dos utilizadores
- Testes contínuos e iterativos permitem avaliação contínua do estado do projecto
- As inconsistências entre desenho e implementação são detectadas atempadamente
- O esforço dos elementos é distribuído ao longo do tempo
- A equipa pode aprender com experiências anteriores
Incremental
Corresponde à ideia de aumentar (ou alargar) pouco-a-pouco o âmbito do sistema. ex. mansão a
partir de 2 anexos.
Iterativo e Incremental
A principal consequência é que os produtos finais de todo o processo vão sendo amadurecidos e
completados ao longo do tempo.
Espiral
É uma pequena variante do modelo iterativo e incremental. Propõe logo de seguida à tarefa de
planeamento a realização de uma tarefa de prototipagem e de análise de risco.
CAP. 3 – EVOLUÇÃO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE
3.1. Introdução
Larry Constantine tentou identificar mecanismos que possibilitassem que a concepção inadequada
de software fosse evitada desde o início, aquando da identificação dos requisitos. Em conjunto
com Wayne Stevens e Glen Myers propôs o conceito de Composite Design, renomeado para
“desenho estruturado” [Stevens74].

3.2. A Programação Como Fonte de Inovação

Depois do programa, veio o módulo.
A ideia era agrupar num módulo dados e código, que estivessem relacionados de forma a limitar
as interacções entre módulos À invocação de funções. No entanto era ainda possível aceder do
exterior aos dados declarados dentro de um módulo.
Para evitar isso foi proposto o conceito de tipo de dados abstracto (ADA) que permitem “esconder”
totalmente partes da sua implementação (quer o nível de dados quer código), e disponibilizam
para o exterior o que se designa por interface. Ligação muito forte entre dados e código.
A evolução levou ao aparecimento das linguagens orientadas por objectos (Smalltalk, C++, Java,
Object Pascal).
A principal diferença para os tipos de dados abstracto é que as OO suportam a noção de herança

3.3. O Desenvolvimento Ad-Hoc

Em face das potencialidades limitadas das LP, as primeiras aplicações foram construídas sem a
utilização de uma metodologia de desenvolvimento formal, correspondendo ao que normalmente
se designa por “programar e corrigir” (“build and fix”).
Estes desenvolvimentos eram caracterizados por:
- Envolvimento limitado dos utilizadores
- Identificação de requisitos efectuada de forma inadequada
- Fraca utilização de técnicas de análise e desenho
- Inexistência de ferramentas de apoio a todo o processo
- tarefas de desenvolvimento muito demoradas
- Sistemas de acesso à informação pouco flexíveis
Quando a complexidade aumentou, a situação ficou mais problemática, o que ainda foi agravado
por:
- Os informáticos eram reconhecidamente bons programadores, mas raramente tinham
preocupação de compreender o negócio
- Não eram aplicadas técnicas ou mecanismos de controlo e de gestão do projecto, e por isso
estes ultrapassavam frequentemente custos e prazos estimados
- A fraca qualidade do produto final implicava correcções frequentes

3.4. Metodologias Estruturadas

Durante os anos 70 e 80 assistiu-se À introdução de técnicas estruturadas de decomposição
funcional, com o objectivo de identificar os requisitos e introduzir técnicas baseadas nas melhores
práticas ao processo de análise e desenho.

3.4.1. Contexto e Motivação

O objectivo era prestar mais atenção ao processo global e menos à programação. A maioria das
metodologias adoptaram o modelo em cascata.
As metodologias estruturadas estavam orientadas segundo uma de 2 abordagens:
- Mais orientada para a decomposição funcional do sistema e identificação dos respectivos
processos (funcional) – funções, algoritmos e actividades
- Mais centrada nos conceitos e nos dados das organizações (orgânica)
Na análise funcional o suporte dado pelas LP da altura permitiam divisão do código em blocos e,
assim, um certo encapsulamento. No entanto, a possibilidade dos dados serem globalmente
visíveis e manipulados por todo o programa reduzia estas características e era pouco flexível a
alterações.
Na análise orgânica a atenção concentra-se nos dados, colocando os conceitos e as entidades
manipuladas no negócio como elementos chave. A ideia é mesmo quando uma aplicação muda,
os conceitos principais devem permanecer e continuar a ser utilizados.
3.4.2. Conceitos Básicos
- Processo (de negócio): Sequência de actividades, que processam vários inputs e produzem
vários outputs (pode ser decomposto em subprocessos)
- Fluxo de Informação: Representa toda a circulação de informação que ocorre na organização de
forma a executar os processos de negócio
- Repositório de Dados: Representam os conceitos sobre os quais importa à organização reter
dados sobre
- Entidade: Representa todos os conceitos de negócio, físicas ou abstractas, internas ou externas.
- Estado de uma entidade: É representado por um conjunto de valores dos atributos da entidade
podem assumir
- Evento: Acontecimento desencadeado internamente ou externamente
É relativamente fácil identificar estes conceitos numa situação concreta, o problema é descrever
bem e organizadamente e objectivamente a situação.
Ex. Compras de uma empresa:
Ex. de processos (verbos), que são o mais relevante nas metodologias estruturadas, os primeiros
a ser identificados e que conduzem toda a análise e especificação posterior.:
preenche uma requisição; consulta uma lista; envia para o seu director; analisar o pedido; pode ou
não autorizar;...

3.4.3. Técnicas e Notações Mais Utilizadas

- Diagrama de Fluxo de Dados (data flow diagram): São especificações orientadas aos processos,
em que se identificam graficamente processos, entidades externas, fluxos de informação e
repositórios de dados. São os principais diagramas utilizados na modelação de processos. Estes
diagramas podem ser construídos em vários níveis, uma vez que existe a possibilidade de
especificar um processo através de um diagrama de maior detalhe. O diagrama de fluxo de dados
de primeiro nível é nalgumas metodologias designado por diagrama de contexto.
- Diagramas de entidade associação: Representam as relações estáticas de sistema,
designadamente as entidades, com os seus atributos, e a forma como estas se encontram
associadas.
- Diagrama de transição de estados: Representam os estados em que um sistema ou uma
entidade se pode encontrar ao longo do tempo, e dos eventos que desencadeiam as transições.
Diagrama de ciclo de vida de entidade: Versão adaptada de um diagrama de estados para
descrever a evolução de uma entidade ao longo da sua existência, designadamente as operações
de criação, alterações e eliminação.
- Dicionário de dados: São repositórios de definições de todos os elementos e conceitos utilizados
e manipulados pela organização (dados, ficheiros, processos e entidades).
- Matrizes entidade-processo: Demonstram as relações existentes entre as entidades e os
processos
- Fluxogramas: Expressam os passos de execução de algoritmos e processamentos realizados no
sistema.
É ainda de referir a técnica da normalização para eliminar redundâncias e garantir a integridade
da informação nas estruturas/bases de dados.
Qualquer relação expressa num diagrama entidade associação pode ser analisada na perspectiva
de qualquer entidade e implica a caracterização segundo 2 conceitos adicionais: a cardinalidade
(nº máximo de cada uma na relação) e a modularidade (nº mínimo de ocorrências de cada uma, o
que permite identificar as obrigatórias e as opcionais). Estes diagramas melhoraram o rigor da
especificação, no entanto continuam a apresentar algum grau de subjectividade até porque
prevêem descrições em linguagem natural. Além disso a utilização de alguns termos e símbolos
muito próximos da tecnologia impediu a compreensão por parte dos não técnicos.
Os diagramas a que aludimos são notações semi-formais e não era possível garantir a sua
correcção, pelo que foram propostas notações formais, que se caracterizavam por adoptar
conceitos muito próximos da matemática, com o rigor e formalismos correspondentes.
Algumas notações mais conhecidas são:
- Redes de Petri: especialmente adequados a problemas de concorrência e com restrições anível
de sincronização. Utiliza conceitos como transições, funções de input e de output.
- Linguagem Z: Com conceitos matemáticos e lógicos de 1ª ordem (conjuntos, tipos de dados,
constantes, definições de estado, estado inicial, operções)

3.4.4. Principais Metodologias

SSADM (Structured Sistems Analysis and Design Methodology). Proposta em 1981 por Learmoth.
Propõe a modelação de um sistema segundo 3 perspectivas complementares:
- a sua funcionalidade (diagrama de fluxo de dados)
- a sua estrutura (diagrama de entidade associação)
- a sua evolução ao longo do tempo (diagramas de ciclo de vida)
É concebida para a análise e desenho não contemplando a implementação, testes e instalação.
A sequência de actividades envolve:
- A realização de um estudo de viabilidade
- A análise de requisitos do negócio
- A especificação dos mesmos requisitos
- A especificação lógica do sistema
- O desenho físico do sistema

Stradis (Strutured analysis, design and implementation of information systems). Gane e Sarson
nos finais da década de 70, baseada na filosofia de decomposição funcional top-down e suportada
essencialmente pela utilização de diagramas de fluxo de dados.

Yourdon Systems Method

1993, Edward Yourdon. É semelhante à Stradis pois recorre muito à decomposição funcional mas
também atribui importância significativa às estruturas de dados.

Engenharia de Informação
James Martin em 1989. Integra muitos conceitos das outras.
Ao contrário das outras tem uma preocupação estratégica com a definição dos sistemas de
informação, o que é expresso nos diferentes estágios de evolução do processo: planeamento
estratégico; análise de áreas de negócio; desenho de sistemas; implementação.

3.5. Metodologias Orientadas por Objectos

As técnicas anteriores apresentavam vários problemas:
- Não conseguem lidar adequadamente com o problema da complexidade e do tamanho
crescente dos sistemas
- Não resolvem o problema da crescente actividade de manutenção do software
- Verifica-se com frequência a má compreensão dos requisitos do utilizador por parte dos técnicos
- Permanece a dificuldade de lidar com alterações aos requisitos
- A integração e reutilização de módulos e componentes não são fáceis
- Os erros de concepção são descobertos tardiamente
- A qualidade do software é baixa e o seu desempenho inadequado
- Não é fácil identificar quem fez o quê, quando e porquê.
O conceito de orientação por objectos baseia-se de facto numa nova forma de analisar o mundo.
A abordagem seguida reproduz a forma como o ser humano se apercebe e expressa a realidade
que o rodeia. Ele classifica e subdivide o mundo em diferentes objectos, com base nas diferenças
e semelhanças existentes ao nível das características e comportamentos. Isso permite a
reutilização dos objectos.
A perspectiva de modelação muda, uma vez que o mesmo conceito base é utilizado ao longo de
todas as fases do processo, promovendo a reutilização e o encapsulamento da informação,
facilitando a manutenção.

3.5.1. Contexto e Motivação

Simula nos finais dos 60; Smalltalk nos 70.
Motivações principais para a realização de actividades de análise segundo o OO:
- Poder tratar domínios de problemas mais complexos
- Melhorar a interacção entre o analista e o especialista do problema
- Aumentar a consistência interna dos resultados da análise
- Representar explicitamente aspectos comuns a diversos conceitos
- Construir especificações capazes de resistir à mudança
- Reutilizar resultados da análise
- Conceber uma representação consistente para a análise e desenho.

3.5.2. Conceitos Básicos (Princípios e Restantes)

Princípios Orientadores do Paradigma
- Encapsulamento da Informação: é o processo de “esconder” todos os detalhes de um objecto
que não contribuem para as suas características essenciais nem para a disponibilização de
funcionalidades para o seu exterior. Pode ainda ser encarado como a localização de
funcionalidades numa única abstracção auto-contida, que esconde a respectiva implementação e
decisões de desenho através da disponibilização de uma interface pública. O conjunto de
operações que são acessíveis do exterior constitui a interface do objecto. Esta característica
permite a criação de objectos estáveis e reutilizáveis, reproduzindo o mundo real de forma
correcta.
- Herança: Representa a definição de relações entre classes através da qual uma subclasse (é
especialização) partilha, acrescenta ou redefine operações e atributos a partir de uma ou mais
superclasses.. É uma forma de aumentar a reutilização do que é comum, permitindo
adicionalmente acrescentar detalhes específicos. Está ligado aos conceitos de generalização e
especialização.
Polimorfismo: É a capacidade de “esconder” várias implementações distintas através de uma
única interface, isto é, representa a capacidade de objectos diferentes responderem de forma
diferente à mesma mensagem.
Abstracção: É a representação concisa duma ideia ou objecto mais complexa, incidindo sobre as
características essenciais. Abstracções funcionais (processos); OO (objectos).
As que não suportam os dois princípios do meio são considerados baseados em objectos e não
OO.
Existem ainda mais 3 noções importantes:
- Modularidade
- Concorrência
- Persistência

Outros Conceitos Chave do Paradigma da OO

- Objecto: há várias definições que podemos resumir em: Representam identidades físicas,
conceptuais ou apenas necessárias para a representação em computador (por ex. estruturas de
dados); um objecto pode ser um conceito, uma abstracção ou uma entidade, com fronteiras bem
definidas e que tem um significado para um problema e respectiva solução; um objecto tem
estado, comportamento e identidade.
- Atributos: São propriedades nomeadas de um objecto, que definem o estado.
- Comportamento (operação ou serviço): Conjunto de acções que um objecto pode realizar de
forma independente.
- Classes (template/fábrica de objectos): São descrições de grupos de objectos com propriedades
(atributos), comportamento (operações) e relações comuns.
Em geral os atributos permitem identificar a classe, definir as características especiais da classe,
definir o estado da classe, reter alguma informação sobre a classe e identificar o comportamento
do objecto. Para especificar detalhadamente um atributo deve-se identificar o domínio dos seus
valores, as unidades de medida, o valor por omissão, o valor inicial, as condições de leitura e
escrita e eventuais condições relacionadas com outros atributos do objecto ou da classe.
dado o enunciado de um problema, procura-se identificar os objectos concretos e as respectivas
classes, a partir de todos os substantivos que dele sejam extraídos. O objectivo último é
identificar:
- Um conjunto de classes que representam totalmente o domínio do problema
- Os atributos de cada classe
- A interface e os serviços de cada classe
- As diversas relações entre classes
- Objectos concretos que seja necessário particularizar.
Cada metodologia propõe diferentes formas de chegar à informação.
Por ex. ver [Coad91] e checklists para saber quando um objecto potencial não o é, na pg.93.
ex. funcionário; requisição; bens; armazém.
As operações realizadas por objectos podem ser identificadas pela pesquisa no enunciado do
problema de verbos associados a cada objecto. Essas operações podem ser agrupadas em:
- Modificadores: operação que altera o estado do objecto.
- Selectores: Operação que acede ao estado de um objecto
- Iteradores: operação que permite que todas as partes de um objecto sejam acedidas segundo
uma ordem bem definida
- Destrutor: Liberta o estado de um objecto ou elimina-o.
Uma mensagem é sempre formada por um selector e opcionalmente por um conjunto de
parâmetros.
A interface é o conjunto de operações e atributos disponibilizados por uma classe, que consoante
a visibilidade pode ser pública (visível por todos os objectos do sistema), privada 8só visível pela
própria classe) ou protegida (pela classe e subclasses).
Entre as diversas classes podem ser estabelecidas diferentes tipos de relações:
- Associação: Representam as relações estruturais entre objectos de classes diferentes (ter).
Subdivide-se em:
- Agregação: Relação entre o todo e as partes (uma empresa tem empregados)
- Composição: O corpo humano tem uma perna
- Dependência: Relação em que uma mudança de estado num objecto (ocorrida pela
recepção de uma mensagem) pode implicar o envio de uma mensagem a outro objecto.
- Generalização/Especialização: Relações entre classes que partilham a estrutura e
comportamento; implementam o conceito de herança (ser). Um cão é um animal.
Subsistema é um conjunto de classes (ou outros subsistemas) que colaboram entre si para
realizar um conjunto de responsabilidades (no UML é o pacote).

3.5.3. Técnicas e Notações Mais Utilizadas

Ver UML mais à frente.

3.5.4. Principais Metodologias

Ao longo das décadas de 80 e 90_
- Método de Booch (1991): baseia-se na ideia da repetição de actividades de um processo de
desenvolvimento de modo a refinar o modelo em sucessivas iterações. As suas principais
actividades estão orientadas para a identificação de classes e objectos e respectivas
características e para a determinação das relações entre classes.
- OMT (Object Modelling Technique)- James Rumbaugh (1991): concentrou-se na análise e
desenho de software.
3 modelos essenciais:
- estático ou de objectos (rep. classes, objectos, relações)
- dinâmico (comportamento dos objectos e sistema global)
- funcional (diagrama de fluxo de informação)
- OOSE (Object Oriented Software Engineering) – Ivar Jacobson (1992)
Resulta da evolução do modelo Objectory e a sua maior contribuição foi a introdução da noção de
caso de utilização.
- OOAD (Object Oriented Analysis and Design) – Peter Code e Edward Yourdon (1991)
vantagem: simplicidade (de conceitos, actividades e diagramas)
- Identificar objectos utilizando critérios simples (substantivos)
- Definir uma estrutura de relações generalização-especilaização
- Definir uma estrutura de relações de associação (whole-part)
- Identificar assuntos (subsistemas)
- Definir os atributos
- Definir os serviços
- Método de Wirfs-Brock
Não efectua distinção clara entre análise e desenho e a sua principal contribuição foi a definição
de diagrama designado por CRC cards (Class-Responsibility-Colaboration) que procura identificar
as classes dos sistema, a sua interface e as relações entre elas.
- Rational (cap.10)
3.6. Outras Metodologias
As metodologias não estão isentas de críticas e aspectos menos positivos:
- Complexidade nos conceitos, técnicas e aplicação
- Desconhecimento global e falta de competências dos informáticos para a sua execução com
qualidade
- Ferramentas difíceis de utilizar
- Constatação da ausência de melhorias no processo e produto final
- Concentração na análise da situação actual e não no futuro
- Tempo
- Rigidez
Como reacção apareceram um conjunto de metodologias que usam um formalismo muito menor.
Código fonte é tudo em documentação e as principais actividades são programar e testar.
Concentram-se na satisfação das necessidades das pessoas e não na definição dos processos. É
iterativo.
Não há designação formal para elas ainda mas usa-se o termo lightweight.
XP – Extreme Programming e DSDM – Dynamic System Development Method.
São aconselháveis para sistemas pequenos e com requisitos incertos ou voláteis e com técnicos e
utilizadores motivados.

3.7. Comparação de Metodologias

É tarefa complexa devido a:
- Não existem metodologias iguais
- Muitas metodologias são influenciadas ou concebidas para linguagens de programação
específicas
- Muitas metodologias assumem contexto particular de aplicação
- A abrangência varia fortemente
Hoje em dia reconhecem-se vantagens das OO relativamente às estruturadas, porque
apresentam:
- Um único paradigma consistente ao longo de todo o processo, mais próximo do processo de
cognição humano
- Facilitam a reutilização
- Modelos que reflectem o mundo real
- Não existe separação entre dados e processos
- Os detalhes de implementação estão escondidos (encapsulamento)
- Maior facilidade de tarefas de manutenção
- O sistema é mais estável
Às vezes o problema é encontrar objectos e classes apropriados pois os informáticos continuam a
pensar funcionalmente.

3.7.1. Gestão de Requisitos e Facilidade de Manutenção

No desenvolvimento estruturado, o sistema consiste num conjunto de dados que são usados
(leitura ou escrita) por inúmeras funções. é pois uma malha arbitrária de inúmeras
interdependências entre funções e dados.
No OO, dados e funções são agregados conjuntamente numa entidade lógica (o objecto) que
providencia uma interface bem definida para outros objectos comunicarem com ele. O sistema
corresponde a uma malha de interdependências entre objectos.
É evidente que as OO facilitam a gestão de alterações de requisitos. Ex alteração da estrutura de
dados implicava alterar todas as funções; no OO desde que interface não mudasse era fácil.

3.7.2. Representação da Realidade

Nas abordagens OO, as entidades do mundo real são captadas directamente por objectos. Nas
estruturadas o foco é no desenho da base de dados ou, alternativamente, na definição dos
processos/funções que acedem e manipulam essas bases. Difícil especializar contas bancárias.

3.7.3. Outros Aspectos

Outras vantagens:
- Providencia blocos de construção de alto nível que reduzem os custos de desenvolvimento, pela
promoção da reutilização e encapsulamento de software. Este facto permite reduzir as
interdependências e facilita manutenção posterior.
- Facilita transferência de conhecimento através da adopção de “padrões de desenho”, reduzindo
custos de aprendizagem
- Providencia framework (aplicacional ou de middleware) para facilitar a extensão do sistema,
reduzindo o custo de novas versões
- Reduz o custo de alteração do sistema.
Todavia há que ter alguns cuidados na sua aplicação:
- Exige uma nova forma de pensar o processo de desenvolvimento
- Deve ser usada em todas as fases do ciclo de vida do software
- A gestão da empresa tem de “comprar” a mudança para a filosofia OO (ex. redução de custos de
manutenção)
- A migração deve ser devidamente planeada.
Parte 2 – Linguagem de Modelação UML
O UML
O UML (Unified Modelling Language) é uma linguagem diagramática, utilizável para especificação,
visualização e documentação de sistemas de software.
Tem as seguintes características principais:
- É independente do domínio de aplicação (sistemas cliente/servidor tradicionais, sistemas
baseados na web, de informação geográficos, de tempo real, etc.).
- É independente do processo ou metodologia
- É independente das ferramentas de modelação
- Apresenta mecanismos potentes de extensão
- Agrega um conjunto muito significativo de diferentes diagramas/técnicas dispersos por diferentes
linguagens (diagramas de casos de utilização, de classes, de objectos, de colaboração, de
actividades, de estados, de componentes, e de instalação).
O objectivo principal do UML é promover e facilitar a comunicação entre um grupo variado de
intervenientes.

CAP. 4 – UML – VISÃO GERAL

4.1. Introdução
O UML é uma linguagem para especificação, construção, visualização e documentação de
artefactos de um sistema de software.
O UML providencia as seguintes particularidades principais
- Semântica e notação para tratar um grande número de tópicos actuais de modelação
- Semântica para tratar tópicos de modelação futura (tecnologia de componentes, computação
distribuída, frameworks e Internet)
- Mecanismos de extensão
- Semântica e sintaxe para facilitar a troca de modelos entre ferramentas distintas
É independente das linguagens de programação, das ferramentas CASE e dos processos de
desenvolvimento.
Os novos elementos introduzidos no UML são:
- Mecanismos de extensão
- Elementos para modelar processos e threads
- Elementos para modelar concorrência e distribuição
- Padrões de desenho e colaborações
- Diagramas de actividades (para modelação de processos de negócio)
- Refinamento
- Interfaces e componentes
- Linguagem de restrições (OCL)
O UML providencia os seguintes tipos de diagramas:
- De casos de utilização
- De classes e de objectos
- De comportamento
- De estados (statechart)
- De actividades
- De interacção ( de sequência e de colaboração)
- De arquitectura
- De componentes
- De instalação

4.2. Visão Histórica

fase da fragmentação – fase da unificação – fase da standardização – fase da industrialização.
Actualmente assiste-se à divulgação e adopção generalizada do UML como “a” linguagem de
modelação de software segundo a abordagem orientada por objectos.
Há 2 aspectos importantes que se obtêm com o UML:
- Terminam as diferenças, geralmente inconsequentes, entre as linguagens de modelação dos
anteriores métodos
- Unifica as distintas perspectivas entre diferentes tipos de sistemas (ex. modelação de negócio,
modelação de software), fases de um processo e conceitos internos.
4.3. Tipos e Elementos Básicos
A estrutura de conceitos do UML é razoavelmente abrangente consistindo num conjunto variado
de notações, as quais podem ser aplicados em diferentes domínios de problemas e diferentes
níveis de abstracção.
A estrutura de conceitos do UML pode ser vista através do seguinte conjunto de noções:
- “Coisas” ou elementos básicos, com base nos quais se definem os modelos
- Relações, que relacionam os elementos
- Diagramas, que agrupam os elementos
Os principais elementos de estrutura são:
- Classes
- Interfaces
- Nós
- Classes activas
- Actores
- Componentes
- Casos de utilização
- Colaborações
Há outros elementos básicos:
- De comportamento:
- Estados
- Mensagens
- De agrupamento:
- Pacotes
- De Anotação
- “Isto é uma anotação”

4.4. Tipos de Relações

São conceitos gerais (com sintaxe (notação) e semântica bem definidas) que permitem o
estabelecimento de interdependências entre os elementos básicos
associação
0-1 *
--------------------
tem vive

realização
-------------------|>

dependência
------------------>

transição de estado
_____________________>

generalização
_____________________|>

4.5. Tipos de Diagramas

São conceitos que traduzem a possibilidade de agrupar elementos básicos e suas relações de
uma forma lógica ou de uma forma estrutural. Há vários tipos, cada um utilizando um subconjunto
dos elementos, com diferentes tipos de relações que tenham sentido para cada caso.
Com base no 4º principio de modelação (ver cap.2) “Nenhum modelo é suficiente por si só.
Qualquer sistema não trivial é melhor representado através de pequeno número de modelos
razoavelmente independentes, o UML define diferentes tipos de diagramas que permitem visões
complementares:
- Diagramas de Casos de Utilização, que representam a visão do sistema na óptica do utilizador.
- Diagramas de Classes, que permitem especificar a estrutura estática de um sistema segundo a
abordagem orientada por objectos
- Diagramas de Interacção Entre Objectos (de sequência e de colaboração) e diagramas de
transição de estados e de actividades que permitem especificar dinâmica ou comportamento do
sistema
- Diagramas de Componentes e Diagramas de Instalação, que dão visão da disposição dos
componentes físicos (software e hardware) de um sistema.

4.5.1. Diagramas de Casos de Utilização

Descreve a relação entre actores e casos de utilização de um dado sistema. Dá visão global de
alto nível do sistema.
São usados preferencialmente na fase de especificação dos requisitos e na modelação de
processos de negócio.

4.5.2. Diagramas de Modelação da Estrutura

Os diagramas de classes descrevem a estrutura estática de um sistema, em particular as
entidades existentes, as suas estruturas internas, e relações entre si.
Um diagrama de objectos ... em determinado momento.

4.5.3. Diagramas de Modelação do Comportamento

Os padrões de interacção entre objectos são representados por diagramas de interacção, que
podem assumi formas complementares, cada um focando aspectos distintos: diagramas de
sequência e diagramas de colaboração.
Diagramas de Sequência
Ilustram interacções entre objectos num determinado período de tempo (objectos são
representados pela sua “linha de vida” e interagem por trocas de mensagens)
Diagramas de Colaboração
Ilustram interacções entre objectos com ênfase para a representação das ligações entre objectos.
Como não aparece o tempo, a sequência de mensagens e actividades concorrentes é
determinada pelo uso de números sequenciais, com diferentes níveis hierárquicos.
As colaborações são entidades de modelação principais e constituem a base para a
representação visual de padrões de desenho (design patterns)
Diagramas de Transição de Estado
Descrevem as sequências de estados que um objecto ou um interacção pode passar ao longo da
sua existência em resposta a estímulos recebidos, conjuntamente com as suas resposta e acções.
Diagramas de Actividades
São caso particular do anterior, no qual a maioria dos estados são substituídos pelos conceitos
correspondentes e acções ou actividades, e no qual as transições são desencadeadas devido à
conclusão de acções nos estados originais. O objectivo é representar fluxos por processamento
interno, em contraste com o diagrama anterior que se usa mais para eventos externos.
Diagramas De Arquitectura
Descrevem aspectos da fase de implementação de um sistema de software. Apresentam-se de
duas formas:
- Diagramas de Componentes
Descrevem as dependências entre componentes de software
- Diagramas de Instalação (deployment diagrams)
Descrevem a configuração de elementos de suporte de processamento, e de componentes de
software, processos e objectos existentes nesses elementos.

4.6. Mecanismos Comuns (aos vários diagramas)

4.6.1. Notas (Anotações)
São os adornos mais importantes que existem autonomamente.
Uma nota ilustra um comentário e não tem qualquer impacto semântico. Não altera pois o
significado do modelo.
É normal usar-se para descrever informalmente: requisitos, restrições, observações, revisões ou
explicações.
Deve ter-se em atenção:
- Localização: perto dos elementos que descrevem
- Visibilidade: escondidas ou visíveis
- Extensão: usar referências (URLs, etc.)
- Evolução

4.6.2. Mecanismos de Extensão

São os Estereótipos; Marcas e Restrições.
No seu uso deve-se:
- Introduzir um número reduzido
- Escolher nomes curtos e com significado, para os 2 primeiros
- Usar texto livre para especificação das restrições, sempre que a precisão possa ser relaxada.
- Deve ser realizada por especialistas em UML, principalmente no caso dos estereótipos

Estereótipos
É um metatipo. Permite definir novos tipos de elementos sem se alterar o metamodelo do UML «»
A definição de um estereótipo tem de ter em conta os seguintes aspectos:
- Propriedades (pode providenciar o seu próprio conjunto de marcas)
- Semântica (pode providenciar as suas próprias restrições)
- Notação (pode providenciar o seu próprio ícone)
- A classe base do metamodelo, que vai ser estendida

Marcas Com Valor

Cada elemento em UML tem um conjunto de propriedades. Por exemplo: as classes têm um
nome, uma lista de atributos e uma lista de operações; as associações têm um nome e dois ou
mais elementos participantes. Enquanto que os estereótipos permitem adicionar novos
elementos UML, as marcas com valor permitem adicionar novas propriedades aos elementos.
Deve ser entendida como metadata (isto é dados que descrevem dados) pois o seu valor aplica-
se ao próprio elemento e não às suas instâncias. { }

Restrições (constraints)
Permitem adicionar ou alterar a semântica assumida por omissão de qualquer elemento UML.
{ } A condição pode ser especificada numa linguagem formal ou informal.

4.7. Tipos de Dados

É uma abstracção utilizada de forma implícita no UML. Não são elementos do modelo e por
conseguinte não lhe são associados estereótipos, marcas com valor ou restrições. Um tipo
primitivo não tem subestrutura.
- Primitivos: Integer, String, Time
- Enumerados: Boolean, AggregationKind, VisibilityKind
- Outros: Expression, Mapping, Name, Multiplicity

4.8. Organização dos Artefactos – pacotes

Um pacote (package) é em UML um elemento meramente organizacional. Permite agregar
diferentes elementos de um sistema em grupos de forma que semântica ou estruturalmente faça
sentido.
A necessidade é evidente em sistemas de média/grande dimensão, impossíveis de modelar de
uma “só vez”. Os benefícios são:
- Facilita a gestão e procura de artefactos
- Evita conflito de nomes ( X::A é diferente de X::Y::A, e diferente de Z::A )
- Providencia um mecanismo de controlo de acessos (visibilidade)

4.8.1. Representação Gráfica

Os pacotes são representados por uma pasta (tabbed folder) com duas zonas complementares:
um pequeno rectângulo (designado por tabulador ou tab), normalmente com o nome do pacote; e
um rectângulo maior onde normalmente se especificam os elementos constituintes. Há várias
formas alternativas e o + significa visibilidade (dos elementos) pública, - é privada e # protegida.
Pode-se ainda especificar hierarquias e marcas, estereótipos e restrições.
4.8.2. Relações Entre Pacotes
Importação; Exportação e Generalização.
Visibilidade
- pública: o elemento pode ser usado/referenciado por qualquer outro elemento
independentemente do local onde é definido
- privada: pode ser usado/referenciado por elementos definidos no mesmo pacote
- protegida: pode ser usado/referenciado por um elemento definido no mesmo pacote ou num
outro pacote que seja uma especialização (através da relação de herança) do primeiro.
Também se pode definir relação de friend entre 2 pacotes (é uma relação de dependência entre
pacotes, com estereótipo «friend»). Contudo esta relação deve ser evitada porque viola os
princípios do encapsulamento e da minimização de dependências.

Importação e Exportação
Um pacote faz a exportação, por definição, de todos os seus elementos públicos. mas tal facto
não implica que um elemento definido noutro pacote possa aceder/referenciar um elemento
exportado num outro pacote. Para que tal acontecesse deveria existir explicitamente uma relação
de importação entre esses dois pacotes.
A relação de importação é uma relação de dependência entre pacotes, especificando que o
pacote base importa todos os elementos públicos definidos no pacote destino. É representada por
uma linha dirigida, a tracejado, com estereótipo «import». Não é transitiva. Não é simétrica.
Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface.

Generalização
É semelhante à homóloga existente entre classes, e é usada para especificação de famílias de
pacotes, típicas em sistemas complexos ou flexíveis (significativamente parametrizáveis, multi-
plataforma, multi-linguagem). Permite especializar pacotes.

4.8.3. Tipos de Pacotes

Ao contrário dos exercícios académicos, em situações reais de modelação de sistemas de
software de média/grande dimensão, realizadas por equipas, torna-se necessário tipificar os
próprios pacotes. A especificação UML propõe 5 estereótipos standard:
- «system» : pacote que representa o sistema inteiro. Agrega os outros.
- «subsystem» : representa uma parte do sistema
- «facade» : pacote com elementos (tipicamente classes e interfaces) que constituem a fachada
(ou a interface de programação)
- «framework» : é uma arquitectura de classes e interfaces com inúmeros pontos de variabilidade
ou de extensão e com estruturas de objectos padronizadas, conhecidas por padrões de desenho.
O desenvolvimento de sistemas baseados em frameworks e em componentes de software é um
tópico emergente extremamente actual.
- «stub»: um adaptador (stub) é usado quando se pretende partir um sistema em diferentes
pacotes por motivos de divisão de trabalho.
Em geral os pacotes mais usados são sistema ou subsistema.

4.8.4. Modelação de Grupos de Elementos

Algumas formas clássicas de organização dos artefactos de projectos em termos de pacotes:
- Organização por casos de utilização: ex. ICONIX
- Organização por tipos de modelos: ex. RUP
CAP. 5 – UML – CASOS DE UTILIZAÇÃO
5.1. Introdução
A engenharia de requisitos preocupa-se em capturar, armazenar e gerir requisitos.
Um requisito é uma especificação de uma determinada acção ou condição que o sistema deve
satisfazer.
Um requisito funcional descreve uma dada acção (ou função) que o sistema deve suportar.
Um requisito não funcional descreve um aspecto (não funcional) que o sistema deve satisfazer.
Requisitos não funcionais têm a ver com aspectos gerais do sistema, tais como: desempenho,
robustez, fiabilidade, distribuição, segurança, integração com Internet, abertura, ou suporte de
standards.
O UML inclui os diagramas de casos de utilização (use cases) que permitem a especificação de
requisitos funcionais segundo uma aproximação focada principalmente nos utilizadores do
sistema. Esta abordagem facilita a comunicação.
A relação entre casos de utilização e requisitos não é pacífica.
Há alguns aspectos importantes na especificação de requisitos, que têm a ver com a sua
apresentação, organização e nível de detalhe.
Quanto aos 2 primeiros há autores que advogam diagramas (de casos de utilização)
seguidamente cada caso em particular deve ser especificado em detalhe através de descrição
textual e, opcionalmente, através de um ou mais diagramas de colaboração e/ou desenhos de
protótipos de interfaces homem-máquina (ex. screenshots).
Quando os requisitos são descritos textualmente, recomenda-se normalmente que sejam
numerados sequencialmente segundo, pelo menos, duas sequências distintas: uma para os
requisitos funcionais e outra para os requisitos não funcionais. Por outro lado, quando os
requisitos são baseados nos casos de utilização, deve usar-se o elemento pacote do UML como
elemento estruturante.
Em geral é preferível a descrição de casos de utilização de forma não muito detalhada, variando
entre uma a 5 páginas.

5.2. Casos de Utilização

É uma sequência de acções que um ou mais actores realizam num sistema de modo a obterem
um resultado particular.
O modelo de casos de utilização permite capturar os requisitos de um sistema através de um
detalhe de todos os cenários que os utilizadores podem realizar. mais que iniciar a modelação de
requisitos do sistema, os casos de utilização dirigem/conduzem todo o processo de
desenvolvimento.
É representado por uma oval, com uma frase (verbo no infinitivo) que representa uma acção.
Deve descrever o que faz o sistema mas não como o faz. É pois a visão do utilizador.

5.2.1. Casos de Utilização e Cenários

Um cenário (2fluxo de acções”) é uma determinada sequência de acções que ilustra um
comportamento do sistema; é uma instância de um caso de utilização.
Deve-se especificar o comportamento de um caso de utilização descrevendo textualmente um
mais fluxos de situação em linguagem não-técnica. deve incluir:
- Como e quando o caso de utilização começa e termina
- Quando é que o caso de utilização interactua com os actores
- que objectos são trocados
- Cenário principal, e
- Cenários alternativos (situações de excepção)
ex. 5.1 Especificação textual do caso de utilização “Validar Utilizador”:
Nome; Cenário Principal; Cenário Alternativo 1 (Cliente cancela operação); cenário alternativo 2
(PIN Inválido).
Um aspecto importante é o nível de detalhe, que varia muito consoante o tipo de projecto.
Normalmente é textual e pode ser complementada por diagramas de interacção ou até protótipos
de interfaces.
Deve evitar-se linguagem técnica, aspectos tecnológicos, referir explicitamente pessoas (sim
papéis) , departamentos específicos, componentes de interface (botões, menus, etc.) ou
referências a dispositivos de hardware.
5.2.2. Relações entre Casos de Utilização
Generalização; Inclusão e Extensão.
Potenciam significativamente a reutilização de especificação de requisitos.
Generalização
Permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou
alternativamente, permite definir casos mais abstractos a partir de casos concretos pelo
mecanismo da redução ou generalização.
Inclusão («include»)
Corresponde a uma relação típica de delegação, isto é, o caso base incorpora o comportamento
do outro caso relacionado. Usa-se para evitar a descrição dos mesmos fluxos inúmeras vezes.
Ex: Obter Extracto de conta e Realizar Pagamentos include Validar Utilizador.
A questão importante é como indicar, em que ponto da especificação, o caso de utilização
relacionado deve ser incorporado no caso base. Este é um aspecto essencial na compreensão e
domínio dos casos de utilização. Deve ser efectuada na especificação textual do caso de
utilização.
Ex. 5.2. Especificação textual do caso de utilização “Obter Extracto de Conta”
Nome; Cenário Principal; Incluir caso de utilização “Validar Utilizador”;...

Extensão («extend»)
O caso base incorpora implicitamente o seu comportamento num local especificado
indirectamente pelo caso que é usado. Ou seja, o caso destino pode ser estendido com o
comportamento de outro(s) caso(s). Permite representar:
- A parte de um caso que um utilizador vê como opcional, ou como existindo várias alternativas
- Um subfluxo de acções que é executado apenas se determinadas condições se verificarem
- Vários fluxos de acções que podem ser inseridos num determinado ponto de extensão, de forma
controlada, através de uma interacção explícita com um actor.
O caso de utilização de destino é estendido num ou mais pontos (pontos de extensão), ou seja
são pontos de entrada do caso de utilização que lhe dá algum nível de configurabilidade e
versatilidade.
Ex. escolher nº de dias no Obter Extracto de Conta.
Textual: Nome: Obter Extracto de Conta; Pontos de Extensão: Nº de Dias; Cenário Principal;
Cenário Alternativo 1.

5.3. Diagramas de Casos de Utilização

Ilustra um conjunto de casos de utilização, de actores e suas relações. As aplicações mais
comuns são:
- Para modelar o contexto de um sistema
- Para modelar os requisitos de um sistema
A ligação entre um actor e um caso de utilização corresponde a um estereótipo de comunicação
(«communicate»). É representada por linha a cheio.

5.3.1. Actores
É o conceito que representa, em geral mas nem sempre (ex. outro sistema informático, hardware,
ou tempo), um papel que um utilizador desempenha relativamente ao sistema em análise.

5.3.2. Casos de Utilização Abstractos e Concretos

Abstracto: é um caso que não apresenta uma relação de comunicação com qualquer actor ( o seu
nome é representado a itálico).
São tipicamente casos envolvidos em relações de generalização, inclusão ou extensão com
outros casos de utilização. O objectivo é dar ao modelo um nível elevado de reutilização e de
flexibilidade.

5.4. Proposta de Metodologia (parece fácil mas não é)

1) Identificar os actores do sistema
2) Identificar, para cada actor, os seus casos de utilização principais
3) Com base nos casos de utilização originai, identificar, factorizar e colocar em evidência casos
de utilização que sejam recorrentes em mais que um dos casos originais. Nessa situação, cria-se
o novo caso (em geral abstracto) e os originais envolvidos estabelecem uma relação de inclusão
com o dito caso. Repetir o processo até não se conseguir identificar qualquer outro caso a
reutilizar.
4) Para flexibilidade e versatilidade, definir pontos de extensão (ou de variabilidade) e
conjuntamente definir um ou mais casos abstractos que os permitam estender nesses pontos.
5) Especificar textualmente cada caso segundo um determinado formato previamente definido.
ex: Máquina de bebidas
1) Cliente; agente do fornecedor; dono da máquina.
2) Comprar bebida; Repor bebidas; Retirar dinheiro
3) Repor bebidas e Retirar dinheiro envolvem Abrir Máquina e Fechar Máquina (inclusão)
4) Repor bebidas tem um ponto de extensão: encher prateleira (abstracto – vários algoritmos – ex.
de acordo com vendas)
CAP. 6 – UML – MODELAÇÃO DA ESTRUTURA
6.1. Introdução
Consiste na identificação de classes e suas respectivas relações.
Uma classe consiste num estrutura que permite criar objectos semelhantes (em estado e
comportamento).
O UML providencia os seguintes elementos que permitem a especificação da estrutura ou estática
de um sistema de software:
- Classes
- Relações
- Interfaces
- Objectos.
Com base nestes elementos podem fazer-se 2 tipos de diagramas com fins complementares:
- Diagramas de Classes
- Diagramas de Objectos

6.2. Classes
É a descrição de um conjunto de objectos que partilham os mesmos atributos, operações,
relações e a mesma semântica. Corresponde a algo tangível ou a uma abstracção conceptual.
É representada por um rectângulo, com uma, duas ou três secções.
Na 1ª - nome da classe; na 2ª - lista de atributos; 3ª - lista de métodos.
Opcionalmente pode ter 4ª - outra informação (ex. lista de responsabilidades que a classe
assume)
O nome pode vir na forma simples ou completa ( pacote::nome).
Os atributos podem ter apenas o nome ou, adicionalmente, os respectivos tipos, visibilidade e
outras qualificações.
visibility name [multiplicity] : type-expression = initial-value {property-string}
A multiplicidade por omissão é 1..1 (exactamente 1).
Nas operações (métodos) podem ver-se só os nomes ou também as assinaturas, visibilidade,
outras qualificações (ex. abstracta ou polimórfica).
visibility name (parameter-list) : return-type-expression {property-string}
Podem definir-se subsecções dentro da 2ª ou 3ª secções de forma a organizar melhor, com base
na noção de estereótipo.

6.3. Relações
Estabelece a ligação entre elementos e é representada graficamente por um determinado tipo de
linha. Os 3 tipos de relações mais importantes são:
- Dependências
- Generalizações
- Associações

6.3.1. Relação de Dependência

Indica que a alteração na especificação de um elemento pode afectar outro elemento que a usa,
mas não necessariamente o oposto. Linha dirigida a tracejado.
No contexto de classes, usam-se dependências para ilustrar que uma classe usa outra como
argumento na assinatura de uma das suas operações ou como tipo na definição dos seus
atributos. Por clareza não se usa normalmente nos diagramas, pois é implícito. Usa-se mais com
pacotes e notas.

6.3.2. Relação de Generalização

É uma relação entre um elemento geral (superclasse,...) e um elemento mais específico. is-a ou
is-a-kind-of. Representa-se por linha dirigida a cheio com um triângulo a branco num extremo.
No contexto das classes usam-se para ilustra relações de herança.
A herança providencia mecanismo natural e potente de organização dos programas de software,
ao permitir:
- Que cada subclasse herde o estado e comportamento de uma superclasse
- Subclasses pode adicionar o seu próprio estado e comportamento
- As subclasses podem ainda alterar os métodos herdados, providenciando especializações
Os benefícios da herança têm a ver com:
- Possibilidade de reutilização de código
- Definição de frameworks (programas com estruturas quase completas) através de classes
abstractas que definem comportamentos genéricos e/ou estilos de desenho comuns.
Por omissão uma relação de generalização representa uma decomposição disjunta ou exclusiva.
No entanto outras semânticas podem ocorrer se especificadas:
- Generalização disjunta (disjoint): especifica que uma classe descendente de X pode apenas ser
descendente de uma das subclasses de X
- Sobreposta (overlapping) Uma classe descendente de X pertence ao produto cartesiano das
subclasses de X
- Completa (complete): completamente especificada ou não. ex. com e sem etiqueta.

6.3.3. Relação de Associação

Especifica que objectos de uma classe estão ligados a objectos de outra. ex. “posse” entre
utilizador e password.
É representada por linha a cheio complementada por um conjunto de “adornos” que
complementam a informação:
- O nome
- O papel de cada participante
- A multiplicidade
- O tipo de agregação
Podem ainda incluir os menos comuns navegação, visibilidade e qualificação

Multiplicidade
Traduz o nº de instâncias de uma classe que se podem relacionar com uma única instância da
outra.
muitos (*); um ou mais (1..*), exactamente 1 (1), zero ou um (0..1), determinado nº (3),
determinada gama (2..6) ou listas (0..3,5..7,10..*)

Navegação
Traduz a forma como a partir de uma instância de uma classe se pode aceder a uma ou mais
instâncias de outra classe relacionada pela associação. Por omissão é bidireccional. Mas pode
interessar ser unidireccional (ex: utilizador e password).

Agregação (Simples)
Traduz que existe uma relação do tipo “is-part-of” ou “has-a”, isto é, uma instância de uma dada
classe possuir ou ser composta por várias instâncias de outra classe. O adorno é um losango
junto do elemento agregador ou “o todo”. Ex: PC e CPU, teclado, ...

Composição (Agregação Composta)

É uma variante da anterior, em que é adicionada a seguinte semântica:
(1) forte pertença do “todo” em relação à “parte”
(2) tempo de vida delimitado (as partes não podem existir sem o todo)
O adorno é um losango a cheio. Ex. Empresa e Departamentos

Associações Qualificadas
Um qualificador é um atributo (da associação), ou lista de atributos, cujos valores servem para
partir o conjunto de instâncias associadas a uma instância ao longo de uma associação.
É representado por pequeno rectângulo junto do extremo de uma associação. É colocado no
extremo da classe origem da associação.
Uma instância da classe de origem, conjuntamente com um valor do qualificador, permite
seleccionar univocamente um subconjunto das instâncias da classe destino. A multiplicidade
afecta o extremo destino. Os valores comuns são: 0..1 1 * . Ex. Banco (qualificador – nº
conta) e Pessoa; Tabuleiro Xadrez – linha/coluna --> Quadrado.

Associações Reflexivas
Quando estabelece uma relação estrutural consigo própria. Acontece quando uma classe tem
objectos que desempenham diferentes papéis. ex. ocupante do carro : condutor e passageiro.

Classes-Associação
A associação pode também ter os seus próprios atributos (e eventualmente operações), devendo
por conseguinte ser modelada também como uma classe. Ex. classe-associação Tarefa que é
traduzida da associação entre pessoa e empresa. Representa-se por linha a tracejado a ligá-la à
linha da associação.

Associações N-Árias (N>=3)

São pouco comuns, mas às vezes proporcionam melhor clareza. Esta associação é representada
por losango com linhas para todas as classes participantes. A multipliciade é mais complexa e
representa o número de tuplos (instâncias) numa associação quando os outros N-1 valores são
fixos. Ex: Tarefa (Pessoa – Empresa – Tipo Tarefa). Podem ser decompostas em binárias através
de estereótipos ou anotações.

6.4. Interfaces
É um contrato na forma de uma colecção de especificações de métodos que providencia um
mecanismo para separação clara entre a vista externa e a interna de um determinado elemento.
É realizada ou implementada por uma ou mais classes.
Este conceito apresenta os seguintes benefícios ao nível de programação:
- Captura de semelhanças entre classes não relacionadas
- Declaração de métodos que uma ou mais classes esperam implementar
- Um objecto pode ser visto de diferentes perspectivas (diferentes tipos) consoante as
circunstâncias.

Representação Gráfica
Como uma classe mas com o estereótipo «interface». Alternativamente pode ser um círculo.

Relações Entre Interfaces, Classes e Componentes

Tal como nas classes, uma interface pode participar em relações do tipo generalização,
associação, e dependência. Adicionalmente pode participar em relações do tipo realização.
Uma relação de realização estabelece-se entre uma interface e uma classe ou entre uma
interface e um componente. Pode representar-se na forma compacta ou expandida.
Em função do acesso ao componente (ou à classe), assim são providenciadas diferentes
funcionalidades.
Fundamental no desenvolvimento de software em componentes porque podemos evoluir o
componente desde que continue a suportar os mesmos interfaces antigos.

6.5. Instâncias e Objectos

Uma instância é uma manifestação concreta de uma abstracção, à qual um conjunto de
operações pode ser aplicado, e que tem um estado que regista os efeitos das operações
realizadas. Objecto não é bem a mesma coisa que instância (+ geral).
Um objecto é uma instância de uma classe, herdando todos os atributos e métodos definidos na
própria classe e possuindo uma representação de execução própria, a qual se pode designar
genericamente por estado, bem como uma identificação única no contexto da execução.
Também é representado por rectângulo com 1,2 ou 3 secções. São, contudo, sublinhados no
nome e sufixados pelo nome das classes respectivas:
Nome-do-objecto : Nome-da-classe

Operações
Os objectos podem efectuar operações definidas nas suas classes. ex: fac.CalculaIvaTotal()

Estado
O estado de um objecto é dado pelos valores assumidos pelo conjunto de atributos de um objecto.
É dinâmico e até pode ser associado a máquina de estados.
 termo:Termo ar:Docente

[em discussão] nome = “Abel Rodrigues”

id:NIF = 123456789
t: TipoDocente = “PCA”

Objectos Activos
Ex. são Processos, fluxos de execução, agentes de software e aplicações, que apresentam uma
visão da dinâmica de um sistema. Têm a particularidade de terem controlo sobre o seu próprio
fluxo de execução. Representam-se com linhas de maior espessura.

Objectos Compostos
É constituído por outros (sub)objectos. Em geral reflectem relações de agregação. São
representados como objectos normais, com a excepção dos seus atributos serem substituídos por
outros objectos, usando sublinhado ou através de uma representação gráfica. A vantagem é de
maior clareza e simplicidade dos diagramas produzidos.

6.6. Diagramas de Classes e Diagramas de Objectos

DC – ilustra um conjunto de classes, interfaces, colaborações e respectivas relações, em geral de
dependências, generalizações e de associação.
São compostos para modelar a estrutura de um sistema. São também designados por “vista do
desenho estático do sistema” e são usados tipicamente em 3 situações:
- Modelar o vocabulário do sistema
- modelar colaborações simples
- modelar o desenho de um esquema de uma base de dados
DO – ilustra um conjunto de objectos e respectivas relações num determinado momento. Permite
captar “fotografia” do sistema.

6.7. Exemplos e Recomendações

Ex. 6.1. Diagrama de Classes/Objectos do Sistema de Gestão de Automóveis

0..1 * 0..1 1
Veiculo Motor
Pessoa
modelo
matrícula numero
cor cilindrada
combustível
CAP. 7 – UML – MODELAÇÃO DO COMPORTAMENTO
7.1. Introdução
Em qualquer sistema minimamente interessante, os objectos não estão estáticos, mas interagem
entre si por troca de mensagens.
A modelação do comportamento de um sistema de software consiste em 2 tipos distintos de
especificações:
- Modelação do comportamento interobjectos (diagramas de interacção)
- Modelação do comportamento intra-objecto, ou seja na identificação dos estados em que o
objecto pode estar ao longo do seu ciclo de vida, dos eventos envolvidos, ebm como dos seus
algoritmos (diagramas de estados e actividades)
O UML providencia os seguintes elementos, que permitem a especificação do comportamento
dum sistema:
- objectos
- interacções
- mensagens
- estados
- eventos
- sinais
- actividades

7.2. Interacções
É a especificação do comportamento de um conjunto de instâncias, representado pela sua troca
de mensagens, num determinado contexto, e com vista à concretização de um objectivo.
As interacções são usadas para modelar o fluxo de controlo de uma operação, classe,
componente, caso de utilização ou sistema na sua globalidade. Sempre que existe uma ligação
(link) entre instâncias, pode ocorrer uma ou mais interacções.
Uma mensagem define uma comunicação particular entre instâncias.
Expls de comunicações:
- invocar uma operação;
- lançar um sinal;
- construir ou destruir uma instância
A mensagem especifica não só o tipo de comunicação mas também os papéis do emissor e do
receptor, a acção lançada e o papel da ligação.

7.2.1. Objectos e Ligações

Os diagramas de interacção podem ser considerados uma extensão dos diagramas de objectos.
Uma ligação (link) entre objectos traduz a existência de uma relação semântica ou estrutural entre
as suas respectivas classes. Ligação representa-se por linha a cheio, não dirigida.

7.2.2 Mensagens e Estímulos

Um estímulo é uma comunicação entre 2 objectos que veicula informação com a expectativa que
determinada actividade seja realizada. Ex. invocação de uma operação, envio de um sinal, criação
ou destruição de instância.
Uma mensagem é a especificação de um estímulo, ou seja, especifica os papéis que os objectos
emissor e receptor devem acordar para que uma acção seja realizada.

7.2.3. Representação de Mensagens

Um estímulo é representado por uma linha sólida dirigida. Há variantes para ilustrar diferentes
tipos de comunicação:
- Simples – Fluxo de controlo simples. Cada seta mostra o próximo passo numa determinada
sequência. Usa-se quando não é relevante mostrar o tipo de comunicação. _____________>
- Síncrona – Invocação de método ou outro fluxo de controlo, dentro do fluxo corrente. Pode ser
usado em situações normais de invocação de operações. Também entre objectos activos
concorrentes, quando invoca um sinal e espera que o comportamento destino termine.
________seta a cheio
- Assíncrona – alternativa à simples, numa sequência procedimental ___________meia seta
- Retorno – retorno de uma invocação de método <----------------
Num fluxo de controlo procedimental a seta retorno deve ser evitada pois é implícito. O valor de
retorno (caso exista) é ilustrado na seta inicial.
Num fluxo de controlo não procedimental (ex. mensagens assíncronas e processamento paralelo)
o retorno deve ser explicitado.
Num sistema concorrente a simples representa passar o fluxo para outra actividade (semântica
bloqueante), enquanto a assíncrona representa o envio de mensagem sem bloqueio.

7.2.4. Tipos de Mensagens

- Call – Invoca uma operação de um objecto (+ comum, comunicação síncrona)
- Return – Devolve resultado para objecto “chamador”
- Send – Envia sinal (assíncrona)
- Create – cria objecto
- Destroy

7.3. Diagramas de Interacção

Uma interacção é representada por um diagrama de interacção. Pode usar-se para:
- especificar a realização de um caso de utilização
- operação envolvendo diversos objectos
Podem ser apresentados de 2 formas:
- Diagrama de Sequência – ênfase na ordenação temporal das mensagens trocadas
- Diagrama de Colaboração – ênfase na organização estrutural dos objectos que trocam...
Os 1ºs são mais usados para detalhar caso de utilização e mais adequados para:
- especificar situações complexas
- múltiplos e concorrentes fluxos de controlo
Os 2ºs são mais adequados para fluxos não concorrentes (sequenciais e procedimentais)
Uma colecção de restrições standard usam-se para representar criação e destruição de objectos
ou ligações durante determinada execução: {new} {destroy} {transient}
Podem introduzir-se várias descrições (ex. restrições temporais, acções). Devem ser colocadas na
margem esquerda ou direita ou junto às activações ou transições que representam.

7.3.1. Diagramas de Sequência

Ilustra uma interacção segundo uma visão temporal. Tem 2 dimensões: horizontal – objectos;
vertical – tempo.
A seta pode ser inclinada se o tempo de envio do estímulo não é negligenciável.

7.3.2. Diagramas de Colaboração

Ilustra interacção organizada espacialmente. Mostra as relações entre objectos que
desempenham diferentes papéis.
Como não mostra o tempo, a sequência de interacções e de actividades concorrentes é
representada usando-se números sequenciais.
Pode ser representado por 2 formas:
- Nível de especificação : ilustra os papéis que as classes e associações desempenham, bem
como as suas mensagens
- Nível de Instância : ilustra objectos, ligações e estímulos.
Ex. 7.1. Diagramas de Colaboração – Pessoa com Distintos Papéis (prof, alunos)

7.3.3. Há equivalência semântica entre os diagramas de sequência e de colaboração.

7.3.4. Diagramas de Interacção e de Casos de Utilização

No ex. 7.2 vimos uma das utilizações dos diagramas de interacção: modelar ao nível do desenho
uma ou um conjunto de interacções entre várias instâncias.
Outra das aplicações típicas é a especificação de um caso de utilização, como complemento À
linguagem natural. Ex. Máquina de bebidas.
O que interessa é identificar os objectos envolvidos e a sequência de acções.

7.4. Diagrama de Estados (statechart, diagrama de transição de estados, máquina de estados)

Permite modelar o comportamento interno de um determinado objecto, subsistema ou sistema
global.
Representam os possíveis estados de um objecto, as correspondentes transições de estados, os
eventos que fazem desencadear as transições, e as operações (acções e actividades) que são
executadas dentro dos estados ou nas transições. Os objectos evoluem ao longo do tempo
através de um conjunto de estados como resposta a eventos e à passagem de tempo.
Os estados são representados por rectângulos com os cantos arredondados, excepto o estado
inicial e final que têm ícones próprios. As transições representam-se por uma linha a cheio
dirigida. Pode ainda ser detalhado por uma secção com o nome e outra com as acções e
actividades realizadas.

7.4.1. Estados
É uma situação registada por um objecto durante o seu respectivo ciclo de vida, durante a qual
uma condição é verificada, vai executando alguma actividade, ou simplesmente espera que
determinado evento ocorra.
Um estado tem diferentes partes:
- Nome. Sem nome é anónimo
- Acções de Entrada e de Saída
- Transições Internas
- Sub-Estados (disjuntos, isto é, sequencialmente activos, ou concorrentes)
- Eventos Deferidos: não são tratados no estado corrente

7.4.2. Transições
É uma relação entre 2 estados que especifica que um objecto que se encontre no primeiro estado,
realizará um conjunto de acções e mudará para o segundo estado quando um determinado
evento ocorrer e determinadas condições se verificarem.
É descrita pela sintaxe:
evento [condição com guarda] / acção
Tem diferentes partes:
- O estado de origem e o estado de destino
- Evento de Gatilho
- Condição de Guarda: expressão lógica
- Acção
Podem existir transições sem gatilho, quando o estado origem termina a sua actividade
normalmente. Pode ter múltiplos estados de origem (concorrentes)

7.4.3. Eventos
É uma ocorrência de um estímulo que pode corresponder a uma transição de estado. Há 4 tipos:
- Sinais
- Invocação
- Passagem do tempo
- Mudança de estado
Um sinal representa um objecto com nome que é enviado (lançado) assincronamente por um
objecto e recebido (apanhado) por outro. Ex. mecanismo de excepções das linguagens.
Um evento de invocação corresponde ao lançamento de uma operação tipicamente de modo
síncrono.
A representação gráfica é igual mas o sinal é tratado pela própria máquina de estados e a
invocação por um método.
O evento passagem de tempo é assinalado no diagrama pela palavra after seguida de uma
expressão, embora possa não se explicitar.
O evento mudança de estado representa uma mudança de estado ou satisfação de determinada
condição e modeliza-se pela palavra-chave when seguida de expressão lógica.

7.4.4. Acções e Actividades

Uma acção é uma computação atómica (instantânea e não interrompível). Ex. invocação de
métodos, criação ou destruição de objectos, envio de sinal.
Podem especificar-se as acções de entrada prefixadas com entry e de saída com exit e ainda
relativas a eventos desencadeados e tratados dentro do estado (notação evento / acção)
Uma actividade é uma computação não atómica, isto é, que pode ser interrompida por outros
eventos, é complexa e eventualmente descrita por outro DE incluso. São os elementos básicos
dos diagramas de actividades. Quando fazem parte do DE são prefixadas com do.

7.4.5. Sub – Estados

É um conceito avançado dos DE e a ideia é a abstracção.
Um estado que tenha um conjunto de sub-estados mais detalhados é um estado composto.
Podem ser ortogonais (concorrentes) ou sequenciais (disjuntos).
Ex. Diagrama de estados de um PC.

7.5. Diagramas de Actividades

É um caso particular de um diagrama de estados, no qual todos ou a maioria dos estados são
estados de actividades e todas ou a maioria das transições são desencadeadas pela conclusão
das actividades dos estados anteriores.
Enquanto nos diagramas de interacção o foco é na visualização das mensagens trocadas entre os
objectos, nos diagramas de actividades a atenção incide na visualização das operações
realizadas pelos objectos intervenientes.
Correspondem aos Fluxogramas.
Contêm:
- Estados-Acção
- Estados-Actividade (a diferença é que podem ter partes adicionais)
- Transições
- Objectos

7.5.1. Decisões
A tomada de decisão é um mecanismo comum aos DE e DA que consiste em especificar que
actividade deve ser realizada após a execução da actividade corrente, dependendo de uma
condição de guarda.

7.5.2. Caminhos Concorrentes (e independentes)

Ex. Acordar – fork – Tomar pequeno almoço; Fazer higiene matinal; – Cumprimentar a família –
join. – barra de sincronização –

7.5.3. Pistas (Swimlanes)

Na modelação de processos de negócio é comum a realização de actividades por várias
entidades. O UML propõe o conceito de pistas para agrupar as várias actividades da
responsabilidade de cada entidade participante. Cada grupo é separado por uma linha vertical.
Cada pista corresponde a uma entidade do mundo real.
Cada actividade pertence a uma pista, apenas as transições cruzam as pistas. Nos casos em que
é realizada por mais que uma entidade faz-se linha separadora em comum.

7.5.4. Actividades e Objectos

Os DA podem explicitar relações entre actividades e objectos. Estas relações de dependência
permitem ilustrar o fluxo de um objecto ao longo de um conjunto de actividades, representadas
por linhas dirigidas a tracejado. Para além disso ilustra ainda os seus papéis, atributos e estado.
Ex: :Orçamento [aberto] [preparação] .....

7.5.5. Envio e Recepção de Sinais

O UML adopta o conceito de evento de envio (output event) e de recepção (input event). Permite
explicitar:
- Relações de dependência: seta dirigida a tracejado entre os eventos de envio e de recepção de
sinal) entre distintas máquinas ou distintos diagramas de actividades pela troca de eventos
assíncronos.
- Dentro da mesma máquina de estados, eventos que deverão ocorrer durante as respectivas
transições de esatdos/actividades.
Evento de emissão – polígono convexo.

7.5.6. Utilizações Típicas

Os DA são usados para modelar o sistema como um todo, um subsistema, uma operação ou de
uma classe. Também se pode associar a um caso de utilização ou colaboração.
No entanto são usados principalmente para:
- Especificar Operações: Fluxogramas de algoritmos --> tomada de decisão, fork, joint
- Especificar workflows ou processos de negócio: Identificação dos actores e correspondente
colaboração com o sistema --> pistas e modelação dos fluxos de objectos.
Ex. 7.5 DA da operação de Fibonacci; 7.6 Da da disseminação de eventos no WebDEI
CAP. 8 – UML – MODELAÇÃO DA ARQUITECTURA
8.1. Introdução
É a aparte mais limitada, mal explorada e compreendida do UML.
Os diagramas de arquitectura (ou de implementação) descrevem aspectos da fase de
implementação e instalação de um sistema de software, designadamente:
- Estrutura e dependências de código fonte e de módulos executáveis
- Respectiva instalação nas diferentes plataformas computacionais subjacentes.
Apresentam-se em 2 formas:
- Diagramas de Componentes
- Diagramas de Instalação
Os 1ºs são usados na perspectiva dos seus componentes digitais, explicitando principalmente as
suas múltiplas dependências.
Os 2ºs são usados na perspectiva dos seus componentes físicos, explicitando as suas
dependências de comunicação. Permitem ainda identificar quais são os componentes instalados
em cada nó computacional.

8.2. Componentes e Nós

Um componente é uma peça básica na implementação de um sistema. ex. ficheiros de código
(fonte, binário ou executável) ou ficheiros de documentos relativos ao negócio.
Há 3 tipos distintos:
- Componentes de Instalação: Base dos sistemas executáveis (DLL, executáveis, controlos
ActiveX, classes Java)
- Componentes de Trabalho: Ficheiros de código fonte, de dados, documentos. São a base dos de
instalação
- Componentes de Execução: criados como resultado da execução dum sistema (processos,
Threads, agentes de software)