코드를 작성하기 전에 애플리케이션의 아키텍처를 어떻게 계획합니까?

코드를 작성하기 전에 애플리케이션의 아키텍처를 어떻게 계획합니까? [닫은]

---

내가 고민하는 한 가지는 코드를 작성하기 전에 애플리케이션의 아키텍처를 계획하는 것입니다.

애플리케이션이해야 할 일을 좁히기 위해 요구 사항을 수집하는 것이 아니라 전체 클래스, 데이터 및 흐름 구조를 배치하는 좋은 방법을 효과적으로 생각하고 이러한 생각을 반복하여 신뢰할 수있는 계획을 세웁니다. IDE를 열기 전에 염두에 두어야합니다. 현재로서는 IDE를 열고 빈 프로젝트를 만들고 비트와 봅슬레이 작성을 시작하고 거기에서 디자인을 '성장'시키는 것이 모두 쉽습니다.

나는 UML을 수집하는 것이 이것을 수행하는 한 가지 방법이지만 경험이 없어서 모호한 것처럼 보입니다.

어떻게 당신은 코드를 작성하기 전에 응용 프로그램의 아키텍처를 계획? UML이 갈 길이라면 작은 응용 프로그램 개발자에게 간결하고 실용적인 소개를 권할 수 있습니까?

귀하의 의견에 감사드립니다.

---

저는 종이나 화이트 보드에 처음으로 글을 쓰는 것이 정말 중요하다는 것을 알게되었습니다. 그런 다음 원하는 경우 UML로 이동하지만 처음에는 손으로 그리는 유연성을 능가하는 것은 없습니다.

---

다음을 고려합니다.

1. 시스템이해야 할 일, 즉 시스템이 해결하려고하는 문제가 무엇인지
2. 고객은 누구이며 그들의 소원은 무엇입니까
3. 시스템이 통합해야하는 것
4. 고려해야 할 레거시 측면이 있습니까?
5. 사용자 간섭은 무엇입니까
6. 기타...

그런 다음 시스템을 블랙 박스로보기 시작합니다.

1. 블랙 박스와 어떤 상호 작용이 필요한지
2. 블랙 박스 내부에서 발생해야하는 동작은 무엇입니까? 즉, 블랙 박스가 더 높은 수준에서 원하는 동작을 나타 내기 위해 이러한 상호 작용에 발생해야하는 동작 (예 : 예약 시스템에서 수신 메시지 수신 및 처리, 데이터베이스 업데이트 등) .

그러면 다양한 내부 블랙 박스로 구성된 시스템보기가 시작되며, 각 블랙 박스는 동일한 방식으로 더 세분화 될 수 있습니다.

UML은 그러한 행동을 나타내는 데 매우 좋습니다. UML의 여러 구성 요소 중 두 가지를 사용하여 대부분의 시스템을 설명 할 수 있습니다.

• 클래스 다이어그램 및
• 시퀀스 다이어그램.

설명해야하는 동작에 병렬성이있는 경우 활동 다이어그램도 필요할 수 있습니다.

