Problem:
Using the architecture of a house or building as a metaphor, draw comparisons with software architecture. How are the disciplines of classical architecture and the software architecture similar? How do they differ?
Answer:
592-10-1P SA Code: 4478
SR Code: 4578
The similarities of classical architecture and software architecture are
The classical architecture of a building is described by
1. Multiple views: exterior, floor plans, plumbing/wiring,
2. Architectural styles: Romanesque, gothic,
3. Style and engineering: how the choice of style influences the physical design of
the building
4. Style and materials: how the choice of style influences the materials used to
construct (implement) the building.
The software architecture of a building is described by
1. Views: control-flow, data-flow, modular structure, behavioral requirements etc
2. Styles: pipe-and-filter, object-oriented, procedural etc
3. Engineering: modules, filters, messages, events etc
4. Materials: control structures, data structures etc
The differences between classical architecture and software architecture are
Classical architecture software architecture
1. This is physical architecture 1. This is conceptual architecture
2. This is static architecture 2.This is dynamic architecture
3. In physical architecture, we can do 3.In software architecture, we can do
Little evolution frequent evolution
4. Classical architecture depends on 4. Software architecture depends on also
different mathematical and scientific different mathematical and scientific
notations notations
Problem:
Present two or three examples of applications for each of the architectural styles noted in Section 13.3.1.
Answer:
An Architectural style with examples is as follows
1. Data-centered architecture: A data store resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store.
Ex: library catalog system and online purchase books
2. Data-flow- architecture: This architecture is applied when input data are to be transformed through a serious of computational or manipulative components into output data.
Ex: engineering applications
Scientific applications
3. Call and return architecture: This architectural style enables a software designer to achieve a program structure that is relatively easy to modify and scale.
Ex: I-P-O- application
4. Object-oriented architecture: The components of a system encapsulate data and the operations that must be applied to manipulate the data.
Ex: object oriented application
Graphical user interface base application
5. Layered architecture: At the outer layer, components service user interface operations, at the inner layer, components perform operating system interfacing. And intermediate layers provide utility services and application software functions
Ex: client-server application
Software functions.
Problem:
Some of the architectural styles noted in Section 13.3.1 are hierarchical in nature and others are not. Make a list of each type. How would the architectural styles that are not hierarchical be implemented?
Answer:
Architectural style
The architectural design process begins by representing the system in context.
Architectural context represents how the S/W interacts with entities external to its boundaries.
The design should define the external entities (other systems, devices, and people) that the software interacts with and the nature of the interaction
Types of Architectural style:
Architectural style is categorized as two types. Those are
1. Hierarchical
2. Non-hierarchical
Hierarchical Style dominated by reduced coupling, with resulting partition of a system into subsystems with limited interaction and it decomposes a system into a number of layers in a hierarchical or non- hierarchical manner.
Some of the architectural styles are hierarchical. Those are
1. Data flow:
This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data.
2. Call return:
The architectural style enables a software designer to achieve a program structure.
Some other architectural styles are Non-hierarchical. Those are as follows:
1. Data-centered: A data store resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise modify data within the store
2. Object-oriented: The non- hierarchical architectures are best implemented using object-oriented and event driven programming techniques.
Architectural styles are not hierarchical for implementing.
Because, the architecture is not the operational software, but it is a representation of software engineering process.
1. Analyze the effectiveness of the design in meeting its stated requirements,
2. Consider architectural alternatives at a stage when making design changes is still relatively easy, and
3. Reduce the risks associated with the construction of the software.
The hierarchical layers style is a commonly misunderstood architectural style. The difficulty arises in the interpretation of the layers. All complex systems are hierarchical in nature. A system can be depicted as a hierarchy of components or modules, which are further decomposed into more primitive components. I argue that the layers style is not really a style or pattern at all, but an attribute of all complex software systems. Since all complex systems have hierarchy, then this implies that there is a fundamental architectural view that represents this aspect of a system’s organization.
Problem:
The terms architectural style, architectural pattern, and framework (not discussed in this book) are often encountered in discussions of software architecture. Do some research and describe how each of these terms differs for its counterparts.
Answer:
592-10-6P SA Cdoe: 4478
SR Code: 4578
An architectural style is a transform that is imposed on the design of an entire system. Different types of architectural styles are
1. Data-centered architecture: A data store resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store.
2. Data-flow architecture: This architecture is applied when input data are to be transformed through a serious of computational or manipulative components into output data.
3. Call and return architecture: This architectural style enables a software designer to achieve a program structure that is relatively easy to modify and scale.
4. Object-Oriented architecture: The components of a system encapsulate data and the operations that must be applied to manipulate the data.
5. Layered architecture: at the outer layer, components service user interface operations, at the inner layer, components perform operating system interfacing. And intermediate layers provide utility services and application software functions.
Architectural patterns: Architectural patterns for software define a specific approach for handling some behavioral characteristics of the system.
1. Concurrency: there are a number of different ways in which an application can handle concurrency, and each can be presented by a different architectural pattern.
2. Persistence: Persistent data are stored in a database or file and may be read or modified by other processes at a later time.
3. Distribution: The distribution problem addresses the manner in which systems or components within systems communicate with one another in a distributed environment.
Architectural pattern as being one it the same, but the framework might be defined as a set of classes providing a general solution to a problem that can be refined to create an application or sub system.
Problem:
Select an application with which you are familiar. Answer each of the questions posed for control and data in Section 13.3.3.
Answer:
To assess the design quality of a knowledge-based system implementation of a graph tracer, just address the control and data points posed in section 13.3.3 of the book. In this case,
• Control Concerns
1. Control management within the architecture: It is done by the knowledge-based interpreter system.
2. Distinct control hierarchy: Control in the knowledge-based system is achieved by the scheduling of events.
3. Roles of component control: There is only one role that of an interpreter.
4. Control transfer between components: Control is not transferred.
5. Control sharing between components: Control is neither shared.
6. Control topology: Processing control is dependent on rules. Rules are used to assert appropriate facts.
7. Synchronous or asynchronous: Components are asynchronous.
• Data Concerns
1. Communication between components: The design provides no built-in mechanism for communication between components.
2. Data flow: It is discrete between the rules and the facts list.
3. Data transfer: Data transfer is from the facts to the list and back using the built-in commands.
4. Data components: They are dynamic, and exist when rules are asserted but not when retracted.
5. Roles of data components: They play the role of firing the actions of the rule-base.
6. Data is passive or active: Data is passive.
7. Interaction of functional component with data and control component: Interaction involves:-
• Interpreter first detects the asserted facts.
• Once facts required to fire a rule are detected the system fires the rule (to initiate some process).
• The rule can later be retracted and new or existing facts from the fact list can be assert.
Problem:
Research the ATAM (using [Kaz98]) and present a detailed discussion of the six steps presented in Section 13.7.1.
Answer:
4633-9-6P SA: 4478
SR: 6376
The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM) that establishes an iterative evaluation process for software architectures. The following design analysis activities are performed iteratively. The detailed discussion of these design analysis activities is as given:
1) Collect scenarios: this method is to elicit system usage scenarios from a representative group of stakeholders. This serves the same purposes as it does in SAAM to operational both functional and quality requirements, to facilitate communication between stakeholders, and to develop a common vision of the important activities the system should support.
2) Elicit requirements, constraints, and environment description. The second step in the method is to identify the attribute based requirements, constraints, and environment of the system. A requirement can have a specific value or can be described via scenarios of hypothetical situations. The environment must be characterized for subsequent analysis (e.g. performance or security) and constraints on the design space, as they evolve, are recorded as these too affect attribute analysis. This step places a strong emphasis on revisiting the scenarios from the previous step to ensure that they account for important quality attributes.
3) Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. The requirements, scenarios, and engineering design principles together generate candidate architectures and constrain the space of design possibilities. In addition, design almost never starts from a clean slate: legacy systems, interoperability, and the successes/failures of previous projects all constrain the space of architectures.
Moreover, the candidate architectures are described in terms of the architectural elements that are relevant to each of the important quality attributes. For example, voting schemes are an important element for reliability; concurrency decomposition and process prioritization are important for performance; firewalls and intruder models are important for security, and encapsulation is important for modifiability.
The ATAM requires building and maintaining attribute models (both quantitative models and qualitative) that reflect and help to reason about the architecture. To change any aspect of architecture—functionality, structural elements, coordination model—will change one or more of the models. Once a change has been proposed, the new and old architectures are “competing”, and must be compared. Hence the need for new models that mirror those changes using the ATAM, then, is a continual process of choosing among competing architectures, even when these look “pretty much the same” to a casual observer.
4) Evaluate quality attributes by considering each attribute in isolation. Once a system’s initial set of requirements and scenarios has been elicited and an initial architecture is proposed, each quality attribute must be analyzed in isolation, with respect to each architecture. These analyses can be conducted in any order; no individual critique of attributes against requirements or interaction between attributes is done at this point. Allowing separate (concurrent) analysis is an important separation of concerns that allows individual attribute experts to bring their expertise to bear on the system.
The result of the analyses leads to statements about system behavior with respect to values of particular attributes like “requests are responded to in 60 ms. average”, “the mean time to failure is 2.3 days”, “the system is resistant to known attack scripts:, “the hardware will cost $80,000 per platform”,” the software will require 4 people per year to maintain”, and so forth.
5) Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. Here, the sensitivity of individual attribute analyses to particular architectural elements is determined. That is, one or more attributes of the architecture are varied, the models are then varied to capture these design changes, and the results are evaluated. Any modeled values that are significantly affected by a change to the architecture are considered to be sensitivity points.
6) Critique candidate architectures using the sensitivity analysis. The next step of the method is to critique the models build in step 4 and to find the architectural tradeoff points. Although it is a standard practice to critique designs, significant additional leverage can be gained by focusing this critique on the interaction of attribute-specific analyses, particularly the location of tradeoff points. Here is how this is done.
Once the architectural sensitivity points have been determined, finding tradeoff points is simply the identification of architectural elements to which multiple attributes are sensitive.
For example, the performance of client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). The availability of that architecture might also vary directly with the number of servers. However, the security of the system might vary inversely with the number of servers (because the system contains more potential points of attack). The number of servers, then, is a tradeoff point with respect to this architecture. It is an element, potentially one of many, where architectural tradeoffs will be made, consciously or unconsciously.
Problem:
If you haven’t done so, complete Problem 9.5. Use the design approach described in this chapter to develop a software architecture for the PHTRS.
Answer:
The department of public works for a city has decided to develop a web-based Pot Hole Tracking and Repair System (PHTRS).
PHTRS follows a data centric architecture design style. At the center of the architecture is the database, which contains the information of pothole, their reporting and repair information.
This architecture has basically four layers:
• The user interface layer: consist of the website and user interface application at the user’s desktop. A citizen uses the website to login and report a pothole information. A PWD employee might use the application to login to the database to issue work order and create a damage file. A contractor uses the same application with his/her user identification to update the pothole with repair information like repair crew identification and strength, material used and date of repairing.
• The business layer: The business layer is where the business logic is located. It encompasses the business components, all business entities and this layer defines the rules that govern the business workflow.
• The data access layer: is the third layer in the architecture of PHTRS. This layer provides more clarity and data security. Data can only be directly accessed by the classes defined in this layer to add, delete or modify data in the database.
• The database makes the last layer in the design.
So, the architecture design of PHTRS would look something like:-
Figure 1: Architecture design diagram of PHTRS
The architecture design of PHTRS would be incomplete without defining their design classes. In this case,
Problem:
Use the architectural decision template from Section 13.1.4 to document one of the architectural decisions for PHTRS architecture developed in Problem 13.7.
Answer:
An architectural decision is documented for review later by stakeholders who want to understand the architecture description. An architectural decision for PHTRS can be:-
| Design Issue: | To use a single API with different user logins for PWD employees and contractors Or to use two separate applications for them. |
| Resolution: | Use a single application with different user login and rights for PWD employees and contractors. |
| Category: | Presentation and component structure |
| Assumption | The rights to create damaged file and other relevant rights will be defined distinctively and allocated only to PWD employee. |
| Constraints: | The administrative rights once defined cannot be changed for the user type. Only new ones can be created. |
| Alternatives | Use of two separate application one each for PWD employee and contractor would have resulted in code and interface redundancies. Integration would also have been an issue. |
| Argument: | A single application approach provides a coherent, integrated approach to the issue at hand. The design, coding and testing process becomes streamlined and easier to control. |
| Related Decisions: | The rights to create, modify and delete data in PHTRS data need to be considered deliberately and then assigned to the two user types. |
| Work products: | This makes the architecture design and the process simpler and easier to manage. It also avoids data and code redundancy. |
| Notes: | Refer to the MOM of team meetings (mention dates and file names here). |
Problem:
Select a mobile application you are familiar with, assess it using the architecture considerations (economy, visibility, spacing, symmetry, emergence) from Section 13.4.
Answer:
Architectural consideration for mobile applications provide the developers with guidance as architectural decisions are being made.
‘Back button (No root)’ is a mobile application available on google play and displays the home, back, navigation bar and scroll buttons on the screen.
Assessing the above mobile application for architectural considerations:-
• Economy: In case of ‘Back button’ app the four buttons are sized so that they can be easily clicked, and can be moved around on the screen. In fact, if required, the size of buttons can also be changed. So, the App performs considerably well in this criteria.
• Visibility: Since the App itself is not much complex, it is clear to even a layman why the design of the App is simple at the same time effective.
• Spacing: There are no hidden dependencies in the App as the application does not require Root. Also, it does not collect data entered at the terminal.
• Symmetry: The App provides structural symmetry. The App is not complex enough to comment on its behavioral symmetry.
• Emergence: The App is flexible to be scalable and has an economic software architecture.
Problem:
List the strengths and weakness of the PHTRS architecture you created for Problem 13.7.
Answer:
The department of public works for a city has decided to develop a web-based Pot Hole Tracking and Repair System (PHTRS). The architecture of PHTRS is specified in solution to 13-7P.
Strengths of architecture of PHTRS
• Information hiding: At every layer the information about the other layer are hidden. The various number of layers of the system make it quite secure. Data is secure as it cannot be directly accessed from a website etc.
• Separation: This reduces complexity of the system as the responsibility of each layer is well defined and there is no interjecting.
• Abstraction: Instead of using separate applications for PWD employee and Contractor, a single application is used with different administrative rights.
• Clarity and Well defined functionality: Each layer has its task and approaches well defined. This brings in more clarity as well.
Weakness of architecture of PHTRS
• Integration: The layering on the architecture means that the integrating the process might be a tedious task if the individual tasks are not performed taking the complete picture in mind.
• Dependencies: There are multiple dependencies in the architectural. Some people might think of it as a disadvantage.
Problem:
Create a dependency structure matrix 20 for the software PHTRS architecture created for Problem 13.7.
Answer:
Dependency structure matrix (DSM) represent dependencies of a system in the form of a square matrix. They are used to show dependencies in a complex system. The elements can then be identified for coupling and cohesion.
The department of public works for a city has decided to develop a web-based Pot Hole Tracking and Repair System (PHTRS).
In the case of PHTRS architecture (provided in solution 13-7P) the dependency structure matrix for the architecture elements of the system is given by:-
|
| Website | Application | Business layer | Data access layer | Database |
| Website | 1 | ||||
| Application | 1 | ||||
| Business layer | 1 | 1 | 1 | ||
| Data access layer | 1 | 1 | |||
| Database | 1 |
Dependency structure matrix for PHTRS
The DSM for PHTRS has five elements and 8 dependencies. The yellow color in dependency implies that the column header is used by the row header component. The green color in the cell signifies that the column header is using the row header component.
For example, in this case, from the matrix it can be concluded that the Business layer is used by website and application and is using data access layer.
Problem:
Pick an agile process model from Chapter 5 and identify the architectural design activities that are included.
Answer:
Solution: CHAPTER 13: ARCHITECTURAL DESIGN
13.1)
The concepts of styles and patterns occur for buildings and software at both macroscopic and microscopic levels. For example, overall styles (center-hall colonial, A-frame) can be found in a house. These represent macroscopic styles. Lower-level microscopic patterns (for a house) can be found in categories of wood molding, fireplace designs, windows, etc
.
13.2)
Data centered architecture: airline reservation system; library catalog system; hotel booking system
Data flow architecture: any engineering/scientific application where computation is the major function
Call and return architecture: any I-P-O application
Object-oriented architectures: GUI-based applications; any OO application
Layered architecture: any application in which the application functions must be decoupled from the underlying OS or network detail. Client server software is often layered.
13.3)
Hierarchical: dataflow, call return, layer
Non-hierarchical: data centered, object-oriented
Non-hierarchical architectures are probably best implemented using object-oriented and event driven programming techniques.
13.4) Many people define architectural style and architectural pattern as being one in the same (a general system model used as the starting point for system design), though patterns tend to be less broad. A framework might be defined by some people as a set of classes providing a general solution to a problem that can be refined to create an application or subsystem.
13.5) Answers will vary
13.6) Answers will vary
13.7) Answers will vary.
13.8) Answers will vary
13.9) Answers will vary
13.10) Answers will vary
13.11) Answers will vary
13.12) Answers will vary