Which CASE Tools do you use? [closed] - case-tools

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which Computer-aided Software Engineering tools do you use and why? In what ways do they increase your productivity or help you design your programs? Or, in case you do not use CASE tools, what are your reasons for this?

The best CASE tool I had to work with is the Enterprise Architect from Sparx.
It's lightweight comparing to Rose (easier to buy and cheaper too) but extremely powerful. You could do great UML diagrams or database model or anything else you want but in a nice and organised way.
It greatly helps on the initial stages of the elaboration process as you could create domain model, do some preliminary use cases, map them to the requirements and present all of it in a nice way to the customer. It helps me thinking and I re-factor my design with it until I am satisfied enough to start proper documentation.
It is also very good for database models as it could reverse-engineer most databases very neatly.
The only (but quite serious) drawback it has in my eyes is that its documentation generator is, to put it mildly, crap. Getting a proper document from it is almost impossible unless you invest a significant amount of work in the templates and then it would be only OK.

I have used Rational Rose and a few other similar packages in the past. Mostly I have used them for the UML diagram elements and have not gone into the more detailed functionality such as code generation etc.
I mostly use them for aiding the design process and clarifying my own ideas. Often I find that, in trying to come up with a design for a componant, I end up needing to write down / draw what I want to happen so I can get a clear overview in my mind of what needs to happen and why. I have found that in a lot of cases, what I end up trying to draw is essentially the same as a predefined kind of diagram in UML, such as a Use Case Diagram etc. and by then adopting that style, it becomes easier to get my ideas on paper as I have some framework to work within.
So, I use CASE tools principally for thier UML / designing tools at a highish, semi-abstract level.

Oracle Designer

Not using any. No money for them.

Related

Choose framework [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Im thinking about starting a website project with a framework that will be also a study project for me. To be more exact a biologist kinda site with quite some filters and there is the question also if I should use separate database or flat file for 8 translations for the different species names (the site also has to be international, but just with 3-4 languages). Im thinking hard about which road to take... so I am asking for some constructive inputs please!
Im thinking of yii because of its simplicity, I tried it and it seems to be working smoothly.
Im thinking of symfony2 because it seems to be more advanced and some great websites were built with it, also drupal8 was constructed with it if Im not mistaken... and even if its harder to get going with it if its worth the effort I would do it.
Im thinking of spark, a java mini framework or Eclipse Link as later I plan to make an offline version of this webpage and I hope its not that hard to port it as a standalone java app. But I'm novice in java and hate the java documentations filled with acronyms all the time and supposing that I know those essential steps that are considered to be self evident by experienced java programmers.
I think there is no correct answer to your question. Chosing a framework is a matter of philosophy, and personal preferences. Some people will think that Yii is easier to use and some other will be amazed by symfony capabilities.
If you know a framework, I'll advise you to stick to this one and if you don't check out the basis of each ones and choose the one that seems to fit your need the most.
But at the end if you choose a popular framework (Yii, Symfony, Laravel, ...) you'll be able to achieve your goal.
Personally I like Yii, having never used the others :) For this exact reason I've flagged to close this as not constructive. There is no correct answer to this question.
I would start up a project in each, try and accomplish some common tasks, then decide. Ultimately you'll be able to acheive everything in all those frameworks. The deciding factor will be how fast and how comfortably you can use the frameworks, not how everyone else uses them.
Yii supports multiple databases very easy; Think about this;
All you have to do is create the database and the rest is, easy ...
Just create a simple blog app, and see wich one is the easyest and fastest when developing.

