Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter One: Introduction (SA)

  • What is the architecture of a software system? How is the architecture of an application relied to the design of the application?

The architecture of a software system "defines [the] system in terms of computational components, like clients and servers, databases, filters, and layers in a hierarchial system". The architecture is the system is also concerned with the interactions among these components.

The architecture of the system is something that would be determined after the design of the system is completed. The authors of this chapter disagree thoughh when they say that the architecture of the system "provide some rationale for the design of the system." I think that they do not understand or agree with the concept of a design that is only concerned with what to create not how to create it. With a "what not how" design you would not dictate what components should be used or how they should work together. The architecture would be derived from the design document. but if you follow the author's opinion then the design should be dervied from the architecture.
Jim Clause

Do you think that your system will adhere to a standard architecture if the system is developed without giving forethought to it's architecture? Is the what not how dichotomoy really applicable to design? Shouldn't a design begin to specify some of the "how"? Of course, if we are using an object-oriented design, I agree that we will not specify all of the "how" because we will not state how a method should be implemented. Greg

The architecture of a software system is the structure and topology of the system and defines the system in terms of computational components and interactions among those components; where components are such things as filters and databases and interactions are procedure calls and shared variable access. The architecture also shows the correspondence between the system requirements and the elements in the system.

Architecture and design are interconnected and from the text architecture is first part of the design stages. It is here where the design issues involve the association of system capability with components. The goal of this design phase is to improve the understanding and precision of the software architectural level.
Noosh Moussavi
Brenda

Software architecture is the components that a software system is built from and how those components interact. As the author puts it "The architecture of a software system defines that system in terms of computational components and interaction among those components." The components include things like clients/servers, databases, filter, and layter in a hierarchical system. Interactions can be described as procedure calls, client/server protocols, and piped streams.

This is related to the design because the architecture shows the correspondence between system requirements and the elements of the system. This will effect the design decisions that are made.

  • Garlan and Shaw contend that a sound basis for software architecture promises benefits for both software development and maintenance. What are the benefits that they expect to result from the application of software architectures?



The benefits that they expect to gain in software development are
1) The ability to recognize comon paradigms. this lets software engineers understand high-level relationships and build new systems as variations on older systems.
2) It will help because it will be easier for engineer to get the "right" architecture for the system that they are trying to design. This helps software to be more successful.
3) A good understaing of different architectures will allow engineers to make good choices between different designs and pick the best one for the current project.
4) It will help software engineers analyze and describe the high level properties of the systems that they write,
5) A standard notation for describing architectues will allow engineers to communicate ideas more effectivley.

A standard set of architectures will also help with the maintenace of software. By capturing a system's structure and properties it will reduce the time needed for another engineer to understand older project and then they will be able to mainatin them in a more efficient manner. Capturing the system's structure and properties will also help ensure that the integrity of the system is maintained. An engineer who knows what the system is suppose to is less likely to change the system and alter its purpose.
Jim Clause

The authors claim that for development, effective engineers require facility in architectural software design. The benefits they expect to result from the application of software architecture are:
1) Being able to recognize common paradigms. This becomes important with high level relationships so that they can be understood and so that new systems can be built as a variation of old systems.
2) It is important to get the right architecture because the wrong architecture could result in bad results.
3) Details in understanding of software architectures allows the engineer to make principled decisions and choices regarding designs
4) An architectural system representation is essential to the analysis and description of the high level properties of a complex system
5) Fluency in the use of notations for describing architectural paradigms, this allows the software engineer to communicate new system designs to others.
Noosh Moussavi
Brenda

Garlan and Shaw assert that software architecture will improve development and maintencance in five main areas:
1. Recognition of common paradigms. Understanding high-level relationships so new systems can be built using variations of old systems.
2. Creating software system designs that are successful.
3. Making better decisions about design alternatives.
4. Analysis and description of the high-level properties of a complex system.
5. Fluency in the notations for describing architectural paradigms allows communication of the designs with other software engineers.

  • The authors assert that software architectures have traditionally found their "roots in diagrams and informal prose". How do the authors feel about this rooting? What is your response to the author's opinion on this issue?

The author's feel that diagrams and descriptions in informal prose are very ambiguous and rely on past experiances and common intuitiuons to have any use. I agree with the authors. I feel that disgrams and verbal descritpions can only go do far in describing a software system. However, currently there isn't a better way that we can describe our software systems. Complexity and invisibility, two, essential problems of software, stand in our way. I also think that other forms of engineering began to generate the architectures in the same way. But because software engineering is still young these informal descriptions have not had time to propagate across the world and become standardized.

If you had to postulate about the kinds of description techniques that will replace diagrams and informal prose, what would you chose? Why would you chose these techniques? Greg

The authors feel that diagrams and descriptions are highly ambiguous and have a tendency of relying on “common institutions and past experience.” I agree with the authors as well, diagrams and description are a good starting point but not something that you can root and base your system on. The authors also feel that rooting systems in diagrams and informal prose also causes other problems when it comes to system designers and tools. System designers lack adequate tools, concepts, and decision criteria for selecting and describing system structures that can fit the problem.
Noosh Moussavi

Should we use something besides diagrams and informal prose on the long-term project? If so, what would you personally advocate? Greg
Brenda

Garlan and Shaw feel that "diagrams and descriptions are highly ambiguous." They assert that there are many questions that can occur during system design that need to be answered and may not have been answered directly through the diagrams and descriptions. It would be impractical to assume that ONLY diagrams and descriptions be used to develope a software system. I feel that they are a valuable tool to some extent, but as we've discussed in class, there comes a point where they cannot illustrate and communicate EVERYTHING about the software and sometimes maintaining and updating diagrams or written prose can become difficult to keep synchronized with the actual system.

Link to this Page

  • Software Design last edited on 14 October 2004 at 2:29 pm by aldenv28.allegheny.edu