Comp 684 Final Exam Review

 

Be able to define and discuss the following terms and concepts:

            Software architecture

            Architecture Business Cycle (ABC)

            Stakeholders

            Architectural patterns

            Reference models

            Reference architectures

            Architectural structures (views)

                        Module

                                    Decomposition

                                    Uses

                                    Layered

                                    Class

                        Component-and-connector

                                    Client-Server

                                    Process

                                    Concurrency

                                    Shared Data

                        Allocation

                                    Deployment

                                    Implementation

                                    Work Assignment

            Quality attributes

                        Availability

Modifiability

                        Performance

                        Security

                        Testability

                        Usability

            General quality attribute scenario

                        Source of stimulus

                        Stimulus

                        Environment

                        Artifact

                        Response

                        Response measure

            Concrete quality attribute scenario

            Business quality attributes

                        Time to market

                        Cost and benefit

                        Projected lifetime of the system

                        Targeted market

                        Rollout schedule

                        Integration with legacy systems

            Architecture quality attributes

                        Conceptual integrity

                        Correctness and completeness

                        Buildability

            Architectural tactics

            Architectural strategy

            Availability tactics

                        Fault detection

                        Fault recovery

                        Fault prevention

            Modifiability tactics

                        Localize modifications

                        Prevent ripple effects

                        Defer binding time

            Performance tactics

                        Resource demand

                        Resource management

                        Resource arbitration

            Security tactics

                        Resisting attacks

                        Detecting attacks

                        Recovering from attacks

            Testability tactics

                        Input/output

                        Internal monitoring

            Usability tactics

                        Runtime tactics

                        Design-time tactics

            Architectural patterns (styles)

                        Interdependent components

                                    Communicating processes

                                    Event systems

                                                Implicit invocation

                                                Explicit invocation

                        Data flow

                                    Batch sequential

                                    Pipes and filters

                        Data-Centered

                                    Repository

                                    Blackboard

                        Virtual Machine

                                    Interpreter

                                    Rule-based system

                        Call/return

                                    Main program and subroutine

                                    Object-oriented

                                    Layered

            The Design Structure Matrix (DSM)

            Design complexity

            Modularity

Attribute-Driven Design (ADD)

            IEEE 1471 Standard (and its elements)

                        System

                        Architecture

                        Mission

                        Environment

                        Architectural Description

                        Stakeholder

                        Concern

                        Rationale

                        Viewpoint

                        View

                        Model

                        Viewpoint Library

 

Be able to explain or describe:

            How architectures are influenced by:

Stakeholders

The developing organization

The background and experience of the architects

The technical environment

            How architectures affect business goals

            Architecture activities

                        Creating the business case for the system

                        Understanding the requirements

                        Creating or selecting the architecture

                        Communicating the architecture

                        Analyzing or evaluating the architecture

                        Implementing based on the architecture

                        Ensuring conformance to an architecture

            What makes a good architecture

            Why software architecture is important

                        How it helps with stakeholder communication

                        How early design decisions affect the software development

                        What is its value is as a transferable re-usable model

            Why different architectural views are needed

            What a quality attribute scenario is

            What the six parts of a scenario are

            What the possible values are for each of the six parts for each quality attribute

Possible tactics to use to address specific quality attributes

The steps in the ADD process

            Choose the module to decompose

            Refine the module according to the following steps

                        Choose the architectural drivers

                        Choose an appropriate architectural pattern

                        Instantiate modules and allocate functionality

                        Define interfaces of the child modules

                        Verify and refine use cases and quality scenarios

            Repeat the above steps for every module that requires decomposition

How a team structure is formed based on the architecture’s decomposition

What is meant by and what is the importance of building a skeletal system

How to build a Design Structure Matrix

The concepts of complexity and modularity with respect to architectural design

The concepts of cohesion and coupling with respect to architectural design

The uses of architectural documentation

How to choose the relevant views to document

What to include when documenting a view

            Primary presentation

            Element catalog

            Context diagram

            Variability guide

            Architecture background

            Glossary of terms

            Other information

           

 

Sample Short Answer Questions:

 

1.     Aside from creating the architecture itself, describe one other architectural activity.

 

2.     Explain what is meant by the Architecture Business Cycle (ABC).

 

