A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro."— Transcrição da apresentação:

1 Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro

2 Classes A fase de an á lise est á preocupada com as primeiras abstra ç ões (classes e objetos) e mecanismos que estarão presentes no dom í nio do problema. As classes são modeladas e ligadas atrav é s de relacionamentos com outras classes, e são descritas no Diagrama de Classe. As colabora ç ões entre classes tamb é m são mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colabora ç ões são criadas atrav é s de modelos dinâmicos em UML. Na an á lise, s ó serão modeladas classes que perten ç am ao dom í nio principal do problema do software, ou seja, classes t é cnicas que vão gerir bases de dados, interface, comunica ç ão, concorrência e outros não estarão presentes neste diagrama.

3 Classes Uma classe é a descri ç ão de um tipo de objecto. Todos os objectos são instâncias de classes, pelo que a classe tem de descrever as propriedades e comportamentos daquele objecto. Usam-se classes para classificar os objectos que identificamos no mundo real. Por exemplo Charles Darwin, usou classes para classificar os animais conhecidos e combinou suas classes por heran ç a para descrever a "Teoria da Evolu ç ão". Uma classe pode ser a descri ç ão de um objecto em qualquer tipo de sistema – sistemas de informa ç ão, t é cnicos, integrados real-time, distribu í dos, software etc. Num sistema de software, por exemplo, existem classes que representam entidades de software num sistema operacional como ficheiros, programas execut á veis, janelas, etc. Identificar as classes de um sistema pode ser complicado, devendo ser feito por analistas capazes de entender o problema que se est á a analisar. As classes devem ser retiradas do dom í nio do problema e serem nomeadas pelo que elas representam no sistema.

4 Classes Quando procuramos definir as classes de um sistema, existem algumas questões que podem ajudar a identific á -las: –Existem informa ç ões que devem ser armazenadas ou analisadas? Se existir alguma informa ç ão que tenha que ser guardada, transformada ou analisada de alguma forma, então é uma poss í vel candidata para ser uma classe. –Existem sistemas externos ao modelado? Se existir, eles deverão ser vistos como classes pelo sistema para que possa interagir com outros externos. –Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo sistema modelado? Se sim, normalmente essas classes, componentes e modelos conterão classes candidatas ao nosso sistema. –Qual o papel dos actores dentro do sistema? Talvez o papel deles possa ser visto como classes, por exemplo, utilizador, operador, cliente etc. Em UML as classes são representadas por um retângulo dividido em três compartimentos: –o compartimento de nome, que conter á apenas o nome da classe modelada, –o de atributos, que possuir á a rela ç ão de atributos que a classe possui em sua estrutura interna, e –o de opera ç ões, que conter á os m é todos de manipula ç ão de dados e de comunica ç ão de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem de programa ç ão, embora possam ser usadas outras sintaxes como a do C++, Java, etc.

5 Objectos Um objecto é um elemento que podemos manipular, acompanhar, criar, destruir etc. Um objecto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por exemplo, uma m á quina, uma organiza ç ão ou neg ó cio. Existem objectos que não encontramos no mundo real, mas que podem ser vistos como deriva ç ões de estudos da estrutura e comportamento de outros objectos do mundo real. Em UML um objecto é apresentado como uma classe s ó que o seu nome é sublinhado e o nome do objecto pode ser apresentado precedido do nome da classe (opcional).

6 Relacionamentos entre classes Os relacionamentos ligam as classes/objectos entre si, criando rela ç ões l ó gicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: – Associa ç ão: É uma conexão entre classes e tamb é m significa que é uma conexão entre objetos daquelas classes. Em UML, uma associa ç ão é definida com um relacionamento que descreve uma s é rie de liga ç ões, onde a liga ç ão é definida como a semântica entre as duplas de objetos ligados. – Generaliza ç ão : É um relacionamento de um elemento mais geral e outro mais espec í fico. O elemento mais espec í fico pode conter apenas informa ç ões adicionais. Uma instância (um objecto é uma instância de uma classe) do elemento mais espec í fico pode ser usada onde o elemento mais geral seja permitido. – Dependência e Refinamentos : Dependência é um relacionamento entre elementos, um independente e outro dependente. Uma modifica ç ão é um elemento independente afectar á diretamente elementos dependentes do anterior. Refinamento é um relacionamento entre duas descri ç ões de uma mesma entidade, mas em n í veis diferentes de abstra ç ão.

