Apontamentos Uml & Modelo De Analise

MODELO DE ANÁLISE 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 Porque não Engenharia de Requisitos? Por definição de Engenharia de Requisitos e de Análise: - Requisitos devem ser especificados utilizando a linguagem dos ‘stakeholders’ - O uso de linguagem formal limita a abrangência da descrição - O uso de semântica formal depende dos conhecimentos dos interlocutores Contra-senso nas Definições: - Limitação de abrangência com a Análise: - O objectivo de compreensibilidade é da Engenharia de Requisitos, não da Análise… - A perda de abrangência é compensada pelo refinamento da descrição - Há sempre perdas de representatividade, o que não há são soluções perfeitas… Limitação de abrangência com a Análise: - “Transmissão” de Resultados: - Abstracção retira abrangência. - A perda de abrangência depende da qualidade da análise! - A diferença de abordagem é minimizada por ‘Requirement Traceability’ Porquê não Desenho ou Concepção? Por definição de Análise e Concepção: - Análise tem, ainda, função descritiva: - Refinamento dos resultados da Engenharia de Requisitos - Mais valias resultam do formalismo - A concepção define a Solução - Determina COMO o problema vai ser resolvido; - Aborda questões de ordem técnica, para alem das necessidades dos ‘stakeholders’

Independência de Desenho e Construção: - Permitir o início do Desenho e Concepção antes de Análise integral do problema em estudo - Agilizar a descrição do problema, facilitar comunicação - Facilitar a manutenção da solução (Traceability) - Integração de ambiente de desenvolvimento heterogéneos - Facilitar desenvolvimento multidisciplinar e/ou de elevada complexidade

Ferramentas e Utensílios Para Engenharia de Requisitos: • Diagrama de Use Case Para Análise • Modelo de Análise Para Ligação a Desenho • Todos os modelos de desenho derivam da Análise… Principais modelos de derivação directa: • Diagrama de Actividades • Diagrama de Classes • Diagrama de Colaboração Formalismo Standards Características da Análise • Análise é precisa • Análise é descritiva; • Análise é intermediária; • Análise é abrangente; • Análise é multidisciplinar. Que Formalismo Utilizar? Dificuldade de Uniformização • Análise como componente autónoma do processo de desenvolvimento; • Dependência perante metodologia de desenvolvimento • Abrangência da linguagem/formalismo Não há standards para Análise!... • Cada área de interesse tem os seus próprios modelos; • O mesmo modelo poderá usar vários formalismos; • A análise é realizada fora do âmbito do desenvolvimento Que elementos incluir num modelo Análise? Mecanismos de selecção e controlo; • Entidades (para não falar já de objectos…) • Controlo de fluxo • Limite do problema; • Interfaces com exterior (…fronteira do sistema); • Utilizadores/Clientes (incluindo maquinas!); 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

Elementos Complementares (UML: Colaboração)

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 Exemplos de uso (Case Study 1): Interface de Utilizador Access Component

Ligação a Sistema Externo

Data

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 Negócio

Derivação de Valores

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:

Processo de

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: - 2ª fase do Processo de Desenvolvimento de Software (RUP) - a 1ª fase é a Engenharia de Requisitos - O modelo de análise tem como função formalizar os resultados da Engenharia de Requisitos - Os objectivos da Engenharia de Requisitos são: Validar a descrição dos requisitos e as necessidades/objectivos dos stakeholders, conseguindo o acordo de todos os participantes; Identificar o problema de modo a ser validado pelos stakeholders; Descrição em termos que o stakeholder entenda (abdica-se da componente técnica) – aqui surge a necessidade de formalizar a linguagem e entra-se na fase de análise.

A Análise tem um peso reduzido porque a única aplicação da Análise é formalizar a Engenharia de Requisitos. Ou seja, retirar ambiguidades da linguagem natural e formalizar a Engenharia de Requisitos numa linguagem semanticamente clara, precisa e que não deixe dúvidas aos stakeholders. Surge da necessidade de proceder à validação de requisitos. Engenharia de Software (fase da Análise até aos Testes)

Engenharia de Requisitos (gestão de empresa)

