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.
Related
Can someone explain me the difference between class diagram during analysis and design?
So far, I understand that the class diagram of design would be the real class diagram, with all methods and attributes (ready to become code), but what about analysis? Do I have to do a class diagram for every sequence diagram? Do I have to add methods and attributes at the design stage already ? Or only connection?
The UML class model is produced and refined iteratively as the understanding of the system increases. There's only one model for your system, although different diagrams may outline different aspects and level of details of this model.
Typically you would start with the domain model based on the requirements (e.g. use cases, user stories, statement of work, user interviews, etc.):
Top priority is to get an overview. So the first sketch would identify the domain classes and how they relate to each other.
You would then enrich this initial understanding by outlining in the diagram the key properties and methods that are essential to the understanding of the domain.
You would then enrich the model with more detailed design diagrams as you design your solution. So you would add any classes required for the implementation (e.g.user interface classes, application controllers, persistence layers, etc.).
Design diagrams are used to get a shared understanding about the software structure within the development team. So they should be easy to understand (i.e.focus on important aspects and not necessarily be cluttered with too many details that would anyhow have to be implemented in code and quickly be outdated if you don't have an army of analysts to update the model).
If you'd use an UML tool able to generate code or if you are contractually obliged to provide all the details in UML form, you would further refine the model with a fully detailed implementation diagram. Attention: for scholar work it is frequent that the teacher asks for a design diagram but expects in reality an implementation diagram.
We have 3 major types of class diagram in Object Oriented Methodologies.
Class Diagrams in Requirement (Domain Modeling)
Analysis Class Diagrams
Design Class Diagrams
Main difference of these class diagrams is their Abstraction.
In Domain Modeling, we use Class Diagrams. BUT, we do not use any Inheritance or any Interfaces, or any preforming analysis on the classes. We just write so little attributes of classes (about 3 attributes). we don't write any methods of classes. WHY? because of Abstraction. Main goal of Domain Modeling is modeling the domain. And detect Which classes should be in problem domain of system.
In Analysis modeling, we use class diagram. Classes in analysis is more detailed than classes in Domain. But it is not the final specification.
In Analysis, we determine Analysis Classes. We can use Inheritance between them. We can write their attributes and methods in detail. BUT, this phase is done by System Analysts. (Not System Designers or Programmer). Their profession is both knowing the Business Logics and Software Techniques. So they can write analysis classes in more detailed than Domain. However, they can not write very detailed as System Designers can.
In the other hand, we can use some analysis patterns to determine our Analysis Classes. For example RUP introduce Boundary/Control/Entity pattern. If we decided to use an existing analysis pattern, we can use the guidelines exist in the pattern documentations.
The guideline of Boundary/Control/Entity about the abstraction of classes are in this reference. In this pattern we should write only attributes for Entity classes and write only methods for Control classes and write attributes and methods for Boundary classes.
However, In my idea, we can follow the guideline or not. We can write more attributes and methods for analysis classes. What is happening? If our System Analyst try to write more detailed attributes or methods, what's happening:
I think that 1) our system analyst is not system analyst. maybe system designer. 2) we don't need their details. It is just time consuming for analysis phase. 3) ONLY if our analysis and design team are the same, or we combine analysis and design (like Agile Methodologies) the details in Analysis can be logical and useable.
In Design modeling, we use class diagram, this type of class diagram should be the final specification and should contain all attributes and methods. This classes are not conceptual. we can use all OOD technologies, Design Pattern and etc.
I need insight on how much UML to teach. I'm an adjunct for a "2-credit 100-level introductory course" on systems analysis and design (a contradiction in terms to me). The text is written for the typical 300-level 3-credit class. This chapter covers ~7 UML diagrams, it's already extremely simplistic, and I have to strip it down further. I have one week, or two class hours, to cover it.
I've concluded I can either trash the book and cover class diagrams well, which would introduce them to a lot of basic OO concepts, or I can simply aim for basic recognition of these 7 diagrams (not even expecting them to create any). But I feel like basic recognition would so totally skim the surface as to be useless for these brand-new programmers and the diagrams would run together meaninglessly. Advice greatly appreciated.
The 7, by the way, are: object relationship, use case, class, sequence, state transition, activity, and business process modeling.
There are several UML elements that map easily to code and are therefore straightforward to use as design elements.
Package diagram (translates to namespaces).
Class diagram (translates to classes in OO languages).
State machine (translates to any number of state-based implementations).
Sequence diagram (shows chronology of method invocations).
I would say that this is the minimum useful set of UML elements to teach. If you have time, I would also encourage people to learn use case diagrams, although many people find text documents just as effective for that type of analysis.
I would recommend to focus on class diagrams. They are the most useful type of UML diagram for analysing, designing and documenting (the information, or state, structure of) a software system. You could show how class diagrams define
the properties of an object type, both data-valued attributes and object-valued reference properties (representing unidirectional associations).
if a property is single-valued or multi-valued (by its multiplicity)
other property constraints
inheritance relationships in class hierarchies
You could show how classes can be used for conceptual information modeling (also called domain modeling) in the analysis phase, where they define the real-world object types, and for design modeling in the design phase, where they define platform-independent computational constructs to be implemented in some target programming language.
I'm currently working on a project for my university and one teacher told me I was wrong to think that there could be classes in a UML class diagram (thinking of it as a design diagram) to which there would be no equivalent in a data model. He then pressured me to provide a counter-example to prove my point but I just couldn't think of one.
I checked a few books I had about UML like "Learning UML 2.0," "Applying UML and Patterns" and UML 2 for dummies, but I couldn't find any information regarding which classes appear on a class diagram. I asked him about implementation classes but he told me that they shouldn't be included in a class diagram. So I'm at a loss here.
I also checked this questions before posting:
Differences between a conceptual UML class diagram and an ERD?
Generate UML from a conceptual data model
how to relate data with function in uml class diagram
But they don't really solve the question I have.
Thanks for any insight you might have.
Both your teacher and you are unnecessarily distracted by the differences between UML and conceptual data modeling (which I take to be tantamount to ER modeling). The real issue you and your teacher are discussing is the difference between analysis and design, regardless of the model used.
A UML model can be created that diagrams the problem as stated or that diagrams the solution as designed. In the first case, implementation classes should be omitted, because they do not pertain to the problem domain. In the second case, they should be included. The first case is analysis. The second case is design.
The same ambiguity exists with regard to ER diagrams. Some people, including myself, use ER models and ER diagrams only to represent the data requirements inherent in the problem itself. This is what is most often meant by "conceptual data modeling". In this framework, the only entities that should appear are entities that have a perceived reality in the subject matter itself, and are not merely constructs inside the database or the application(s). This is analysis.
But there are plenty of other people, perhaps a majority, who use ER diagrams to pictorialize the design of a schema of tables. In this framework, foreign keys are included, and junction tables are elevated to the status of entities, even though they are not subject matter entities. There's nothing inherently wrong in this, so long as the distiction between analysis and design is kept clear.
Unfortunately, the distinction between analysis and design is very often obscured beyond recognition. There are dozens of instances of this right here in SO.
So, if a confusion between analysis and design is allowed to creep into the discussion between you and your teacher, the discussion could end up going in almost any direction.
"one teacher told me I was wrong to think that there could be classes in a UML class diagram (thinking of it as a design diagram) to which there would be no equivalent in a data model. He then pressured me to provide a counter-example to prove my point but I just couldn't think of one."
He is right. In the stage of conceptual analysis/conceptual design, those rectangular boxes in a UML class diagram depict "concepts". And whatever the "concept" happens to be, you can always also draw an E/R diagram around it to illustrate (the nature of) that concept, other concepts that relate to it, and what the nature of those relationships is.
From my understanding of UML, it does NOT define what should be in a diagram. I found this example in the IBM site: (image did'nt lode, so here is the link: http://www.ibm.com/developerworks/webservices/library/ws-RESTservices/)
Surely, a servlet is not part of a domain model.
A UML class diagram us used to model classes, which are entities that have attributes and methods. IMHO, it doesn't matter if they are part of the domain model or are functional classes that support the application. If you need to show them to the customer, they must be there.
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? :-)