Tag Info

Hot answers tagged

19

The design phase is a vital part of the software development process; if you cannot design software, you cannot develop software, and shouldn't be calling yourself "software developer" ("programmer" would be more appropriate). However, designing software is not about diagrams and flowcharts. It is about figuring out solutions to a given problem on an ...


12

Designing the architecture of your project is the real assignment and they surely taught you the general principles, or they want you to learn those by yourself, practicing. Anyway, a first approach could be: Study your specs. Underline specific nouns in blue. They are probably your classes/objects/properties. Underline specific verbs in red. They are ...


11

If a nucleotide has no significant behavior, and if its type information can be represented compactly (for example, a single character), then it doesn't deserve a separate class at all. Simply represent each nucleotide as a character (or whatever). If, however, a nucleotide has behavior, then I would model this with singletons, one instance per nucleotide ...


9

Planning is critical, but as the famous strategist Carl von Clausewitz warns No campaign plan survives first contact with the enemy So its not a huge waste of time for planning how to initially attack the problems. But likely a waste of time for documenting your code for future programmers. To use a military metaphor, you need a battle plan, but you ...


9

I think UML diagrams can only be useful if they express something in a higher level of abstraction than your code. Writing UML just for the sake of writing UML becomes unneeded bureaucracy and makes the project and the code less adaptable to changes with no benefit whatsoever. For example, a UML class diagram showing all the classes on a package, with all ...


9

I had to deal with this a couple times. The first time I used option 2 (events) and as you said it became really complicated. If you go that route, I highly suggest you need very thorough unit tests to make sure the events are done correctly and you're not leaving dangling references, otherwise it's a really big pain to debug. The second time, I just ...


8

When I implemented a History<T> class (a sorted list of date values associated with some data of type T, allowing for old values to be dropped when new one's come in and a maximum size was reached etc.) I did it as a wrapper class around SortedDictionary<DateTime, T>. Because this collection implements IEnumerable, you can use LINQ's extension ...


8

XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even ...


8

UML has value if team members collectively understand it and consider it a useful way of summarising and communicating design decisions. You don't need to know it all, just that subset that the team finds useful. Also, you don't need to draw perfect, polished diagrams. A roughly-sketched sequence diagram on a whiteboard or a class diagram in which classes ...


7

The developers should in my opinion always be active in the design. Why? Because they are the ones implementing it. If you have dedicated designers, those designer should also code. It's kind of an eat your own dog shit thing. It's also not necessarily the best thing to do a large upfront design. Uncle Bob talks a lot about user driven design, and user ...


7

Recursive composition (or aggregation) is simply the composition or aggregation arrow looped back to the individual class. You can use the multiplicity notation to indicate any "can have" or "must have" relationships. Figure 8 of Scott Ambler's tutorial on class diagrams provides an image of this.


6

It actually depends on the level of details in the class diagrams and the way they are used. An important distinction that has to be made: a UML class is not (necessarily) the same as a programming language class. It denotes domain concepts that may be implemented in many different ways (or not at all). Defining these concepts is a job for the domain ...


6

You need to specify more description of your tables and of your requirements. Anyway, here is one way to model the tables. However, in a real application there would be other things to consider. Only PKs and FKs are shown. Other columns depend on your case.


6

Wrong is a big word. The reason why you shouldn't put it in the DB, is because the vocabulary of (most) DB systems is incredibly limited. There is nothing about "SELECT", "INSERT", "UPDATE", "DELETE" that allows you to fluently express why something is happening and to what it is a reaction, in domain language terms. As to the second part of your question: ...


6

In your specific scenario, a Parent should have a DefaultChild. The problem with giving a child an IsDefault property is that it A) allows for Parents with multiple default children and B) disallows Parents of the same child to have different settings for their child. The fact that neither of these scenarios can actually happen is irrelevant; both scenarios ...


5

The mismatch between internal and external names definitely smells. Like Rinzwind points out, the homophones and synonyms smell the worst. The real question you need to answer is: What is the cost/benefit tradeoff in making the change? The cost of not changing is a steeper learning curve for new team members and increased likelihood of future bugs. The ...


5

Go read Code Complete, Second Edition. It has a lot of advice about software design, and almost all of it is very, very applicable to procedural code. (The original edition of the book came out before OO code was popular.)


5

I once worked on a gig where I needed to manage a team of contract developers overseas. Some of the stuff they were producing was pretty horrendous (a common symptom of remote contract coders - they don't really care a lot for your code, they just want to get done fast). To manage the project, I found myself producing UML diagrams and handing it to them to ...


5

All the documents you described will work to describe your system from the perspectives they capture. A class diagram is to show the structure of your project without needing to see the code, the fact your code is very structured is irrelevant. A DFD does not need to have a data storage listed, not all systems store data, but its still important to map how ...


5

Activity diagrams don't use the concept of objects, as they usually don't show who does what, but only which actions/decisions are taken. You could use partitions (also called swim lanes) to indicate who executes the actions, but if you have more than two or three objects interacting, this can become rather unreadable. For describing the interactions ...


4

UML is not just for OOP. Modularity and separation of concerns comes into play in any large scale system and it doesn't matter whether your language falls into the procedural, functional, declarative, or object oriented paradigm. There is no reason you can't adapt the concepts and diagrams in UML to document whatever software you're developing.


4

There are two common ways of going about this sort of thing: Non-normalized, with a status field and a result field. The status field can be a bit, char(1), char(3), whatever, it doesn't matter. You allow NULL values in this field but more importantly you put a constraint on it - this is how you prevent garbage like "ja" and "yyy" from going into it. ...


4

Writing programs on a larger scale is much like writing programs on a smaller scale. You just have more classes, that's all. To solve a larger problem, you break it into smaller pieces, and deal with the pieces individually using separate classes. I think the best way to begin the learning process of tackling large projects is by studying design ...


4

I'm not an expert on diagramming, but I like using shapes with multiple points to specify an alternative path, such as Diamonds or Triangles


4

If the flowchart for one function is so complex that it is difficult to understand, then the function is too complex. Consider the Refactoring pattern called "Extract Method." (It can be used on non-OO procedural functions too.)


4

Personally, I'd recommend Eric Evan's: Domain Driven Design This book gives a good history of modeling and quickly get's into best practices, with a bias on having a domain model in place, separate from infrastructure and UI layers. While this sounds very obvious, you'd be surprised at the number of apps out there that don't follow it and the developers ...


4

Is it normal for a domain expert to do class diagrams? If a domain expert does class diagrams in the traditional sense*, then the answer is "absolutely not". You should resist this as much as you can, for everyone's benefit. I have been in a situation like that in a start-ups many years ago, where a very strong domain expert has been trying to map a ...


4

It really smells to me like you want an ICartItem interface. If it's contract needs changing, every single implementer will break the build until they all have been updated appropriately, so it'll keep you honest. If you're in a dynamically typed language however then I would say the same thing except as an interface exists to be a contract that keeps ...


4

Why don't you just use interfaces? If you're concerned about sharing functionality, you can use extension methods to serve as your pseudo-base class. It's not exactly ideal, but it should get what you're looking for done. Something along the lines of: public interface IAnimalWithSuperPower { public SuperPower power { get; set; } } public class ...



Only top voted, non community-wiki answers of a minimum length are eligible