A partir da selecção do Modelo de Análise e seu direccionamento para o Software, entra-se na Engenharia de Software. O pico da Análise antecede o pico da Engenharia de Requisitos – quando se passa de uma definição informal para uma definição formal, implica que já haja uma concepção prévia de conceitos para permitir essa formalização. Definir os termos e seu significado em cada contexto. 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. Momento em que se pode começar a Análise: conhecimento vasto do contexto em que se vai trabalhar Validação (≠ fim Engenharia de Requisitos) formalizar a parte da gestão. O que é o Modelo de Análise? • Necessidade de Validação • Primeiro ponto de entrada da fase técnica Passagem de uma descrição informal para regras próprias de modelo e formalizar em contexto, utilizando uma semântica própria. 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). A Análise é descritiva e formal ao contrário da Engenharia de Requisitos onde a descrição é feita na linguagem do stakeholder. A Análise é uma componente do PDS, sendo um complemento ao Desenvolvimento. Permite obter muito mais informação sobre aquilo que realmente vão ser as funcionalidades da aplicação, sendo um meio de capturar elementos complementares à solução.

Conclusão: O único objectivo do Modelo de Análise é traduzir para linguagem formal a Engenharia de Requisitos. Tem como única razão de existir a validação de requisitos. As competências são definidas por quem entende do negócio (não técnicos). A validação é feita numa linguagem acessível aos stakeholders (Engenharia de Requisitos). A Análise vai estruturar os requisitos em função do tipo de projecto que vai ser desenvolvido. A semântica tem de ser formal, clara e precisa para ser programada. Não é código. … uma estruturação de raciocínio descritiva, usando uma linguagem próxima da utilizada para o projecto. A linguagem é formal, como tal rígida e estruturada, obedecendo à sintaxe. Os requisitos do software e os requisitos de todo o contexto de uso têm de responder às necessidades dos stakeholders. A Análise apenas modela os requisitos que são necessários para a Engenharia de Software. Decide também que o tipo de projecto (condicionar o processo). O processo não é condicionado pela Engenharia de Requisitos, é condicionado pelo Modelo de Análise. 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. O stakeholder tem de perceber do negócio. A Análise tem de perceber da área técnica. 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 –Unified Modeling Language … uma linguagem para: - especificação; - construção; - visualização; - e documentação de um SI. 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. - Diagramas de Casos de Uso - Representam a visão do sistema na perspectiva do utilizador. - Diagramas de Classes - Permitem especificar a estrutura estática de um sistema de forma orientada a objectos. - Diagramas de Comportamento - Permitem especificar o comportamento de um sistema de forma orientada a objectos. -Diagramas de Arquitectura - Dão a visão da disposição dos componentes físicos de um sistema. Mecanismos Comuns: - Anotações - ilustram um comentário sem ter qualquer valor semântico; • Localização: devem ser colocadas perto dos elementos a que dizem respeito; • Visibilidade: dependendo da ferramenta podem ser visíveis e/ou invisíveis; • Extensão: devem usar referências – nomes, URL’s, …; • Evolução: devem permanecer no desenho enquanto “fazem falta”. - Extensões - adicionam entendimento ao desenho. • Devem existir em nº equilibrado; • Estereótipos e marcas devem ter nomes curtos; • Usar sempre que possível texto livre nas Restrições. Estereótipos • “tipo” que descreve outro; • Nome entre “«” e “ª“; Marcas • Metadata – descreve dados; • Adiciona propriedades aos elementos; Restrições • Permitem acrescentar ou alterar semântica; • Especificação de uma condição.

Tipos de Dados - Abstracção utilizada de forma implícita na UML; -Ex: • -Primitivos: Integer, String, Time; • -Enumerados: Boolean; • -Outros: Name, Multiplicity. 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… Diagramas de Use Cases - permitem a representação de requisitos funcionais; - suportados sempre na visão do utilizador; - facilitam: - Comunicação: utilizador - fornecedor; - Gestão do projecto. Diagramas de Use Cases - Apresentação: oval; - Organização: graficamente visíveis; - Detalhe: depende do projecto, do cliente, do sistema a especificar, etc.

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.

Os atributos podem ser: + => Públicos: qualquer classe tem acesso;

- => Privados: só a própria classe tem acesso; # => Protegidos: qualquer descendente tem acesso. 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.