Choosing a Game Engine for my 2D Game [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am starter game developer. And also i am 2nd year student of software engineering. I have a team, and i am the only 1 who can code something!(And i have a guy from Marvel :))) )
So, we have decided to do a 2D game targeted to PC. I have made research in this side. And found not so many choices, because at the moment 3D games are in fashion. I do not want to use a game maker by the way.
So i decided to ask you this questions:Can you give some advise about using an engine or i have to write my own one? And if i have to write my own engine, which resources must i have?
Appreciate each of your answer !
Thanx !
Since PC games has many awesome titles out there, I think indie developer like you should heading for simple and time-killer games for mobile, a good game engine for mobile (free version available) is Gideros Mobile (http://www.giderosmobile.com). It use Lua language and you can publish for both Android and iOS platform. Gideros also has an active community which are ready to answer all your questions at here: http://www.giderosmobile.com/forum/
Currently I have 6 month experience with it, publish 3 games with about 60.000+ downloads.
I would say you should start by researching what a typical game engine gives you. There's a lot usually, such as physics, wrappers to draw objects, wrappers to load assests (such as sound and models or pictures), possibly even networking.
A game engine is potentially a huge, huge undertaking. If you're looking to make a game, focus on that by utilizing what's available to you.
My suggestion for starting would be XNA. It's a quick learn for the basics and easy to scale for large projects. They provide a lot of what I talked about and allows you to focus on what you started the project for.
Good Luck.
If you want to use a lower-level language like C++, I suggest SFML. It is extremely simple to use and provides both high-level and low-level graphics, audio, and networking functions for different uses.
You can also use it to easily create a context for OpenGL.
http://www.sfml-dev.org/
You will have to build the latest and best version (2.0) yourself, but this tutorial will show you how:
http://sfmlcoder.wordpress.com/2011/06/16/building-sfml-2-0-with-mingw-make/
Have fun!
I'd suggest checking out FlashPunk or Flixel. Both are Flash-based engines, so they use Actionscript 3, and can target the web-browser (Flash), or PC/Mac via the use of Adobe Air. Also, the performance isn't quite there yet from what I have read, but Adobe Air can also deploy to both iOS and Android. This is merely just a suggestion though, and if I were you I'd test out a few engines/technologies until finding the one I am most comfortable with.
Good luck!
Links to both:
http://www.flashpunk.net
http://flixel.org

Are you using "pen and paper" during programming? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
There are many CASE tools, many software for diagrams, drawing, documenting. But can they replace old good paper?
Every day, all day! (Okay, not all day, but a lot)
I actually had a debate a while back on the value of psuedocode, and I was giving my input on how much pen/paper and some pseudocode could work wonders at times :)
I use computers to solve easy design problems, but when I hit something really hard I break out the powerful tools - pen, paper and brain.
I use a whiteboard for design and pen-and-paper for TODOs.
Especially when it comes to doing some math before the implementation, there's nothing better than putting it down on paper first!
No software can ever replace the sheer ease of jotting down ideas and solution sketches using pen/paper! EVER!
Once you have your critical thinking down on a paper you can take your time to beautify them using fancy softwares and tools.
All the time I use pen and paper, I find them invaluable tools to programming! Making notes, etc, etc...
Using quick sketches is an invaluable tool in clarifying requirements with a client. You don't have to be Da Vinci to quickly encapsulate complex business logic or UI behaviors in some simple sketches. Leah Buley at Adaptive Path has great resources on sketching for UX. Programmers can learn these techniques as well. You'll save a lot of time using paper first, before sitting down in front of Visio.
I vastly prefer pencil & paper (or pen & markerboard) for real-time thinking. It can handle just about anything my brain thinks of. If I need to create any official artifacts, I'll take what I've drawn and set it up using a tool. But usually the initial copy is sufficient.
On a side note, I'm still not sure why just about everyone in college switched to laptops for taking notes. You don't have anywhere near the ability to express your thoughts in Word as you do on paper.
All the time, especially for complex logic with lots of conditional programming!
I always find it easier to jot down what I'm about to draw/model before using application tools.
All the time. When I want to draw/write something complex, I don't want to master a piece of software to do it. Also means there are no extra applications hogging up my system resources. Plus, there's something satisfying about writing at all angles on a piece of paper :).
Most of the times when I program you can see papers all over my desk, some are wrinkled on the floor and some are not.
I usually do my brainstorming on paper and preliminary UML diagrams.
If only I had a whiteboard... :)
I don't use pen and paper when working alone, but I always use them when working with other people, talking with customers and so on. I mainly use pencils to draw diagrams.
In my opinion, the most beauty about programming, its heart its about designing good algorithm or pseudocode.
I thought before that a paper and a pen could be a good idea but I went ahead to write it, They were easy programs though, short ones.
I just approached the PNP question, not that I expect to resolve it but curiosity rules me,
You do not need to face such a big problem to use paper and pen but since I got into that I realized how important It is.
It saves time, makes you more efficient.
General while you are programming you concentrate in small concepts like: Is this variable int...?
To have a big picture of the program, the best way It is a pen, that lets you concentrate on a problem and the go with the technical stuff, memory management, security, fast code...
If you go directyle into the keyboard, You might spend lots of time creating a big powerful function to realize at the end You do not need that because It happens that variable "a" will always be negative or whatever.
But please trust me I just started programming but happily I have discovered the world of the pen and paper.
I just realized that your question is actually nor a yes no question is it about comparison with diagrams, documenting.
Pen and paper before writing the program.
Documenting while You program and that It is a good idea to use a computer, I mean of course You can document it with papers but having you code full of /* */ It is just faster and better to read it and edit it again.
So there is a place for both things but stick with the pen at the beginning.

