Related
I want to create flow diagram with drag and drop functionality. Is vis.js suitable for that functionality as showing in this example
Or there are other open source libraries are available which is based on node js.
suggest me.
Thanks.
Vis.js is a great tool, if you what to build something not that complex in no time.
Another great library is D3.js. There is a big community around it. But for the functionality you want D3.js. I highly recommend their docummentation.
I have watched this keynote that talk about develop an app based on an UML model, but I can't find any tutorial or docs about it.
Do you know any tutorial or documentation to help me?
thanks
Have a look at ArchGenXML.
ArchGenXML is a code generator. It builds on architecture-centric, model-based and test-driven development. Generates Python code from UML-Models (XMI-Format). It's optimized for the generation of code based on the Archetypes framework.
Documentation about using it with Plone (Zope) can be found here.
As Aussie says, ArchGenXML is the way to go - I use it a lot. But use Paster and Zopeskel too. Create an "egg" skeleton as documented in the link (use the "archetype" template), then create your model (A .zargo file) in the main code directory (ie, the directory containing config.py).
This way ArchgenXML (AGX) will create everything as appropriate for an egg.
UML (Unified Modeling Languge) - is a modeling language.
Is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development.
Refer to here.
[http://en.wikipedia.org/wiki/Unified_Modeling_Language][1]
If you searched using "UML" you'll find a bunch of result that will help you.
As soon as you will understand the concept of UML and know how to create UML diagrams then there's no more problem creating your app based on your model.
Very best,
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
As part of an assignment, I have to create a component diagram for existing code. I understand what a component diagram is and the information it presents, but I'm not sure of a process to follow when looking at code to diagram it out to produce a component diagram. I'm also not sold on how a component diagram, if I am presented with one, would help me with implementation of a system.
Maybe have a look at Scott Ambler's UML 2 Component Diagramming Guidelines and Introduction to UML 2 Component Diagrams. These are IMHO two good resources that explain how and when such diagram can be used.
You state two separate concerns: how to get from code to diagram, and how to use one as a guide to implementing a system. If you're diagramming existing code, I don't think the second question applies.
If you're designing new code, then a component diagram can be 1) a useful abstraction to understanding the important parts of the code, minus all the distractions, and 2) a good way to communicate to others.
If you're looking at existing code, then an existing component diagram (or one of several other UML artifacts) can be a guide to the code, which especially helps in maintenance: it can be easier to identify the location of bugs, major class responsibilities, etc.
If there's no diagram, then the exercise of making one by reading code is a good way to familiarize yourself. I've done this in a number of cases when inheriting a complex codebase. As a result, I have a couple of pages of diagrams of the application and database that tell me at a glance the interesting things about its major components. At any given time, I'll be very familiar with some areas and not others, depending on what I'm working on. The diagrams are a good reminder of how to use various parts of the application. And they're helpful when bringing others onto the team; they understand the code much faster after a half-hour walk through the diagram.
To work from existing code, you'll need to read through it, identify the major classes in use, and trace back to understand the dependencies and the interfaces, method signatures and data structures they use to collaborate. If it's a database-backed app, it can be helpful to see a description of the DB, as it should embody the main concerns of the application.
It helps to have some use cases to guide the investigation, since with event-driven applications you need to understand what the user is doing in order to trace through the code. If there are no existing use cases, then start by writing some simple high-level ones yourself. Then go through the code by use case, and identify the major objects in use. Hopefully, you'll find major classes in the program to macth the major use cases you identify. E.g., if the application is a web-based e-commerce app with an administrative user-interface, then you'll identify a number of end-user and administrative-user use cases, and should expect to see some classes specific to each of those families, as well as generic and utility classes used throughout.
Stay at a high level, avoid the temptation to account for every single thing you encounter.
As Pascal said, Scott Ambler's a great resource of practical UML knowledge, and has guildelines that can be used as little or as much as necessary. Specifically, see Introduction to UML 2 Component Diagrams. Hoever, he's writing much more for people designing new code than those documenting existing code, so you have to adapt some of what he discusses.
Martin Fowler's "UML Distilled" is still the best book on UML you can get. Its chief virtue is that it's thin - densely packed with info.
For me UML isn't primarily about helping me to design a system (though it does help). It's about helping me to communicate the design to others by giving us a common language/notation.
It makes the conversation easier so we don't waste time trying to translate between our different frames of reference.
The Scott Ambler is another good off-the-shelf standard answer. However, in the case of component diagrams I find the suggestions under (Section Creating Component Diagrams) fine, but long and not relevant to your documentation needs. From Scott's list (Creating Component Diagrams) I would really focus on just (1, 4, 5, 13), as many of the suggestions are design best practices. I will add some more of my own below.
Martin Fowler's book is great in many ways, but not really in depth for Component Diagrams or Co.. A massive 7 pages, which shows you where it was prioritized during his writing, as class diagrams get 18 pages or so.
I agree with you that you should be able to realize when to use a UML diagram. The UML 2.2 Specification itself says that it was built for Component (Service/Interface) Oriented systems. Taking a basic MVC GUI app and pushing into a Component diagram/model really does not make sense. There are also a couple ways of diagramming the component relationships, Scott Ambler's site shows them in Figure 1. For large multi system implementations I have found these diagrams very effective, e.g. lots of interfaces and lots of abstraction of systems.
My Suggestions: (I use components for modeling often, and I read the UML spec on this stuff)
Skip using ports for the HL component diagram, they are for grouping and although they look fun in Scott Ambler's diagramming you do not gain a lot for the effort.
Avoid getting caught up in an internal Component Structure. Only do this if clarity is needed for a high level of complexity.
Don't slip into making most "classes" into components.
Focus on the interfaces and where real boundaries exist, clues are public interfaces, package groupings, WSDL, external system interactions.
For your first several I would start top down. First make one of all the external system interactions, then do the next level down, use ports and composite structure if you want, but I don't like them, they are messy because the composite structure are actually Parts, a UML object that is an instance of a class or component, the naming get complex etc.
Pick one notation in general, use the ball and socket connections for tight coupling and only switch to the use/depends line between component and provider for loose coupling where there component (interface realizations) can actually be switched, both are mixed in Scott Ambler's figure 1 (linked above), loose on the left and tight coupling on the right. The UML spec also mentions this in section 8 of the UML 2.2 Superstructure.
From the following topic in the VS 2010 Ultimate docs:
UML Component Diagrams: Guidelines: http://msdn.microsoft.com/en-us/library/dd409393%28VS.100%29.aspx
Drawing component diagrams has several benefits:
Thinking of your design with regard to the major blocks helps the development team to understand an
existing design and create a new one.
By thinking of your system as a collection of components with well-defined provided and required
interfaces, you improve the separation between the components. This in turn makes the design easier to
understand and easier to change when requirements change.
(source: microsoft.com)
I am trying to learn java web programming. I come from a perl scripting background and know very little Java, much less JSF/Seam/EJB3.0. I've made a LOT of progress in this very steep learning curve, but there are some large conceptual issues that I think are hampering me a bit.
Lately I've turned my attention to learning JSF. Usually discussions of JSF include a description of component-based web programming, but seem to assume one has experience with the other paradigms of web programming. I would be interested to see a fuller discussion of this component-based paradigm in the context of other paradigms.
Can someone explain?
Thanks in advance for your thoughts.
TDR
The basic idea is just an extension of Object Oriented Design: Separate the concerns of your program. The same way you may make several different PERL scripts and string them together to do work, we will make several different JSF components and string them together to do work.
Let's take a simple registration form as an example. I want to know your name, your birth date, your address and submit this all to the back end to do work.
First thing we need to do is break up your form into logical pieces. If we knew we were going to reuse this exact form in a lot of different places, maybe this form itself would be a logical piece. In which case we could create a component that would render this whole form and tie it to a bean like "Contact." That way, any time you needed to use the form, you could dump it in, tie it to a Contact bean (the how would depend on your framework) and go from there. But that would make this a pretty dull example. :)
From my estimation I see name, birth date and address as three seperate, logical units. Name would probably be simple. Just a standard text input. So we can use a h:inputText element, or your framework's prefered version, and tie that to your bean's name field.
Second, we have the birth date. At its simplest, we can create a h:inputText field and add a f:converter element so that when we tie it to the bean, it will come out a date. You can scale this up to be a fully interactive calendar widget, complete with Java Script and what not. Check out IceFaces and RichFaces for some good examples. But the same core concept remains: A single component which you will tie to a date object.
Third, we have the address. This makes a great choice for a component, because likely you will need to know addresses in a lot of different pages. It's also a lot more complex than a single input. You'll need to combine multiple inputs, validations and fun ajaxy stuff to make a single cohesive unit. However, the developer who uses it will hopefully only need to do use
<foo:address value="#{BarBean.address}"/>
with maybe a couple of other options.
This seperation of concerns is at the core of not only Component based web design but object oriented programming itself. There are plenty of tools to make this easier too! Facelets is a great example. You can seperate your basic layout into its own sheet, simply injecting the useful content via the ui:define elements. You can create composition components that allow you to quickly create more useful components without delving into the JSF component framework; the address example would be very simple to do with a Facelets composition component. IceFaces is another good example. It handles all sorts of AJAXy type inputs, redraws and updates without me having to worry about how it all works (for the most part. ;) letting me focus on what the form is to accomplish, not how to accomplish the form.
This only scratches the surface but the broadest strokes are similar to any large program: Identify the smallest, logical pieces and build them before using those to build bigger pieces.
I think that a good explanation would take a lot of effort. I'd suggest to get first your java skills straight, so you can understand the code examples that you'll encounter later when you try to follow tutorials from the web or even better buy a book.
In short:
JSF tries to give you the programming experience of a desktop application for a web based app.
Instead of having for example big JSPs you have lots of smaller components, that you can reuse.
The state of the page is preserved as much as possible even you do a real request (not just an ajax call) by transfering the state of the DOM components to and from the server.
JSF and Java EE in general is designed in such a way that large teams can split up the tasks into a more modular form.
Therefore, with components, instead of having multiple people working on the same .jsp or .xhtml page and the same Java backing bean class, components allow people to work on the same application without tripping over each other's feet.
We are working on standardizing our Bugzilla application across all projects. The default installation has bugs grouped into Products which have Components and Versions.
We are united in our definitions of Product and Version but there is still some confusion/discussion/argument about what constitutes a Component.
How would you define a Component as far as it relates to classifying bugs in a project?
For bug tracking purposes, I would use Component to represent high-level areas that different developers tend to handle. For me, Component [in bug tracking] == Area of Concern.
For example, for a fictional EventPlanner application, I would list my components as:
Calendar
User Interface
Printing
Note that this may be different than what I, as a developer, would typically consider a software component. For example, my EventPlanner app might have use Calendar API, but "User Interface" and "Printing" themselves are not software components.
A component is a subdivision of a product and it provides a subset of the functionality of the product.
For example, if Stack Overflow is the product here are some potential components:
Questions
Tags
Badges
Profiles
A bit of glue logic should piece the components together to form the project.
I would define Component similar to referencing a branch of code like a project within Visual Studio which could be a class library, console application, windows application, or website/web application.
A good definition that will serve your purpose.
Anything that's a "helper" object, something that does something small to support the larger functionality of the application, and can be reused in other Products.
For example, an EmailSender class, or an ErrorLogger, etc.
Whatever it is you're most interested in breaking down your Products into for purposes of bug tracking. It's more important that the distinction is useful to you than it be "correct" according to some concept that's not specific to the problem of bug tracking.
To me, any part of the code for which you can change the implementation without breaking other parts could qualify as a component. Something you can definitively point to and say, "This bug is there, and nowhere else."
If your product is a giant spaghetti code ball, you might not get any benefit from components. If you've decoupled very well, and you have a very large project, you might have hundreds of things that could qualify as "components", and you'll probably have to semantically group them to prevent the distinction from being more trouble than it's worth.
EDIT: In response to a comment on another answer, this model works best if the person filing the bugs has the necessary knowledge of the problem to do the filing. We always review (triage) reported bugs and file them ourselves. If you're leaving component selection up to the users, this idea won't work very well for you.
Dr. A. Richard Newton from the University of Berkeley who teaches a course called "Component-Based SoftwareState-of-the-Art and Lessons Learned" defines a software component as
A software component is a unit of
composition with contractually
specified interfaces and explicit
context dependencies only. A software
component can be deployed
independently and is subject to
composition by third parties
I dont think there is a better definition. So bug here could be at component level or at interface level i.e. composition level.