Related
I'm trying to design a desktop UI for schematics, layout, drawing stuff. Just looking for high level advice from actual software designers.
Assuming an in-memory "database", (clojure map of arbitrary depth for all user data, and possibly another one for application preferences, etc.), I'm examining how to do the model-view-controller thing on these, where the data may be rendered and modified by any one or more of:
A standalone text field that shows a single parameter, such as box width.
An "inspector" type of view that shows multiple parameters of a selected object, such as box width, height, color, checkboxes, etc.
A table/spreadsheet type of view that shows multiple parameters of multiple objects, potentially the whole database
A graphical rendering of the whole thing, such as both schematic and layout view.
Modifying any one of these should show up immediately in every other active view, both text and graphical, not after clicking "ok"... so no modal boxes allowed. If for some reason the table view, an inspector view, and a graphical rendering are all in view, dragging the corner of the box graphically should immediately show up in the text, etc.
The platform in question is JavaFX, but I'd like a clean separation between UI and everything else, so I want to avoid binding in the JFX sense, as that ties my design data very tightly to JFX Properties, increases the graininess of the model, and forces me to work outside the standard clojure functions for dealing with data, and/or deal heavily with the whole getValue/setValue world.
I'm still assuming at least some statefulness/mutability, and the use of built-in Clojure functionality such as the ability to add-watch on an atom/var/ref and let the runtime signal dependent functions.
Platform-specific interaction will rest tightly with the actual UI, such as reifying ActionListeners, and dealing with ObservableValues etc., and will attempt to minimize the reliance on things like JavaFX Property for actual application data. I'm not entertaining FRP for this.
I don't mind extending JFX interfaces or making up my own protocols to use application-specific defrecords, but I'd prefer for the application data to remain as straight Clojure data, unsullied by the platform.
The question is how to set this all up, with closest adherence to the immutable model. I see a few options:
Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, or String) is an atom, and each view which can modify the value "reaches in" as far as it needs to in the database to change the value. This could suck as there could potentially be thousands of individual values (for example points on a hand-drawn curve), and will require lots of (deref...) junk. I believe this is how JFX would want to do this, with giant arrays of Properties at the leaf nodes, etc., which feels bloated. With this approach it doesn't seem much better than just coding it up in Java/C++.
Medium-grain: Each object/record in the database is an atom of a Clojure map. The entire map is replaced when any one of its values changes. Fewer total atoms to deal with, and allows for example long arrays of straight-up numbers for various things. But this gets complicated when some objects in the database require more nesting than others.
Coarse-grain: There is just one atom: the database. Any time anything changes, the entire database is replaced, and every view needs to re-render its particular portion. This feels a bit like using a hammer to swat a fly, and a naive implementation would require everything to re-render all the time. But I still think this is the best trade off, as any primitive has a clear access path from the root node, whether it is accessed on a per-primitive level or per-record level.
I also need the ability for one data template to be instantiated many times. So for example if the user changes a symbol or shape which is used in multiple places, a single edit will apply everywhere. I believe this also requires some type of "pointer"-like behavior. I think I can store a atom to the model, then instantiate as needed, and it can work in any of the above grain models.
Any other approaches? Is trying to do a GUI editor-like tool in a functional language just stupid?
Thanks
I don't think is stupid to use a functional language to do a GUI editor-like tool. But I can't claim to have an answer to your question. Here are some links that might help you in your journey:
Stuart Sierra - Components Just Enough Structure
Chris Granger - Light Table: Explains how Light Table (source) is structured.
Chris Granger - The IDE as a Value: blog post related to the video above
Conal Elliott - Tangible Functional Programming: Using Functional Reactive Programming to create a composable UI, but his code is in Haskell.
Nathan Herzing & Chris Shea - Helping voters with Pedestal, Datomic, Om and core.async
David Nolen - Comparative Literate Programming: Shows all to use core.async to simplify UI programming in ClojureScript. The ideas here can be used in a desktop UI.
Rich Hickey - The Language of the System: Amazing talk about system programming by the creator of Clojure.
Erik Meijer has a good quote about functional vs imperative code:
...no matter whether it's Haskell, C# Java, F#, Scala, Python, PHP think about the idea of having a sea of imperative code that interacts with the outside world and in there have islands of pure code where you write your functions in a pure way.
But you have to decide how big the islands are and how big the sea is. But the answer is never that there are only islands or only sea. A good programmer knows exactly the right balance.
Hi and sorry advance if this has already been covered.
I'm mainly preoccupied with writing numerical software but I'm a bit of a noob when it comes to application design.
I've written a library that essentially takes input from different data streams or static files, performs some data analysis and outputs the data to screen or file etc and I've decided to write a gui application to make it a bit more user friendly.
The sequence in which library calls must be made is fairly simple but there are some constraints on which events should be handled depending on the state the application is in. I.e. I don't want the user to start grabbing from a data source whilst they are already processing from another.
So I've decided to use a finite state machine. However, I was wondering on what the best practice for integrating a finite state machine into your application is. Should I make it the public interface to my library or should I essentially use it as the controller in an MVC framework, with the library being the model and GUI being the view? Or is there a better way of controlling the flow of your application?
Thanks for your help.
You got it right. Gui = View, FSM=Controller, Library+ Static data + Database + Model.
Having said that, see if you can further split the FSM into two parts. The state transition definition itself should be made declarative so that you can easily change the state rules. The FSM should be a simple state transitor which uses the rules in the state rule base.
you can store the rules declaratively using PMML, a variant of XML.
Take a look at this, it will explain what I tried to say, more eloquently:
http://en.wikipedia.org/wiki/ADAPA
(not related to ADAPA)
I am not fluent in UML, but I would like to create a class diagram based on existing C++ code. Other StackOverflow questions have indicated that two programs - Enterprise Architect and Rational Software Architect - are fairly good at "reverse engineering" C++ code (i.e., creating UML class diagrams based on existing C++ code).
I have downloaded the trial version for both of these applications. However, I cannot make any headway into understanding what to do to create a class diagram in either of these applications.
In Rational Software Architect, I have created a UML project, but I cannot find any way within the program to select, and reverse engineer, my existing C++ code.
In Enterprise Architect, I was able to import my C++ code, but all the elements (classes) appeared in a useless, overlapping diagonal line within the diagram. I attempted other settings, such as circle, but these were equally impossible to read because the diagrams were so large (due to the attributes and methods taking up alot of space) that no amount of panning and zooming was useful. What I would like is to hide everything except the class names (i.e., not display any methods or attributes) so that all 20 classes appear conveniently and legibly in one screen.
However, I am unable to find a way to hide everything except the class names. Rather, when I found an option (in Enterprise Architect) that seemed like it might hide everything but the class names, for some reason the elements all vanished in the class diagram, and no amount of repeating the steps & deleting and re-adding packages made the class diagram reappear.
Note: My C++ code (at least those files I selected for import into Enterprise Architect) amount to only about 20 classes.
Sadly, a very careful search of the documentation for both of these programs provides only generalities - no specific instructions are given regarding reverse engineering for either of these programs, so far as I could find.
I would be grateful if someone could tell me the basic steps to create a legible, easy-to-navigate diagram via. reverse engineering (i.e., C++-to-UML) that shows only the class names, so that about 20 classes fit (legibly) on one screen, using either Enterprise Architect, or Rational Software Architect - OR any other tool whatsoever that is capable of doing this (I suggest EA and Rational only because they have been highlighted in other StackOverflow answers as the best programs available for this purpose).
This answer applies to EA.
You can import individual files or whole directories, recursively or no. Directory import is by far the most common case; single file import does not allow you to create a diagram automatically.
When you import a source directory, you have the option of creating diagrams for each UML package, or no diagrams at all. You also decide whether to create packages for each source code directory, namespace (default) or file.
If your code constists of only 20 classes then it's likely they're in a single directory and/or namespace, so play around with that option (Package Structure in the Import Source dialog) to get the right number of diagrams.
In the same dialog, there's a button "New Diagram Options," which opens another config dialog where you can choose whether the diagrams should contain the classes' attributes and/or operations. You can also make the decision on a visibility basis, eg show public members only.
This dialog only affects what's shown in the diagrams when they are created. The members are still imported, just not displayed. This sounds like what you're after.
You can change the display options for any diagram by double-clicking an empty area of it, or right-clicking and selecting Properties. It sounds like you got into this dialog and changed something around, but I can't really tell what. The situation you describe, where you can't get the display back the way it was, is not one I've ever encountered in EA.
It is also possible to select display options on a per-class basis by right-clicking it in the diagram and selecting Feature Visibility. I don't recommend you use this in reverse-engineered diagrams, I'm just mentioning it for completeness.
The layout you describe, with all classes in a meaningless diagonal, suggests to me that the diagram isn't being laid out properly after creation. The diagram creation is a two-step process; first all the classes are dropped onto it, then the layout is applied.
This is strange, as EA automatically lays out generated diagrams and I haven't been able to find an option which allows you to deselect this behaviour. If this persists, send a bug report to Sparx Systems. You can always lay out the diagram by opening it and selecting Layout Diagram from the top-level Diagram menu.
If, finally, your classes are spread out among different packages and namespaces so that EA generates multiple diagrams for them, you'll have to merge them manually. Do this by opening both diagrams, selecting all (Ctrl-A) in one, copying (Ctrl-C) and pasting (Ctrl-V) into the other, then ask EA to Layout Diagram again.
So:
Right-click an empty package in the project browser, select Code Engineering - Import Source Directory.
In the dialog, select the root directory and source type.
Tick "Create Logical Diagram for Each Package" and select the Package Structure which best fits your source structure.
Click "New Diagram Options" and in the new dialog untick "Show Attributes," "Show Operations" and "Show Property Methods" if applicable.
OK both dialogs.
If multiple diagrams have been created, copy all classes into a single diagram.
If the layout looks bad, select Diagram - Layout Diagram.
Hope this helps.
For my project report, i need to show the class diagram of the software i've built which counts around 20 classes! The problem, is that when i render the class diagram in jpeg file(either using StarUML or ArgoUMl or whatever..) we can't see the details correctly (very big picture because of the large number of classes). Well, how to manage this situation correctly? Since the report is gonna be printed on A4 pages ?
Thanks !
With 20 classes I would expect at least 3 subsystems, (modules, layers), possibly more
Make package diagram showing the relation between those, one class diagram for each subsystem.
Add class diagrams for special things you want to show. Print each on A4.
If you can't split the diagram easily into modules, I'd consider that a design smell.
Its fun to print large diagrams on huge pieces of paper (like 500 tables on A0 ;-) but it really isn't of much use.
Producing a class diagram containing 20 classes is totally useless- what does it actually show? When using class diagrams I've never created a diagram that has more than about 5-8 classes on it.
The question to ask yourself is "what useful information am I trying to show with this diagram?". Don't produce a class diagram for the sake of it!
Breaking it down to demonstrate a particular design pattern, subsystem or component is what I find class diagrams useful for.
an other way is to not show all members but only the main ones, this reduce the size of the classes then the size of the diagram. Of course this suppose you use a tool allowing to choose which operations/attributs/relations must be visible, but this drawing setting is classical
may be you tool also have drawing setting to hide some part of the operation to reduce the width, for instance to show or not the parameters, or their direction, their type etc
Bouml (http://bouml.free.fr) has all this drawing options, and as it was said has PNG and SVG exports
best regards and happy modeling
Bruno
There are a few things you can do:
Bigger paper
Don't display method signatures
Don't display private methods
Partition your problem into more packages
Fewer classes per diagram
This is one of the problems with trying to treat UML like engineering drawings: Once you get it off a whiteboard, it's a poor language for communication. It doesn't read so well.
Generally a good way to deal with this is to create different diagrams for different modules or areas of functionality for your software. Alternately you could print the single image on multiple pages and show how to assemble them to form the full image.
I think it's the inherent problem that you're trying to show so many things in one diagram. Your question is just like "how can I put 100 words in a sentence without the reader getting tired of it?"
You can probably refactor it with FacadePattern. Basically it's just breaking down stuffs into modules. For e.g. Timesheet, PayCheck, BonusRecord can be ground into ManagementSystem. Product, Order can be grouped into OperationSystem, etc.
Use BOUML. The ArgoUML and StarUML are classics which everybody mention when it comes to question "is there any free UML software?". It's funny that being a historic software does not make the software unknown and unused. In case of Argo and Star the historic coefficient makes them known and used.
BOUML can export to SVG. This will solve your problems.I described the tool here
Thanks to SVG you will be able to quickly switch between birds eye view and detail view. I do this with Firefox. It's rapidly fast.
PS. I just noticed that you want to print the report. The SVG is then probably not what you want :\
Split your classes in several diagrams! When creating a UML model, you can have model elements such as classes displayed (no not) in several diagrams. A diagram is just a view of your UML model so that you can highlight modules in your specific diagrams.
I want to know why we use Data Flow Diagrams instead of flow charts.
A flow chart details the processes to follow. A DFD details the flow of data through a system.
In a flow chart, the arrows represent transfer of control (not data) between elements and the elements are instructions or decision (or I/O, etc).
In a DFD, the arrows are actually data transfer between the elements, which are themselves parts of a system.
Wikipedia has a good article on DFDs here.
You should use whatever you like. The diagram is just a tool. Use whatever tool fits you and your problem best. I usually just use boxes and arrows and squiggles and circles and little stick figures and whatever else I think gets the point across to the viewer. In short it doesn't matter if you even use a standard diagraming standard. People are usually pretty good at understanding pictures.
Data flow diagram shows the flow of data between the different entities and datastores in a system while a flow chart shows the steps involved to carried out a task. In a sense, data flow diagram provides a very high level view of the system, while a flow chart is a lower level view (basically showing the algorithm).
Whether you use data flow diagram or flow charts depends on figuring out what is it that you are trying to show.
The difference between a data flow diagram (DFD) and a flow chart (FC) are that a data flow diagram typically describes the data flow within a system and the flow chart usually describes the detailed logic of a business process.
Data Flow and Flow Chart differ in processes, flow, and timing.
Processes
a.) On DFDs, processes can operate in parallel (at-the-same-time).
b.) On flowcharts, processes execute one at a time.
Flow
a.) DFDs show the flow of data through a system
b.) Flowcharts show the flow of control (sequence and transfer of control)
Timing
a.) Processes on a DFD can have dramatically different timing (daily, weekly, on demand)
b.)
Processes on flowcharts are part of a single program with consistent timing
A DFD shows how the data moves through a system, a flowchart is closer to the operations that system does.
In the classic make a cup of tea example, a DFD would show where the water, tea, milk, sugar were going, whereas the flowchart shows the process.
Other answers have gone over the basics of what each thing is. At the higher level, a flowchart is a design level tool, while DFDs are more analysis.
DFDs have some nice features. Since they show the flow of data, some things become more obvious when charted this way: some data is only used by a few routines, some routines use only some bits of data, some routines touch everything. Seeing that up front helps organize, restructuring, and planning.
A follow-on worth exploring is the Event-Response Diagram, which is basically a DFD only showing process and data needed to process an "event", meaning something triggered externally (customer makes payment, etc.).
A Data Flow Diagram is functional relationship which includes input values and output values
and internal data stored.
A Flow Chart is a process relationship which includes input and output values.
Flow chart describes the program (see old fortran flow charts - surely, there are some floating around on google).
Data flow diagram determines the flow of data, for example, between subroutines, or between different programs.
Although my experience with DFD diagrams is limited I can tell you that a DFD shows you how the data moves (flows) between the various modules. Furthermore a DFD can be partitioned in levels, that is in the Initial Level you see the system (say, a System to Rent a Movie) as a whole (called the Context Level). That level could be broken down into another Level that contains activities (say, rent a movie, return a movie) and how the data flows into those activities (could be a name, number of days, whatever). Now you can make a sublevel for each activity detailing the many tasks or scenarios of those activities. And so on, so forth. Remember that the data is always passing between levels.
Now as for the flowchart just remember that a flowchart describes an algorithm!
have a look to this site
http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9#The_Flow
its really help u to understand what is DFD
Between the above answers its been explained but I will try to expand slightly...
The point about the cup of tea is a good one. A flow chart is concerned with the physical aspects of a task and as such is used to represent something as it is currently. This is useful in developing understanding about a situation/communication/training etc etc..You will likley have come across these in your work places, certainly if they have adopted the ISO9000 standards.
A data flow diagram is concerned with the logical aspects of an activity so again the cup of tea analogy is a good one. If you use a data flow diagram in conjunction with a process flow your data flow would only be concerned with the flow of data/information regarding a process, to the exclusion of the physical aspects. If you wonder why that would be useful then its because data flow diagrams allow us to move from the 'as it is' situation and see it that something as it could/will be. These two modelling approaches are common in structured analysis and design and typically used by systems/business analysts as part of business process improvement/re-engineering.
Data flow diagram: A modeling notation that represents a functional decomposition of a system.
Flow chart: Step by step flow of a programe.
Data Flow Diagrams
The formal, structured analysis approach employs the data-flow diagram (DFD) to assist in the functional decomposition process. I learned structured analysis techniques from DeMarco [7], and those techniques are representative of present conventions. To summarize, DFD's are comprised of four components: