How do you plan your application architecture before writing code?

Question

One thing I come across is planning the architecture of the application before writing the code.

I do not mean collecting requirements that need to be limited by what applications need to do, but rather thinking effectively about a good way to lay out a common class, data and stream structures and repeat these thoughts so that I have a trustworthy action plan before even open the IDE. At the moment, everything is easy to just open an IDE, create an empty project, start writing bits and beans and let the design "grow" from there.

I am collecting UML - this is one way to do this, but I have no experience with it, so it seems a bit foggy.

How do you plan your application architecture before writing code? If UML is a way, can you recommend a short and practical introduction for a small application developer?

I appreciate your input.

Answer 1

I truly believe that writing on paper or on a blackboard is of utmost importance. Then go to UML if you want, but nothing beats the flexibility of simple hand-drawing.

Answer 2

I consider the following:

• what the system should do, that is, what is the problem that the system is trying to solve.
• who is the client and what are his wishes.
• the system must integrate with
• Are there any outdated aspects that need to be considered.
• what user breaks
• etc...

Then I start to consider the system as a black box and:

• What are the interactions that should happen with this black box
• what is the behavior that should happen inside the black box, that is, what should happen with these interactions for the black box in order to exhibit the desired behavior at a higher level, for example. receive and process incoming messages from the reservation system, update the database, etc.

Then it will begin to give you an idea of ​​the system, consisting of various internal black boxes, each of which can be further broken in the same way.

UML is very good at representing this behavior. You can describe most systems using only two of the many UML components, namely:

• class diagrams and
• sequence diagrams.

You might need activity diagrams if the behavior contains a description of parallelism.