Generalização => herança nas Classes - relação entre um elemento geral (e.g., superclasse, super-casoutilização, superpacote) e um elemento mais específico (e.g., subclasse, sub-caso-utilização, subpacote).

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. Benefícios para a programação: - Captura de semelhanças entre classes não relacionadas sem forçar a criação de relações artificiais entre elas; - Declaração de métodos que uma ou mais classes esperam implementar; - Revelar a interface de programação de um objecto sem revelar a sua classe. Relações com classes e componentes - Generalização; - Associação; - Dependência; - Realização. Instâncias e/ou Objectos Definição – 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. Definição Instância – 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. Definição Objecto – instância de uma classe, herdando, por conseguinte, 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. Diagramas de Classes Ilustra um conjunto de classes, interfaces, colaborações e respectivas relações, em geral de dependência, generalização e de associação. 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. Exemplos de Use Cases relativos a um sistema de gestão de uma biblioteca:

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. Na sequência de acções necessária para o processamento de uma requisição (e devolução) de uma publicação, é necessário incluir o Use Case Validar Stock.

Extend é relação de dependência entre dois Use Cases normalmente utilizada quando existem situações alternativas (Cenários) ou excepções. Na sequência de acções necessária para o processamento de uma devolução de uma publicação, pode ocorrer a aplicação de uma sanção (entrega fora do prazo).

Utilização da relação Extend para representar opções alternativas de um Menu.

Um Use Case não pode relacionar-se com outro Use Case.

Usualmente todos os Use Case estão associados a pelo menos dois actores (cliente / fornecedor do serviço). Um Use Case pode ser accionado sem a intervenção de nenhum actor (e.g., eventos temporais). A descrição do Use Case pode ser efectuada através de um texto descritivo, de um Diagrama de Sequência, de um Diagrama de Actividades ou através de pseudocódigo.

Modelação Orientada a Objectos No software existem actualmente duas perspectivas essenciais ◊ Algorítmica ◊ Orientação por Objectos – O.O. • 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 • Perspectiva da Orientação por Objectos ◊ elementos base são classes e objectos ◊ tem provado ser adequada em variados domínios de problema e diferentes níveis de dimensão e complexidade ◊ actualmente grande parte das linguagens, sistemas operativos e ferramentas promovem uma "visão do mundo orientada a objectos" ◊ ... UML existe para especificar, construir e documentar sistemas O.O. ! Ênfase da UML • Definição de uma linguagem de modelação standard ◊ independente das linguagens de programação ◊ independente das ferramentas CASE ◊ independente dos processos de desenvolvimento • O processo de desenvolvimento pode depender ◊ do tipo de projecto ◊ da ferramenta de suporte ◊ da organização e know-how das equipas de projecto • ... mas a mesma linguagem de modelação é sempre a mesma ◊ UML • Actualmente assiste-se à adopção generalizada da UML ◊ como "a" linguagem de modelação de software na abordagem da O.O. ◊ ... artigos, relatórios, ferramentas CASE, etc – industrialização da UML ! ◊ "The primary product of a development team is not beautiful documents, worldclass meetings, great slogans, or Pulitzer prize-winning lines of source code. Rather, it is good software that satisfies the evolving needs of its users and the business. Everything else is secondary." • ... mas secundário não se pode confundir com irrelevante ! ◊ cumprir prazos, qualidade duradoura, desenvolvimento efectivo, ... ◊ implica pessoas certas, foco correcto, ferramentas adequadas, ... • Modelos – peças centrais a todas as actividades de desenvolvimento ◊ fornecem base para partilha de ideias sobre estrutura e comportamento ◊ permitem visualizar e controlar a arquitectura ◊ realçam oportunidades de simplificação e reutilização ◊ ... modelos servem para compreender o sistema, controlar e gerir o risco

A importância dos modelos

• "A model is a simplification of reality." ◊ um bom modelo omite elementos não relevantes para o nível de abstracção que pretende exibir ◊ ... pode referir a estrutura – ênfase na organização do sistema ◊ ... pode referir o comportamento – ênfase na dinâmica do sistema • "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 • "We build models of complex systems because we cannot comprehend such a system in its entirety." ◊ permite uma abordagem do tipo "divide-and-conquer" ◊ amplify human intellect – permite pensar a nível de abstracção mais alto A model is a complete description of a system from a particular perspective. UML – blocos base de construção O vocabulário da UML tem 3 espécies de Blocos Base ◊ Conceitos (Things) ◊ Relações (Relationships) ◊ Diagramas (Diagrams) O que são esses Blocos Base? ◊ ... os Conceitos são os "cidadãos de primeira" num modelo ◊ ... as Relações "ligam" os Conceitos ◊ ... os Diagramas juntam "colecções de Conceitos" interessantes! O vocabulário da UML tem 4 espécies de Conceitos (Things) ◊ de Estrutura (Structural) ◊ de Comportamento (Behavioral) ◊ de Agrupamento (Grouping) ◊ de Anotação (Annotational) • O estudo da UML vai prosseguir do seguinte modo: ◊ 1) Conceitos de Estrutura ◊ 2) Relações ◊ 3) Conceitos de Comportamento ◊ 4) Conceitos de Agrupamento e Anotação ◊ 5) Diagramas

