Archimate uses a specific set of symbols and notations: Archimate Notation summary
The relationships notations are based heavily on UML. Just not sure about the Core Motivation, Strategy, Implementation and Migration Elements. Where did these come from? Were they designed especially for Archimate? Or derived from another modelling standard?
ArchiMate is a language having its notation like UML is a language with its notations. ArchiMate visibly reuse notations from UML, UML is older than ArchiMate.
As you can see on http://pubs.opengroup.org/architecture/archimate3-doc/toc.html there is a reference to UML and other standards :
Appendix D, Relationship to Other Standards (Informative), describes the relationships of the ArchiMate language to other standards, including the TOGAF framework, BPMN, UML, and BMM.
D Relationship to Other Standards (Informative)
Concerning UML :
D.3 The UML Standard
The ArchiMate language has derived a number of concepts from UML [8]. For other concepts, straightforward correspondences can be defined.
In the Business Layer, the ArchiMate business process concept can be mapped onto UML activity diagrams, where more detailed specifications of such processes can be given (although BPMN would be the preferred language for detailed process and workflow modeling). The ArchiMate business actor and role concepts can both be mapped onto UML actors, although the latter can also be used for modeling automated actors. Business collaborations have been inspired by collaborations as defined in the UML standard [8], although the UML collaborations apply to components in the Application Layer.
In the Application Layer, the application component element corresponds to the UML component. This facilitates the direct linkage between higher-level Enterprise Architecture models described in ArchiMate notation and lower-level solution architecture and implementation models in UML in one continuous development chain. In a less direct manner, the ArchiMate application function concept can be mapped onto UML activity diagrams, and an application service to a use-case diagram. Application collaborations also correspond to UML collaborations.
Many of the elements of the ArchiMate Technology Layer correspond directly to UML. The node, artifact, device, system software, and path elements have a direct counterpart in UML (where system software is called execution environment).
In addition to these elements, many relationships in the ArchiMate language have close ties to UML as well. The ArchiMate association, composition, aggregation, specialization, and realization relationships have a direct counterpart in UML.
There are also some notable differences between the two languages. The ArchiMate serving relationship (formerly used by) is different from UML dependency. Although their notations are similar, their directions are different. UML dependency is often used to model, for example, function calls in software programs, but in ArchiMate notation, the direction of the serving relationship denotes the direction of service delivery, independent of whether this service is called by the user or offered pro-actively by the provider. At the architectural level at which the ArchiMate language is aimed, the run-time operational details of such call graphs is less important than the more stable and generic notion of service provision.
This also points to another important difference: UML does not have a separate service concept, since in its object-oriented paradigm the behavior expressed by a service is encapsulated within the interface offering that behavior (i.e., its operations). The ArchiMate language differentiates between interfaces and the services they provide to allow, for example, specifying that the same service is offered through multiple interfaces. Hence, an ArchiMate application interface does not equate directly with a UML interface.
Finally, UML has a predefined, fixed set of diagram types, whereas the ArchiMate viewpoint mechanism allows for the construction of custom, stakeholder-oriented views on an architecture.
Related
This question already exists:
Which diagrams, ie languages, notations can be used in addition to UML class diagrams to describe the structure of the system? [closed]
Closed 9 months ago.
What other languages or notations can be used to describe the structure of the system in addition to the classic UML class diagram?
The structure of a system can be expressed in many flavors. For example:
UML class diagram. That‘s the microscope: you can show the most detailed level if you wan to.
UML component diagram. That‘s the magnifying glasses: you can show higher level of interchangeable components.
UML composite structure. That‘s the surgical view: you open up components to show the classes and parts which are inside.
UML deployment diagram. It shows how components are materialized in artefacts (executables, libraries, configuration files) and distributed on processing nodes.
C4 model diagrams. These allow to show the high level structure of a system in a light, simple an intuitive manner (mostly nested boxes), at the level of the context (system in its environment), the container (main platforms/servers/…) and the component level. It‘s simple, intuitive but less precise than UML, and this is why C4 relies on UML for lower levels that are more detailed (e.g. UML class diagrams).
There are many others, but UML is the convergence of many of these modeling techniques and covers the full spectrum of the structure.
Note that I didn‘t on purpose quote:
ERD diagrams as these are not meant for modeling the full structure of a system, but only of domain information.
Archimate which is another very rich language that has several features to describe system structure at a higher level, for architectural purpose, but is not suited for implementation level.
Suppose I draw an UML class diagram representing the class and interface structure of my project. Are there any methods to assess the UML design before actually creating those classes and interfaces?
Example: It is known that the diagram below will lead to diamond problem. And must be changed or handled.
UML is a powerful design language. It is programming language independent (although it has a bias towards class based languages) and thus allows to design things that are not implementable in some languages but trivial in some other languages.
The real question is what you expect from assessment:
syntactic and semantic validity of the model with regard to its compliance with the UML specifications? In your diagram, you use void type, which does not belong to the primitive types of UML. It's a language dependent type.
completeness and accuracy of the model, with an eye on potential ambiguities and missing informations? In your diagram, Animal.eats() may for example be {abstract}. But is the absence of this information an indication that it's not abstract ?
evaluation of the class design, such as for example its complexity, the deepness of the inheritance, the intensity of relations, mutual dependencies, etc... ? But how can this help to spot a bad design, when some domains are just inheriently complex ?
feasibility? UML allows for multiple inheritance, but does not precisely define the semantics behind it. For instance, in C++ you can very well cope with this design with the virtual inheritance of Animal. In Java, multiple inheritance is forbidden and this would not be implementable as such (you would need to alter this model to introduce an interface and use interface realization). Now here, we will not reopen the debate about MI.
A systematic review of of diagrams is done here everyday. The goal of such assessment is to see if the notation is consistent with the UML specification, and eventually with the constraints of the chosen UML profile. There are some research papers that explore the automation of such consistency assessments.
Design is currently not highly automated; There is therefore no systematic method to assess the design as far as I know.
There are some general metrics (e.g. CK metrics) and some of these can be calculated for UML class diagrams (e.g. only 3 out of 6 CK metrics for example). Metrics are not assessments, but they can help an analyst in this task.
I am new to UML. I have studied more tutorials.I learned two broad categories like,
UML Diagrams:
1. Structural Diagrams
Class diagram
Object diagram
Component diagram
Deployment diagram
2. Behavioral Diagrams
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
But I dont know which one is high level design and low design. Anyone list out the UML diagram types based on priorities. (high-level diagrams to low level)
There is not really a well-defined order of higher-level versus lower-level diagram languages in UML. The same diagram language (e.g. class diagrams) can be used at different levels of abstraction. For instance, a conceptual information model, but also a Java data model, can be expressed as a class diagram.
Generally, a use case diagram is higher-level, since it describes requirements, while a deployment diagram is lower-level, since it describes system deployment structures.
But all other diagrams languages can be used at different levels of abstraction.
UML diagrams - from the most common to most detailed level.
Please, notice, that nowadays (the start of 2014) there are no special instrument for UI modelling. So, I'll explain how to do this part of work, too, with the tools we have. But they will be used in a less or more nonstandard way.
Human level. Use case diagrams and state machines. How people will work with the system.
Use cases are about what the system does, who works with it and maybe, grouping of those subjects. Subsystems can be defined here. Try not to show much structure or behaviour. Not to use any IT slang!
State machines show what states the system, subsystems and actors can have and what actions/events can happen in these states and to which other states can it lead. Not to use any IT slang!
Do not forget, that administrators, programmers and testers are users of the system, too. So, plan not only how the system helps to the work of the common user and his senior, but also to the installation/administration/testing/support processes. Don't forget to continue this work on all deeper diagraming levels. These use cases/state machines needn't be so human-oriented.
You can draw activities, sequence, timing diagrams for some dialogues between Actors and subsystems, if they are the part of the requirements. Or make them the part of requirements if they are important. Not to use any IT slang!
Draw the sketches for the UI and talk over them with client. The work on UI art design should be connected to UI planning and realization
Start to work on User Guide - create plan and structure. (I use class diagrams for that).
Deployment and component diagrams. Here you are starting to imagine the inner construction of your system
Components - What compact parts it has. It needn't have much in common with the subsystems, as user see them. Only some components are visible to the user. You could decide on the use of some interfaces between them. Think on the license problems of the third-party components.
Deployment - how the components could be distributed among PCs. The same question about interfaces, but more from the physical side.
A special deployment diagram for license politics of your product could be drawn, too. You can use other diagrams for it, as well. It is at your choice.
You could already plan your user interface by these diagrams, too. In MVC (model-viewer-controller) construction only the components of the controller level are mutually connected and obviously need this level modelling. But the viewer layer (UI) components are connected in a conceptual way, they should be, for the sake of user. So, it should be planned too, by the same diagrams.
On this level you also plan the architecture of the development environment. It consists of components, too.
Draw Interaction Overview and Communication diagrams to see the cooperation of components as a whole or in complex groups.
Package, activities, sequence, timing diagrams
Package diagrams are for planning the hierarchy of your code and mutual visibility of its parts. Don't forget the place for testing packages, too. Notice, that the structures of packages and components hierarchies are different, but they have to work together. It is very important part, frequently overlooked.
Use behavioral diagrams for better understanding how different processes could run.
System analysis - the class diagrams level.
Some important classes could appear on the previous level diagrams - as definitions of intercomponent interfaces or subjects of processes. But now you should do all of them. Minimally a diagram for a component. You should do these class diagrams, using ready package diagrams.
Plan the content of UI, defining elements and functonalities and connections between them WITHOUT choosing the concrete components. Use diagrams that you like. Class ones are usable, but in not standard reading.
Deeper insight
If you have instances with specific behavior, use Object diagrams for their planning.
If you have some very complex classes or their tight groups, use Composite Structure Diagrams.
UI: Plan the content of screen elements WITH choice of the UI components (frames, buttons and so on) and connecting functionalities to them. On this level you can again use class/object and sequence/timing diagrams.
Code. Really, the coding, at least on the prototype level starts already on the stage of component planning. You have to control if and how different technologies will cooperate. But the real coding should be done only after you are sure you understand what are you doing. And to create all or some correct diagrams is the best way to be sure in it.
Notice the rule of thumb - structure diagrams set the sequence of levels. Behavioral diagrams support them on all levels. You can use state machine on the lowest level and timing diagram for to discuss with a client. But try not to mix the levels with the structural diagrams!
Also, do not try to mix diagrams, especially behavioral with structural ones. You should clearly set the rules, by which you can say, what part of information can be on the diagram and what not. And break these rules really only in the most exceptional cases.
As gwag noted, there is no separation of UML diagrams into high and low levels. The different diagrams are used for describing different aspects, not different levels, of a (software) system.
But if you look at UML in a broader context, the Unified Modelling Language is just one of a whole family of modelling languages standardized by OMG. These different languages do have more specific scopes.
SysML (Systems Modelling Language) shares many features with UML and looks very similar, but is specifically intended for the higher levels of systems analysis / design. It also includes a visual representation of requirements, which are conspicuously absent from UML.
Another related language is BPMN (Business Process Model and Notation), which is used for business processes. So you could for instance use BPMN for business analysis, SysML for system design and UML for software design.
UML does not specify level of details you define in diagram. Every diagram can be used for description on business level, implementation or design level as well.
It is up to modeler, what type of diagram uses to descrbe modeled system. Information in diagrams must correspond with each other and all diagrams must give complet view on system.
For example, you can declare services of Bank company using UseCase on business level or use UseCase to declare services implemented by concret physical component of program writen in Java.
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
Similar diagrams would be:
information flow diagram
communication diagram
sequence diagram
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.
Im a bit uncertain about the relation between the Unified Modeling Language (UML) and the different modelling perspectives (conceptual, specification and impelementation) endorsed by (R)UP among other OOA/D methodologies.
From what I understand the same type of diagram using the same notation can have different meaning depending on the perspective* being used. For instance the class diagram can represent an abstraction of real world systems / phenomena in the conceptual perspective and when perspective is later changed to specification/implementation the class diagram is used to abstract constructs of a computer program.
Questions:
1) It is my understanding that certain rules exist for a UML class diagram in general. For instance that a class can extend another class but that it can't extend an association. Where are the entities of the class diagram and the rules about how they can relate defined? Does it all take place at the M2 layer in the UML metamodeling architecture
(see wikipedias illustratio of metamodel architecture)?
2) A related question. The way I see it, the general rules for a specific diagram span the modelling perspectives (again, it is absurd for a class to extend an association), but the different modelling perspectives will superimpose certain meaning to a particular type of diagram. For instance an association in the class diagram of the domain model (conceptual perspective) will inherently be bidirectional whereas it can be either bi- or unidirectional in the class diagram of the design model (specification / implementation perspective).
In the scenario just described the rule superimposed limits the properties of an association. Is it a correct assumption that rules superimposed by perspectives will always be a subset/limitation of the rules defined by the uml metamodel and never a superset?
Are these rules/limitations defined by the perspectives formalized (in a way similar to the metamodel) or are they mere conventions described in the OOA/D litterature?
* Perspectives are explained in paragraph 10.8: http://books.google.co.uk/books?id=r8i-4En_aa4C&printsec=frontcover&hl=da&source=gbs_v2_summary_r&cad=0
1) Your first question is quite clear. The rules that you are looking for are called a "metamodel". And yes, they are documented as what the OMG (the creators of UML, basically) call "MOF" or "meta-object facility". It is an OMG standard.
2) Your second question is a bit more confusing. I'll try to answer here. Diagrams are just views on an underlying model. The model is overarching and all-encompassing, if you wish. But diagrams are not. The perspectives that you mention are related to diagrams. But the model that underlies is multi-perspective, in the sense that all the elements form a connected mesh, without isolated "islands". Does this make sense? :-)