3.     Software architecture is often described as “high-level design”.  What is wrong with this definition?

 

4.     Identify and explain one reason software architecture is important.

 

5.     What is a process structure (view) useful for?

 

6.     In a quality attribute scenario what is meant by the response?

 

7.     For a performance scenario what would be typical response measures?

 

8.     What is meant by the business quality attribute of time to market?

 

9.     What is meant by the architecture quality attribute of conceptual integrity?

 

10.  Identify a specific tactic to use for fault recovery to achieve high availability in a system.

 

11.  One tactic to use when trying to achieve high performance is to manage the resource demand.  Explain one way to do this.

 

12.  What is meant by an architectural pattern?

 

13.  When documenting a view, what is meant by the primary presentation?

 

14.  Identify one piece of information you might include in the architecture background portion of your documentation of a view.

 

15.  Identify one important use of architectural documentation.

 

Sample Essay Questions

 

1.     Why is it important to have an architect as part of the requirements engineering team?

 

2.     List and describe the main activities associated with the job of a software architect.

 

3.     Software architectures are influenced by the stakeholders, the development organization, the background and experience of the architect, and the technical environment.  For each of these influences, explain specifically how the architecture is affected.  Give examples to illustrate your points.

 

4.     It is claimed that the quality attributes defined for a software product drive the software architecture of that product (at least, if done correctly).  Explain why this is the case.  Give examples showing potential problems that could result from ignoring, or failing to recognize, required quality attributes.

 

5.     Describe the Design Structure Matrix (DSM) and explain how creating and utilizing one can aid in dealing with complexity in the software architecture process.  Since modularity can help to manage complexity, how can a DSM help us to correctly modularize our architecture? 

 

6.     Even with significant advances in software engineering processes over the past several years, achieving quality in products today seems to be as big a problem as it ever was.  In your opinion (especially based on what you have learned in this course), what is the reason for this?  What are the barriers to achieving quality, and what specific actions would you recommend be taken within a software development organization to improve the quality of the software produced?

 

7.     Suppose you were the architect working on a software engineering project to develop a medical information processing system.  Assume that the stated goal of this system was to manage the health records of patients for a large health maintenance organization.  Among the identified functions of the system were capabilities for doctors to access patient history online, especially in emergency situations, to add new information based on examinations and laboratory tests, and to allow patients access to their own medical information.  It is also recognized that this system will potentially need to upload and download information from a National Health Information Management System in the future.  Regarding nonfunctional requirements little information is currently available.  With regard to security, the preliminary requirements specification only said that the system should be secure, with regard to performance it stated that the system should respond quickly in emergency situations, and with regard to usability it said that the system should be user friendly.  As the architect you decide to meet with the stakeholders of the system to better understand the nonfunctional (quality) requirements.  What questions would you ask to help in establishing the important quality attributes of the system to be built?  Based on your limited understanding of this system what architectural style or styles do you think would be appropriate to apply and why?

 

8.     Suppose you worked for a software development company that, although they followed a sound software engineering process, did not really have any individual(s) designated as architects, nor did they really engage in any activity resembling architectural design.  How would you try to convince your management that it would advantageous to add architectural design as a fundamental activity in the development process and to designate one or more individuals as software architects?  That is, development an argument that would explain the advantages of conducting architectural design and/or the disadvantages of not doing so, as far as the good of the company was concerned.

 

9.     Explain how the Attribute-Driven Design process is different from approaching architecture design using a Design Structure Matrix and give an example to show how different architectural designs might result for the same problem depending on which approach is taken.

 

10.  Consider the case of an ATM (Automatic Teller Machine) system.  Using the general security scenario shown below, identify one specific security requirement and develop an appropriate concrete quality attribute scenario for it. Then identify useful tactics that you could use to satisfy this requirement.

 

Portion of Scenario

Possible Values

Source

Individual or system that is correctly identified, identified incorrectly, of unknown identity who is internal/external, authorized/not authorized with access to limited resources, vast resources

Stimulus

Tries to display data, change/delete data, access system services, reduce availability to system services

Artifact

System services; data within system

Environment

Either online or offline, connected or disconnected, firewalled or open

Response

Authenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable  high demand for services, and informs a user or another system, and restricts availability of services

Response Measure

Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied