Ave Coder!
Você teve uma ideia interessante do produto, mas não quer se prender ao código e perder toda a imagem devido a pequenos detalhes? Você está prestes a se sentar para o charlatão de um servidor corporativo e precisa encher algo bacana e de TI?
Esta série de artigos será dedicada a um conhecimento útil, mas às vezes esquivo, do crescimento jovem - diagramas UML. E vou começar com uma visão geral dos diagramas existentes, vamos falar um pouco sobre história e por que deveria haver tantos diagramas.
UML é a abreviação de Unified Modeling Language e, como sabemos, é uma linguagem de modelagem padronizada composta por um conjunto integrado de diagramas projetados para ajudar os desenvolvedores de sistemas e software a definir, visualizar, projetar e documentar artefatos de sistema de software e , por exemplo, para modelagem de negócios.
A UML é um conjunto de melhores práticas de engenharia que provaram ser eficazes na modelagem de sistemas grandes e complexos e é uma parte muito importante do desenvolvimento de software orientado a objetos.
A UML usa principalmente notação gráfica para expressar o design de projetos de software. O uso da UML ajuda as equipes de projeto a se comunicar, explorar projetos em potencial e validar o design da arquitetura do software.
A origem da UML
O objetivo da UML é fornecer uma notação padrão que possa ser usada por todos os métodos orientados a objetos, além de selecionar e integrar os melhores elementos das notações predecessoras. UML foi desenvolvido para uma ampla gama de aplicações. Consequentemente, fornece projetos para uma ampla gama de sistemas e atividades (por exemplo, sistemas distribuídos, análise, design e implantação de sistemas).
A UML não surgiu do zero, foi precedida por vários eventos significativos, personalidades e metodologias. Por exemplo:
- OMT [James Rumbaugh 1991], .
- Booch [Grady Booch 1994] — . - . , , , , .
- OOSE (- [Ivar Jacobson 1992]) — , — , , .
Em 1994, Jim Rambeau, para não ser confundido com John Rambo, embora Jim também tenha sido legal porque foi, por um momento, o criador da técnica de modelagem de objetos acima mencionada, surpreendeu o mundo do software quando deixou a General Electric e se juntou a Grady Booch na Rational Corp. O objetivo da parceria era combinar suas idéias em um único método unificado (o nome de trabalho do método era realmente - "O método unificado").
Em 1995, o criador do OOSE, Ivar Jacobson, também havia se juntado ao Rational, e suas idéias (em particular o conceito de "casos de uso") foram incorporadas a um novo método unificado, agora chamado de Unified Modeling Language.
Em contraste com o conhecido "Gang of Four", a equipe Rumbo, Butch e Jacobson é conhecida como "Three Amigos".
A UML também foi influenciada por outras notações orientadas a objetos:
- Mellor e Schlaer [1998]
- Coad e Yourdon [1995]
- Wirfs Brock [1990]
- Martin e Odell [1992]
A UML também inclui novos conceitos, que na época não estavam em outros métodos básicos, como mecanismos de extensão e restrições de linguagem.
Por que UML?
À medida que o valor estratégico do software aumentou para muitas empresas, o setor procurou métodos para automatizar a produção de software, além de melhorar a qualidade e reduzir custos e tempo de colocação no mercado.
Esses métodos incluem tecnologia de componentes, programação visual, padrões e estruturas.
As empresas também estão procurando métodos para gerenciar a complexidade dos sistemas à medida que crescem.
Em particular, eles reconhecem a necessidade de abordar problemas arquiteturais recorrentes, como distribuição física, concorrência, replicação, segurança, balanceamento de carga e tolerância a falhas.
Além disso, o desenvolvimento da Web, embora simplifique as coisas, geralmente agrava esses problemas arquitetônicos.
A UML (Unified Modeling Language) foi desenvolvida para atender a essas necessidades.
Os principais objetivos do design da UML são:
- Forneça aos usuários uma linguagem de modelagem visual expressiva e pronta para que eles possam desenvolver e compartilhar modelos significativos.
- Forneça mecanismos de extensibilidade e especialização para expandir os conceitos principais.
- Seja independente de linguagens de programação específicas e processos de desenvolvimento.
- Forneça uma estrutura formal para entender a linguagem de modelagem.
- Incentivar o crescimento do mercado de ferramentas orientadas a objetos.
- Suporte para conceitos de desenvolvimento de alto nível, como colaboração, estruturas, modelos e componentes.
- Integre as melhores práticas.
Os diagramas UML são classificados em dois tipos - diagramas de estrutura e diagramas de comportamento.
Os diagramas estruturais mostram a estrutura estática do sistema e suas partes em diferentes níveis de abstração e implementação, bem como seu relacionamento. Os elementos em um diagrama de estrutura representam conceitos significativos do sistema e podem incluir conceitos abstratos, do mundo real e de implementação. Existem sete tipos de diagramas de estrutura:
- Diagrama de estrutura composta
- Diagrama de implantação
- Diagrama do pacote
- Gráfico de perfil
- Diagrama de classe
- Diagrama de objeto
- Gráfico de componentes
Os diagramas de comportamento mostram o comportamento dinâmico dos objetos em um sistema, que pode ser descrito como uma série de alterações no sistema ao longo do tempo. Os diagramas de comportamento incluem:
- Gráfico de atividades
- Diagrama de casos de uso
- Diagrama de estado
- Diagrama de sequência
- Diagrama de comunicação
- Gráfico de visão geral da interação
- Diagrama de tempo
Agora, algumas palavras sobre cada um deles
Diagrama de classe
O diagrama de classes é uma técnica de modelagem central usada em quase todos os métodos orientados a objetos. Este diagrama descreve os tipos de objetos no sistema e os diferentes tipos de relacionamentos estáticos que existem entre eles.
Os três tipos mais importantes de relacionamento nos diagramas de classe (na verdade existem mais deles) são:
Associação, que representa o relacionamento entre instâncias dos tipos, por exemplo, uma pessoa trabalha para uma empresa, uma empresa tem vários escritórios.
Herança, que se aproxima da herança no Design Orientado a Objetos.
Agregação, que é uma forma de composição de objetos no design orientado a objetos.
Gráfico de componentes
Na linguagem de modelagem unificada, um diagrama de componentes mostra como os componentes se reúnem para formar componentes maiores ou sistemas de software.
Ilustra as arquiteturas dos componentes de software e as dependências entre eles.
Esses componentes de software incluem componentes de tempo de execução, componentes executáveis e componentes de código-fonte.
Diagrama de implantação
Um diagrama de implantação ajuda a simular o aspecto físico de um sistema de software orientado a objetos. Este é um diagrama de blocos que mostra a arquitetura do sistema como a implementação (distribuição) de artefatos de software.
Artefatos são elementos específicos no mundo físico que são o resultado de um processo de desenvolvimento.
O diagrama simula a configuração de tempo de execução em uma visualização estática e visualiza a distribuição de artefatos no aplicativo.
Na maioria dos casos, isso inclui modelar configurações de hardware junto com os componentes de software nos quais eles estão localizados.
Diagrama de objeto
Um diagrama de objeto estático é uma instância de um diagrama de classes; mostra uma captura instantânea do status detalhado do sistema em um momento específico. A diferença é que um diagrama de classes é um modelo abstrato de classes e seus relacionamentos.
No entanto, um diagrama de objetos é uma instância em um momento específico de natureza específica.O uso de diagramas de objetos é bastante limitado, ou seja, para mostrar exemplos de estrutura de dados.
Diagrama do pacote
Um diagrama de pacotes é um diagrama de blocos UML que mostra pacotes e dependências entre eles.
Ele permite exibir diferentes visualizações do sistema; por exemplo, é fácil modelar um aplicativo de várias camadas.
Diagrama de estrutura composta
O diagrama da estrutura composta é semelhante ao diagrama de classes e é um tipo de diagrama de componentes usado principalmente na modelagem do sistema no nível micro, mas descreve partes individuais em vez de classes inteiras. É um tipo de diagrama de estrutura estática que mostra a estrutura interna de uma classe e as interações que essa estrutura possibilita.
Esse diagrama pode incluir componentes internos, portas através das quais as partes se comunicam ou através das quais instâncias de classe interagem com partes e com o mundo externo e conectores entre partes ou portas. Uma estrutura composta é um conjunto de elementos interconectados que interagem em tempo de execução para atingir uma meta. Cada elemento tem um papel específico na colaboração.
Gráfico de perfil
O diagrama do perfil nos permite criar estereótipos específicos de domínio e plataforma e definir relacionamentos entre eles. Podemos criar estereótipos desenhando formas de estereótipos e vinculando-os à composição ou generalização por meio de uma interface orientada a recursos. Também podemos definir e visualizar o significado de estereótipos.
Diagrama de casos de uso
O diagrama de casos de uso descreve os requisitos funcionais do sistema em termos de casos de uso. Em essência, é um modelo da funcionalidade pretendida do sistema (casos de uso) e seu ambiente (atores).
Os casos de uso permitem vincular o que precisamos do sistema à forma como o sistema atende a essas necessidades.
Diagrama de atividades
Os diagramas de atividades são uma representação gráfica dos fluxos de trabalho de ações em fases e ações com suporte para seleção, iteração e simultaneidade.
Eles descrevem o fluxo de controle do sistema de destino, como explorar regras e operações de negócios complexas e descrever casos de uso e processos de negócios.
Na UML, os diagramas de atividades são projetados para modelar processos computacionais e organizacionais.
Diagrama de estado
Um diagrama de estados é um tipo de diagrama usado na UML para descrever o comportamento dos sistemas, baseado no conceito de diagramas de estados de David Harel. Os diagramas de estados mostram os estados e transições permitidos, bem como os eventos que afetam essas transições. Ele ajuda a visualizar todo o ciclo de vida dos objetos e, assim, ajuda a entender melhor os sistemas baseados em estado.
Diagrama de sequência
Um diagrama de sequência modela a interação de objetos com base em uma sequência de tempo. Ele mostra como alguns objetos interagem com outros em um caso de uso específico.
Diagrama de Comunicação
Como um diagrama de sequência, um diagrama de comunicação também é usado para modelar o comportamento dinâmico de um caso de uso. Comparado a um diagrama de sequência, o diagrama de comunicação é mais focado em mostrar a interação dos objetos em vez de uma sequência temporal. De fato, o diagrama de comunicação e o diagrama de sequência são semanticamente equivalentes e podem fluir um para o outro.
Gráfico de visão geral da interação
O diagrama de visão geral da interação enfoca uma visão geral do fluxo de gerenciamento de interação. Essa é uma variante do diagrama de atividades em que os nós são interações ou eventos de interação. Um diagrama de visão geral da interação descreve interações nas quais mensagens e linhas de vida estão ocultas. Podemos vincular diagramas "reais" e obter um alto grau de navegação entre diagramas em um diagrama de visão geral da interação.
Diagrama de tempo
O diagrama de tempo mostra o comportamento do (s) objeto (s) em um determinado período. De fato, esta é uma forma especial de um diagrama de seqüência e as diferenças entre eles são que os eixos são trocados para que o tempo aumente da esquerda para a direita e as linhas de vida sejam exibidas em compartimentos separados, localizados verticalmente.
Por que existem tantos diagramas na UML?
A razão para isso é que você pode olhar para o sistema de diferentes pontos de vista, porque muitas partes interessadas estarão envolvidas no desenvolvimento de software, como: analistas, designers, codificadores, testadores, controle de qualidade, clientes, autores técnicos.
Todas essas pessoas estão interessadas em diferentes aspectos do sistema e cada uma delas exige um nível de detalhe diferente.
Por exemplo, o codificador deve entender o design do sistema e poder convertê-lo em código de baixo nível.
Por outro lado, um escritor técnico está interessado no comportamento do sistema como um todo e deve entender como o produto funciona.
A UML está tentando fornecer a linguagem de maneira tão expressiva que todas as partes interessadas possam se beneficiar de pelo menos um diagrama UML.
Para quem tem preguiça de ler:
Ave!