7 Relacionamento entre classes Uma associa ç ão representa que duas classes possuem uma liga ç ão (link) entre elas, significando por exemplo que elas se conhecem", "estão ligadas com", "para cada X existe um Y" e tc. Classes e associa ç ões são muito poderosas quando modeladas em sistemas complexos. Associação Normal

8 Relacionamento entre Classes Associação Recursiva Associação Qualificada Associação Exclusiva Um contrato refere-se a uma pessoa ou empresa; nunca às duas Ver outras Associações na Apostilha de UML

9 Diagrama de Classes O diagrama de classes mostra a estrutura est á tica das classes de um sistema onde estas representam as "coisas" que são geridas pela aplica ç ão modelada. Classes podem estar relacionadas com outras de diversas maneiras: –associa ç ão (ligadas entre si), –dependência (uma classe depende ou usa outra classe), –especializa ç ão (uma classe é uma especializa ç ão de outra classe), ou em –pacotes (classes agrupadas por caracter í sticas similares). Todos estes relacionamentos são apresentados no diagrama de classes juntamente com as suas estruturas internas, que são os atributos e opera ç ões. O diagrama de classes é considerado est á tico j á que a estrutura descrita é sempre v á lida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, j á que nem todas as classes que estão inseridas em um ú nico diagrama e uma determinada classes pode participar de v á rios diagramas de classes. Uma classe num diagrama pode ser implementada directamentecaso se utilize uma linguagem de programa ç ão orientada a objectos, que tenha suporte directo para constru ç ão de classes. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas e relacionadas entre si.

10 Diagrama de Classes

11 Diagrama de Sequência Um diagrama de sequência mostra a colabora ç ão dinâmica entre os v á rios objectos de um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a sequência de mensagens enviadas entre os objectos. O diagrama de sequência consiste num n ú mero de objectos apresentado em linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima para baixo.. Diagramas de sequência possuem dois eixos: –o eixo vertical, que mostra o tempo e –o eixo horizontal, que mostra os objectos envolvidos na sequência de uma certa actividade. O diagrama de sequência mostra tamb é m as intera ç ões para um cen á rio espec í fico asssociado a uma certa actividade do sistema. A comunica ç ão entre os objectos é representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objectos. A seta especifica se a mensagem é s í ncrona, ass í ncrona ou simples. As mensagens podem possuir tamb é m n ú meros sequenciais, eles são utilizados para tornar mais expl í cito as sequência no diagrama. Em alguns sistemas, objectos rodam concorrentemente, cada um com sua linha de execu ç ão (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como activa ç ão, mensagens ass í ncronas, ou objetos ass í ncronos.

12 Diagrama de Sequência

13 Diagrama de Colabora ç ão Um diagrama de colabora ç ão mostra de maneira semelhante ao diagrama de sequência, a colabora ç ão dinâmica entre os objectos. Normalmente pode-se escolher entre utilizar o diagrama de colabora ç ão ou o diagrama de sequência. No diagrama de colabora ç ão, al é m de mostrar a troca de mensagens entre os objetos, percebe-se tamb é m os relacionamentos entre objetos. A intera ç ão de mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de sequência, mas se a ênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colabora ç ão. O diagrama de colabora ç ão é desenhado como um diagrama de objecto, onde os diversos objectos são mostrados juntamente com seus relacionamentos. As setas de mensagens são desenhadas entre os objectos para mostrar o fluxo de mensagens entre eles. As mensagens são nomeadas, pois mostram a ordem em que as mensagens são enviadas. Podem mostrar tamb é m condi ç ões, interac ç ões, valores de resposta, etc. O diagrama de colabora ç ão tamb é m pode conter objetos activos, que funcionam em paralelo.

14 Diagrama de Colabora ç ão

15 U2 Partners –www.u2-partners.orgwww.u2-partners.org OMG UML Resources –www.uml.orgwww.uml.org UML Forum –www.uml-forum.comwww.uml-forum.com –Contains links to the UML Revision Task Force and UML 2.0 Working Group webs as well as other UML resources. UML Models and Methods column –www.telelogic.com/publications/uml_models/www.telelogic.com/publications/uml_models/ Referências


Carregar ppt "Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro."

Apresentações semelhantes


Anúncios Google