Conceitos de Estrutura • São os elementos "mais estáticos" dos modelos UML ◊ "nomes próprios" / "substantivos" do modelo ◊ representam elementos lógicos (conceptuais) ou físicos • Existem 7 espécies de "Conceitos de Estrutura" ◊ os primeiros 4 são ⋅ Classe (Class) ⋅ Interface (Interface) – um "molde particular" / estereótipo de classe ⋅ Caso de Utilização (Use Case) ⋅ Colaboração (Collaboration) – um estereótipo de caso de utilização ◊ os últimos 3 representam aspectos particulares do conceito de classe ⋅ Classe Activa (Active Class) ⋅ Componente (Component) estes 2 representam conceitos ⋅ Nó (Node) físicos ... todos os anteriores eram Conceitos de Estrutura – Classe • 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

Conceitos de Estrutura – Caso de Utilização • Caso de Utilização (Use Case) ◊ conjunto de sequências de acções que o sistema efectua ⋅ oferece um resultado observável, de valor para um actor específico ⋅ usado para estruturar os conceitos de comportamento do sistema ⋅ é concretizado pelo conceito de colaboração ◊ normalmente apresentado por uma elipse, apenas com o seu nome ◊ aparecem ligados ao(s) actor(es) ⋅ que dele tiram partido ⋅ ou de quem depende

Conceitos de Estrutura – Colaboração • 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 – Classe Activa • Classe Activa (Active Class) ◊ classe cujos objectos detém um ou mais processos ou threads ⋅ processo – fluxo "pesado" (heavyweight) de execução que pode ocorrer em simultâneo com outros processos ⋅ thread – fluxo "leve" (lightweight) de execução que pode ocorrer em simultâneo com outras threads, no contexto do mesmo processo ◊ classe que representa um fluxo de controlo independente ⋅ comportamento dos objectos pode ser concorrente com o de outros ◊ as "outras classes" (as não activas) são passivas, ou seja, ⋅ não podem, de forma independente, iniciar actividade de controlo ◊ normalmente apresentado por um rectângulo de traço mais forte e inclui, ⋅ nome, atributos e operações

Conceitos de Estrutura – Componente

• Componente (Component) ◊ elemento físico e que pode ser substituído ⋅ está em conformidade e realiza um conjunto de interfaces ◊ representa o "empacotamento" físico de elementos lógicos, tais como, ⋅ classes, interfaces e colaborações ◊ num sistema podem existir diferentes componentes ⋅ Java Beans, Corba, COM, ... ⋅ ficheiros de código (são artefactos do processo de desenvolvimento) ◊ normalmente apresentado por rectângulo com alças, e inclui o seu nome

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 • Existem 4 espécies de "Relações" ◊ Dependência (Dependency) ◊ Associação (Association) ⋅ Qualificação (Qualification) – um adorno (adornment) importante ⋅ Agregação (Aggregation) – "um outro tipo de Associação" ◊ Generalização (Generalization) ◊ Realização (Realization) • Estas Relações são, ◊ as formas base de relacionar Conceitos • Estas Relações utilizam-se,

◊ para construir Diagramas "bem–formados", ou seja, ⋅ construídos de acordo com as regras da linguagem 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

Relações – Associação / Qualificação (um adorno) • Qualificação (Qualification) como adorno de uma Associação ◊ um problema muito comum das associações é o de, ⋅ ... partindo de um objecto num lado de uma associação, ⋅ identificar o objecto (ou conjunto de objectos) que, ⋅ do outro lado da associação a ele estão ligados ... ◊ exemplo – "um gato pode ser sempre vadio, ou ter ao longo da sua vida, diversos donos, assim como um dono pode ter diversos gatos ... mas cada gato, em determinado data, ou tem um dono ou nenhum !"

