Related
I'm not sure if this is the right place to ask this question but here goes.
I'm currently looking into some different techniques to model a business proces. I need to find a suitable option for my company which develops all kind of web applications.
What i have found so far:
UML, specificly the activity diagrams
Flow charts
Windows workflow foundation
Business process modeling
I had a dive into the world of workflows but it's mainly about automating a process of a company and thats not what I'm looking for. My focus is on software and the process within.
If anyone else knows some other technique or can tell me the advantages or disadvanteges of the techniques I allready found that would be much appreciated because I'm a little stuck right now.
Right now BPMN (Business Process Modeling Notation) and UML activity diagrams are the two most popular options for that.
I think of BPMN as the right choice when you are modeling the business aspects of the organization and move to Activity Diagrams as soon as you drill down to the technical design of the software system (as a core component of the UML language, activity diagrams are a better fit when having to combine workflow information with other views of the system, expressed also as UML diagrams like class diagrams or sequence diagrams).
Note that now a UML profile for BPMN is being created which means that you will be able to mix BPMN and UML diagrams in the same project
I suggest you consider ISO/IEC 24744. It will give you a very different perspective, since it does not use the ubiquitous "organisation as machine" metaphor, going for a more opportunistic, people-oriented viewpoint.
In other words, ISO/IEC 24744 does not represent a business process as a workflow where the process to follow is the driver. Instead, a business process is represented through the work products that are involved and the people that act upon them. The process performed plays an important but secondary role.
If you are interested in why this is so, or what the advantages are, let me know and I'll be happy to elaborate.
I think you are asking about transforming your business requirements/rules into technical requirements and then into a design? After that you will implement this design into code.
Am not sure if this is what you are asking about..
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.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I want to ask you to provide me with some articles (maybe books), which you possibly have found very convincing criticising the OOP methodology.
I have read some in the WWW on this topic and I didn't really find a 'definitive demotivator'.
It's not much about my personal attitude to the OOP, but I really would like to have something constructive, rigorous foundation for any kind of discussion and just abstract thinking.
You can post some original research too, but please be very constructive (as my personal request).
Which version of OOP? Alan Kay's original vision? The bastardized modern form of it that misses the point entirely and thus encumbers us with bizarre access control, member variables, etc? Inheritance-centric? Prototype-based? Compositional OOP?
Each form of OOP has its strengths and its weaknesses; its advocates and its detractors; its domains of utility and its domains of uselessness. There's nothing magical about OOP that makes it the Killer Paradigm and there's nothing infernal about it that makes it the Killer (of Programmers) Paradigm.
I can't really point you to any books or articles that killed my interest in OOP as a Silver Bullet (as opposed to one of many techniques I can use to keep my projects survivable). I can point to the funniest critique of a specific brand of OOP, however: Steve Yegge's classic "Execution in the Kingdom of Nouns".
Rick Hickey's Are We There Yet ? - A Deconstruction of Object Oriented Time was an eye opener for me. It's the most logical OO criticism I have come across.
If you want a criticism of OO programming, here's what I'd recommend:
Learn Smalltalk
Learn Erlang
Learn Scheme
Once you've done that, you will have plenty of criticism of the common interpretation of OO programming.
(Hint: OO was in many ways intended to more closely resemble the Actor model of computation, but the common interpretation of it is effectively a modification of the procedural/structured model)
Problem is - most people don't really know Object-Oriented Programming, so many designs SUCK.
Read the works of Scott Ambler, including his (now pretty old) Building Object Applications That Work. This has been eye-opening for quite a lot of people.
Maybe not quite what you were looking for but have a look at the Jan/Feb issue of IEEE Software magazine: Object-Oriented Analysis: Is It Just Theory?. The basic conclusion is that OOA does not provide a good cost/benefit ratio so is poorly utilized.
Given that OOA is not effectively utililzed or supported in the "real world", I suspect that for larger development projects the overall system architecture, deployed object model and class hiearchy end up being sub-optimal and poorly understood (implemented) by various parts of the development team. A second article in the same journal: Four Trends Leading to Java Runtime Bloat point to some common OOP issues that detract from deploying high-volume Java (OOP) systems. The observations made in this article probably apply to most highly architected OOP applications.
Do not take this as OO bashing, it just reflects that as software practictioners we have quite a bit of work to do toward developing better person-to-person communication mechanisms to convey highly complex and abstracted process models.
When you define a process in natural language. You use sentences where you define the subject who will do an action on one or more objects.
The only fix point is the action, the predicate of the sentence.
I don't think assigning actions to objects is a good idea.
There is only one verb, but can be multiple nouns.
In OOP you can write a file in at least 3 ways:
file.write(data);
or
data.writeToFile(file);
or
OperatingSystem.write(file, data);
Which object should implement the method? You need to think about this too.
While in the procedural way, you probably write
write(file, data);
And the only thing you need to think is the order of the operands which is usally does not matter.
(Well file and data may not be the best example but you probably see the point)
You should really see Mr. B. Jacobs's:
OOP Myths Debunked
(also known as OOP Oversold.)
http://cat-v.org has a great page on Object Oriented Programming.
Most of the page consists of humorous but not terribly informative quotes. However, at the bottom of the page are a number of links to articles challenging OOP. They are:
Bad Engineering Properties of Object-Oriented Languages by Luca Cardelli.
Why OO Sucks by Joe Armstrong
Pitfalls of Object Oriented Programming – By Tony Albrecht of Sony Computer Entertainment Europe, Research & Development Division.
Object-Oriented Considered Harmful by Frans Faase.
Object Oriented Programming Oversold!
I Hate Patterns – By Parand Tony Darugar.
Why arc Isn’t Particularly Object-Oriented – By Paul Graham.
The questions about inheritance in the Java IAQ.
Stop Writing Classes – Great talk about how classes are often used and abused. By Jack Diederich.
If you are interested in alternatives to Object-Oriented Programming:
cat-v.org. From their 'about' page: Cat-v.org hosts a series of sites dedicated to diverse subjects that share an idiosyncratic intellectual perspective, questioning orthodoxy and fomenting elitism and high standards in topics from software design to politics, passing by art and journalism and anything else interesting.
Structure and Interpretation of Computer Programs. Specifically teaches functional programming. Available free online here, for sale here. I cannot recommend this highly enough. It is absolutely revolutionary. It will change the way you think.
Any and all writings/videos/lectures by Rob Pike and Steve Yegge. Of particular interest is Yegge's Whirlwind Languages Tour.
I'd recommend learning a different programming paradigm or reading pro arguments for specific paradigms (http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf). Besides OOP, I think the most widely used is the functional paradigm (search f.e. "Why functional programming matters"), but also have a look at the other ones. When you start looking at programming from a different perspective, the flaws of OOP start to appear automatically.
Simple exercise: define the objects IPerson, CMale and CFemale and implement the methods "sex" and "reproduce".
hows about steve yegge's execution in the kingdom of the noun
for java style OO
The Gideon Bible of object-oriented design patterns, aptly named Design Patterns. One of the best software design books I've ever read.
I am currently trying to draw a set of UML diagrams to represent products, offers, orders, deliveries and payments. These diagrams have probably been invented by a million developers before me.
Are there any efforts to standardize the modeling of such common things? Or even the modeling of specific domains (for example car-manufacturing).
Do you know if there is some sort of repository containing UML diagrams (class diagrams, sequence diagrams, state diagrams...)?
There is a movement for documenting (as opposed to standardizing) models for certain domains. These are called analysis patterns and is a term Martin Fowler came up with. He actually wrote a book called Analysis patterns. Also, he has a dedicated section on his website where he presents some of these patterns accompanied by UML diagrams.
Maybe you'll find some inspiration that will help you in modeling your domain. I've stressed the word inspiration as I think different businesses have different requirements although they operate the same domain so the solutions you might read about may not be appropriate for your problem.
There are many tools out there that do both - but they're generally not free!
Microsoft Visio does both and is extensible. For UML artefacts they come with auto generators into VB/Java template code - but you can modify them to auto-generate any code. There are many users of Visio that have created models from which to use as templates.
Artisan Enterprize is by far the most powerful UML tool (but it's not cheap).
Some would argue that Rational Rose or RUP is the better tool
But for Car-Manufacturing and other similar real world modelling, by far the best tool is Mathworks Simulink (not because it's one of the most expensive). It is by far the best tool beccause you can animate the model - you can prove the model working before generating the slik code (in whatever grammar/language/other Models you care to push it)!
You can obtain a student license for around £180; with the 'real thing' pushing £4000 (for car-related artefacts). The full product with all the trimmings is about £15k. Simulink is also extensible with a C like language though there is a .Net addin and APIs to use a plethora of other langhuages. And, just like Visio there is a world-wide forum creating saleable, shareware & freeware real world model templates. Many world-wide Auto-Manufacturers are already using Simulink.
I think that MiniQuark question is really good and will sooner or later be provided by vendors such as Omondo, Rational IBM etc... Users doesn't just need tools, they need models out of the box and just add their business rules inside an existing well defined architecture. Why to develop from scratch a new architecture if the job has already be done ? In Java we use plenty of frameworks, existing methods etc...so why not to go one level higher and reuse architecture ? It is today impossible to guess how a project will evole and new demands are coming every day. We therefore need a stable architecture which has been tested previously and is extensible. I have seen so many projects starting with a nice architecture then realizing in the middle of the project that this is not what is the best and then changing their architecture. Renaming classes, splitting classes, creating packages etc...after the first iteration it is getting a real mess. Could you imagine what we found after 10 iterations !! a total mess !!
This mess would had been avoided if using a predefined model which has been tested previously because the missing class, or package etc..would have already been created and only a class rename would be sufficient for architecture purposes. Adding business rules methods will end the codding stage before deployment test.
I think there is a confusion between patterns and the initial question which is related to UML model re usability.
There is no today any reusable model out of the box which has been developped. This is really strange but the job has never been done or never been shared.
Omondo has tried to launch an initiative without real success. I have heard that they are working on hundred of out of box models which will be open source and given for free to the community. I hope this will be done because this is really important for me and would save me a lot of time at the beginning of a project.
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.
I'm a confused newbie and hobbyist programmer trying to get a grip on this, so forgive me if my question is a little off or doesn't make much sense.
I see a lot of questions on SO revolving around the use of design patterns, and I'm wondering if anyone has a good resources for learning about, and implementing design patterns? I understand the general idea, and know how/when to use a couple of them(Singletons, Factory methods) but I know I'm missing out.
(Just in case it matters, my language of preference is C# but I could learn from examples in other languages)
Head First Design Patterns
and the Design Pattern Wikipedia page are the best resources for beginners. FluffyCat is another good, free online resource for design patterns in both Java and PHP.
The Gang of Four book is where to go afterward, but it's fairly advanced, so I'd wait until you have a pretty firm grasp from the other resources.
Design patterns are great for various reasons:
gives you a starting for solving common problems.
gives developers a vocabulary to talk about certain ways of solving problems in a very compact manner.
when working with developers who know design patterns and you use design patterns in your solutions they will understand the solutions a lot faster.
But when your goal is just to learn design patterns I think you are missing the fundamentals. All design patterns are based on more common principles. High Cohesion, Low Coupling Open Closed Principle, DRY, Liskov Substitution Principle etc. For these fundamentals I would read the following books in this order:
Head First Object-Oriented Analysis and Design (Head First) [ILLUSTRATED] (Paperback)
Applying UML and Patterns (Hardcover)
Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series) (Hardcover)
After that you are ready for the basic gang of four design patterns
Head First Design Patterns (Head First) [ILLUSTRATED] (Paperback)
The BIBLE
A nice website (don't buy anything, it is not worth it) http://dofactory.com/Patterns/Patterns.aspx (some implementations of this site are worth a discussion
The next step:
Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) (Hardcover)
The POSA books
And always remember : the pattern is not the goal !
I'd add that Design Patterns book from the "Gang of four" is a bible for anyone who is seriously interested in design patterns.
My tip:
Read a lot about the patterns from different sources.
Trying to force as many patterns as possible into all the code you're writing as this point is not going to give good results. Instead, let the information rest inside your brain for a while (read: months).
Suddenly you'll find yourself stumbling upon a problem or piece of code and you'll vaguely remember that you've seen something that might work as a solution to this particular problem. Now is the time to look up the details on the pattern you are thinking of and try to apply it.
That's what has worked for me, anyway.
Design Patterns
This tutorial site contains following sub-sections
Intent of each design pattern
Real World Structure for the design pattern
A Problem statement
Detailed discussion on the problem
Checklist on how to arrive at a pattern
Rules of thumb while arriving at pattern.
Code snippets for the design pattern which includes C#, C++, Delphi, Java and PHP
This site also contains guide on Anti Patterns, UML and Refactoring.
Bruce Eckel has a book on design patterns, although it's Java, it's like all of his books amazing. And the best thing is, they are free!
C# 3.0 Design Patterns for a C# perspective on design patterns.
(source: oreilly.com)
An introductory book that I found useful and well written is
Design Patterns Explained by Alan Shalloway and James Trott (Addison Wesley).
Do not start from the Gang of Four book, for it is not an introductory book by any means.
I would recommend taking a look at Jean Paul Boodhoo's quintology (?) on Demystifying Design Patterns on DNRtv, urls supplied below. The videocasts touches on Singleton, Abstract Factory among others- the difference being that you can watch him code as he discusses the theory. Good to watch over lunch on a rainy weekday.
http://www.dnrtv.com/default.aspx?showNum=63
http://www.dnrtv.com/default.aspx?showNum=65
http://www.dnrtv.com/default.aspx?showNum=68
http://www.dnrtv.com/default.aspx?showNum=71
http://www.dnrtv.com/default.aspx?showNum=92
An annotation to the above comments.
A Quick Reference For GOF Patterns
Here is a good place you can start dofactory.com/patterns/patterns.aspx - You can find link to each pattern, along with corresponding implementations.
How ever, remember that these are GOF patterns. You might need to read and understand advanced patterns as well, once you gain enough expertise in OOAD. Head First Design Patterns is a good start, and after making some progress, go with Martin Fowler's Enterprise Application Architecture Patterns.
Applying Design Patterns - The Thought Process
Another main aspect - Applying Design patterns is as important as just knowing them. Reading these articles might help you as well.
Applying Design Patterns Part I
Applying Design Patterns Part II
Hope this helps
Head First Design Patterns is a good one like others already noted. Besides this, of course the original book and C# Design Patterns. Also there are good websites already mentioned.
Besides self-learning, I seriously recommend starting or attending a pattern study group in your area. See A Learning Guide To Design Patterns for explanation and great order to study the patterns in. We did this and I can honestly say that I would not understand as much as I do now. A weekly meeting with other interested people keeps you surprisingly disciplined when learning something abstract like design patterns.
Happy studies!
Before spending money on books I would recommend Wikipedia's excellent design patterns page. Also for something different Google for "design pattern screencasts" or search for "design patterns" on YouTube. Getting the same information presented differently often helps the penny drop.
The Gang of Four book is the definitive text on the most well known patterns but is not that easy to read and with C++ examples not everyone's favourite.
The Head First Design Patterns text is far more accessible but only contains a subset of the Gang of Four patterns.
The most important thing is to understand where and why a particular pattern is useful. Afterwards search the web for implementation examples in the language of your choice and experiment until you "get it". Understand one pattern before moving on to the next. Everyone understands some patterns better than others (and there are hundreds of lesser known ones).
Just keep plugging away.
(source: Amazon)
Patterns of Enterprise Application Architecture (Hardcover) by Martin Fowler
Refactoring to Patterns (Hardcover) by Joshua Kerievsky
Continuous Integration: Improving Software Quality and Reducing Risk (Paperback) by Paul Duval et.al.
Beyond Software Architecture: Creating and Sustaining Winning Solutions (Paperback) by Luke Hohmann
Design patterns are like any library function, read about them, then when a problem comes up, the design pattern will be in your "Toolchest". There are many design patterns books all patterned after the original "Gang of four" design patters.
For any programmers, I think that and the Refactoring book by Fowler are the absolute minimal requirements.
For websites, a very good site is http://ajaxpatterns.org, from one of the developers of the ajaxian website
The original Design Patterns book is a must-read for all programmers.
It is an excellent book on every level: layout, clarity, insight, depth. It's one of those great books that you first read cover-to-cover, and then use as a reference until you literally know it inside out.
You could start by the Wikipedia page, but treat yourself with the great book too.
Applying UML and Patterns by Craig Larman. Start from the basic of analysis, design and uses a simple Case scenario. Introduces most of the basic patterns in a simple way.
If you read about design patterns you'll notice that Java seems to have a few of them implemented.
Look at the source for any framework and you can glean info about design patterns. Personally I don't see them fitting in perfectly to any of my code, sometimes the examples in books and tutorials seem a little idealized, especially for the lone coder.
Design patterns aren't for lazy coders.
For me and my colleagues study Design Pattern that following on Pattern Study Group. They prepare a list of each pattern that we should learn in order and also have the opening questions that make more discussion in group.
I also suggest having a shufty at Refactoring to Patterns once you've read Head First Design Patterns.
Note: The code examples are in Java, but should be very similar to C# examples...
It does not make too much sense to me for someone with very little experience to delve too far deeply into design patterns. It is great to know they exist, but at this point you should focus more on other things rather than just learning about design patterns.
They are useful in context of a problem - as a concept for a new/beginner developer they are really not too much practical value aside form knowing that you should make use of them when and where you can.
EDIT
To clarify - many design patterns are a result of problems found in some domains. A new programmer can hardly be expected (IMO) to know the design pattern(s) to use for some set of problems. Just as we get a smattering of algorithms in CS studies, we need an understanding of the things we can do with patterns and their benefits, but when a person is still building hello world or discovering stl there is not much practical need for design patterns. Patterns are great. But they are not the silver bullet.
(Neither was CASE (tools), neither is/was UML, neither is SCRUM, neither is TDD, nor STL, nor Java, nor XML, etc. ) These are all just aspects of our profession and to treat these topics as the second coming is naive.
Patterns comprise the high level vocabulary programmers use to talk about abstract design. If you are reusing an abstract solution, it is helpful to refer to it by name. If you invent a pattern, it is professional to do a little checking to make sure it hasn't already been given a name. If it has been named, then the description may be useful.
After you code even a tiny bit, you will notice yourself writing something similar to what you coded before. This is a pattern. Even if it is a tiny pattern, it is worth noticing. Is there a better pattern? Do you see certain tiny patterns cooperating together to solve a larger problem? Well next time, when you want to solve larger problem, the entire pattern comes into your mind as a single chunk. Fleshing out the detailed lines of code becomes mechanical.
The more you notice patterns, the easier programming becomes, and the more you will appreciate some of the biggest and best patterns worked out by other programmers.
Try mastering the MVC pattern. One way or another, variations show up all over the place, even in tiny design decisions.
Once you understand the concept, go through the Eclipse source code or design, lots of really good examples of these patterns (no surprise, Gamma was one of the designers).
I have found Design Pattern articles on this website really easy to understand
Design Patterns in C#
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 find that whenever I begin writing an app in Java/C#, things start off good, but over time, as the app becomes more complex, it just gets more and more complicated. I've become aware of the fact that I'm not very good at design and high level architecture. All my classes become fairly strongly coupled and the design isn't "elegant" at all. I'm fairly competent at "low level" programming. That is, I can get just about anything done within a function or a class, but my high level design is weak and I'd really like to improve it. Does anyone have pointers to techniques, books, etc. that would be helpful in making me a better software engineer?
I disagree about starting with a book on design patterns or refactoring.
In my opinion, for a solid OO design, you should first be familiar with the main OO design principles, then understand how your problem can be represented in those basic principles. Then you can start discovering opportunities for applying design patterns and refactoring techniques in order to achieve those fundamental principles.
I would start with this book:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
In this book, Robert Martin describes the fundamental principles that make a good OO design, all of them related to encapsulation, coupling and modularity:
The Open/Closed Principle
Liskov Substitution
Dependency Inversion
Granularity
Common Closure
Reuse
No Cyclic Dependency
Stability Of Dependency
Abstraction And Stability
After all, almost every Design Pattern and Refactoring technique I have seen documented in GoF and Fowler is aimed at achieving one of several of these basic principles, depending on their relative priority for a given scenario.
Books:
Code Complete, by Steve McConnel
Design Patterns, by Gamma, et. al.
I would start by sketching my design. That sketch could be a box and arrow diagram to show relationships between classes or it could be a variation on UML (or perhaps even standard UML). But I find that sketches help me see that a design is good/bad and maybe even how to fix it.
I would also look at a book on design patterns.
Write a large project and let it spread as big as you can. Then study what you can do to improve your code.
Perhaps single large routines can be clean and understandable too, if they are well-structured.
There's no single good answer on good design. It's actually one of those valuable things a programmer can learn.
You can refactor mercilessly to improve the design of existing code.
The main idea is, at some point the code did make sense, when new features are bring into the code then probably some features or responsibilities must be moved around to another classes, that's fine. Then you stop developing new features and start refacoring your code.
I would recommend you to read:
Refactoring by Martin Fowler
use Object Oriented Design Principles (http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm). also consider some oo design heursitics (http://www.cs.colorado.edu/~kena/classes/6448/s02/lectures/lecture27.pdf)
Try making program outlines and diagrams before you start, and have someone else review and critique it. Then as the program grows, continually update the outlines and diagrams to include the new functionality. Get it reviewed and critiqued by someone else. Eventually, assuming you are learning from the critiques, you will become better at designing programs.
Books and tutorials can only get you so far. While you do need to learn the tools and methods available, knowledge on its own won't help you here. Practice is what will make you better at design, along with having a mentor coach you from time to time to show you how you can better apply some of the knowledge you've gained from the books.
Read the books by all means, but don't feel bad if you write code that ends up having stupidities in it. Everybody does. The question is, can you refactor what you have to fix it? To be able to do that effectively and often, you need to use TDD and write lots of unit tests.
I would highly recommend you try Test Driven Development (TDD). You will find that to make your code testable, and not need to constantly perform rework of your tests, you will need to have a solid design. What you will find is that when you add \ change \ remove functionality, your better designs will require a very small set of changes to a specific set of tests. A poor design will wipe out a huge set of tests - because you have tight coupling, objects responsible for multiple concerns, etc, etc, etc ...
I have found that the better I get at TDD, the better my architecture is, and the better the end result is.
Be advised, TDD takes real mental discipline. You should not expect that you use it for 1-2 days and see immediate results. You will need to really want to do it, and really make the effort - otherwise you won't benefit and likely just end up hating it.
HTH ...
There are a couple of things that you can do
Use tools for high-level and
low level design before you
actually start programming. E.g.
Creating Class UML Diagrams will
help your mind visualize the
solution in a Diagramtic form rather
than Code form.
Familiarize yourself with Java
Design Patterns. E.g. Using
Inheritance Polymorphically to begin
with will warm you up to start using
the standard Java and J2EE design
patterns.
There are a tonne of books and websites pertaining to both the subjects I just pointed out here.
Browse through good API code. For instance Spring framework code.
Read some good books such as Design Patterns (like everyone else mentioned here) and some other books on good practices. For example in Java, Head First Design, Effective Java series, etc.
C++ - Effective C++ series
I would start with : Head first object-oriented analysis and design. and once you mastered it : Head first design patterns.
Obviously, reading some of the recommmended books will help. I think Head First Design Patterns is definitely less abstract than GoF book.
The primary question I ask is "Is this code doing something very specific that could be re-used anywhwere else?" If so, put in in a class in an assembly that allows for re-use.
If you truly are just starting then one thing I used to do was to consider each database table an 'object'. So each database table represents a class. The purists will tell you this is a disaster, but I found it a good way to get myself started thinking in object terms.
Read Head First Design Patterns.