At what point do you need to be a programmer to work with Drupal? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Drupal seems to have lots to offer to the non-programmer. Tons of modules and easy installation. But at what point would you say you need to be a programmer? Where does it fall down and require more hands-on attention?
Also, even though they aren't "meant" to be done, I'm interested in any custom tweaks you've had to do to the code base.
I strongly disagree with the idea that you need programming skills when you want to do something different than the 'out of the box' functionality, unless "out of the box" includes the myriad of ways one can mix and match the thousands of third-party plugins.
The biggest challenge is this: Drupal's community is moving more and more towards building small, reusable blocks that can be combined in novel ways via configuration, rather than coding. This means that the number of things you can accomplish by combining small pieces via administrative screens is impressive. However, it means that the tools you put together this way lack a lot of the 'smooth edges' that would be there with a single built-to-spec plugin.
It's those places -- the rough edges -- where custom code is most frequently needed. Writing a short hook_form_alter() function to hide some unneeded form fields or change the location a form redirects to when it's completed, building a simple custom sidebar block to give the use some useful links to the different pieces you've assembled, things like that. Custom theming also takes up a lot of that 'smoothing' work.
This is to say that you can do insane amounts of stuff with zero code, but you will reach a point of diminishing returns, especially when trying to build complex rule-based logic ("Under certain circumstances, I want X to appear, otherwise the user should be prompted for Y..."). Knowing at least some PHP, not being afraid to peek at what's going on under the hood, and the willingness to write a (small!) custom module to accomplish certain tweaky goals will definitely serve you well on more complex sites.
Also, it's easy to find plugins that do interesting things but are still in beta/development. Knowing some PHP will help you keep your head above water if you decide to work with 'not quite finished' code.
The only time you'd need a programmer would be if there was some functionality that you wanted and current plugins just did not provide what you were looking for. Most Drupal-powered sites can be run by non-programming types. In short, I'd say you would need to be a programmer if you need to develop custom functionality not found in any of the available plugins out for Drupal now.
Slightly off topic, but addressing one point you made:
Also, even though they aren't "meant"
to be done, I'm interested in any
custom tweaks you've had to do to the
code base.
It's open source software. You get to decide what's "meant to be done," based on your needs and desires.
Some of the best features start out as someone changing or using something in a way no one else had anticipated, thereby producing something new, interesting, and useful. Finding out what customizations others have made like this is a great way to broaden your understanding, and nothing to be furtive about.
I've used drupal without ever need to do any "programming", and if you don't have programming skills you could always use a cheap contractor (e.g. rent-a-coder or similar) to quickly/cheaply modify/create a plug-in for you.
There are a lot of modules available, but as soon as you want to do something slightly different than the out-of-the-box functionality, you need to be a programmer.
Personally, I have never altered the core codebase. It is really not recommended. I have taken existing modules and either taken parts of them to use in my own modules, or renamed them and modified them as my own.