⋅ ⋅ ⋅ ⋅ ⋅

"data" não é atributo de nenhuma classe participante na associação ou seja, "data" é um atributo da associação um atributo da associação representa-se como uma qualificação ... qualificação pode "reduzir" a multiplicidade da associação ... objecto qualificado + valor do qualificador → objecto do outro lado

Relações – Associação / Agregação (outro tipo) • 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

Relações – Generalização (cont.)

• Generalização implica Herança de "pai para filho" ◊ de estrutura e comportamento • Herança Simples e Múltipla ◊ Simples – conceito com um única classe-pai ◊ Múltipla – conceito com mais que uma classe-pai • Classe Abstracta ◊ não tem instâncias ◊ é base para definição de ⋅ operações e ⋅ estado ⋅ ... a herdar por subclasses • Se pelo menos uma operação é abstracta ◊ a Classe é também Abstracta

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"

Mecanismos Comuns – "divisão do mundo" • Na modelação Orientada por Objectos é usual "dividir o mundo" em ◊ Interface / Implementação ◊ Classe / Objecto • 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 • São a parte "dinâmica" dos modelos UML ◊ "acções" / "verbos" do modelo ◊ representam comportamento ao longo do tempo e espaço • Existem 2 espécies de "conceitos de comportamento" ◊ Interacção (Interaction) ⋅ ênfase na ordem temporal das mensagens ⋅ ênfase na descrição do modo como as mensagens fluem, no contexto de determinada organização estrutural entre Objectos ⋅ ... Diagramas de Interacção – Sequência e Colaboração ◊ Máquina de Estados (State Machine) ⋅ ênfase na descrição do ciclo de vida de um Objecto – que pode ser uma instância de classe, um caso de utilização ou todo o sistema

⋅ ... Diagramas de Transição de Estados Conceitos de Comportamento – Interacção • 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 Comportamento – Máquina de Estados • Máquina de Estados (State Machine) ◊ especifica a sequência de estados que um Objecto ou uma Interacção ⋅ percorre em resposta a eventos, ⋅ durante a sua vida ◊ o comportamento de uma Classe ou Interacção de Classes ⋅ pode ser especificado por uma Máquina de Estados ◊ uma Máquina de Estados envolve outros elementos, ⋅ estado ⋅ transições – fluxos entre estados ⋅ eventos – elementos que desencadeiam (trigger) uma transição ⋅ actividades – respostas a uma transição ◊ um estado é normalmente apresentado por um ⋅ rectângulo arredondado ⋅ etiquetada com o seu nome Conceitos de Agrupamento • Elemento organizacional, designado por pacote – package ◊ permite agrupar diferentes elementos que, façam sentido na perspectiva, ⋅ semântica ou estrutural ◊ um package pode conter ⋅ classes, interfaces, casos de utilização, ... e mesmo outros pacotes ◊ um elemento está definido num único package ◊ algumas das vantagens na sua utilização são, ⋅ facilitar gestão e procura de artefactos ⋅ evitar conflitos de nomes – X::A é diferente de X::Y::A e de Z::A ⋅ oferecer mecanismo de controlo de acessos (visibilidade) Conceitos de Anotação • Anotações ou Notas são os "adornos autónomos" mais importantes ◊ autónomos – podem existir não associados a qualquer outro elemento ⋅ outro exemplo de "adorno" – Qualificação é adorno de Associação

◊ são comentários (textos e/ou gráficos) usados para, ⋅ descrever, realçar, ilustrar ... algum elemento do modelo ◊ o seu conteúdo não altera o significado do modelo em que encontra ◊ é normal utilizar Anotações para descrever informalmente, ⋅ algum detalhe dos requisitos; observações; revisões; explicações; ... ⋅ restrições adicionais a impor ao modelo ◊ algumas considerações na utilização de Anotações, ⋅ localização – graficamente perto dos elementos que descrevem ⋅ evolução – as mais antigas devem ser eliminadas (modelo evolui) ⋅ extensão – referir outros documentos para comentários extensos

