Solutions Produits
Modeling: UML, BPMN, EA
Comprehensive System Modeling
Methodological Support
SOA SolutionA
SOA Architecture
Entreprise Architecture (EA)
Business Process Modeling
Goals, Dictionnary, Business Rules
Requirements
UML Analysis and Design
Document Generation
MDA - Model Driven Architecture
Code Generation: Java, C#, C++
Teamwork
Packaging
UML Modeler
Scope Manager
SOA Solution (EA, BPMN, SOA)
SysML
Document Publisher
TeamWork
MDA Modeler
Java Developer
C# Developer
C++ Developer
SQL Designer
Fortran Developer
Free Add Ons
Modelio Modeler
Services and Assistance
Consulting and Training
Diagrams supported
Products brochures
White papers
Objecteering tutorials
Modelling Practical Guides
Objecteering 6 Enterprise Edition
Objecteering UML Free Edition
Objecteering SOA Free Edition
Patches & Service Packs
Free Add-ons
Objecteering Software
Contact-us
References
Customers
Partners
Events
Accueil
Home Solutions Products Services & Support Ressources Downloads About us Home
Objecteering empowers UML2 – Examples
Présentation
Diagramme de classe
Diagramme de Use Case
Diagramme de d'objets
Diagramme de communication
Diagramme de déploiement
Diagramme de d'activité
Diagramme de séquence
Diagramme
Diagramme d'état
Diagramme de BPMN
Diagramme de profils
Diagramme d'objectifs
Diagramme d'exigences
Diagramme de dictionnaire
Class diagrams
Class diagrams are the most commonly used diagrams in UML: they represent the notions of a system (or supported by a system), along with their properties and inter-relations.
From a high level (conceptual) perspective, classes represent the concepts supported by a system, while from a low level (physical) perspective they can represent the classes implemented by an object language. The Figure shows a conceptual view of Human society. This is a typical use of class diagrams. Here we see classes, generalizations, associations and an operation. In addition, we see constraints attached to some model elements.
This more complete example shows the conceptual model of a travel agency. We recommend that attributes be typed by primitive classes (any class can be designated as being primitive) or by “data types”. Data types and enumerations are also represented in this diagram. Properties typed by complex classes must be modeled via associations
This figure presents a class diagram more oriented to “design” aspects. It could produce equivalent Java code for example. We see the notions of interface, operations with a signature, thrown exceptions.
Here, we see components, ports, parts and required and provided interfaces. From these specifications at the “typing” level, detailed models presenting the assembly of instances (parts) in a “container” class context, can be constructed.
This model expresses that in order to build a Video session, we need to connect (assemble) a PC to a video projector through a “VGA” port, and to connect these elements (parts) using a connector. This construction is called the “internal structure” of a class.
This diagram shows an SOA architecture using service components that are interconnected through services. The Objecteering EA profile is used here to extend UML for SOA. The use of internal class structure, component assembly and component modeling has greatly increased with the rise in SOA architecture based information system development.
The figure shows some complex cases with nary associations and qualifiers on associations. This adds precision to associations for more accurate models.
In this example of a package diagram, we see that a package can be developed to show its contents, which will probably consist not only of classes but also of a wide variety of elements such as processes (activities), actors, packages, interactions, etc.
In UML2, a class can have many types of property. In the example, we see that there is a zone dedicated to attributes within a class, another zone dedicated to operations, another to parts, and yet another dedicated to embedded elements, such as classes, actors, activities, interactions, etc. and all sort of authorized elements such as actors, activities, interactions, etc.
précedente
suivante
Copyright © 2009 Objecteering Software : Modeling