There are different Alloy applications (railway switching, access control, etc). For example, hotel room locking in "Software Abstractions". But how can I implement such model in real hotel?:-)
Are there some articles or examples of code when Alloy is used in real-life problems?
Thanks!
Vadik.
Related
I'm wondering if System Sequence Diagram (SSD) belongs to design part or analysis part?
A System Sequence Diagram (SSD) is be a special type of UML sequence diagram that intends to document for one specific use case the the sequence of exchanges between the system under consideration and the outside actors.
It is not a standard UML diagram, but build upon such diagrams. The book "System analysis and design in a changing world" seem to have popularized this approach, but I could find articles dating back to the early 2000' (like this or this).
The above mentioned book places the SSD in the analysis activities. The reason is that analysis is about understanding the requirements, which often start with use-case. The SSD is then a fine-tuning of this analysis.
However, one could argue that it's part of the design activities, since the use case are the requirements, but how these requirements are addressed through a sequence of exchanges is already the start of the design of a solution, exactly as when you start to sketch an UI: more than one SSD could satisfy the needs and you have the choice.
So the answer depends on the purpose for which you're using the model.
My own point of view is that you're already drafting a solution, so it should be design, unless you do some reverse engineering of an existing application, or your client has very detailed requirements
Elaborating a little on Christophe's answer:
I would add that analysis and design are two highly intertwined activities, so you would probably see these SSDs in both contexts and it would be perfectly fine and acceptable. Use Cases, those that involve a system, are necessarily a design artefact (they are a design of what the system does in relation to external actors) although you can of course see that same thing as a pure analysis output (telling you what the system is required to do). These things are very hard to separate. The point may seem philosophical (it is somewhat), but it is useful to think in these terms.
When you see people creating "Login" Use Cases you can bet they already stepped into pure design, in other words: functional decomposition. In analytical terms the state of a User being logged in is a constraint on a Use Case, not a Use Case itself. Having a Use Case called Login therefore represents only a design choice (incidentally, if you see this in contexts where there is a division of responsibilities between the people performing analysis and design, then you'd do well to consider it an analysis fail: the analyst is essentially designing the system and that's not their role). Analysts sometimes use Use Cases to model layers of requirements that relate only to business processes, usually referred to as "Business Use Cases", that don't involve any system per se. But the origins of Use Cases from 20-odd years ago was in the system space.
I would like to know:
how to convert users stories into sequence diagrams?
and what is the most easy diagram to understand (for customer)?
Traditionally, a use case is converted into sequence diagrams (through a "use case realization" collaboration for traceability). User stories are different from use cases in that the latter provide a set of distinct steps to take whereas the former concentrate on a need and reason.
If you were to to take a use case, each of the steps in the use case would be represented by messages in the sequence diagram. The use case actor (the "user" in the user story) would be the initiating timeline and a second timeline would be the "system". You could then iterate on that sequence diagram to extract various system components (thereby building a domain model for your application).
Does that make sense to you?
how to convert users stories into sequence diagrams?
There is no straightforward easy way. There is not enough information as user story is basically one or few sentences of text. Converting use cases to sequence diagrams is easier and can be partially automated
what is the most easy diagram to understand (for customer)?
it depends on who is the customer. In general, overview diagrams, e.g. BPMN style should be easy to read. See my answer to the question "UML diagram for dependency between systems" for some options and useful links
suggested readings
Enterprise Architect video - how to convert use case into a diagram -http://www.sparxsystems.com/resources/demos/use-case-analysis/structured-use-case-scenarios.htm
Enterprise Architect - various ways how to capture requirements and communicate them to stakeholders - http://www.sparxsystems.com/products/ea/requirements.html
Mike Cohn's page (defined the term "user story") about user stories - http://www.mountaingoatsoftware.com/agile/user-stories
Alistair Cockburn's page (defined the term "use case") about use cases - http://alistair.cockburn.us/Use+Cases
Some examples of tools for creation of sequence diagrams: https://www.websequencediagrams.com/, http://creately.com/diagram-type/uml-sequence-diagrams, you can Google out many more examples both free and payed both online and offline
In my opinion, what works best with the customers are not use cases. They are too abstract and complicated even for the most of developers. And when they are finally approved, you're never sure whether the customers actually understood them correctly.
I suggest the mix of UML activity diagrams and user interface prototypes (non UML) as far the best tool to work on this level of analysis with non technical business people.
Activities model their business in an intuitive, easy to understand and clear way.
UI Prototypes as well, so they can see how they business maps to screens.
Behind the curtains, I like to support activities with a formal and accurate domain class model, invisible to customers of course, but open to developers and making a nice technical backbone of the future system.
User stories fit perfectly in this modelling set, you can even make them less formal and more high-level, as the rest will fill the information gap. Sequences can now be build using domain objects, connecting 2 views - customers' and developers'.
I avoid use cases strongly, whenever possible (although I personally like them).
I am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.
Where can one find thorough documentation and UML diagrams of popular software? I've searched around and have found very few examples. I'm sure most of this documentation will be private for enterprises, but maybe there are a few links around?
Cheers!
You will not find such a document except if you work at MOF level like Omondo EclipseUML does.
There is also a dilemma in UML.
Should UML just be a view of a problem and therefore only covers a specific view of a software or should it cover the full project ?
UML has been stuck during many year by Model Driven Development which is a code generation from a model. It is therefore one shot modeling which could not be reused. The problem is that to complete a project you can not just generate a code from a model you need to complete the code by hand !! This is why MDD and UML is useless.
Your question is really good because why don't we just use an existing model which is specific to a business, arrange the model as much as needed and then generate the code ?
I think reusable models do not exist because too many transformation layers between graphical model, views, metamodel , MOF etc.....
Projects would be developped 10 times faster if reusable models and architecture would be robust. So why no free model exist today ? It is always question of money :-)
If no money then you need to use open source but open source is crap MDD. It is not a full model but just a specific view of a problem while you need full project to generate usable code !!
Omondo has done a courageous initiative to cover the full project by reversing all model information inside a MOF model and then giving views of the model using multiple class diagrams. Class diagram is live syncrhonized with the code and MOF. The problem is that you need to pay for the tool and consulting companies are selling their business models build on the top of MOF. The UML tools have less and less value but models could be a lot more profitable market in the near future.
I am fairly new to this discussion but I HAVE to ask this question even at the risk of sounding 'ignorant'. Why is it that we now stress so much on 'DDD'. The more I look into 'DDD' the more complex it seems to make my application. Whereas modeling my domain with the database helps keep my application consistent across layers. Then I can use DAL Helpers such as SubSonic or L2S to easily access that model. What is so bad about this? Even in enterprise applications?
Why do we strive to create a new way of modeling our domain when we have a tried and tested one?
I am willing to hear from the purists here.
You can't sell an old methodology, because too many projects failed and too many people know the old methodology anyway. There has to be a new one to market.
If you're doing fine with the old way then use what works. Do pay attention to new stuff, as some really nice ideas come along. But that doesn't mean everything old is bad and stupid. Usually you can incorporate new ideas into the old models to a large degree.
There does come a time to make a move. Like I wouldn't do OOP with structures and function pointers. ;-)
This is actually a really excellent question, and the short answer is "you can." We used to do it that way, and there was a whole area of enterprise (data) modeling. In fact, the common OOD notations evolved from ERD.
What we discovered, however, was that data-driven designs like that had some difficulties, the biggest of them being that the natural structure for a data base doesn't necessarily match well to the natural structure for code.
OOD, to a great extent, derives from the desire to make it easier to find a code structure that has a couple of desirable properties:
it should be easy to think out the design
it should be robust under changes.
The ease to think out design comes originally from Simula, which used what we now think of as "objects" for simulation specifically; it was convenient in simulation to have software entities that correspond to the things you're simulating. It was only later that Alan kay et al at Xerox saw that as a more general structuring method.
The part about robustness under changes had many parents, but one of the most important ones among them was Dave Parnas, you wrote several papers that identified a basic rule for modularization, which I call Parnas' Law: every module should keep a secret, and that secret is a requirements that is likely to change.
It turns out that by combining Parnas' Law with the Simula idea of a "object" as corresponding to something that can be identified with the real world, you tend to get system designs that are more robust under requirements changes than the old way we did things. (Not always, and sometime you have to be crafty, as with the Command pattern. Most objects are nouns, thing that have persistent existence. In the Command pattern, the ideal objects are verbs, things you do.)
However, it also turns out that that structure isn't necessarily a good way to represent the underlying data in a relational database, so we end up with the "object relational impedance mismatch" problem: how to represent the transformation from objectland to database-land.
Short answer: if all you need is a CRUD system that allows users to edit data, just build an Access front-end to your back-end database (or use a scaffolding framework like you mentioned) and call it a day. You should be able to lop off 70% of your budget vs. a domain-driven system.
Long answer: with a data-driven design, what does the implementation of the business model look like? Usually after a couple years of building on new features to your application, you'll find that it's all over the place: tables, views, stored procedures, various application services, code-behind files, presenters/ViewModels, etc. with duplication everywhere. When you're having a conversation with the domain expert about a new feature they are requesting, you are constantly trying to translate from the business language into the language around your implementation, and it just does not translate.
What typically ends up happening is that you are forced to communicate with the business in terms of the implementation of the system, and the implementation becomes the "ubiquitous language" that the business and developers are forced to use when communicating. This has a wide range of consequences. The domain experts in the business start believing that they are experts in the implementation domain, and they start demanding features in terms of implementation rather than the business need they are trying to solve.
Also, you'll find that most data-driven implementations do not follow the "conceptual contours" of the domain, and the components of the system aren't very flexible in how they can be combined together to solve the problem, because they don't map one-to-one with concepts in the business model. When code isn't cohesive, changes and new features may require modifications all over your implementation.
Domain Driven-Design provides tools for making your implementation so closely resemble the business model that it's easy for everyone to speak the language of the business. It allows you to write "executable specifications" that test your implementation, but can actually be understood by your domain experts.