Diagramas • Cada Diagrama é uma Vista de um Modelo ◊ apresenta a perspectiva de algum dos intervenientes no sistema ◊ constitui uma representação parcial do sistema ◊ é semanticamente consistente com as restantes Vistas Na UML existem 9 espécies de Diagramas ◊ Casos de Utilização (Use Case) Vistas dos Modelos ◊ Classes (Class) de Estrutura ◊ Objectos (Object) (Static Views) ◊ Componentes (Component) ◊ Implantação (Deployment) ◊ ◊ ◊ ◊

Sequência (Sequence) Colaboração (Collaboration) Transição de Estados (Statechart) Actividade (Activity)

Vistas dos Modelos de Comportamento (Dynamic Views)

Diagramas de Casos de Utilização • Capturam a funcionalidade do sistema ◊ na perspectiva dos seus utilizadores • São construídos ◊ nas fases inicias do processo de desenvolvimento • Têm como objectivo ◊ especificar o contexto do sistema ◊ capturar os requisitos do sistema ◊ elaborar uma arquitectura para o sistema ◊ orientar a implementação e gerar casos de teste • São desenvolvidos por ◊ analistas (analysts) e ◊ peritos do domínio / negócio (domain experts) Modelo de Casos de Utilização – Diagrama • Considere um sistema ATM (Automatic Teller Machine) – multibanco ◊ "O cliente do banco utiliza o ATM para levantar e depositar dinheiro das suas conta e para efectuar transferências entre diferentes contas"

Diagramas de Classes • Capturam o vocabulário do sistema ◊ usando a terminologia dos seus utilizadores ◊ usando as convenções e técnicas dos analistas • São construídos e refinados ◊ nas diversas fases do processo de desenvolvimento • Têm como objectivo ◊ concretizar com nomes e modelos, os conceitos no sistema ◊ especificar as colaborações (partindo dos Casos de Utilização) ◊ especificar esquemas lógicos de bases de dados • São desenvolvidos por ◊ analistas (analysts) ◊ analistas / especialistas em desenho (designers) ◊ programadores (implementers) • A construção de Diagramas de Casos de Utilização ◊ é um modo intuitivo e sistemático de capturar requisitos funcionais ◊ ... com ênfase no "valor acrescentado" aos seus utilizadores / clientes • ... do Diagrama de Casos de Utilização, para o de Classes fazer, ◊ olhar para um use case de cada vez ⋅ ler cada um dos seus cenários ◊ criar uma sua realização – use case realization ⋅ eventualmente uma já anteriormente definida ⋅ ... esta realização faz a ligação com à fase de análise ... ◊ identificar, no use case realization, classes de cada um de 3 estereótipos ⋅ boundary – a fronteira do sistema com os actores ⋅ entity – a representação do que é persistente no use case ⋅ control – a perspectiva de análise do use case • 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 • Representam normalmente abstracções de, ◊ janelas, formulários, terminais, sensores, interfaces de comunicação, ... ◊ e APIs – Application Programming Interface (eventualmente não O. O.) "... boundary classes need not describe how the interaction is physically realized, since this is considered in subsquent design and implementation activities." • entity – "... isolate changes to the information they represent" ◊ usado para modelar informação persistente (com longa vida ...) ◊ estado e comportamento de algum fenómeno ou conceito como, ⋅ um indivíduo ⋅ um objecto do mundo real ⋅ um evento do mundo real ◊ é usual ter uma vida longa e participar em diversos use case ⋅ normalmente "sobrevivem" à terminação do use case • 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 – "... dynamics of the system are modeled by control classes" ◊ usado para, estabelecer canais de comunicação entre objectos ⋅ p.e. construindo os links entre eles, ◊ coordenar actividades; construir sequências de acções, ◊ definir os mecanismos de transacção; controlar os outros objectos ◊ usado para encapsular o controlo de um use case específico ◊ é usual ser criado ao iniciar o use case; ser destruído quando ele acaba ⋅ excepções: o control participar em mais que um use case; diversos participarem num mesmo use case; o use case não precisar dele • Normalmente usado para modelar a dinâmica do sistema, ◊ coordenando as acções principais e controlando o controlo de fluxo ◊ e delegando trabalho nos outros objectos (boundary e entity) "... 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." Modelo de Análise – Diagrama de Classes

Use Case Model

Diagrama de Objectos

