Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Almost every one of my programming classes has made use of UML, but none have really explained when or where it might be used in a professional setting. Is it done for every single file in a project, or is there some rule of thumb of when you might want to use it? Also, is it more commonly done by hand (which I've always dreaded) or using some sort of generator?
This question is very good example of opinion-based and very broad question with no real problem to solve behind it and no one correct possible answer
Certainly in the amount of millions of software developers there are some who learned to use UML and do use it. And there are some who either did not learn to use UML or just don't use it for whatever reason
I recall that in the pre-agile era it was believed that no "big" software can be realized without thorough analysis and modeling phase and no "big" software contract can be signed if the business documents don't include some UML-style pictures
And in some countries it is still true and government-owned agencies declare what kind of documentation software contractor must provide, and for some of the requirements an UML picture is the good form
See also:
Wikipedia: Rational Unified Process (RUP)
Wikipedia: Software requirements specification
Programmers: Writing a Software Requirement Specification
So there are UML believers, UML skeptics and even UML haters, it depends on ... things.
I'm UML believer
and so is for example Mr. Kenji Hiranabe from Change Vision, Inc the company behind Astah UML modeling tool and he says
...Is modeling obsolete? Is UML dead? I don't think so. In this article...
as foreword to article Modeling in the Agile Age: What to keep next to Code to Scale Agile Teams
my favorite guideline is what The Guru said in an interview with Mark Collins-Cope for the Objective View magazine on Sep 12, 2014
Grady Booch, creator of the Unified Modelling Language (UML):
"The UML should be used to reason about alternatives. Put up some diagrams. Throw some use cases against it. Throw away those diagrams then write some code against you best decision. Repeat (and refactor)"
How you finally evaluate "..UML...commonly...real world.." depends on what you want to see and which software development best practices you adopt in your own work
It depends on your role, in most developer roles you will rarely, if ever, have to use it. I can see it being useful if you are designing something though, like a new database structure, or architecting a new system or application.
It can be useful for lead developers, architects, or IT managers in the design stages of the application for communicating ideas to the business folks as well as passing on a plan for the development team that will be building it out.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 12 months ago.
Improve this question
UML has come into many projects with object-oriented programming and is widely taught in colleges. However, today many software projects use a more or less agile approach, avoiding up-front in-depth analysis and leading to many changes ("welcome change"). In contrast, creating correct and readable UML (class) diagrams is still time-consuming; hence the value of documenting the model is in practice often considered time waste, as it changes often.
Even autogenerated (from source code) diagrams are not solving the problem, as they cannot correctly resolve class relationships often have insufficient graph layouts and distracting extensions.
Can UML be used in an agile context in a way that avoids the overhead of frequent manual updates? Or are other lighter alternatives to UML more suitable in such a context?
UML can be used in a light way in an agile context. The key is simply to be clear about its purpose and what you expect from modeling in your project.
Class diagrams and sequence diagrams are proven to be good candidates for helping teams to discuss points of concerns. It can express clearly ideas that are not obvious in the code (or scattered across many source files).
Scott Ambler for example wrote a lot on agile modeling, based on UML. Of course, you will not use it for producing an exhaustive model with all classes and all properties. But you'd sketch the core with some relevant classes, and only a few properties that matter in the discussion (Ambler says "Just barely enough" modeling).
However, for architectural modeling (deployment diagrams and the like), UML requires a degree of precision that is not always possible in early stages. Here C4 models has established as a convenient and flexible alternative. But C4 relies on UML for the OOP design discussion. There is simply no alternative that allows to easily show classes and interaction between them, and that would be sufficiently widely known.
Conclusion: In an agile context, don't get misguided thinking that UML would require an exhaustive up-front design. Don't use it as for visual programming either, slavishly replicating details of the code. But use it as a communication tool to highlight key ideas and allow everyone to grasp the design and contribute productively.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am developing a project using prototyping methodology. However, since end users are involved, I am thinking of user stories for requirements gathering. I can see that user stories are generally associated with AGILE methodology. So can I use it in a project that involves prototyping methodology?
In my experience User stories are used to divide a major chunk of work into smaller parts from an end users point of view.
Similarly, it can be used in prototyping methodology to divide the functionality of the prototype into small parts, each from an end users point of view.
since end users are involved, I am thinking of user stories for requirements gathering.
In line with the previous answer by Surkeet, user stories are written from the perspective of the user. Having them written in their language may make the communication between your development team and the user(s) smoother and based on a common vocabulary. The answer to this question is that "it depends". It really depends on the nature of your project. If the details of the user story (i.e. as a , I would like to so that ) is good enough for you, you have good-enough communication with your customer, and the nature your development tolerates iterations, then maybe user stories alone would be a good tactic to document and communicate requirements. However, there are cases where documenting requirements in terms of user stories is not enough. An example of that would the pressing need to agree on the non-functional requirements (a.k.a. quality attributes). An example of theses requirements is reliability, performance, and security. Especially in very large/critical systems that may fit an agile methodology, having to formally express non-functional requirements is a must. This is arguable and may start technical wars as some people do use user stories to document non-functional requirements.
So can I use it in a project that involves prototyping methodology?
Using user stories, however, is not the only tactic that you could use to develop effective prototype. Yes, it can be used to trigger the first iteration of prototyping and maybe govern the iterations of prototyping, but again it is not the only way. One could complement prototyping with different tactics that fits agile methodologies well such as storyboarding. Think of storyboards as an interactive, comic-like, representation of a given interaction to achieve a certain user-defined goal. The great thing about them is that they are graphical (as opposed to narrated bullet points of a use-case scenario), making them a powerful illustration tools. Here is a short article about the subject (link).
Also, I would recommend not thinking about Agile as a package that comes with techniques that you have to follow. Tailor the process to your needs.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I'd like to model software components and their interaction between them, what information is passed, what processes take place in each component(not too detailed) and a clear specification of the input/output of the components.
What i've seen so far in UML is far too abstract and doesn't go into too much detail.
Any suggestions?
Someg guys Design programs on papers as diagrams,
Then pass them to software developer to Contruct.
This appraoach is tried: "Clever guys" do modeling, and pass models to "ordinary" developers to do laborious task. And this not worked.
We like analogies. So many times we make analogy to construction industry where some guys do models-bluprints and other do building-contruction.And we first think that UML or other models diagrams are equivalent to construction industry models-blueprints. But it seems that we are wrong.
To make an analogy with construction industry our blueprints are not
models-diagrams, our blueprints are actually the code we write.
Detailed Paper Models like Cooking Receipes
It is not realistic to design a software system entirely on a paper with detailed models upfront.Software development is iterative and incremental process.
Think of a map maker who make a paper map of city as big as city, since the modeler include every details without any abstraction level.Will it be usefull?
Is Modeling Useless ?
Definitely not. But you should apply it to difficult part of your problem-solution space, not every trival part of them.
So instead of giving every details of system on paper to developers, explore difficult part of problem-solution space with developers face to face using visual diagrams.
In software industry like it or hate it, Source Code is still the
King. And all models are liar until they are implemented and tested
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 5 years ago.
Improve this question
Hallo everybody
Recently I've been reading the book:
"Agile software development, Principles, Patterns and Practices" by Bob Martin
The following (S.O.L.I.D) agile-design-principles are listed within the book:
Single Responsibility Principle
Open Closed Principle Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Because of the fact that this book quite old(2003), I have a question:
Are there any other newly developed principles besides the SOLID methods?? If yes, is there any book/site covering these new emerging principles with practical code examples that you could recommend to me??
Of course I can google for some of these.
However, in stackoverflow read and write many profis, so I would like to hear their opinion too :D
You may want to look at books such as Code Complete and Pragmatic Programmer as they also talk about some excellent development principles.
I like the Domain Driven Design approach from Eric Evans:
http://domaindrivendesign.org/
http://domaindrivendesign.org/books#DDD
As the SOLID approach you describe, DDD is mostly sound and clean Object Orientation guidelines. DDD focus especially on creating a design which match as much as possible with the business to be implemented in the system, rather than having it guided by the technology and/or the frameworks you use. This lead to great testable design, easy to refactor.
In support to DDD, I like the Hexagonal Architecture of Alistair Cockburn. It gives you great ideas about general design of Object Oriented systems:
http://alistair.cockburn.us/Hexagonal+architecture
A more advanced and innovative approach I am currently exploring is the theory of centers, but this is not yet really documented. A presentation about it:
http://www.dreamsongs.com/Files/NatureOfOrder.pdf
UncleBob's book is a SOLID start ;) I'd add his Clean Code to your reading list too. For actual code construction it is a great tome.
Kindness,
Dan
You can find further design principles at http://www.objectmentor.com, the author's / Object Mentor's homepage. They were written around the same time as SOLID, you can find most of them at http://www.objectmentor.com/resources/publishedArticles.html.
This list is not for design principles only, but also an explanation of OOP, Agile architecture, design and practices, it is based on patterns of mistakes and a regular pain from my real projects, including both books and online articles:
Software Developer / Architect Recommended Reading
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Can anyone point me towards any references that attempt to formulate an economics of software development? In my own research, I discovered a book by Barry Boehm on this, but it seems very awkward and theoretical.
Dependency Structure Matrices seem to offer something worthwhile. Carliss Baldwin has used these in some work on modularization, boundaries, and transaction costs. A lot of it comes off as just common sense, though.
Also, economists have developed something called Behavioral Economics. Is there a "Behavioral Software Engineering" that addresses cognitive biases in developers or groups of developers?
Here's an interesting looking reference:
http://www.amazon.com/Knowledge-Sharing-Software-Development-Comparing/dp/3639100840/ref=sr_1_1?ie=UTF8&s=books&qid=1232979573&sr=1-1
Before Hal Varian became the Chief Economist at Google, he had worked on the economics of information technology at Berkeley, although he did not focus on software development per se. Nevertheless I would recommend a look at his paper on the more general topic from 2001. You can find a more complete list of his research work on his website. Hope that helps.
Software as Capital wasn't a waste of time, though you won't find any math in it and it reads like a PhD thesis because it started as one.
Another review.
I think that what you're looking for might fall under a sociology of software development... sociologists study all modern subjects, and from there you will no doubt find references to an economics of software development if there is one.
Facts and Fallacies of Software Engineering by Robert Glass has some dollar amounts associated with some activities (or, at least, percentage of total budget). Don't know if that helps at all, but it's something.
Several years ago I taught an "Economics of E-Commerce" course using Varian's book INFORMATION RULES. His idea of lock-in, though, leads the reader almost towards a drug-addict model of purchaser behaviour and exploitation. This book is more of an economics of e-business than an analysis of the software development process.
In terms of actually making software, there are ideas in the Mythical Man Month well worth knowing about.
The "Applied Information Economics" approach of Douglas Hubbard could be part of what you're looking for. If we assume software development is (often|always|sometimes|???) about supporting decision making by providing (better|more accurate|more up to date|whatever) information, then AIE helps as it's a technique for quantifying the value of better information. Read Hubbard's book How to Measure Anything for a good overview of the idea.
Also, the book Software By Numbers by Mark Denne and Jane Cleland-Huang provides a model for managing software projects by using something they call the "Incremental Funding Methodology". IFM is based on decomposing software projects into features based on the business value created, rather than decomposing them along technical boundaries. They then use a series of calculations based on Discounted Cash Flow (DCF), Net Present Value (NPV), Internal Rate of Return (IRR), etc. to show when in the project lifecycle the project will reach self-funding status, when it will reach "breakeven" and when it will generate a real positive cash return for the organization.
You might also find the Capability Cases book of interest. It doesn't strictly deal with any economic issues in detail, but it's an approach to software specification which attempts to more clearly map software capabilities to business strategy and business issues.