Question 1. What Are The Major Issues Associated With Managing Product Line Evolution?
Adopting a product line paradigm creates an organizational shift. Managing product line evolution is the most difficult part of the paradigm. The product line will change as new versions of the current product come out. An organization would need to use the new versions to satisfy changing client needs. Additionally, new improvements to various components may change the way the products are built. New version of components may not be entirely backward compatible, thus additional rework will need to be done to accommodate the changes.
Question 2. What Is The Basic Approach To Problem Solving In The Blackboard Framework?
The blackboard framework is a dynamic group of independent entities that communicate and work together in order to solve some common problem. The knowledge sources adds a solution piece to the blackboard data structure when they (independently) think it’s appropriate. There is no centralized control mechanism that makes decisions as to when a knowledge source needs to contribute some piece of information. Rather the control entity states the conditions of when and each knowledge source need to contribute. The knowledge sources observe the commotion on the blackboard and contribute to progress independently.
Question 3. What Are The Components Of The Blackboard Model?
The blackboard model is usually composed of three components: knowledge sources, blackboard data structure, and control. The knowledge source component represents the chunks of information that is needed in order to solve a problem. These sources are separate from each other. The blackboard data structure can be looked at as a repository for the final solution. In this storage receptacle the final solution is slowly developed based on the sources and controls used. The control is not a module, but rather a mechanism or an abstract algorithm that specifies how a problem will be solved.
Question 4. In Addition To The Architecture Itself, What Are The Assets That Can Be Considered As Members Of A Product Line?
A collection of assets includes the following elements:
- Components – this asset does not directly deal with re-use of code, it encompasses and utilizes all elements of previously built successful parts (components) of the system. This includes re-use of design, documentation, structure, and etc. of components.
- Personnel – when the products have the same structure, then workers can shift from project to project and be able to quickly understand and adapt to changes.
- Defect elimination – when a component is re-used in different projects, eliminating a fault in one component solves problems in multiple projects.
- Project Planning – previous experiences help planning.
- Performance – these issues are similar from product to product. Predictability increases.
- Processes, methods, and tools – re-use occurs extensively, as the way components have been developed before is well known and understood.
- Exemplar systems – the benefit of seeing systems in action and in operation shows that an organization can deliver on its promises.
Question 5. What Is The Main Function Of The Hla?
The main function of the High Level Architecture is to establish a common infrastructure, or the foundation, for a building other components of a system. The infrastructure is then used and re-used by other components of a system that rely on communication and other resources through HLA. This non-software blueprint of a system has been used by the AMG to create an environment that supports interoperability and reusability. Interface specification is used to coordinate communication efforts of various components that are built on top of the HLA.
Question 6. When Is Middleware Not Appropriate?
Middleware can get very complex and difficult to develop. The difficulties arise from the need to know the location of the servers and the amount of low-level details exposed. Certain domain specific systems with hard real-time systems may not afford to use a middleware services as that may slow down transaction speeds between an OS and applications. If a development company does not trust the middleware vendors, due to the secrecy of client’s data transmitted between databases and some applications, then that company may need to implement such middleware layer in-house.
Question 7. What Kinds Of Changes Are Difficult For An Object-oriented System To Handle?
Managing changes to an object’s identify is the most significant disadvantage of an object-oriented system. If an identify of an object changes, then all other objects that use that identify must be updated in order to reflect the change in just one object. Manageability of various objects becomes a major issue.
Question 8. Can An Object (in The Architectural Sense) Have Multiple Interfaces? Is Such A Feature Desirable?
Yes, an object can have multiple interfaces. From an architectural point of view there are advantages to having multiple interfaces. Because an object preserves the integrity of data it contains, the only way to send messages to that object is via interfaces. Thus if some object A wants to communicate with some other object B, then it has to talk through an interface. One interface does not fit the needs of all objects, thus it is useful to have multiple interfaces to promote communication between different objects that have different requirements.
Question 9. How Can The Activity Of A Filter Be Triggered?
The activity of a filter is triggered when there is information to be processed. When the pipe runs dry and no information is incoming a filter may fall asleep until more information arrives. Additionally, feedback and feedforward controls are responsible for continuing feeding information back into a filter.
Question 10. What Problems Does Architecture Analysis Solve?
Software defects that lead to security problems come in two major flavors:
- bugs in the implementation and
- flaws in the design.
Implementation bugs in code account for at least half of the overall software security problem. The other half involves a different kind of software defect occurring at the design level. The division of design flaws and bugs is about 50/50. Both need to be secured to ensure your software’s well-being. You can institute the best code review program on the planet, with the strongest tools known to humanity, but it’s unlikely that you will be able to find and fix flaws this way.
4 ways to identify flaws
- Analyze fundamental design principles.
- Assess the attack surface.
- Enumerate various threat agents.
- Identify weaknesses and gaps in security controls.
It is far more cost-effective to identify and remediate design flaws early in the design process than to patch flawed design implementations after deployment. Architecture risk analysis (ARA), Threat Modeling, and Security Control Design Analysis (SCDA) are useful in finding and fixing design flaws.
SCDAs are a light-weight approach to ARA. They take less time to conduct and can be carried out by a much larger talent pool than traditional ARA reviews. Most importantly, the lightweight approach is efficient enough that it can be scaled to cover an entire application portfolio.
Organizations failing to integrate architecture and design reviews in the development process are often surprised to find that their software suffers from systemic faults both at the design level and in the implementation. In many cases, the defects uncovered in penetration testing could have been identified more easily through other techniques—earlier in the life cycle. Testers who use architecture analysis results to direct their work often reap greater benefit.
Question 11. What’s The Relationship Between Software Architecture And Software Design?
Software architecture exposes the structure of a system while hiding the implementation details. Architecture also focuses on how the elements and components within a system interact with one other. Software design delves deeper into the implementation details of the system. Design concerns include the selection of data structures and algorithms, or the implementation details of individual components.
Architecture and design concerns often overlap. Rather than use hard and fast rules to distinguish between architecture and design, it makes sense to combine them. In some cases, decisions are clearly more architectural in nature. In other cases, decisions focus heavily on design and how it helps to realize that architecture.
An important detail to note is that architecture is design, but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases—although, there have been attempts to formalize the distinction.
Current trends in software architecture assume that the design evolves over time and that a software architect cannot know everything up front to fully architect a system. The design generally evolves during the implementation stages of the system. The software architect continuously learns and tests the design against real world requirements.
Question 12. What Is Software Design?
Software design is the process of conceptualizing the software requirements into software implementation. This is the initial phase within the software development life cycle (SDLC)—shifting the concentration from the problem to the solution.
When conceptualizing the software, the design process establishes a plan that takes the user requirements as challenges and works to identify optimum solutions. The plan should determine the best possible design for implementing the intended solution.
Software design includes all activities that aid in the transformation from requirement specification to implementation.
Major artifacts of the software design process include:
Software requirements specification: This document describes the expected behavior of the system in the form of functional and non-functional requirements. These requirements should be clear, actionable, measurable, and traceable to business requirements. Requirements should also define how the software should interact with humans, hardware, and other systems.
High-level design: The high-level design breaks the system’s architectural design into a less-abstracted view of sub-systems and modules and depicts their interaction with each other. This high-level design perspective focuses on how the system, along with all its components, implements in the form of modules. It recognizes the modular structure of each sub-system and their interaction among one another.
Detailed design: Detailed design involves the implementation of what is visible as a system and its sub-systems in a high-level design. This activity is more detailed towards modules and their implementations. It defines a logical structure of each module and their interfaces to communicate with other modules.
Question 13. What Is Software Architecture?
The software architecture of a system depicts the system’s organization or structure, and provides an explanation of how it behaves. A system represents the collection of components that accomplish a specific function or set of functions. In other words, the software architecture provides a sturdy foundation on which software can be built.
A series of architecture decisions and trade-offs impact quality, performance, maintainability, and overall success of the system. Failing to consider common problems and long-term consequences can put your system at risk.
There are multiple high-level architecture patterns and principles commonly used in modern systems. These are often referred to as architectural styles. The architecture of a software system is rarely limited to a single architectural style. Instead, a combination of styles often make up the complete system.
Question 14. How Do Engineering Disciplines Evolve?
The engineering disciplines evolve from ad hoc state in two steps. Initially, talented and passionate amateurs pioneer the discipline. They achieve their goals by all means necessary – usually irrationally using available resources. Later the routine production occurs. With time the need for advancement arises and supporting science for an engineering discipline emerges. The maturing science eventuallys turn into a “professional engineering practice,” where science will become the main driving force of a discipline.
Question 15. What Are Four Methods That Are Commonly Used By Architects To Build Systems?
Normative, rational, argumentative, heuristic methodologies. The selection of the four methods depends on the circumstances of the project and a problem at hand. The first two methodologies are widely practiced in engineering institutions.
Question 16. What Influences Architect’s Decisions?
Architect’s decisions are influenced by the system stakeholders, technical environment, problem domain area, organization’s intellectual assets, architect’s education and experience, and politics.
Question 17. Why Do You Need To Have Multiple Views To Accurately Describe System Architecture?
Each view has a specific goals and a purpose; each view accomplishes different objectives. Multiple views of a system provide an abstraction – a developer does not always need to see the whole system and all of its components. Additionally, different stakeholders need different views to understand their role in the system. This promotes understanding for all stakeholders and saves time, as some stakeholders may not care at all about someone else’s view. Finally, multiple views allow for a more concrete view. It is not possible to fit all components of the system on one sheet of paper and make clear sense of it.
Question 18. What Are The Principles Of Good Architectural Documentation?
- Statement of requirements establishes the problem boundary, puts the problem in perspective and explains why the work to be done makes sense. This is the most critical part of documentation as it gives a reader the perspective of a problem.
- Description of context provides a list of inputs and outputs that will interact with a system at stake. Additionally, this description shows the interfaces of the external systems.
- Use of architectural diagrams allows for improved communication and understanding of a system to be developed. The diagrams depict a developer’s imagination, and allow others to see how an original developer envisioned a system.
- Consideration of implementation-level constraints prevents developers from fantasizing about a system that cannot be implemented. If a developer is working with a data-oriented repository style some of the implementation-level constraints may depend on hardware. Addressing these issues early build confidence among many stakeholders – to convince them that a system at stake is indeed possible.
- Rationale for architectural design discusses different options and considerations that were entertained before a set architecture was chosen. Keeping a record of the rationale is important, as new employees or system maintainers will question the decisions later.
Question 19. What Is The Essential Role Of A Software Architect?
Making the right decisions at the right time is the chief responsibility of a software architect. Specifically the architect must evaluate various design options in light of overall system objectives and constraints. Each architectural decision has its benefits and costs, and since it is not possible to achieve all quality attributes that one may desire, an architect must make tradeoffs between available options.
Question 20. What Is The Difference Between Routine And Innovative Design?
Routine design aims at “solving familiar problems” and designing solutions by using the knowledge base from previous projects and experiences. For example, an accounting (payroll) system would most likely involve routine design; as such systems have been in production for a long time and are well understood. Routine design involves a lot of re-use and occurs much more frequently than an innovative design that requires original thinking. Innovative design is opposite of routine design, and aims at solving problems that do not have any previous knowledge base. Innovative design aims at solving original and unique problems, such as controlling an unmanned helicopter through a remote control center.
Question 21. When Should You Seriously Consider Using The Process Control Paradigm To Organize A Software System (or Part Of One)?
Process control paradigm is ideal for the systems that require continuous monitoring of certain output values. In such systems the output values need to be at a specified range in order for the system to function. This paradigm may be applied to real-time systems, where the timing is a critical element of system requirements. An autopilot system is a good candidate for process control paradigm. Altitude control element of an autopilot system is an example of a closed-loop system, as the system must be running continuously (reading information from sensors and processing acting accordingly). A set point of such system would be a specified attitude, and an input variable would be the data from the altimeter. The manipulated variables would be the engine thrust and the elevators of an airplane. The goal of the system would be to maintain the specified altitude (controlled variable) to ensure a smooth flight.
Question 22. How Do You Reason About The Functionality Of Pure Pipe-and-filter Systems? For Example, If Filter F With Input Stream X Delivers The Output Stream F(x), What Does The Following Compute? Why?
The nature of the pure pipe-and-filter systems allows an architect to construct complex data flow system from simpler components. This method allows an architect to understand, in detail, the properties of simpler components. Additionally, an architect can start from a simple system with just a few components, and then build up a more complex system. We can reason about the example in the following manner. It is given that when the input stream X enters filter F, the output stream will be F(X). The output stream F(X) sequentially becomes an input stream to filter G, and the output stream of filter G is G(F(X)). In a similar manner the input stream G(F(X)) enters filter H and the final output stream of the system is H(G(F(X))). The following computation leads to the final result by using the results of previous computation.
Question 23. What Is An Open Proprietary Architectural Standard?
An open proprietary architectural standard is promoted by Morris and Ferguson who make case for open systems where the “complex of standards and rules” would be freely published. This open standard would allow anyone to see how the system was designed and constructed. This open-ended architecture would allow the software to evolve, because any enhancements to the software would have to adhere to a defined architectural, and freely available, standard. An example of an open proprietary product is the CCITT fax standard and the NTSC television standard. An example of a closed proprietary product is Adobe’s PDF file format and Windows 2000 OS, as no one but the company can make changes to the architecture.
CSS3 Interview Questions
Systems Software Interview Questions
Software Engineering Tutorial
Software Engineering Interview Questions
UI Developer Interview Questions
Software testing Tutorial
Software Requirement Analysis and Specifications Interview Questions
CSS3 Interview Questions
Software Development Lifecycle (SDLC) Tutorial
Software testing Interview Questions
Adaptive software development Tutorial
Software Development Lifecycle (SDLC) Interview Questions
Systems Software Interview Questions
Software Process Engineer Interview Questions
Scalable Software Interview Questions