How do you prototype? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We prototype a design, GUI, just to analyze a particular problem, proof of concept, etc. Sometimes we throw away the prototype, and sometimes it ends up in the production code. We use different languages, technologies, strategies, and styles to prototype.
What are the different situations you prototype usually and how do you prototype? Any good resource out there to master the craft?
One hot title is Effective Prototyping for Software Makers. The issue is that there are several schools of thought.
Rapid Prototyping. Use fancy tools; get
something done soon.
Evolutionary Prototyping. Evolve from prototype to production.
Some of this is legacy thinking, based on an era where tools were primitive and projects had to be meticulously planned from the beginning. When I started in this industry, the "green-screen" character-mode applications where rocket science and very painful to mock up. Tools and formal techniques were essential to manage the costs and risks.
This thinking is trumped by some more recent thinking.
Powerful tools remove the need for complex prototypes. HTML mockups can be slapped together quickly. Is it still a prototype when you barely have to budget or plan for it?
[You can mock it up in MS-Word and save it as HTML. It's quicker for a Business Analyst to do it than to specify it and have a programmer do it.]
Also, powerful tools can reduce the cost of mistakes. If it only took a week to put something together -- production-ready -- what's the point of an formal prototype effort?
Agile techniques reduce the need to do quite so much detailed up-front planning. When you put something that works in the hands of users quickly, you don't have quite so much need to be sure every nuance is right before you start. It just has to be good enough to consider it progress.
What can happen is the following. [The hidden question is: is this still "prototyping" -- or is this just an Agile approach with powerful tools?]
Using tools like Django, you can put together the essential, core data structure and exercise it almost immediately. Use the default Django admin pages and you should be up and running as soon as you can articulate the data structures and write load utilities.
Then, add presentation pages wrapped around real, working data. Be sure you've got things right. Since you've only built data model and template-driven HTML pages, your investment is minimal. Explore.
Iterate until people start asking for smarter transactions than those available in the default admin pages. At this point, you're moving away from "discovery" and "elaboration" and into "construction". Did you do any prototyping? I suppose each HTML template you discarded was a kind of prototype. For that matter, so where the ones you kept.
The whole time, you can be working with more-or-less live, production users.
Personally, I believe a true prototype should not be much more than diagrams drawn on paper to demonstrate the flow of whatever it is you are trying to achieve. You can then use these documented flows to run through several scenarios to see if it works with whoever has requested the functionality.
Once the paper prototype has been modified to a point where it works then use it as a basis to start coding properly.
The benefits of this process are that you can't end up actually using the prototype code in production because there isn't any. Also, it is much easier to test it with business experts as there is not any code for them to understand.
Right now I just draw pictures. I would like to do more, but to get something to a point where the users would understand any better than a picture would cost to much time.
I am interested in seeing some of these responses :)
I should mention where I work is just me and one other guy to play the roles of project manager (collect data, design spec & app), dbas, coders, tool researcher/developer, et al that comes with the job of making an app for a small company.
For webapps, start with an pure (x)HTML + CSS mock-up, and then use a framework that makes it easy to implement the functionality.
Template-based frameworks are very good for this, but we've had some good experiences with JSF + Facelets + Seam, too.
The main reason for doing prototypes is reducing risk. Thus, we do UI prototypes, which are really not very helpful unless they actually do something that a user can play around with. Just as important, we also do prototypes to either prove that something can work or figure out how something does work.
I start off making a prototype that makes the most interesting part work, then I throw it away and move on to a new, more interesting project...
*kills self*

Resources