Software structure versus Software architecture [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

I can't get the precise differences between software structure and software architecture

A simple example explains the precise differences would be very appreciated

BTW,I use UML for representing architecture

Answer 1

Software architecture and Software structure overlap between them.

Software architecture is a set of important aspects and decisions in relation to a software system (simply said). It includes the most important requirements and all kind of restrictions (performance, security, etc.), then the high-level system organization, the principal communication mechanisms between the system parts, external dependencies, implementation technologies and guidlines, even risks, etc, etc, etc.

I read once a great statement about the software architecture: it's a set of decisions, which are hard to change.

So, when you are not sure if an aspect/decision is really architectonic relevant, just ask yourself - if I later change this aspect/decision, what is the impact? How hard it to change it?

Examples:

• Let's say we want to change the client-server system structure to 3-Tier. How hard is this restructuring? Well, probably pretty hard. Therefore is this an architectonic aspect.
• we want to change the communication between XML and JSON. This could be very complicated if not well designed, so we treat this with care and as an architectonic req.
• What if we want to change a sorting algorithm in a method. This change is likely to be localized and not very costly. Therefore, it's not an architectonic aspect.
• Change in the definition of the API od some core-module of a system, that is used by a lot of other modules and systems is very likely to be an architectonic theme.

Software structure on the other hand is practically a system design, and can be very high-level (like block-diagram that shows the main modules or tiers) till very detailed (blueprint of code).

This high-level view of the software structure would definitelly be part of the software architecture, while detailed design not (maybe some important parts).

UPDATE (after the comments)

1#Any hints about which diagram is highly recommended for Software architecture and software structure?because it sounds that class diagram should be used in both cases (architecture and structure)

It's not about which UML diagram to make, but rather what is important to show, which aspect.

All diagrams could be therefore used to depict an architectonic aspect. Most common however and probably mandatory diagram is component diagram. It naturally shows the high-level design in terms of system modules and the way they interface each other. It can be optionally extended by a deployment view. Class diagram is used to show the internal structure of the components, by representing more or less detailed class structure and relationships. Not all class diagrams are architectonic relevants, but some can definitelly be so ("ask yourself..." :))

There are lots of other potentialy important aspects, like system behavior. Hier you can use UML sequences, state machines, activities and so on. Some of those build up the architecture, others are less significant, but also usefull to show.

2#As I understand from the answer that the detailed design is not part of architecture/structure design but I can use for it the same type of UML diagrams such as class and sequence diagram (that is used in architecture and structure )with more detailed information. right?

As told, it's not about the type of diagram itself, but about the displayed content. So, if you consider that content is relevant, youput it under architecture. If not, it is considered as a detailed design.

Example: a sequence can be shown to show a critical real-time communication with an external device. Although it can be very low-level, it can be fundamental for the fullfillment of an important requirement. The same type of diagram can be used to show a local algorithm or a use case scenario which is not so important, therefore not part of the architecture.

3#Does the high level design is the same as Architectural design

You can say so. Keep in mind though that there is no clear frontier between architectonic and not architectonic. It is sometimes subjective, and the point is not to correctly separate between those, but rather to build up a good specification which would lead to a successful product development.