Diagramas de Interacção – Sequência e Colaboração • Capturam a comportamento dinâmico do sistema ◊ Sequência ⋅ ênfase na ordem temporal das mensagens (time oriented) ◊ Colaboração ⋅ ênfase nas ligações entre objectos (message oriented) • Sequência – têm como objectivo ◊ modelar o fluxo de controlo ◊ ilustrar os cenários (os dos Casos de Utilização) e outros típicos • Colaboração – têm como objectivo ◊ modelar o fluxo de controlo ◊ ilustrar o modo como acontece a coordenação entre objectos

Modelo de Análise – Diagrama de Sequência

Modelo de Análise – Diagrama de Colaboração

Modelo de Análise versus Modelo de Desenho • Modelo de Análise (Analysis Model) ◊ descreve o sistema quanto à sua função ⋅ O que é oferecido a cada utilizador ? ◊ constrói uma percepção detalhada dos requisitos • Modelo de Desenho (Design Model) ◊ descreve o sistema quanto à sua forma ⋅ Quais os blocos e qual a sua interacção? ◊ tem como input o Modelo de Análise ◊ visa aprofundar aspectos não funcionais e restrições ⋅ linguagens de programação; sistemas operativos; tecnologias de suporte à concorrência e distribuição; tecnologias de bases de dados; gestão de transacções; interfaces pessoa-máquina; ◊ visa definir uma forma (arquitectura) que contemple, ⋅ os aspectos funcionais ⋅ os aspectos não funcionais e restrições

Diagramas de Estados • Os Diagramas de Estados, tal como os Diagramas de Interacção ◊ capturam a comportamento dinâmico do sistema • Os Diagramas de Interacção, usam-se para modelar ◊ uma sociedade de objectos que opera em conjunto • Os Diagramas de Estados, usam-se para modelar ◊ a evolução de um objecto individual, através de um conjunto de estados, ◊ como resposta a eventos e à passagem do tempo • 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 • Um Diagrama de Estados, representa, ◊ os possíveis estados de um objecto ◊ as correspondentes transições entre estados ◊ os eventos que fazem desencadear as transições ◊ as operações (acções e actividades) ⋅ executadas dentro de um estado ⋅ ou durante uma transição

Diagrama de Estados / Actividades • Comum usar Diagrama de Estados para modelar objectos reactivos ◊ model the discrete stages of an object's lifetime – state centric • Comum usar Diagrama de Actividades para modelar ◊ fluxos de trabalho ou operações ◊ ... de modo idêntico ao dos flowchart (fluxograma) ◊ model the sequence of activities in a process – activity centric • Comum Diagrama de Actividades modelar comportamento de ◊ uma operação (método), de uma classe ◊ um caso de utilização (a sequência de actividades dos seus cenários) ◊ todo o fluxo de um qualquer processo de negócio (workflow) • Diagrama de Actividades é idêntico ao de Estados, no entanto, ◊ maioria dos Estados são Actividades ◊ maioria das transições são disparadas pela conclusão da actividade 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) • ... uma definição de workflow – fluxo de trabalho ◊ ... a well-defined sequence of activities that produces an observable value or objective to an individual or entity when performed ◊ por Rational Software Corporation • Objectivos da modelação de um workflow ◊ compreender a estrutura e dinâmica de uma organização

◊ garantir que clientes, utilizadores e implementadores têm um entendimento comum da organização ◊ derivar os requisitos dos sistemas que suportam a organização ◊ ... cada use case pode também ser visto como um workflow • In business and in other industries, ◊ there are many manual and automated systems ◊ ... each of these systems contains one or more workflows • Quando um Diagrama de Actividades especifica um workflow devem-se encontrar nele respostas às seguintes questões, ◊ que actividades são necessárias para se atingir o objectivo ? ⋅ apenas contemplar as actividades mais importantes para o workflow ⋅ ... não é necessário indicar todas as actividades ou estados ◊ que actividades criam ou modificam objectos ? ⋅ as actividades e objectos podem ser ligados por object flows ⋅ ... o objecto pode ainda ter a indicação sobre o estado em que está ◊ em que momento cada actividade ou estado ocorre ? ⋅ a colocação de cada actividade no diagrama, dá essa indicação ◊ quem tem responsabilidade no workflow ? ⋅ o diagrama de actividade pode pertencer a um use case ou classe ◊ quem é responsável por executar as diversas actividades ou estados ? ⋅ definir cada actividade numa pista (swimlane) ⋅ ... cada pista é responsável pelas actividades que contem 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.