O que é a Análise?
- Componente do processo de Desenvolvimento:
- Refinar e estruturar Requisitos;
- Formalização dos resultados da Engenharia de Requisitos, utilizando semântica e
formalismo próprios;
- Aproximar a descrição da realidade do processo de concepção;
- Primeira “Investida” no desenho da solução;
Complemento ao Desenvolvimento:
- A Engenharia de Requisitos permite conhecer mais da realidade do que os
elementos que são tidos em conta para a construção da solução;
- Análise como meio de capturar elementos complementares à solução;
Exemplos:
- Engenharia de Processos;
- Interfaces – Boundaries
Para Análise
• Modelo de Análise
Formalismo
Standards
Características da Análise
• Análise é precisa
• Análise é descritiva;
• Análise é intermediária;
• Análise é abrangente;
• Análise é multidisciplinar.
Modelos Comuns
• Event Process Chain (EPC)
• RUP/UML
• Total Quality Management e Fault Tree Analysis
• Audit Diagrams
• Data Flow Diagram (DFD)
• Specification and Description Language (SDL)
• Business Process Management (BPM)
• IDEF (ICAM Definition ou Integrated Definition)
• Fluxogramas
Modelos de Análise
Formalismo de RUP
Elementos próprios
Fronteira
– Indica os limites do problema e as fronteiras do sistema
– Permite definir os pontos de contacto e interacção do sistema com o exterior
Controlo
– Mecanismos de Decisão
– Representação de procedimentos e/ou cálculos complexos
- Indica funcionalidades do sistema, mas sem especificação concreta de mecanismo
Exemplos de uso (Case Study 1):
Bussiness Logic Derivação de Valores Processo de
Negócio
Entidade
– Elementos com carácter duradouro
– Representação de arquivo persistente de dados
– Eventos/acções simples, sem mecanismo de controlo
– Identifica objectos, sem indicação de atributos ou operações
Exemplo:
Modelo de Análise:
Vantagens:
• Representa todos os elementos de análise
• Bom ponto intermédio entre „stakeholders’ e construção
• Independente de plataforma
• Grau de abrangência elevado
• Representação clara de interfaces
• Permite compreender modelo estático e dinâmico do sistema
• Facilidade de automação
Desvantagens:
• Representação de processos incompleta
• Decisão
• Repetição
• Sequência linear rígida
• Risco de se tornar extenso e complexo
• Aumento do detalhe aproxima o modelo de OOP
‘Requirement Traceability’ correcta implica número elevado de diagramas
Modelo de Análise:
Todas as necessidades dos stakeholders são válidas mas podem não ser aplicáveis.
Muitos requisitos podem significar choque com requisitos já identificados ou
diminuição de rentabilidade da aplicação.
2 Visões:
1. Participação como fase autónoma do PDS, com o objectivo de refinar e estruturar
requisitos – formalização, o que não significa avaliar requisitos na Engenharia de
Requisitos (informais), mas viabilidade para a aplicação e para o contexto.
2. O Modelo de Análise é uma linguagem tão formal quanto uma linguagem corrente.
… muito mais rígida e formal que qualquer linguagem falada. Tem de obedecer à
sintaxe da linguagem formal. Aproxima a descrição da realidade do processo de
concepção.
O Modelo de Análise elimina ambiguidades, logo não pode introduzir nada de novo,
nem alterar o significado dos requisitos.
… a primeira entrada no desenho da solução (fase técnica).
O UML não pode representar tudo o que é externo ao sistema. Surge então a
Engenharia de Processos, como complemento para identificar os elementos externos.
A Análise tem muito menos informação que a Engenharia de Requisitos porque o que
não é necessário deixa de fazer parte.
Modelo de Análise: tem um ponto de entrada e vários pontos de saída. Não pode ter
pontos de paragem senão não é consistente.
UML é:
- independente do domínio de aplicação;
- independente do processo de desenvolvimento;
- independente das ferramentas de modelação.
Elementos Básicos:
- Classe e Classe Activa;
- Interface;
- Nó;
- Caso de Utilização (Use Case) e Colaboração;
- Actor;
- Componente.
Relações standard:
- Associação;
- Realização;
- Transição de Estado;
- Dependência;
- Generalização.
Tipos de Diagramas
- Diagramas de Casos de Uso (Use Cases);
- Diagramas de Classes e de Objectos;
- Diagramas de Comportamento:
- Estados;
- Actividades;
- Interacção: Sequências e Colaboração;
- Diagramas de Arquitectura:
- Diagramas de Componentes;
- Diagramas de Instalação.
Mecanismos Comuns:
Pacotes
- elemento organizacional;
- agrega diferentes elementos de um sistema de forma coerente, quer a nível da
semântica, quer a nível de estrutura;
- útil principalmente na modelação de médios/grandes sistemas.
Use Cases
Características:
Definição: “Sequência de acções que um mais actores realizam num sistema de
modo a obterem um resultado particular.”
Nota: A frase/expressão do Use Case é sempre escrita na voz activa com um
verbo no infinitivo.
Requisito
- Especificação de uma determinada acção ou condição que o sistema deve
satisfazer.
- Requisito Funcional: acção do sistema; ex.: consulta de catálogo de serviços…
- Requisito não Funcional: aspecto geral do sistema; ex.: desempenho, fiabilidade…
Cenário
- Sequência de acções em texto que ilustram um comportamento do sistema.
- Descrição estruturada que pode incluir pré e/ou pós condições.
Relações
- Generalização;
- Inclusão – Includes ou Uses: são as pré-condições;
- Extensão - Extends;
Modelação de Estrutura
Introdução
- Consiste na identificação de classes e suas respectivas relações.
- Uma classe consiste numa estrutura que permite criar objectos semelhantes –
apresentam estado e comportamento semelhantes.
- Um objecto é uma entidade do mundo real e apresenta um estado e
comportamento próprios.
- Os objectos inter-actuam entre si por troca de mensagens.
Uma classe é uma fábrica de objectos e que um objecto é uma instância de uma
classe.
Classe
- descrição de um conjunto de objectos que partilham os mesmos atributos,
operações, relações e a mesma semântica.
- Uma classe corresponde a algo tangível ou a uma abstracção conceptual existente
no domínio do utilizador ou no domínio do engenheiro de software.
- é simples e facilmente entendida;
- providencia uma abstracção definida a partir do vocabulário do domínio do
problema ou do domínio da solução;
- agrega um conjunto restrito e bem definido de responsabilidades;
- e providencia uma separação clara entre a especificação abstracta e a sua
implementação.
Classe
Tem três “partes”:
- nome;
- atributos;
- Métodos ou operações.
Relações:
• Dependências;
• Generalizações;
• Associações.
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.
Associação
- relação estrutural que especifica que objectos de uma classe estão ligados a
objectos de outra.
Agregação
- traduz apenas o facto de uma classe ser composta por diferentes outras classes,
suas componentes.
Interfaces: especificações de métodos
- dão a conhecer um determinado elemento, escondendo os seus detalhes internos;
- é realizada (ou implementada) por uma ou mais classes, as quais prometem
implementar todos os métodos nela especificados.
Diagramas de Classes
Usados quando:
- Queremos modelar o vocabulário de um sistema;
- Queremos modelar colaborações simples;
- Queremos modelar o desenho de um esquema de uma base de dados.
Diagramas de Objectos
Ilustra um conjunto de objectos e respectivas relações num determinado momento.
Características
- Permite captar uma imagem ou fotografia momentânea sobre determinado sistema;
- … um grafo composto por objectos e ligações (links) entre eles;
- Não pode especificar completamente a estrutura de objectos de um dado sistema,
já que para cada classe ou conjunto de classes relacionadas, há uma infinidade de
potenciais combinações entre as suas instâncias.
Diagrama de Use Cases
Os Use Case (cenários de utilização) são utilizados para representar o
comportamento desejado de um sistema (requisitos), independentemente da forma
como o sistema vai ser implementado.
Permitem ter uma visão geral das funcionalidades (serviços) do sistema e da forma
como ele interactua com os Actores (clientes).
São frequentemente utilizados como uma primeira abordagem à modelação de um
sistema.
Um Use Case é uma descrição de uma sequência de acções que o sistema executa
por forma a satisfazer os objectivos de um actor. Essa descrição pode ser informal ou
formal.
Nos diagramas apenas se indica o nome do Use Case. Cada Use Case deverá ter um
nome distinto que facilmente o associe às acções efectuadas pelo sistema.
Actores
Um Actor representa a função que uma pessoa, um programa informático ou um
equipamento desempenha no sistema.
Os Actores estão associados aos Use Cases que eles utilizam. Um diagrama de Use
Cases é uma descrição do comportamento do sistema na perspectiva do utilizador.
Nível de Detalhe
Os diagramas de Use Case podem ser utilizados apenas para indicar as principais
funcionalidades do sistema e delimitar a fronteira (utilizadores externos). Neste
cenário não é comum representar actores internos.
Complementarmente, os Use Case podem na sua descrição conter um conjunto mais
ou menos exaustivo de requisitos funcionais descritos, por exemplo, através de
linguagem estruturada (condições, ciclos, sequência, etc.). Neste cenário, é habitual
contemplar-se um conjunto mais vasto de use cases nos diagramas, assim como
actores internos ao sistema.
Include é relação de dependência entre dois Use Cases normalmente utilizada
quando existem Use Cases que são partilhados (incluídos / usados) por mais que um
Use Case. Também é designada por Use.
Um Use Case pode ser accionado sem a intervenção de nenhum actor (e.g., eventos
temporais).
• Perspectiva Algorítmica
◊ elementos base são procedimentos ou funções
◊ foco nas estruturas de controlo e na decomposição top-down
◊ difícil contemplar alterações aos requisitos e crescimento do sistema
Ênfase da UML
• "We build models so that we can better understand the system we are developing."
◊ permite ver o sistema tal como ele é, ou como pretendemos que ele seja
◊ constitui um guião, a seguir na construção do sistema
◊ documenta as decisões que se tomam
• Classe (Class)
◊ descrição de um conjunto de objectos que,
⋅ partilham os mesmos atributos, operações, relações e semântica
◊ implementa uma ou mais interfaces
◊ normalmente apresentado como um rectângulo, que inclui,
⋅ nome, atributos e operações
◊ a apresentação gráfica depende do estereótipo escolhido ...
⋅ o estereótipo estende o vocabulário da UML
⋅ permite ter blocos específicos, adequados a determinadas situações
Conceitos de Estrutura – Interface
• Interface (Interface)
◊ colecção de operações que especificam um serviço de,
⋅ uma classe ou componente
⋅ tipicamente apenas uma parte limitada do seu comportamento
◊ define especificações de operações (assinaturas)
⋅ nunca a implementação dessas operações
◊ normalmente apresentada por um circulo, que inclui, o seu nome
⋅ é um estereótipo de classe
◊ raramente aparece sozinha
⋅ normalmente está ligada à classe ou componente que a concretiza
• Colaboração (Collaboration)
◊ "sociedade" de elementos que "trabalham" em conjunto para,
⋅ fornecer comportamento superior ao da soma dos seus elementos
⋅ inclui estrutura e comportamento
⋅ uma mesma classe pode participar em diversas colaborações
◊ as colaborações representam a concretização
⋅ dos "padrões" que constituem o sistema
◊ normalmente apresentada por elipse tracejada, apenas com o seu nome
◊ é usual aparecer como realização de
⋅ casos de utilização ou operações
Conceitos de Estrutura – Nó
• Nó (Node)
◊ elemento físico que existe em tempo de execução
⋅ recurso computacional com alguma memória
⋅ e possivelmente com capacidade de processamento
◊ um conjunto de componentes pode,
⋅ residir num nó; migrar de um nó para outro
◊ existem diferenças importantes entre nó e componente
⋅ componente participa na execução de um sistema
⋅ nó executa componentes
⋅ componente representa um "pacote" físico de conceitos lógicos
⋅ nó representa a implantação (deployment) física de componentes
◊ normalmente apresentado por cubo com nome
Relações
Relações – Dependência
• Dependência (Dependency)
◊ relação semântica de utilização (using) entre dois conceitos
⋅ a alteração de um Conceito (o independente) pode afectar
⋅ a semântica do outro Conceito (o dependente)
⋅ mas o inverso não é necessariamente verdade
◊ muitas vezes, no contexto de uma classe é usada para mostrar que,
⋅ a classe usa outra como argumento na assinatura de uma operação
⋅ a operação pode ser afectada por uma alteração na classe usada
⋅ ... se passar a exibir outro comportamento ou interface
◊ normalmente apresentada por uma linha tracejada, orientada
⋅ para o sentido do conceito de que se depende
Relações – Associação
• Associação (Association)
◊ relação estrutural que descreve
⋅ um "conjunto de ligações" (set of links)
⋅ onde cada ligação (link) "é um tuplo" de vários objectos
◊ tendo uma associação, é possível navegar entre os objectos,
⋅ que são instâncias das classes participantes nessa associação
◊ pode-se estabelecer uma associação,
⋅ de uma classe para ela mesma
⋅ entre duas classes (associação binária)
⋅ entre mais que duas classes (associação n-ária)
◊ normalmente apresentada por uma linha ligando as classes participantes
⋅ podendo ter – multiplicidade, nome, papel
• Agregação (Aggregation)
◊ uma associação entre duas classes, representa uma relação estrutural
⋅ entre pares – entre elementos que estão ao mesmo nível conceptual
◊ numa relação "todo/parte" (whole/part)
⋅ uma classe representa "algo maior" – o todo
⋅ que é composta por "constituintes mais pequenos" – as partes
◊ uma Agregação é uma relação "todo/parte", também designada por has
◊ normalmente apresentada por um losango perto do "todo"
⋅ contorno – partes têm uma existência própria (has by reference)
⋅ cheio – partes só existem no contexto do todo (has by value)
Relações – Generalização
• Generalização (Generalization)
◊ relação estrutural entre
⋅ um conceito geral – super-classe ou classe-pai
⋅ e uma "espécie" mais específica desse conceito – classe filho
◊ os objectos da classe filho
⋅ podem ocorrer em qualquer local onde ocorra a classe pai
⋅ o filho pode substituir o pai – o inverso não é verdade ...
◊ o filho herda as propriedades (atributos e operações) dos pais
⋅ e o filho pode adicionar propriedades que só são suas
◊ uma operação de um filho com a mesma assinatura que a do pai
⋅ sobrepõe (overrides) a operação do pai – polimorfismo
◊ normalmente apresentada por uma linha orientada,
⋅ com uma seta apontando o pai
• Classe Abstracta
◊ não tem instâncias
◊ é base para definição de
⋅ operações e
⋅ estado
⋅ ... a herdar por subclasses
Relações – Realização
• Realização (Realization)
◊ ligação semântica do género "estabelecimento de contrato"
◊ contrato entre dois Conceitos
⋅ um "define" serviços
⋅ outro "garante" levar a cabo os serviços especificados
◊ semanticamente a Realização está "a meio caminho" entre
⋅ a Dependência e a Generalização
⋅ ... depende da definição dos serviços; é uma concretização particular
◊ é usual usar-se em dois contextos
⋅ interface – operações / serviços de classes ou componentes
⋅ colaboração – relação entre um use case e a sua concretização
◊ normalmente apresentada por uma linha tracejada, orientada
⋅ para o sentido do conceito que se pretende "garantir"
• Interface e Classe
◊ Interface tem semelhanças com Classe Virtual
⋅ nenhuma pode ter instâncias directas
◊ Interface é diferente de Classe Virtual (CV)
⋅ Interface não pode ter atributos (estado); CV pode
⋅ Interface delimita fronteiras do modelo; CV é Abstracção de topo
◊ a mesma Interface pode ser realizada por diferentes
⋅ Classes (Abstracção lógica); Componentes (Abstracção física)
• Implementação e Objecto
◊ implementação → comportamento + estado (de cada Objecto)
determina ...
• Interface
◊ apresenta um contrato
◊ define um serviço
◊ declara um tipo
• Implementação
◊ realiza o contrato
◊ concretiza o serviço
◊ implementa o tipo
Conceitos de Comportamento
• Interacção (Interaction)
◊ num contexto particular e para atingir determinado objectivo, inclui,
⋅ o conjunto de mensagens trocadas entre objectos nesse contexto
◊ especifica o comportamento
⋅ de uma "sociedade" de objectos, ou
⋅ de uma operação individual
◊ uma interacção envolve outros elementos,
⋅ mensagens
⋅ sequência de acções – fluxo desencadeado pela mensagem
⋅ associações (links) – ligações entre objectos
◊ uma mensagem é normalmente apresentada por uma linha direccionada
⋅ etiquetada com o seu nome
Conceitos de Agrupamento
Conceitos de Anotação
Diagramas
• boundary – "... should be related to at least one actor and vice versa"
◊ usado para modelar a interacção entre o sistema e os seus actores
◊ interacção envolve, normalmente,
⋅ recepção e apresentação de informação a actores
⋅ atender e efectuar pedidos a actores
◊ não precisa ser específico de um único use case
◊ é usual ser criado e destruído no contexto de determinado use case
⋅ podendo, ao longo da vida, participar em diversos use case
"... boundary classes need not describe how the interaction is physically realized,
since this is considered in subsquent design and implementation activities."
• Representam normalmente,
◊ a estrutura lógica dos dados
◊ contribui para identificar a informação da qual o sistema depende
"... an entity object need not be passive and may sometimes have complex
behaviour related to the information it represents."
"... control classes are also used to represent complex derivations and calculations,
such as business logic, that cannot be related to any specific, long-lived information
stored by the system."
Diagrama de Objectos
Diagramas de Interacção – Sequência e Colaboração
• Um Diagrama de Estados
◊ pode caracterizar o ciclo de vida, das instâncias de,
⋅ uma classe
⋅ um caso de utilização (para modelar os seus cenários)
⋅ todo um sistema / subsistema
Actividade
• Pode representar a execução de,
◊ uma tarefa dentro de um fluxo de trabalho (workfow)
◊ uma directiva dentro de um procedimento (statement in a procedure)
• Uma Actividade é idêntica a um Estado, mas expressa a intenção,
◊ da não existência de ênfase na espera pela ocorrência de eventos
• Ligações Actividade-Actividade e Actividade-Objecto
◊ Actividade-Actividade
⋅ através de transições (tal como com os Estados)
◊ Actividade-Objecto
⋅ através de um "fluxo de objecto" (object flow)
Exemplo:
Numa empresa existe um departamento – televenda, responsável pela venda de
produtos via telefone.
Toda a informação necessária à venda é registada durante o telefonema do cliente.
Em seguida o televenda coloca uma ordem de compra e transmite-a a um dos
armazéns da empresa.
No armazém a ordem de compra é analisada e os produtos embalados. Em seguida o
armazém envia os produtos ao cliente.
O armazém indica ao televenda que os produtos já seguiram. Nesse momento, o
televenda emite uma factura e envia-a ao cliente.