I have an interface (android activity, but that should not matter) with text input, spinners and a toggle button (all on one page). Depending on the state of all these elements I produce text output (on the same page).
Since the relationship is not trivial, I would like to somehow visualize the logic relationship between these elements. I am reading about UML, activity diagrams, etc but got a bit lost there.
What term should I look for? What program do you recommend to use for drawing such diagrams on computer (linux)?
UML Activity Diagrams might not be what you are looking for. They are usually used to model activities in a process. They tend to be more high-level and conceptual and less about the implementation.
From your question it reads as if you are working on the implementation itself. In that case I would urge you to look at UML State Diagrams. They are really neat when you want to think about different states your application (or components of your application) can be in. It also lets you logically decompose behaviour into states.
Furthermore, it is also a straight-forward way to model your application in a way that you can apply a Design Pattern, notably the State Pattern, to implement your model.
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
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 have a conceptual question and believe Stack Overflow may be a great place to ask it. Often in my reading and learning I hear conversation of "layers" - and loosely defined layers, at that, it seems. Too, a lot of software jargon is used in describing these layers (so, for an entry-level guy or gal (like me), they each become difficult to get a grasp of).
So far, I have heard tell of three (3) layers that interact with each other and that make a program "run":
Business Logic Layer (BLL) - Wikipedia's got a great introductory article to this/
Application Logic Layer - that which is responsible for enabling the business logic layer to interact with boundary technologies
Presentation Layer (the layer I just learned of, today).
Here's my question (and it may not be possible to answer): how many of these layer "types" exist and - briefly - what are they?
I also encourage posting resources via hyperlink that people can consult, particularly as these layers do seem to be so loosely defined.
In this particular case, the layers are essentially a generalization of the Model View Controller system architecture. Briefly, they are:
BLL: The 'guts' of the application, if you will. This is the logic that works on your own internal data types and does, as the name suggests, the 'business logic' that makes your application actually work. It should be as independent as possible from any particular implementation of how the user might interact with the business logic. For example, if you were building a Tic Tac Toe game, the BLL would be the rules engine that does the actual work of tracking people's moves, determining who wins, etc.
ALL: The 'interface' between the BLL and all of the stuff that feeds data into the BLL. This is going to be much more specific to a particular application of the BLL. For example, if your Tic Tac Toe engine had the ability to save out the results of games, the ALL might provide an interface to a database engine that stores the results. It would also be responsable for interfacing the BLL with whatever PL you chose to use (text based, a GUI, etc).
PL: This is the 'front end' of your application that the user interacts with. This could be built from a complicated framework like Qt, or something simple like a text interface. Either way, it's generally completely independent in terms of implementation from the application it's trying to expose. To continue the Tic Tac Toe analogy, you could build a relatively generic 3x3 grid with shapes and a message output that just happens, via the ALL, to wind up displaying a Tic Tac Toe game. Now in practice they're rarely that decoupled, but the point is that you should try and keep any actual logic out of the PL, such that you can change the implementation of the BLL or ALL without having to touch your PL code as long as the interfaces stay the same.
These layers are loosely defined because they're just generalizations used to make visualizing the design of complex systems easier to reason about and to naturally guide development towards proper compartmentalization of functionality for maximum code reuse and component swappability, as well as allowing for more easily performing formal Verification and Validation and other QA tasks. There are many, many ways you can split up software design into 'layers', but these three are the ones that are typically formally described in Soft Eng course material. So there isn't really any specific 'number of layers' that you can talk about. How segmented a particular design is really depends on that specific domain and the 'buzzwords' in the industry at the time. You will however almost always find something akin to these three layers, sometimes broken into a few smaller chunks.
It is strange to me that the three concepts you list should be called "layers". They may be three components of a software system but they don't appear to lie on top of each other except in a crude PowerPoint block diagram.
The idea of layering relates to levels of abstraction in code development where lower layers provide the components used to build higher layers. The OSI model is a paradigm example.
There can be any number of layers in a particular software system depending on how many levels of dependency exist. Perhaps there are only one or two layers within the immediate application being developed, though that application is likely to be dependent on a larger stack of assumed sub-structure.
Box2D suggestes a physics engine for games which combines and model and view. Now I want to use MVC design pattern or a framework based on MVC design pattern such as Robotlegs of PureMVC in order to create a game. If I choose Box2D, is it true that Box2D breaks MVC concept? And if it is true, should I worry?
I don't feel the Box2D breaks the MVC concept at all (as long as we are talking about Model-View-Controller here...I often get lost in the acronym ocean ;).
The physics is part of the model. Not the entire model.
Consider the simulation of a missile in flight across a 2-D landscape (e.g. this). The "missile" has a model of how it moves. Part of that is the mass, moment of inertia, velocity, etc. This is the physical part of the simulation.
It also has some kind of "AI Code" to decide how much force to apply, how to turn the missile, etc. These or often called "steering" forces. This is the next level up of the simulation, the "getting things moving" part of it.
There is also a larger part of the model, the part that decides what to do when the missile hits something (which it gets from the physics). Or when to fire the missile in the first place. Or the route the missile should take.
You can go even higher, probably, but the point to take away from this is that at no point have I mentioned how the missile is displayed or presented to the user. That would be the view.
So, my take on all this:
The Model (in layers):
PHYSICS
MOVEMENT
LOGIC AND REASONING
OVERALL SIMULATION or STRATEGY
At no point is the View mentioned in any of these...they operate and exist regardless of whether they are displayed in 2-D, 3-D, or by balloons tied to chipmunks. The layers may interact with each other...the physics detect a collision that ends up causing change in state in the LOGIC AND REASONING layer, etc.
For completeness, the controller brings the user into this. The user "uses" the controller to manipulate the model. I've always felt this was a little hard to think about; I like concrete examples.
On the "hard core definition" level, the user uses the controller to give input to the model. So I touch the screen and the missile knows where it should fly towards. The model gets a command to "go here" and the AI of the missile takes this command and "runs with it".
On the other hand, the controller may also be used by the user to manipulate the view (which is not part of the "hard core mvc" definition. Consider a tablet applications where a pinch changes the viewport but a tap signals the missile to strike "this target". The first changes the view while the second changes the model. NOTE: This situation may be a manifestation of more modern forms of patterns derived from MVC, and not pure MVC.
Regardless, the physics is part of the model, not the whole model.
Was this helpful?
No, it's not true that Box2D breaks MVC. Box2D doesn't combine the model and view, in fact, quite the opposite. Box2D is completely agnostic about what you choose to render your view, so it's highly compatible with an MVC architecture.
Games are conceptually tricky when considering MVC because the model has many parallels with the view (unlike a business app). However, you still get lots of benefits from separating concerns in your architecture.
As Fuzzy says, Box2D is part of the game model.
MVC in a game looks like this:
Box2D will get wrapped in game model classes. Your rendering library (you haven't said what platform you're writing for) will get wrappped in your View classes. Any UI stuff goes in your Controllers.
If you want read more about how to use MVC for HTML5 Games using Box2DWeb (for physics) with EaselJS (view) in CoffeeScript, I've written more about it here.
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
We are currently working on designing the installer for our product. We are currently on the design phase and I'm wondering what is the best diagram (UML or not) to use when modeling installation logic or flow?
Currently, we are using the good'ol flowchart.
Thanks!
What problems are you having with the flowchart? Are you trying to model the functional flow of the application or the logic flow through the components of the system?
If you're just trying to show how the installer works from a functional perspective, then a flowchart is fine and has the advantage of being understandable by non-technical people.
But if you're doing a technical design, then probably you should use UML class and sequence diagrams. The class diagram shows the static relationships between classes, while sequence diagrams show how the classes interact to implement the functions of the application. You'll generally only need one class diagram but a whole bunch of sequence diagrams, because you need to work out the logic flow for each of the use cases that you've identified.
UML defines other diagram types that are all useful under limited circumstances, but class diagrams and sequence diagrams will get you 90% of the way home at least.
There's a diagram called a collaboration diagram that's related to a sequence diagram in that both show interactions between components. A collaboration diagram is what you create when you draw a bunch of boxes on a napkin and with arrows between them to show how components talk to each other. You may find that starting out with collaboration diagrams is easier.
This is a useful tool for making sequence diagrams:
http://www.websequencediagrams.com/