I'm going to work on a software application for project planning and I’m looking for a constraint programming library that supports interval arithmetic and constraints on real numbers.
The feature I have to implement is the scheduling of project.
Could you advise me a constraint programming framework for such problem?
Thanks in advance!
There is a nice book called "Constraint-Based Scheduling: Applying Constraint Programming to Scheduling Problems" co-authored by Philippe Baptiste, Claude Le Pape and Wim Nuijten.
IBM has a commercial tool called ILOG CPLEX specially designed for constraint solving as means of addressing scheduling questions http://www-01.ibm.com/software/integration/optimization/cplex-optimization-studio/ Free alternatives would be GeoCode http://www.gecode.org/ and Minion http://minion.sourceforge.net/ Both are C++-based.
You should however be aware that constraints solving over the reals is not always decidable and would depend on the kind of constraints you intend to use in your modeling. As long as your constraints are linear, you are safe ;-)
Related
James Neighbors mentioned DSLs as an approach for software reuse but without explaining why.He just say that DSLs can be a better approach than a library of reusable components. I could not understand the relationship and what benefits can we come up with using DSLs in software reuse ?
Also in When and How to develop DSLs paper by Mernik , he mentioned that DSLs can serve as an input language to application generators, and application generators is one approach of reusing software discussed by Krueger.
Could anybody tell me the relationships or just how would a DSL be an effective approach towards software reuse ? Thanks a lot for your help
James made it very clear why DSLs are a good approach for software reuse (he and I were at UC Irvine together):
They capture the concepts of interest in the problem domain
They use a notation familiar to community that works in that domain
They define the rules of composition of specification/solution components to produce an answer, so that a DSL fragment can be checked for sanity as it is provided
His Draco system implemented all these concepts, accepting DSL descriptions, followed by a DSL instance, which Draco then compiled to low level code by applying implementation knowledge fragments ("refinement rules") to map from a high-level DSL into lower level DSLs/optimizing in the lower level DSL, and then repeating until you finally reach a DSL at low-enough level abstraction to give to a conventional compiler (e.g, to LISP or C or Ada or COBOL or ...).
This is his refine-and-optimize paradigm, that allows a set of DSLs to refine through layers of hierarchy to low level code. Thus, you get composability of layered domains and you can work at a very high level of abstraction.
So you capture problem specification and implementation knowledge, and apply it to get code. Reuse of abstractions, of specifications, of implementation, wow, ... not just reuse of "code" which is where lots of folks still seem stuck, as they were in the early 80s. Code is really hard to reuse.
This is really a very nice paradigm compared to "subroutines-as-components" (the fancy term for this currently is "inner DSL", which misses the domain notation, specification checking, implementation, and compositionality elements).
I think you really ought to read his PhD thesis (accessible here along with a lot of his other papers) carefully. It is a lot more approachable than might expect. It isn't full of arcane math; it is full of concepts and demonstrations of how to engineer his kinds of DSLs.
I am trying to wrap my head around why we first approach the problem of design and decide upon a visual method (UML), instead of starting with formal specifications that happen to also be executable (RAD prototyping), we start with diagrams that can't be easily proven to work. So when it comes time to prove properties of a model, we find we need to define constraints into our design, so we design a formal syntax (OCL) to define the constraints on the model. I am having a hard time understanding this leap back to where we started.
I find OCL encumbered UML designs (even samples shown in brochures) unreadable, even more impenetrable than the myriad of UML symbols and conventions. So what I want to know is: What are the key areas where OCL is used in the working software development world today, and for whom is it relevant or worthwhile to learn? What does your job role look like? Do architects who never write code use UML and OCL, or do programmers who also design and architect the systems with the same team that implements it, use it too?
[updated: Secondly, it occurs to me that Agile development seems kind of opposed to "Heavyweight" procedures, and that a domain specific language for design diagram constraints like OCL doesn't seem very Agile. Is UML+OCL used in ANY "Agile" shops, or is it universally eschewed by Scrummers?]
Interesting question.
The "holy grail" of the Object Constraint Language was to provide a framework that when coupled with UML allowed a tool to transform that into a concrete Object Graph / Meta Model i.e. a set of classes that already had their basic structure and constraints wired in, so that all the developer had to do was implement business methods. (all this in a language independent way)
JBuilder from Borland tried supoprting this in their enterprise edition, and Delphi with ECO also made use of OCL in a practical way (though not as a transformation input) by supporting the Query abilities. In fact Anders Inver from Borland / BoldSoft, and one of the ECO team, wrote the forward on the OCL bible, The Object Constraint Language, Second Edition (addison wesley)
My personal opinion is that there is not enough pay back to warrant the learning curve. Without using specialised (and expensive) tools the UML/OCL model is still not easily testable in real terms, and the value you get is marginal (if anything) over itterative test driven development. The language independence thing is waaay overrated, lets face it once we start down the Java, C#, Delphi, C++ or whatever path, there is no way in hell we will re-generate in something else, its just not practical.
For what its worth, I am yet to see Model Driven Development with OCL actually used in the real world for a real project. (other than as a proof of concept) What seems to be working lately in the real world is Agile processes, Scrum etc and just itterative development using standard IDE's with standard languages and user stories (perhaps some UML on a whiteboard or storyboard).
The benefit of defining OCL constraints on your models is the possibility of specifying all the business rules of your domain that you cannot represent with the graphical constructs of the UML (for instance, multiplicities are constraints that can be graphically represented as part of an association definition, saying that the attribute A of class C has to be greater than 5 is also a constraint but in this case has to be defined in OCL since UML does not provide a graphical syntax for this)
Obviously, this would be very useful if code-generation tools would be able to take these constraints and automatically generate a code that enforces them (e.g. as if-conditions in Java methods or as triggers in databases that raise an exception when the data violates the rule).
Unfortunately, there aren't many tools offering this functionality (see a list here: http://modeling-languages.com/content/list-ocl-tools) but the situation is slowly improving
Much has changed.
UML 2.5 used Eclipse OCL tooling to remedy the numerous bugs in the UML 2.0...2.4 embedded OCL.
SysML is using Papyrus and Eclipse OCL tooling for SysML next.
Eclipse OCL provides a much stronger UI and an OCL2Java code generator so that OCL embedded in Ecore/UML provides much more acceptable/executable code.
Much has still to change.
The OCL embedded in UML has never been seriously executed.
The OCL definition of OCL itself is lamentable.
I worked with OCL Constraints as a small part of my bachelor thesis. Borland (now Microfocus) Together had an interesting approach thus generating Java code out of OCL Constraints. You defined that variable X should be >= 0 or not empty and Together created assert commands to verify it automatically.
I heard about B-Method which is invented in France. Is it an alternative to traditional programming languages like c++ and java or is it a completely different thing with different purposes?
Quote the B-website:
B is a formal specification method
which, thanks to an adequate language,
allows for highly accurate expressions
of the properties required by
specifications. One can then prove in
a fully automated fashion that these
properties are unambiguous, coherent
and are not contradictory. This then
allows us to mathematically prove that
these properties are taken into
account as the design stages progress.
Therefore, this method and its
associated proof allow for:
(1) Clear technical specifications and
system specifications to be reached
that are structured, coherent and
unambiguous, and (2) The development of
software that is contractually
guaranteed to be fault-free.
To answer your question: No, B-Method is not an alternative to programming languages. It’s a way of creating blueprints for programs and for verifying that the thing you created really works as described by the blueprints. If you don’t understand this you can safely forget about it.
No, as the Wikipedia article says, B-Method is a Formal Method not a programming language. You can read up on Formal Methods on Wikipedia too. Basically, they can be used during development to describe and verify algorithms.
In formal specifications based on abstract algebraic types and equational theory you use formulas of equational theory to specify theory. System which will satisfy those constraints is called in formal logic a model.
Modeling is process of creating a model, which abstracts of some aspects, which are unnecessary details for a specific case. So concrete system has to adhere to created model in observed aspects.
Programming is a process of creating a program which will have specific behaviour - will perform specific algorithms - and programming languages through different paradigms enable us to think in a certain specific way, which abstracts of some details, usually machine specific ones.
So could we be doing all those things at the same time, because they are principially the same? Is declarative programming the nearest attempt to do that? Could we use some sort f programming languages which will be good for programming as well as for modeling and specification?
The scientist who has done the most to advance this point of view is Tony Hoare. Tony, along with his colleague Edsger Dijkstra, advocated nondeterministic programming languages so that there would be a smoother path from specification to implementation. Tony definitely wanted a single language for both specification and implementation. For more on this view, read his book on the Alegbra of Programming. Tony also did the seminal work on proving correctness of abstractions. All of this work was done in the context of simple, imperative languages with structured control flow and classic, side-effecting procedures. So there is not any connection with declarative programming of necessity. And historically, work on functional programming (the main branch of declarative programming) has followed more from Backus's Turing lecture on "liberating programming from the von Neumann bottleneck"; functional programming has been about programming productivity as much as anything else.
What we discovered since Hoare is that formal specifications and formal modelsl are very expensive. The expense hasn't been shown to be justified except in very special circumstances, like "if the software doesn't work, the patient will die" or "if the software doesn't work, the plane will crash." Informal models and specifications are quite useful, and much cheaper to produce and work with. There is still interesting research going on around the fringes on modelling, model checking, and so on. One of my personal favorites is the Alloy language done by Daniel Jackson's group at MIT. There's also great stuff done at Microsoft Research and plenty of good stuff elsewhere. There's some work in declarative programming as well, but it too is of the "cheap and cheerful" variety rather than a comprehensive, programmatic approach like Hoare's. One of my favorites there is Claessen's and Hughes's QuickCheck, which provides a way to state formal properties and explore them by random testing. No proofs or theorems, but still jolly useful.
In summary, you describe an agenda of doing formal models, specifications, and programs, all within a single framework. There is still plenty of good work going on piecemeal, but the unified agenda has been abandoned.
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.