I am working on a technical engineering solution of connecting systems to other systems throughout a building environment. I am attempting to create a diagram that visually shows an input energy and then flow it through a series of systems, each of which will use a portion of that energy for operation. The diagram will update with different operations based on amount of energy, time of day, location, and desired output (heating or cooling).
The problem I have is that I need an extremely visual way of laying this out in a dynamic way. This all sounds super technical but to simplify, I'm basically creating a systems operation diagram (OR workflow diagram) that needs some serious power and visualization. I hope to make this a powerful tool in which, environmental data will automatically alter the diagram's configuration.
I am comfortable with learning a programming language if necessary but I'm just not sure which will be the best. I would like to start simple with one configuration and keep implementing new parameters. I was looking at Python, JavaScript, C++, C#, and VisualBasic. I almost imagine this like a game design for aesthetics but I'm not sure.
Below is a static example of the systems diagrams created for one specific case. This example is only the diagram and lacks any interactivity. Basically I would like to make a dynamic and interactive diagram that can take inputs and alter itself. But for starters, change visually with specific button presses.
Original
Related
I wish to document code for a fairly complex algorithm whose implementation is intertwined across several methods and classes. A sequence diagram cannot really describe the detail of each method well so I am looking at an activity diagram; however this doesn't typically seem to represent classes and methods, only the logic.
Is there a common or even proper way to show which methods the logic belongs to? I do not need to follow strict UML, the purpose is simply to make it clear what's happening visually.
Activity diagrams and partitions
The activity diagram are supposed to models activities without necessarily relating them to classes/objects. They are however very suitable for modeling complex algorithms, as they allows to show :
the control flow -- flowchart diagrams have proven effective for modeling alorthims; activity diagrams are much more precise in their semantic and can do this as well.
object flows that show what objects are passed through
there are object actions that are specifically meant for dealing with objects
Activity diagrams support partitions, i.e. visual grouping of activities according to a criteria. A popular use is to split actions by using subsystems as grouping criteria. Breaking down by classes seems overkill, but nothing forbids such groupings if it helps, and if you're able to use it consistently.
Interaction overview diagrams
Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions.
Interaction overview diagrams are a kind of combination of activity and sequence diagrams. The general idea is to use some activity modeling features for showing the big picture of the flows, between interaction nodes, i.e. mini sequence diagrams embedded in the larger diagram, to show which objects are involved and what messages they exchange.
There is an inspiring example here. But be careful: the linked website is based on a former version of UML and the text is not fully up-to-date. The most accurate source on these diagrams is section 17.10 of the UML 2.5.1 specs.
Additional thoughts
Instead of trying to show everything in one diagram, you may prefer the beauty of simplicity: use an easy to understand, simpler overview diagram, and uncover the complexity in additional diagrams that focus on details. This works with activity diagram complements with more detailed activities or sequence diagrams. But it also works the other way round, showing exchanges between key objects in a sequence diagram, and provide more detailed activity diagrams to describe what happens inside of one of the invoked operation.
Disclaimer: While I provide some hints that you can use to model algorithms in relation with their classes, I have at the same time to warn you that visual programming, i.e. a very very very detailed modeling, may lead to very complex diagrams that are difficult to read, and even more difficult to maintain. They loose the benefit of communicating the big picture. I'm not alone in this criticism, see Grady Booch who knows what he is talking about, since he is one of the co-inventor of UML, Martin Fowler, and many others
I work as a UX designer for a company who makes a creative application for the live video events space.
I want to do some work on information architecture for our product. The software is complex (think photoshop) in its layout.
Is a site map a good approach to mapping objects with in the software with windows and menus? Is there another option for building an overview of information contained.
Cheers Jim
A Sitemap makes more sense to me when you are actually creating a website. What you describe is a software with probably multiple features and a very clear goal.
I don't want to forget my favorite tool: pen a paper.
But also, I would do a Content Inventory and use it to create an Affinity Diagram so you can Categorize which features you will display where and how the information will be shown. Don't be afraid to explore about Databases and how relationships between data might be. You will have to iterate on this several times and do some Data Modeling at this point.
Also, if it is that complex, I would create Tasks Flows and User Flows to understand how the user will complete tasks from top to bottom better.
At the end, you will have to model Navigation and processes with a certain Hierarchy. Usually, I rely on B&W wireframes better than anything as they help me represent better the visual impact step by step.
Hope this helps and lots of luck!
I don't think a "site" map in the traditional sense will really help you. However, some elements like hierarchy & categorization certainly sound useful.
I think I would use traditional artifacts like a card sort if you're talking to users. Otherwise, you run the risk of confusing the issue (applications don't utilize links in a traditional site map structure).
For you, and/or internal team members, I wonder if mind mapping tools would help?
You could also use some visual design program to lay out all the options/sub-options in physical space. Imagine an interface with all options expanded. This would give you a better way to audit all features and make sure you're accounting for everything.
Finally, journey maps or storyboards that utilize interface options in the steps, should be created for the highest priority tasks/workflows. This helps you know how to deal with interface changes (eg picking settings for a process).
I would like to be able to use a tool that lets you visualize a program's control flow(s) in the context of its source code. To clarify, such a tool should basically show what happens in a program by spitting out a human-readable abstract syntax tree in the form of a multidigraph with nodes containing snippets of source-code translation units. The resulting graph initial node would, I presume, contain the block of code starting with a program's entry point (that'd be main for a C or C++ program.) New nodes would be created when a node needs to reference another block of code, whether that might be in the current file or in another one, and arrows would connect the nodes. Does such a tool exist, or would it have to be created from scratch?
You aren't going to get a tool that does this for arbitrary languages off the shelf. There are too many languages, each with its own syntax and semantics. You somehow need a tool per language. You might find such tools for very commonly used languages, e.g, Understand for Software.
I think that the only way to do this is to build metatools that enable the construction of language-specific tools relatively easily. Such a tool has to have the common machinery needed by all such language processing tools: strong parsers (so writing grammars for languages is relatively straightforward), AST construction machinery, symbol table support, routines to build control and data flow graphs. By providing such machinery, one can build language front ends for modest costs.
There's a class of tools that does this, program transformation. Most of them have parsing engines, but not the rest of the mechanisms I have suggested above.
I believe this enough to have invested 20 years of my life to building
such meta tools. Our DMS Software Reengineering toolkit shows its strength in being able to parse some 50+ languages, including the stunningly hard C++14 (both MS and GNU variants). It shows symbol table support and control flow graph construction for COBOL, Java, C, C++. (We can't do everything at once; pedaling as fast as practical).
[DMS builds these graphs as data structures rather than "showing" them; the examples on that page are drawn with the additional help of DOT].
One of the few other tools that tries to do this is Clang/LLVM; this covers a wide variety of popular languages. Clang doesn't have any specific support for parsing that I know about; you get to code it all yourself. I think you get control flow graphs only after you convert the language to LLVM. I don't think it has any specific support for drawing control flow graphs, either.
An older tool with a good reputation for multi-language support in this space is CoCo/R;
I don't know a lot about it. I know it parses,
and has some support for ASTs; I don't know what it does
about control flow analysis.
I am working on designing a user interface and want to convey my design to my peers. Typically, I'd use a mock-up of the UI and UML, but given the complexity, size, and multiple asynchronous interactions I'm not sure that this makes the most sense. It doesn't seem to allow to efficiently describe the process.
Does anyone have experience in designing large User Interface's? How would a company that designs UI's go about modeling their process/ design? This seems to be a question for the 'front-end' engineers.
well let's go for an answer even if your question is very large. I'll give you my experience and hope it will help you to decide.
To my mind, using UML in a project is very useful if you use it right, it's often clear, quite easy to understand. On the other side, when working on huge project, it's sometimes costly because it takes time to create your diagrams and nowadays, you have to be as fast as possible !
These last months I have worked on a project with a GUI and to well define it, I have first draw some screen on paper and quickly ask for some drawbacks near the coffee machine.
I have created some activity diagrams and then, created a mock-up.
How to choose now ?
First of all, if your GUI should have a beautiful design, I don't think you can avoid a mock-up, but I'm don't know if it's your goal.
My main tip would be, try to simplify your complexity in your program. If you have multiple asynchronous that could arise everytime/everywhere, you'll encounter a lot a problem.
In my project, let's say my tablet could be preempted by an external computer whenever/wherever. I just have created a class beforehand to manage this asynchronous call but my sub-activity-diagrams stayed intact.
Draw specific diagram for specific functionalities and leave useless diagrams which are not relevant/too simple.
Hard to explain you more than this without giving you any example. Hope it will help a bit.
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 4 years ago.
Improve this question
In my experience, UI programming is very time consuming, expensive (designers, graphics, etc) and error prone - and by definition UI bugs or glitches are very visible embarasing.
What do you do to mitigate this problem?
Do you know of a solution that can automatically convert an API to a user interface (preferably a Web user interface?).
Probably something like a JMX console
with good defaults
can be tweaked with css
where fields can be configured to be radio button or drop down list, text field or text area, etc
localizable
etc
Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
Please also see an excellent question: "Why is good UI design so hard for some developers?" that has some very insightful and valuable answers, specifically:
Shameless plug for my own answer.
Great answer by Karl Fast.
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
Looks like you are looking for the 'Naked Objects' Architectual pattern. There are various implementations available.
http://en.wikipedia.org/wiki/Naked_objects
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
if you already know or could learn to use Ruby on Rails, ActiveScaffold is excellent for this.
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
It's hard because most users/customers are dumb and can't think straight! :)
It's time consuming because UI devs/designers are so obsessive-compulsive! :)