UML을 배우기위한 좋은 자료는 Martin Fowler의 훌륭한 책 "UML Distilled"입니다. ( Amazon 링크 -스크립트 아동용 링크 나치를 위해 삭제되었습니다 (-:).이 책은 각 구성 요소의 필수 부분을 간략하게 살펴 봅니다. UML.

오. 제가 설명한 것은 Ivar Jacobson의 접근 방식입니다. Jacobson은 OO의 Three Amigos 중 하나입니다. 사실 UML은 처음에 Three Amigos, Grady Booch 및 Jim Rumbaugh를 구성하는 다른 두 사람이 개발했습니다.

---

Steve McConnell의 Code Complete, 특히 "Design in Construction"에 대한 그의 공짜 챕터를 반드시 확인해야합니다.

그의 웹 사이트에서 다운로드 할 수 있습니다.

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

---

.NET 용으로 개발하는 경우 Microsoft는 Application Architecture Guide 2.0b1 을 방금 게시했습니다 (무료 전자 책으로!) . 코드를 작성하기 전에 아키텍처 계획에 대한 정말 좋은 정보를 많이 제공합니다.

절망적이라면 .NET 기반이 아닌 아키텍처에 많은 양을 사용할 수있을 것으로 기대합니다.

---

나는 대부분의 아키텍처가 이미 사전에 결정된 웹 개발 (WebForms, 현재 MVC)을 주로하고 있으며 대부분의 프로젝트는 1 년도 채 걸리지 않는 소규모의 1 인 작업이라고 말하면서 서문을 시작할 것입니다. 또한 비즈니스 개체와 데이터 상호 작용을 각각 처리 할 ORM과 DAL이 있다는 것도 알고 있습니다. 최근에 저는이를 위해 LINQ를 사용하도록 전환했습니다. 너무 많은 "디자인"이 DBML 디자이너를 통한 데이터베이스 디자인 및 매핑이됩니다.

일반적으로 TDD (테스트 주도 개발) 방식으로 작업합니다. 나는 건축 또는 디자인 세부 사항에 대해 미리 작업하는 데 많은 시간을 소비하지 않습니다. 나는 스토리를 통해 사용자와 애플리케이션의 전반적인 상호 작용을 수집합니다. 스토리를 사용하여 인터랙션 디자인을 작업하고 응용 프로그램의 주요 구성 요소를 발견합니다. 저는이 과정에서 고객과 함께 많은 화이트 보드 작업을합니다. 때로는 디지털 카메라로 세부 사항이 다이어그램 형식으로 유지하기에 충분히 중요하다고 생각되면 캡처합니다. 주로 내 이야기는 위키에서 이야기 형식으로 캡처됩니다. 결국 스토리는 릴리스와 반복으로 구성됩니다.

이 무렵에는 보통 아키텍처에 대해 꽤 잘 알고 있습니다. 복잡하거나 비정상적인 부분이있는 경우 (일반적인 관행과 다른 것) 또는 다른 사람과 함께 작업하는 경우 (일반적이지 않은 경우), 다이어그램을 작성합니다 (다시 화이트 보드에 표시). 복잡한 상호 작용의 경우도 마찬가지입니다. 페이지 레이아웃과 흐름을 화이트 보드에 디자인하여 해당 섹션을 완료 할 때까지 유지 (또는 카메라를 통해 캡처) 할 수 있습니다. 내가 어디로 가고 무엇을 먼저해야하는지에 대한 일반적인 아이디어를 얻은 후에는 첫 번째 이야기에 대한 테스트를 작성하기 시작합니다. 일반적으로 다음과 같이 진행됩니다. "좋아요. 이렇게하려면이 수업이 필요합니다.이 수업부터 시작하겠습니다.이 수업을 수행해야합니다." 그런 다음 즐겁게 TDDing을 시작하고 아키텍처 / 디자인은 애플리케이션의 요구 사항에 따라 성장합니다.

주기적으로, 나는 약간의 코드를 다시 작성하고 싶거나 "이게 정말 냄새가 난다"고 생각하고 중복을 제거하거나 냄새 나는 부분을 더 우아한 것으로 대체하기 위해 내 디자인을 리팩토링 할 것입니다. 대부분은 좋은 디자인 원칙을 따르면서 기능을 낮추는 데 관심이 있습니다. 나는 알려진 패턴을 사용하고 당신이 따라갈 때 좋은 원칙에주의를 기울이는 것이 꽤 잘 작동한다는 것을 알았다.

---

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

저는 UML을 사용하고 있으며 그 가이드가 매우 유용하고 읽기 쉽습니다. 다른 것이 필요하면 알려주세요.

---

나는 조금 이상 미리 계획 할만큼 똑똑하지 않다. 미리 계획을 할 때 내 계획은 항상 틀렸지 만 지금 은 나쁜 계획에 n 일을 보냈습니다 . 내 한도는 화이트 보드에서 약 15 분인 것 같습니다.

기본적으로 나는 내가 올바른 방향으로 가고 있는지 알아 내기 위해 할 수있는 한 적은 일을한다.

중요한 질문에 대한 내 디자인을 살펴 봅니다. A가 B에서 C로 이동하면 D가 충분히 빠를까요? 그렇지 않다면 다른 디자인이 필요합니다. 이러한 각 질문에 대한 답은 급증 할 수 있습니다. 스파이크가 좋아 보이면 디자인이있는 것이므로 확장 할 때입니다.

나는 가능한 한 빨리 실제 고객 가치를 얻는 방향으로 코딩하여 고객이 내가 어디로 가야하는지 말할 수 있습니다.

나는 항상 일이 잘못되기 때문에 리팩토링에 의존하여 올바른 일을합니다. 리팩토링은 위험하므로 이동하면서 단위 테스트를 작성해야합니다. 사실 후 단위 테스트를 작성하는 것은 커플 링 때문에 어렵 기 때문에 먼저 테스트를 작성합니다. 이 일에 대해 훈육을 유지하는 것은 어렵고, 다른 두뇌는 사물을 다르게 보는 것이므로 친구가 코딩하는 것을 좋아합니다. 코딩 친구는 코가있어서 정기적으로 샤워를합니다.

그것을 "극단적 인 프로그래밍"이라고합시다.

---

"화이트 보드, 스케치 및 포스트잇 노트는 훌륭한 디자인 도구입니다. 복잡한 모델링 도구는 조명보다 산만 해지는 경향이 있습니다." 에서 벤 카트 Subramaniam 앤디 헌트에 의해 애자일 개발자의 사례 .

---

UML is a notation. It is a way of recording your design, but not (in my opinion) of doing a design. If you need to write things down, I would recommend UML, though, not because it's the "best" but because it is a standard which others probably already know how to read, and it beats inventing your own "standard".

I think the best introduction to UML is still UML Distilled, by Martin Fowler, because it's concise, gives pratical guidance on where to use it, and makes it clear you don't have to buy into the whole UML/RUP story for it to be useful

Doing design is hard.It can't really be captured in one StackOverflow answer. Unfortunately, my design skills, such as they are, have evolved over the years and so I don't have one source I can refer you to.

However, one model I have found useful is robustness analysis (google for it, but there's an intro here). If you have your use-cases for what the system should do, a domain model of what things are involved, then I've found robustness analysis a useful tool in connecting the two and working out what the key components of the system need to be.

But the best advice is read widely, think hard, and practice. It's not a purely teachable skill, you've got to actually do it.

---

I'm not convinced anything can be planned in advance before implementation. I've got 10 years experience, but that's only been at 4 companies (including 2 sites at one company, that were almost polar opposites), and almost all of my experience has been in terms of watching colossal cluster********s occur. I'm starting to think that stuff like refactoring is really the best way to do things, but at the same time I realize that my experience is limited, and I might just be reacting to what I've seen. What I'd really like to know is how to gain the best experience so I'm able to arrive at proper conclusions, but it seems like there's no shortcut and it just involves a lot of time seeing people doing things wrong :(. I'd really like to give a go at working at a company where people do things right (as evidenced by successful product deployments), to know whether I'm a just a contrarian bastard, or if I'm really as smart as I think I am.

---

I beg to differ: UML can be used for application architecture, but is more often used for technical architecture (frameworks, class or sequence diagrams, ...), because this is where those diagrams can most easily been kept in sync with the development.

Application Architecture occurs when you take some functional specifications (which describe the nature and flows of operations without making any assumptions about a future implementation), and you transform them into technical specifications.

Those specifications represent the applications you need for implementing some business and functional needs.

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

• a dispatcher to assign those heavy calculations to different servers
• a launcher to make sure all calculation servers are up and running before starting to process those portfolios.
• a GUI to be able to show what is going on.
• a "common" component to develop the specific portfolio algorithms, independently of the rest of the application architecture, in order to facilitate unit testing, but also some functional and regression testing.

So basically, to think about application architecture is to decide what "group of files" you need to develop in a coherent way (you can not develop in the same group of files a launcher, a GUI, a dispatcher, ...: they would not be able to evolve at the same pace)

When an application architecture is well defined, each of its components is usually a good candidate for a configuration component, that is a group of file which can be versionned as a all into a VCS (Version Control System), meaning all its files will be labeled together every time you need to record a snapshot of that application (again, it would be hard to label all your system, each of its application can not be in a stable state at the same time)

---

I have been doing architecture for a while. I use BPML to first refine the business process and then use UML to capture various details! Third step generally is ERD! By the time you are done with BPML and UML your ERD will be fairly stable! No plan is perfect and no abstraction is going to be 100%. Plan on refactoring, goal is to minimize refactoring as much as possible!

---

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

When I'm trying to model the stuff I'm trying to manipulate, I come up with a series of discrete item definitions- an ecommerce site will have a SKU, a product, a customer, and so forth. I'll also have some non-material things that I'm working with- an order, or a category. Once I have all of the "nouns" in the system, I'll make a domain model that shows how these objects are related to each other- an order has a customer and multiple SKUs, many skus are grouped into a product, and so on.

These domain models can be represented as UML domain models, class diagrams, and SQL ERD's.

Once I have the nouns of the system figured out, I move on to the verbs- for instance, the operations that each of these items go through to commit an order. These usually map pretty well to use cases from my functional requirements- the easiest way to express these that I've found is UML sequence, activity, or collaboration diagrams or swimlane diagrams.

It's important to think of this as an iterative process; I'll do a little corner of the domain, and then work on the actions, and then go back. Ideally I'll have time to write code to try stuff out as I'm going along- you never want the design to get too far ahead of the application. This process is usually terrible if you think that you are building the complete and final architecture for everything; really, all you're trying to do is establish the basic foundations that the team will be sharing in common as they move through development. You're mostly creating a shared vocabulary for team members to use as they describe the system, not laying down the law for how it's gotta be done.

---

I find myself having trouble fully thinking a system out before coding it. It's just too easy to only bring a cursory glance to some components which you only later realize are much more complicated than you thought they were.

One solution is to just try really hard. Write UML everywhere. Go through every class. Think how it will interact with your other classes. This is difficult to do.

What I like doing is to make a general overview at first. I don't like UML, but I do like drawing diagrams which get the point across. Then I begin to implement it. Even while I'm just writing out the class structure with empty methods, I often see things that I missed earlier, so then I update my design. As I'm coding, I'll realize I need to do something differently, so I'll update my design. It's an iterative process. The concept of "design everything first, and then implement it all" is known as the waterfall model, and I think others have shown it's a bad way of doing software.

---

Try Archimate.

참고URL : https://stackoverflow.com/questions/292463/how-do-you-plan-an-applications-architecture-before-writing-any-code