A good resource for learning UML is Martin Fowler, the excellent book "UML Distilled" ( Amazon link - sanitized for script kiddie link nazis (- :). In this book you will quickly look at the main parts of each of the UML components.

A. What I have described is largely the approach of Ivar Jacobson. Jacobson is one of the Three Amigo OO. In fact, UML was originally developed by the other two people who form the three amigo, Grady Butch and Jim Rumbo

Answer 3

You should definitely take a look at the Steve McConnell code, and especially in his subject, “Design in Construction,”

You can download it from your website:

http://cc2e.com/File.ashx?cid=336

Answer 4

If you are developing .NET, Microsoft has just published (as a free e-book!) 2.0b1 Application Architecture Guide . It provides a ton of really good information about planning your architecture before writing any code.

If you were desperate, I expect you to be able to use large chunks for a non-.NET architecture.

Answer 5

I will talk about this by saying that I mainly deal with web development, where most of the architecture has already been decided in advance (WebForms, now MVC), and most of my projects are quite small, one person’s efforts that take less than a year. I also know that I will have ORM and DAL for processing my business object and data interaction, respectively. I recently switched to using LINQ for this, so much of the “design” becomes the construction and mapping of the database through the DBML constructor.

As a rule, I work in TDD (test development process). I do not spend much time working on architectural or design details. I collect general user interaction with the application through stories. I use stories to design interaction designs and discover the core components of an application. I make a lot of whiteboard during this process with the client - sometimes capturing details with a digital camera if they seem important enough to stay in the shape of a diagram. Mostly my stories go to wiki history. In the end, stories come together in issues and iterations.

By this time, I am usually well versed in architecture. If it is difficult or there are unusual bits - things that are different from my usual practices - or I work with someone else (not typical), I will draw things (again on the board). The same applies to complex interactions - I can develop a page layout and stream on the board, keeping it (or capturing it with the camera) until it ends with this section. When I have a general idea of ​​where I'm going and what needs to be done first, I will start writing tests for the first stories. Usually it looks like this: “Okay, for this I need these classes. I will start from this and it needs to be done.” Then I start fun TDDing and the architecture / design grows out of the needs of the application.

Periodically, I find that I want to re-write a few bits of code or think “it really smells”, and I will reorganize my project to remove duplication or replace smelly bits with something more elegant. Basically, I am interested in disabling functionality, following good design principles. I find that using well-known patterns and paying attention to good principles as you go works well.

Answer 6

http://dn.codegear.com/article/31863

I use UML and I think the manual is very useful and easy to read. Let me know if you need something else.

Answer 7

"Whiteboards, sketches, and Post-it notes are great design tools. Sophisticated modeling tools tend to be more distracting than lighting." From Flexible Developer Practice by Wenkrath Subramaniam and Andy Hunt .

Answer 8

UML is a designation. This is a way to write your design, but not (in my opinion) do the design. If you need to write something, I would recommend UML, although not because it is "the best", but because it is a standard that others probably already know how to read, and it strives to invent its own "standard "

I think the best introduction to UML is still UML Distilled by Martin Fowler because it is concise, gives the right guide on where to use this, and makes it clear that you don’t have to buy the whole UML / RUP story so that it was helpful.

Making design is difficult. It cannot be captured in a single StackOverflow answer. Unfortunately, my design skills, such as these, have evolved over the years, and so I don’t have one source that I can link to.

However, one model that I found useful is reliability analysis (google for it, but there it is ). If you have your precedents for what the system should do, a domain model of what is happening, then I found a reliability analysis of a useful tool for connecting the two and developing what the key components of the system should be.

But the best advice is read widely, they think and practice a lot. This is not a purely trained skill; you must do it.

Answer 9

I’m not sure that something can be planned in advance before its implementation. I have 10 years of experience, but it was only in 4 companies (including 2 sites in one company, which were almost polar opposites), and almost all my experience was in terms of observing a huge cluster ****** * * s. I am starting to think that things like refactoring are really the best way to do something, but at the same time I understand that my experience is limited and I can just react to what I saw. What I really would like to know is how to get the best experience so that I can come to the right conclusions, but it seems that there is no shortcut, and this is simply due to a lot of time when people do something wrong: (. "I really like working in a company where people are doing everything right (as evidenced by successful product deployments) to find out if I'm just a smuggled bastard, or if I'm really as smart as I think I am.

Answer 10

I'm not smart enough to plan more than a little. When I plan ahead, my plans always go wrong, but now I have spent n days on bad plans. My limit is about 15 minutes on the board.

Basically, I do as little work as possible to find out if I'm heading in the right direction.

I consider my project for critical questions: when A makes B to C, will it be fast enough for D? If not, we need a different design. Each of these questions can be answered with a spike. If the spikes look good, then we have the design and the time to expand it.

I have the code as soon as possible in order to get some real value for the client as soon as possible, so the client can tell me where I should go.

Because I'm always wrong, I rely on refactoring to help me understand them. Refactoring is risky, so I have to write unit tests when I go. Writing block tests after a fact is difficult due to communication, so I write tests first. Staying disciplined about this is difficult, and the other brain sees things differently, so I like to have a friendly code with me. My coder buddy has a nose, so I swim regularly.

Let me call it Extreme Programming.

Answer 11

I ask you to distinguish: UML can be used for application architecture, but it is most often used for technical architecture (frameworks, class diagrams or sequences ...), because it is there that these diagrams can be most easily synchronized with development.

The architecture of the application arises when certain functional specifications are fulfilled (describing the nature and workflows without any assumptions about a future implementation), and you convert them into technical specifications.

These specifications are the applications necessary to implement certain business tasks and functional needs.

So, if you need to process several large financial portfolios (functional specifications), you can determine that you need to divide this large specification into:

• dispatcher to assign these heavy computing to different servers
• to ensure that all computing servers are up and running before starting these portfolios.
• GUI to show what is happening.
• A “common” component for developing specific portfolio algorithms, regardless of the rest of the application architecture, to facilitate unit testing, as well as some functional and regression tests.

Basically, thinking about application architecture is to decide which “group of files” you need to develop in a consistent way (you cannot develop a launcher, GUI, dispatcher, ... in the same group of files: they cannot develop at the same pace)

When the architecture of an application is well defined, each of its components is usually a good candidate for a configuration component, which is a group of files that can be updated as everything in VCS (version control system), which means all its files will be marked together every time when you need to record a snapshot of this application (again, it would be difficult to identify your entire system, each of its applications cannot be in a stable state at the same time)

Answer 12

I try to break my thinking into two areas: the representation of the things that I am trying to manipulate, and what I intend to do with them.

When I try to simulate the material that I am trying to manipulate, I come up with a series of separate element definitions - on the e-commerce site there will be SKU, product, client, etc. I will also have some intangible things that I work with - an order or a category. As soon as I have all the "nouns" in the system, I will make a domain model that shows how these objects are related to each other - the order has a customer and several SKUs, many skus are grouped into a product, and therefore on.

These domain models can be represented as UML domain models, class diagrams, and SQL ERDs.

As soon as I have nouns, I move on to verbs, for example, to operations that each of these elements go through to complete an order. As a rule, they are very well suited for use from my functional requirements - the easiest way to express them, which I found, are UML sequence diagrams, activity or collaboration diagrams or swimming map diagrams.

It is important to think of it as an iterative process; I will make a small corner of the domain, and then work on the actions, and then come back. Ideally, I will have time to write code to try something like that, because you never want the design too far ahead of the application. This process is usually terrible if you think you are building a complete and final architecture for everything; indeed, all you are trying to do is to establish the basic foundations that the team will share when moving through development. You basically create a common vocabulary for team members to use, describing the system, rather than setting a law on how this should be done.

Answer 13

I found that I could not fully understand the system before coding it. It is too simple for a quick glance at some of the components that you understand only later to be much more complicated than you thought.

One solution is simply very hard. Write UML everywhere. Go through each class. Think about how it will interact with your other classes. This is hard to do.

I like to do a general review first. I don't like UML, but I like to draw diagrams that make sense. Then I start to implement it. Even when I just write the class structure with an empty method, I often see things that I missed before, so I update my design. Since I am coding, I will understand that I need to do something differently, so I am updating my design. This is an iterative process . The concept of “designing everything first and then implementing everything” is known as a waterfall model, and I think others have shown it as a poor way to create software.

Answer 14

Try Archimate.

Answer 15

I have been doing architecture for a while. I use BPML to first refine the business process, and then use UML to collect various details! The third step is ERD! By the time you finish working with BPML and UML, your ERD will be fairly stable! No plan is perfect, and abstraction will not be 100%. Plan refactoring, the goal is to minimize refactoring as much as possible!