I was wondering how would i represent class functions and program flow when creating a design model. I've heard about design tools like UML but not sure how you actually represent functions and flow in diagram. could any give me an example? Is flow charting enough for this?
In the UML you're doing the design, where you specify a high-level model of the project.
Functions belong to implementation. There contain many technical details which are irrelevant to your model, so you don't put them into the model.
You may create a list of class functions. Good choice of their names helps to understand what they are supposed to do. For some of them you may provide comments where you explain how you are going to implement them.
Of course you can represent some high-level interactions in the sequence diagrams.
In UML what you are looking for sounds like an Activity Diagram. Like Oleg said, that's far more than detailed design, it begins to become a view on the implementation. If you have to show up how some complex internal logic works, how information is processed an activity diagram becomes useful. It is like flow charting but standardized, so I would prefer use that type of UML diagram instead of self made stuff.
Related
For my next project I would like to try UML modeling. There are several reason - mainly documentation + to break ground for development to avoid re-coding everything over and over again.
I've tried it several times in the past, but I had a feeling like without a deep knowledge of the background libraries my work will depend on, It's not a trivial task, as at the very beginning I don't know, what kind of member variables and functions I would need.
Usually I was coding to get familiar with the libraries and API my app was interface and I get into a state, where the work was almost done or let's say it was from 50% ready, where it made no sense to me to start modeling something.
Am I true you really need to understand well the background or there are ways/techniques how to overcome this?
Another point is, do you built up the model from bottom to top or from top to bottom or it depends on the use case?
Thank you for any recommendations how to proceed.
If I understand well, your main challenge is to get an understanding of the libraries and API that you are using.
If you intend to create an UML diagram for reverse-engineering the library and understand it, you might loose your time: You'd be able to make a meaningful model only once you've understood how the pieces fit together. And for this discovery and knowledge acquisition, you already use the most effective approach:
Usually I was coding to get familiar with the libraries and API my app was interfaced.
Now, if the library or the API is delivered with an UML model, it's another story: an existing design model (not all the details of the implementation, but the core elements of the design, and interaction scenario that are difficult to grasp from the code) could help you to grasp faster how the library works, which will help you to go faster through the exploratory phase.
It's also a different story when you are reverese-engineering an undocumented app: there you don't have a tutorial, and it's difficult to write code to use the existing elements in a meaninful way. There it could make sense to document the system post-mortem. But again, do not lose yourself in a detailed implementation model with all the details: focus on the core elements, whose understanding will really matter for your maintenance fellows.
The three main purposes of making UML class models when developing an app are:
Describing the entity types of the app's problem domain for analyzing and better understanding the requirements for the app in a conceptual (domain) model.
Designing the schema of the app's underlying database (this is typically an RDB schema defined with a bunch of CREATE TABLE statements).
Designing the model classes of the data model of your app, which will be coded, e.g., as Java Entity classes or C# classes with EF annotations.
For 1 and 2, you may take a look at my book An introduction to information modeling and databases, while for 3 you may check out a book on model-based development, e.g. for Java Backend Apps or JavaScript Frontend Apps.
If your goal is to model the dependencies of your app, this may indeed be another purpose. However, as argued by #Christope, reverse-engineering a library is itself a big project that may easily consume more time than you have for developing your app.
Does UML Class Diagram support expressing Concept?
Also, is there any other diagrams that expresses Concept?
Just in case of misunderstanding, I mean the "Concept" in C++ and generic programming.
Basically the question can be answered with an answer to the "base class" question :
"does UML make any attempt to make it 1-to-1 fitting to C++?"
Answer is simply "no".
This is a very common misunderstanding, one can meet people looking for possibilities of expressing a pointer in UML or any other C++ specific things. You will unluckily not find it.
The misunderstanding is comes historically from the availability of C++ code generation engines which come with some UML modeling tools. All those code generation engines come with their own coding patterns to address the transition from model to code. Simply because there is no standard for the transition patterns itself.
UML comes from OMG and OMG has a generation patterns document for (Corba)IDL-to-C++ but none for UML-to-C++.
After reading shortly Wikipedia explanation of C++ "concepts" it looks to me like tool with same goals as generic classes and type constraints in C#
If I understood it correctly then by following older Stack Overflow question Representing a C# Generic Method in a UML Class Diagram it turns out that you should check the http://www.uml-diagrams.org/template.html as already suggested by #Aleks
Basically I mean to model your interfaces and classes as you'd normally do it. Just use the templating annotation and you can also chart some type restrictions using a virtual dependency, inheritance associations between the formal parameters used in the template
You can show in UML all structures used by concept - i.e., functions, algorithms, classes and so on. But not the concept itself, for it is an element creating syntax.
Also, you can't show in UML macros, preprocessor commands, etc.
All these things simply do not belong to model, but to the language/grammar/syntax. There are other tools for their support. Formal grammars, theories, etc. Yes, there are diagrams for it. Look for "formal grammar diagrams" in google and you'll see heaps of them.
We are going to develop a strong plugin-based c++ software. There is only few source-code examples for it. Due to the big size of the project, we want to do a simple software modeling, before we start to implement it. First of all class and sequence diagramms. We are newbies to UML, due to this reason, it would be nice, to have an UML-Example for a plugin-based project. We haven't found any examples for it on the web. Design patterns we want to use are i.e. plugins, plugins manager, factory method, singleton and some others. And now my question:
Do you know a (simple) example for a UML-Project for a similar software design?
Thank you.
Cheers Alex.
I don't know about the examples of this kind, but I can suggest you a set of diagrams/views that you should probably create in this kind of project. UML is very flexible tool and software projects are so diverse in nature, that it is hard to set up rules. You should listen to your developer instinct and simply model what you need in order to go forward with the project.
So...
1- Components (mandatory)
As this is a plug-in project, there are implicite external dependencies involved. You should make a component diagram to show your future plug-in (a component) as a black-box in its environment. Another obvious component will be the base-tool (to which your komponent will be plugged-in)
- Model all relevant interfaces between parts! This is fundamental
- Use stereotypes to show the implementation platform for each component (e.g. C++)
2- Use Cases (optional)
Here you can identify your Users (Actors) and what they can do with the plug-in (use cases). An alternative would be to capture reqs using wireframe model (non UML) or something like that.
3- Conceptual views (optional)
You did not tell anything about your plug-in functional logic. How complex is it? If the plug-in logic is very complex and has many concepts, algorithm, etc. then you should consider modelling this aspect on the conceptual level. Problem concepts and their relationships are captured using class diagrams. In addition you can use state machines (for active classes), activity diagrams (for complex algorithms), sequences (relevant scenarios), etc. all on conceptual analysis level (no implementation details)
If your plug-in domain logic is trivial, you can minimize this view. Sometimes a single state machine helps or an activity diagram, etc.
4- Architecture (mandatory)
Here you can use components and/or class diagrams to show the high-level view of your plug-in internal structure. This view extens the black-box view (explained in 1-), giving a white box complement. Only main modules are shown with an accent on interfaces between them and especially towards the external world.
5- Design (optional)
Here you should be pragmatic and not do this view just to have it done. If the plug-in is not very large and you have a trained team, the Architecture view will do the job. All depending on your plug-in complexity you can decide to show one or more levels of hierarchically related view. Components are typically on the top level, including more components and/or design classes.
Note that we speak the implementation-language on this level and ALL elements should have a clear stereotype (C++, DLL, EXE, etc).
Design view should also have some behavior diagrams of choice (sequences, activities, states, etc), again on the implementation level.
Traceability
The last but not the least. All these views look at the same underlaying system from different points of view and in different stages. Therefore there are a lot of implicit or explicit dependencies and relationships between the elements in different view. You should be fully aware of them and even show some of them on separate diagrams or via traceability matrix (some tools support it). Some traces you can make between proposed views:
1->4 Black-box and the corresponding white-boxes
4->5 high-level to low-level map (a component on architecture level is implemented by classes on the design level)
2->4, 2->5 Which components/classes will participate in which use cases
2->3 a single use case logic can be further specified through some conceptual modelling
behavior diagrams are strongly related to structural elements (state machines belong to classes or components), sequence diagram includes collaborating instances of classes/components, activities can show lverall usage scenarios of components or a class's method algorithm, etc.
etc.
There are a lot of ways to do this work and nobody can give you a concrete winning formula. UML modelling should assist you in your analysis/design work, beign a natural side-product of it. If you feel that you don't know what to model or you don't see the clear purpose of a diagram - just don't do it.
As for "factory method, singleton and some others", expressed in class diagrams, read the Gang of Four book.
As for plugins, you are looking in bad places. They are to be expressed in means of component and package diagrams, not class ones.
As for sequence diagrams, (also state machines, timing, activity...) , they are not intended for showing the problems of structure. And plugin is a structural term. Behavioral diagrams are useful, but they don't have any specifics when used for plugins.
For interactions of plugins, also look for UML communication and interactions overview diagrams. And maybe look at diagrams in the book "Enterprise Integration Patterns...". Their diagrams are not UML standard ones, but IMHO, are very convenient and useful for modelling of interactions on the level of components and packages (or plugins).
Here is my small link collection for the plugin architecture topic:
C++ basic implementation
Dobbs article series for that topic with all the implementation details, c++
Microsoft article, using .net features
Implementation details considering loading dlls in c++
I'm to write an event correlator. A fundamental part of the system will be a huge decision tree that recognizes the origin of the fault basing on recorded states and log files, and one of the primary concerns was keeping that tree maintainable - written in a format easily understandable and editable for the programmer.
Since 7-levels-deep nested if()s is not my idea of "maintainable and easy to understand", I asked for ideas how to represent it in a form that is a good middle ground between machine-friendly, user-friendly and cost-efficient. The obvious answer was using a Domain-specific language that would be compilable to C++ in which the actual event correlator will be written. The obvious question was how that DSL should look like.
The suggestion I liked best was to use UML activity diagram, and have it compiled to C++. The diagram would likely consist almost strictly of decisions, with activities only at leaves of the tree, as conclusions reached by the decision process. In essence, the diagram is my graphical DSL, which should be then compiled into that huge bunch of if()s in C++. And while I'll still need to craft all conditional functions by hand, at least the interconnections between the conditions should get handled by the system.
Now, what tool should I use for creating that diagram?
Since "roll your own" isn't my idea of cost-efficient, considering it is to ultimately create one, single diagram for one device (even if it will likely be edited forever, as new modes of failure are discovered), I had a look at the List of Unified Modeling Language tools.
Quite a few of these, including these that have "C++" listed in the "Languages generated" but I know the reality is never that good - I'm not interested in a bunch of header files pre-filled with class definitions according to the class diagram. I need a file that contains my decision tree; a bunch of conditional statements with conditions pre-filled with decision functions calls which I'm to write by hand, and outcomes as specific conclusion function calls.
Now my question is which ones can do that, aren't overly difficult to use, and aren't expensive either - free tools preferred but reasonably priced commercial ones are fine too.
Alternatively, failing that - which ones can save that diagram in a form that I could parse with a self-made "compiler", and how to approach creating that compiler.
Of course other suggestions are most welcome too - maybe a tool for old-fashioned flow diagram that can generate such code? Maybe a dedicated DSL to create what I need exists already?
Enterprise Architect can generate C++ code from behavioral diagrams, including Activity Diagrams. It's offered in several editions; the lowest edition to support behavioral code generation costs $599. Here's the section of the user guide: Generate From Behavioral Models. Beyond code generation, EA offers simulation, traceability, and many other niceties.
If you can implement your logic in a Statechart instead, you can use the free QM Modeler. It generates C++ code. It's designed to work with the QP active object framework, but you can use QM without relying on QP. (You can also use Enterprise Architect to generate code from Statecharts.)
This URL states that UML is represented as "an XMI format" - a kind of XML based
standard for representing UML.
http://documentation.softwareag.com/webmethods/tamino/ins441/advconc/FromUMLtoXML.htm
If you were to use this standard, your data might be more compatible with the
other CASE tools:
Most UML tools provide a function to serialize a model into XMI format. XMI is an XML-based industry standard for the exchange of metadata between CASE tools. Because it is XML based, XMI can be converted with the help of XSLT stylesheets into other formats such as XML Schema. An example of such a stylesheet can be found at http://www.aomodeling.org/.
I am guessing this XML could be parsed with an ordinary C++ XML parser such as
Xerces or (for Windows) MSXML /XML DOM.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've tried wedging my clojure diagrams into what's available in UML, using class-blocks as the file-level namespaces and dependency links to show relationships, but it's awkward and tends to discourage functional patterns. I've also tried developing ad-hoc solutions, but I can't discover a solution that works as well as UML with, say, Java (simple directed graphs seem to work in a vague manner, but this the results aren't detailed enough). Furthermore, I'm not finding anything on the web about this.
Just to be clear, I'm not trying to do anything fancy like code generation; I'm just talking about pen-and-paper diagrams mostly for my own benefit. I'm assuming I'm not the first person to have ever considered this for a lisp language.
What solutions have been proposed? Are there any commonly-used standards? What do you recommend? What tools do you use?
It depends on what you want to describe in your program.
Dependencies
Use class diagrams to model the dependencies between namespaces; in this case, it's more clear if you use packages instead of classes in a diagram.
You can also use class diagrams to model dependencies between actors
Data flow
You can also use Communication Diagrams to model the flow of data in your program. In this case, depict each namespace as an entity and each function as a method of that entity.
Or, in the case of actors, depict each actor as an entity and each message as a method.
In any case, it's not useful to try and describe the algorithm of your program in UML. In my experience, they are better described in comments in the source file.
I think its less about the language and more about your conceptual model. If you are taking a "stream processing" approach then a data-flow network diagram might be the right approach as in some of the Scheme diagrams in SICP. If you are taking a more object oriented approach (which is well supported in Lisp) then UML activity diagrams might make more sense.
My personal thought is to model the flow of the data and not the structure of the code because from what i'v seen of large(not really that large) Clojure projects the code layout tends to be really boring, with a huge pile of composeable utilities and one class that threads them together with map, redure, and STM transactions.
Clojure is very flexible in the model you choose and so you may want to go the other way around this. make the diagram first then choose the parts and patterns of the language that cleanly express the model you built.
Well, UML is deeply rooted in OO design (with C++!), so it will be very difficult to map a functional approach with UML. I don't know Clojure that well but you may be able to represent the things that resemble Java classes and interfaces (protocols?), for all the others it will be really hard.
FP is more like a series of transformations from input to output, there's no clear UML diagram for that (maybe activity diagrams?). The most common diagrams are for the static structure and the interaction between objects, but they aren't really useful for the FP paradigm.
Depending on your goal the component and deployment diagrams can be applicable.
I don't think something like UML would be a good fit for Clojure - UML is rather focused on the object oriented paradigm which is usually discouraged in Clojure.
When I'm doing functional programming I tend to think much more in terms of data and functions:
What data structures do I need? In Clojure this usually boils down to defining a map structure for each important entity I am dealing with. A simple list of fields is often enough in simple cases. In more complex cases with many different entities you will probably want to draw a tree showing the structure of your data (where each node in the tree represents a map or record type)
How do these data structures flow through different transformation functions to get the right result? Ideally these are pure functions that take an immutable value as input and produce an immutable value as output. Typically I sketch these as a pipeline / flowchart.
If you've thought through the above well enough, then converting to Clojure code is pretty easy.
Define one or more constructor functions for your data structures, and a write a couple of tests to prove they are working
Write the transformation functions bottom up (i.e. get the most basic operations working and tested first, then compose these together to define the larger functions). Write tests for every function.
If you need utility functions for GUI or IO etc., write them on demand as they are needed.
Glue it all together, testing at the REPL to make sure everything is working.
Note that you source files will typically also be structured in the sequence listed above, with more elementary functions at the top and the higher level composed functions towards the bottom. You shouldn't need any circular dependencies (that's a bad design smell in Clojure). Tests are critical - IMHO much more important in a dynamic language like Clojure than in a statically typed OOP language.
The overall logic of my code is usually the last few lines of my main source code file.
I have been wrestling with this as well. I find flow charts work great for basic functions and data. It's easy to show the data and data flow that way. Conditionals and recursion are straightforward. UML sequence/collaboration diagrams can capture some of the same info pretty well.
However, once you start using HOF, this does not work well at all.
Normal UML diagrams for packages work ok for namespaces, not that that does much.