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
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 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.
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 4 years ago.
Improve this question
I'm looking for a diagramming program that can help in designing software, right from the high-level requirements down to the low-level classes and functions.
I've seen a lot of UML programs, but they don't let you design at multiple levels of detail in the same map, like if you could "zoom in" and design the details of a part.
Do programs exist that help in such designing? Programs that let you design at the high-level and low-level on the same map?
Most of the UML products from large vendors will let you do what you want. "Rational Rose" and "Enterprise Architect" are just two examples that I have used. They both let you mix component, package and class level information in the same view. Both of them provide a way to specify requirements as part of the meta-data to a class and I believe, functions too.
Edit 8/23/09
I just found Topcased. It's free and does many of the same things as Rose & EA. I'm not sure about mixing different diagram types in one view, but you might want to give it a shot. I'm definitely going to investigate using it for my personal projects.
I recommend BOUML. It's a free UML modelling application, which:
has a great SVG export support, which is important, because viewing large graphs in vector format, which scales fast in e.g. Firefox, is very convenient (you can quickly switch between "birds eye" view and class detail view),
this can work as the "zoom" feature you're asking (I use such SVG exports my self, to be able to quickly overview relation of group of classes, and then zoom in into details of selected one),
is extremely fast (fastest UML tool ever created, check out benchmarks),
has rock solid C++, Java, PHP and others import support,
is multiplatform (Linux, Windows, other OSes),
is full featured, impressively intensively developed (look at development history, it's hard to believe that such fast progress is possible).
supports plugins, has modular architecture (this allows user contributions, looks like BOUML community is forming up)
The "zoom" feature you're asking can be obtained through SVG export. I use such exports my self in the way you're asking.
I've used Rational Rose and looks like it fits your needs.
You could try BOUML which, although it doesn't allow you to "zoom in", does cover all the aspects of UML, and allows you to view different parts of the design at once (in multiple windows). It is also free, which may or may not make it more desirable for you, and is quite cross platform.
First of all there are different diagrams for different things you want to express. During software design you dont only use UML, but also HTML sketches and things like that. So choose the right tool for the right task is my advice. Create a folder structure depending on your granularity, one for Frontend sketches (you can place it hiracially), one for class diagrams and so on. So try to establish a process that fullfils all your needs. Often the holy grail programm doenst exist or is not good, just because of the fact that it tries to satisfy to many customers.
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 6 years ago.
Improve this question
I was having a conversation last week with a coworker about architecture (real architecture, as in designing buildings). During our talk it came up that architectural blueprints give an architect, civil engineer, and contractor all the detail they need to build something. It got both of us thinking about the state of software engineering and that there is no universally adopted approach for describing the design of software.
We have UML, but I find that it is often hard to convey enough detail without the diagrams being overly complex. Are there good examples of large software that was designed out using elaborate UML diagrams?
Then again, is having a large set of software blueprints even useful? After all refactoring and rebuilding software is much cheaper than rebuilding a skyscraper. Are architectural blueprints the wrong analogy for software design? Is there a better analogy that you can think of?
I think you can't compare software architecture with real architecture. When you build a house you have to have everything planned in advance and what's more important you also can plan almost everything in advance.
Recently I read that software engineering is more similar to gardening than it is to real architecture. I think this comparison comes closer to reality: you can't know what will work out and what won't; you have to rework things that seemed good in theory but prove to be impractical and you can constantly improve your plan while your garden/software is getting more complete.
In summary: Software blueprints shouldn't have the same level of detail than blueprints for building houses because more often than not you find that you simply cannot stick to your original plan.
Architectural blueprints are a nearly-precise representation of the actual house. They are not - usually - an abstraction conforming to a model of how houses should look, they are a representation of how the house will be.
Contrast that with UML/Flowcharts/Rational Rose/Methodology-of-the-month - those are models. They abstract away implementation details, and presume that a given model(Say, OO) is how software should be, while in reality, software is always breaking those abstractions, because the models are not a good representation.
In a sense, this ties into a question of explanatory power and computability: a house blueprint is a fixed representation with a fixed expression, and a fixed input; whereas a software blueprint must account for variable input, possibly even of potentially unbounded length. Software that permits plugins or other "computing" tie-ins now has what amounts to a Turing machine operator embedded into it, which gives rise to a host of unpredictability. So the input space of software vis-a-vis a house is mathematically larger, meaning the representational techniques must be correspondingly more computationally powerful. And this is where UML et al. falls down - they are not homomorphic with real software.
I'd say that designing software is closer to Mad-Libs than blueprints
One of the arguments made in Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools is that UML is not adequate. Even with the addition of constraints, it is still unclear. Among other things, it does not express the authors intent sufficiently that good code could be reliably generated.
UML is fine, but photographs of whiteboard diagrams drawn roughly are just as good or better in practice (in a time/cost sense of things)
So it's more like drawing a strategy in the sand before lanching an attack, that attitude seems to work better in most cases.
Besides half the time UML gets drawn by some guy with lots of imagination and no investment in the actual implementation.
For large, computationally dense, long-lived, safety-critical, software systems like DoD and FAA weapons and sensor systems, blueprints are essential to long term success. (phew, that was a mouthful :)) Without a set of blueprints for these behemoths, maintainers, and even the original developers, will experience distress and frustration when they try to locate/fix bugs or add major features. Without blueprints, incorporating changes, even small ones, will become a high risk game and failure could mean the loss of lives downstream.
Having said that, UML and it's offspring SysML, are (right now) the only game in town. Modeling and abstraction are important tools in the battle against ambiguity and complexity and they'll become more important in the future. The sooner they are embraced by people who want to grow, the better.
Thanx for listening.
I have just completed a successful C#/Sql Server project where I used a UML diagram to flesh out the application design. That UML diagram avoided any misunderstandings about what the application was designed to do and not do. All class relationships along with the class deletion rules (composite, aggregate, none) were spelled out. Along with a couple of easy to understand State diagrams and some OCL (Object Constraint Language), it was a breeze to discuss with the stakeholders how the application was supposed to work. UML and OCL abstract out a tremendous amount of mundane and low level programming that I was able to avoid. UML and OCL are simple enough that users can understand what is going on under the hood. When my users ask how calculations were arrived at, I simply refer them to the UML and OCL. What could be easier? So, yes, IMHO UML is very appropriate in making software blueprints. There is something to said about employing domain driven development.
The combination of Text + Diagrams is usually the best way to explain how your architecture works. Rational Rose can only get you so far.
I think any metaphor is only going to stretch so far. You will get value comparing some aspects of programming to building houses and also from comparing different aspects to gardening / playing chess/ reading the dictionary whilst standing on your head...
I think it is easier in building to specify what level of detail is required for a particular project as there are generally accepted practices, that have been around for some time, for managing a building project.
Maybe in 50 years time, if everyone settles on a methodology, something similar will happen in our industry.
In my experience, uml is garbage.
You can achieve much, more by using TDD and have 10000x more fun.. by jumping in and writing test cases and seeing how your objects interact.
UML designs just suck. I am a coder, not a data entry type person.
Before TDD I used random pieces of paper to sketch out the basic entities and relationships and then jumped right into coding.
I don't see these tools being used commonplace and the popularity of them is whaning.
I'd say that UML is limited. Yes, you can represent basic relationships, but you still don't get much when you think about interactions and constraints (even with OCL)
If you want to give a software team "all the detail they need to build something" then put your efforts into requirements analysis and creating a nailed-down functional specification. This will contain descriptions of every feature that the customer wants. If those descriptions include UML diagrams then all well and good - in many cases UML is a better language than English/French/German/whatever for describing software - but don't get hung up on creating UML diagrams for the sake of it. Joel on Software has a series of feature articles on how to write functional specs and they are well worth reading - start here: http://www.joelonsoftware.com/articles/fog0000000036.html.