quiz 2
Barriers: Firewall
A firewall is a computer at the junction of two network segments that: Inspects every packet that attempts to cross the boundary Rejects any packet that does not satisfy certain criteria, e.g., -> an incoming request to open a TCP connection -> an unknown packet type Firewalls provide increased security at a loss of flexibility, inconvenience for users, and extra system administration.
Compiler components
A lexical analyzer, which takes input language tokens and converts them to an internal form. A symbol table, which holds information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated. A syntax analyzer, which checks the syntax of the language being translated. A syntax tree, which is an internal structure representing the program being compiled. A semantic analyzer that uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text. A code generator that 'walks' the syntax tree and generates abstract machine code.
4 + 1 view model of software architecture
A logical view, which shows the key abstractions in the system as objects or object classes. A process view, which shows how, at run-time, the system is composed of interacting processes. A development view, which shows how the software is decomposed for development. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. Related using use cases or scenarios (+1)
4. What is an architectural pattern?
A stylized abstract description of good practice in architectural design that has been tried and tested in different systems and environments. The pattern should include information on when it is and is not appropriate to use that architectural design.
Context and interaction models
A system context model is a structural model that demonstrates the other systems in the environment of the system being developed. An interaction model is a dynamic model that shows how the system interacts with its environment as it is used.
7. Briefly describe pipe and filter architecture?
A system is decomposed into a set of functional transformations that consume inputs and produce outputs. Data flows from one function to another (the pipeline) and is transformed as it passes through the sequence.
Language processing systems
Accept a natural or artificial language as input and generate some other representation of that language. May include an interpreter to act on the instructions in the language that is being processed. Used in situations where the easiest way to solve a problem is to describe an algorithm or describe the system data Meta-case tools process tool descriptions, method rules, etc and generate tools.
5. What is the fundamental characteristic of a repository architecture?
All shared data is held in a central database that can be accessed by all sub-systems.
Security Techniques: Encryption
Allows data to be stored and transmitted securely, even when the bits are viewed by unauthorized agents and the algorithms are known. Private key and public key Digital signatures
Development platform tools
An integrated compiler and syntax-directed editing system that allows you to create, edit and compile code. A language debugging system. Graphical editing tools, such as tools to edit UML models. Testing tools, such as Junit that can automatically run a set of tests on a new version of a program. Project support tools that help you organize the code for different development projects. Make sure you test out your software on the target platforms!!!
Application architectures
Application systems are designed to meet an organizational need. As businesses have much in common, their application systems also tend to have a common architecture that reflects the application requirements.
Architectural abstraction
Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.
2. Whatarethetwowaysinwhichanarchitecturalmodelofasystemmaybeused?
As a means of facilitating discussion about the most appropriate architecture for a system. As a means of documenting the architecture of an existing or an intended system.
Use of application architectures
As a starting point for architectural design. As a design checklist. As a way of organizing the work of the development team. As a means of assessing components for reuse.
Use of architectural models
As a way of facilitating discussion about the system design A architectural view of a system is useful for communication with system stakeholders and project planning because it is not cluttered with detail. Stakeholders can relate to it and understand an abstract view of the system. They can then discuss the system as a whole without being confused by detail. As a way of documenting an architecture that has been designed The aim here is to produce a complete system model that shows the different components in a system, their interfaces and their connections.
Security risk assessment
Asset identification Identify the key system assets (or services) that have to be protected. Asset value assessment Estimate the value of the identified assets. Exposure assessment Assess the potential losses associated with each asset. Threat identification Identify the most probable threats to the system assets Attack assessment Decompose threats into possible attacks on the system and the ways that these may occur. Control identification Propose the controls that may be put in place to protect an asset. Feasibility assessment Assess the technical feasibility and cost of the controls. Security requirements definition Define system security requirements. These can be infrastructure or application system requirements.
Configuration management
Configuration management is the name given to the general process of managing a changing software system. The aim of configuration management is to support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system.
Examples of application types
Data processing applications Data driven applications that process data in batches without explicit user intervention during the processing. (A digital camera converts raw data from a sensor into a photo file by applying a series of algorithms based on a color model. Transaction processing applications Data-centred applications that process user requests and update information in a system database. Event processing systems Applications where system actions depend on interpreting events from the system's environment. Language processing systems Applications where the users' intentions are specified in a formal language that is processed and interpreted by the system. Two very widely used generic application architectures are transaction processing systems and language processing systems. Transaction processing systems E-commerce systems; Reservation systems. Language processing systems Compilers; Command interpreters.
System context and interactions
Deciding how to provide the required system functionality and how to structure the system to communicate with its environment. Also lets you establish the boundaries of the system. boundaries help you decide what features are implemented in the system being designed and what features are in other associated systems.
Design models
Design models show the objects and object classes and relationships between these entities. There are two kinds of design model: Structural models describe the static structure of the system in terms of object classes and relationships. Dynamic models describe the dynamic interactions between objects.
Implementation issues
Focus here is not on programming, although this is obviously important, but on other implementation issues that are often not covered in programming texts: Reuse Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code. Configuration management During the development process, you have to keep track of the many different versions of each software component in a configuration management system. Host-target development Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system).
Models for System Architecture
For every system, there is a choice of models Choose the models that best model the system and are clearest to everybody. When developing a system, every diagram must have supporting specification The diagrams shows the relationships among parts of the system, but much, much more detail is needed to specify a system explicitly.
Reuse
From the 1960s to the 1990s, most new software was developed from scratch, by writing all code in a high-level programming language. The only significant reuse of software was the reuse of functions and objects in programming language libraries. Costs and schedule pressure mean that this approach became increasingly unviable, especially for commercial and Internet-based systems. An approach to development based around the reuse of existing software emerged and is now generally used for business and scientific software.
Architecture Patterns:Pipe and filter
Functional transformations process their inputs to produce outputs. May be referred to as a pipe and filter model (as in UNIX shell). Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. Not really suitable for interactive Output from one subsystem is the input to the next. Example: 3-pass compiler
Object class identification
Identifying object classes is often a difficult part of object oriented design. There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers. Object identification is an iterative process. You are unlikely to get it right first time.
Build or buy
In a wide range of domains, it is now possible to buy off-the-shelf systems (COTS) that can be adapted and tailored to the users' requirements. For example, if you want to implement a medical records system, you can buy a package that is already used in hospitals. It can be cheaper and faster to use this approach rather than developing a system in a conventional programming language. When you develop an application in this way, the design process becomes concerned with how to use the configuration features of that system to deliver the system requirements.
Information systems architecture
Information systems have a generic architecture that can be organized as a layered architecture. These are transaction-based systems as interaction with these systems generally involves database transactions. Layers include: The user interface User communications Information retrieval System database
Security levels
Infrastructure security concerned with maintaining the security of all systems and networks that provide an infrastructure and a set of shared services to the organization. Application security concerned with the security of individual application systems or related groups of systems. Operational security Concerned with the secure operation and use of the organization's systems.
List4fundamentalquestionsthatshouldbeaddressedinarchitecturaldesign?
Is there a generic application architecture that can be used? How will the system be distributed? What architectural style or styles are appropriate? How should the system be structured? What control strategy should be used?
1. Whataretheadvantageofexplicitlydesigninganddocumentingasoftwarearchitecture?
It improves stakeholder communications It encourages a detailed analysis of the system It helps with large-scale reuse.
Agility and architecture
It is generally accepted that an early stage of agile processes is to design an overall systems architecture. Refactoring the system architecture is usually expensive because it affects so many components in the system
Design for Security: People
Make it easy for responsible people to use the system (e.g., make security procedures simple). Make it hard for dishonest or careless people (e.g., password management). Train people in responsible behavior. Test the security of the system thoroughly and repeatedly, particularly after changes. Do not hide violations.
Misuse cases
Misuse cases are instances of threats to a system Interception threats Attacker gains access to an asset Interruption threats Attacker makes part of a system unavailable Modification threats A system asset if tampered with Fabrication threats False information is added to a system
Host-target development
Most software is developed on one computer (the host), but runs on a separate machine (the target). More generally, we can talk about a development platform and an execution platform. A platform is more than just hardware. It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment. Development platform usually has different installed software than execution platform; these platforms may have different architectures.
Architectural design
Once interactions between the system and its environment have been understood, you use this information for designing the system architecture. You identify the major components that make up the system and their interactions, and then may organize the components using an architectural pattern such as a layered or client-server model. The weather station is composed of independent subsystems that communicate by broadcasting messages on a common infrastructure.
Architecture Patterns/Styles
Patterns are a means of representing, sharing and reusing knowledge A pattern is a stylized description of good design practice that has been tried and tested Patterns include information about when they are/aren't useful Patterns may be represented using tabular and graphical descriptions.
Transaction processing systems
Process user requests for information from a database or requests to update the database. From a user perspective a transaction is: Any coherent sequence of operations that satisfies a goal; For example - find the times of flights from London to Paris. Users make asynchronous requests for service which are then processed by a transaction manager.
Security requirements classification
Risk avoidance set out the risks that should be avoided by designing the system so that these risks simply cannot arise. Risk detection define mechanisms that identify the risk if it arises and neutralise the risk before losses occur. Risk mitigation set out how the system should be designed so that it can recover from and restore system assets after some loss has occurred.
Architectural representations
Simple, informal block diagrams showing entities and relationships are the most frequently used method for documenting software architectures. But these have been criticized because they lack semantics, do not show the types of relationships between entities nor the visible properties of entities in the architecture. Depends on the use of architectural models. The requirements for model semantics depends on how the models are used.
Design and Implementation
Software design and implementation is the stage at which an executable software system is developed. Software design and implementation activities are always mixed. Software design is a creative activity in which you identify software components and their relationships, based on a customer's requirements. Implementation is the process of realizing the design as a program. If the program design is done properly, all significant design should be made before implementation. Implementation should focus on the actual coding.
Representing architectural views
Some people argue that the Unified Modeling Language (UML) is an appropriate notation for describing and documenting system architectures Architectural description languages (ADLs) have been developed but are not widely used
An object-oriented design process
Structured object-oriented design processes involve developing a number of different system models. They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. However, for large systems developed by different groups design models are an important communication mechanism.
Architecture Styles: Repository
Sub-systems must exchange data. Can be done in 2 ways: 1. shared data held in central database and can be accessed by all sub-systems 2. each sub-system maintains its own database and passes data explicitly to other sub-systems First option is more efficient when large amounts of data to be shared
Examples of design models
Subsystem models that show logical groupings of objects into coherent subsystems. Sequence models that show the sequence of object interactions. State machine models that show how individual objects change their state in response to events. Other models include use-case models, aggregation models, generalisation models, etc.
Reuse levels
The abstraction level At this level, you don't reuse software directly but use knowledge of successful abstractions in the design of your software. The object level At this level, you directly reuse objects from a library rather than writing the code yourself. The component level Components are collections of objects and object classes that you reuse in application systems. The system level At this level, you reuse entire application systems.
Architecture Styles: Client/Server Example: a mail system
The control flows in the client and the server are independent. Communication between client and server follows a protocol. Set of stand-alone servers which provide specific services such as printing, data management, etc. Set of clients which call on these services. Network which allows clients to access servers.
Process stages
There are a variety of different object-oriented design processes that depend on the organization using the process. Common activities in these processes include: Define the context and external interactions with the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces.
6. What is the most important advantage of a client-server architecture?
This is a distributed architecture so that it is possible to provide services on different computers. It is easy to add a new server or upgrade existing servers without disrupting the system
Layered architecture
Used to model the interfacing of sub-systems. Organises the system into a set of layers (or abstract machines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.
8. . What are the principal functions of the 4 layers in a generic information System architecture?
User interface User communications, authentication and authorization Information retrieval and modification Database and transaction management
Configuration management activities
Version management support is provided to keep track of the different versions of software components. include facilities to coordinate development by several programmers. System integration support is provided to help developers define what versions of components are used to create each version of a system. This description is then used to build a system automatically by compiling and linking the required components. Problem tracking support is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed.
Box and line diagrams
Very abstract - they do not show the nature of component relationships nor the externally visible properties of the sub-systems. However, useful for communication with stakeholders and for project planning.
Architectural views
What views or perspectives are useful when designing and documenting a system's architecture? What notations should be used for describing architectural models? Each architectural model only shows one view or perspective of the system. It might show how a system is decomposed into modules, how the run- time processes interact or the different ways in which system components are distributed across a network. For both design and documentation, you usually need to present multiple views of the software architecture.
A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements.
A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements.
Control
A protective measure that reduces a system's vulnerability. Encryption is an example of a control that reduces a vulnerability of a weak access control system
Vulnerability
A weakness in a computer-based system that may be exploited to cause loss or harm.
External Intruders
All network systems are vulnerable to security breaches by external intruders: financial malicious secrets and worse Modern software is so complex that it is impossible to eliminate all vulnerabilities. Many skilled individuals and organizations are continually seeking to discover and exploit new vulnerabilities.
Attack
An exploitation of a system's vulnerability. Generally, this is from outside the system and is a deliberate attempt to cause some damage.
An ideal division of a complex system into subsystems has low coupling between subsystems and high cohesion with subsystems.
An ideal division of a complex system into subsystems has low coupling between subsystems and high cohesion with subsystems.
System Architecture
Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system. Computers and networks (e.g. centralized, distributed) Interfaces and protocols (e.g., http, ODBC) Databases (e.g., relational, distributed) Security (e.g., smart card authentication) Operations (e.g., backup, archiving, audit trails)At this stage of the development process, you should also be selecting: Software environments (languages, database systems, class frameworks, etc.) Testing frameworks
System Architecture pt 2
Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.
Security Techniques: Authentication & Authorization
Authentication establishes the identity of an agent: What does the agent know (e.g., password)? What does the agent possess (e.g., smart card)? What does the agent have physical access to (e.g., crt-alt-del)? What are the physical properties of the agent (e.g., fingerprint)? Authorization establishes what an authenticated agent may do: Access control lists Group membership
Threat
Circumstances that have potential to cause loss or harm. You can think of these as a system vulnerability that is subjected to an attack.
Security in the Software Development Process Conclusion
Conclusion You can never guarantee that a system is completely secure, but you can do a great deal to minimize the risks and to be able to recover from problems.
External Intruders examples
Examples of external security vulnerabilities: unauthorized access — modify software, install listening devices backdoors — bypass authentication denial of service — overload and other forms of blocking eavesdropping spoofing phishing etc., etc.
The Economics of Security
How secure should your system be? Building secure systems adds cost and time to software development
Security within an Organization: People
Many security problems come from people inside the organization
Security Needs and Dangers
Needs Secrecy: control of who gets to read information Integrity: control of how information changes or resources are used Availability: providing prompt access to information and resources Accountability: knowing who has had access to resourcesDangers Damage to information — integrity Disruption of service — availability Theft of money — integrity Theft of information — secrecy Loss of privacy — secrecy
Architecture and system characteristics
Performance Localize critical operations and minimize communications. Use large rather than fine-grain components. Security Use a layered architecture with critical assets in the inner layers. Safety Localize safety-critical features in a small number of sub-systems. Availability Include redundant components and mechanisms for fault tolerance. Maintainability Use fine-grain, replaceable components.
Security Techniques: Barriers
Place barriers that separate parts of a complex system: Isolate components Firewalls Require authentication to access certain systems or parts of systems Every barrier imposes restrictions on permitted uses of the system. Barriers are most effective when the system can be divided into subsystems.
Exposure
Possible loss or harm to a computing system. This can be loss or damage to data, or can be a loss of time and effort if recovery is necessary after a security breach.
Programming Secure Software
Programs that interface with the outside world (e.g., web sites, mail servers) need to be written in a manner that resists intrusion. Insecure interaction between components Risky resource management Leak defenses Project management and test procedures must ensure that programs avoid these errors.
Reuse costs
Reuse costs The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs. Where applicable, the costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high. The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that you are developing. The costs of integrating reusable software elements with each other (if you are using software from different sources) and with the new code that you have developed.
Subsystem models
Shows how the design is organised into logically related groups of objects. In the UML, these are shown using packages - an encapsulation construct. This is a logical model. The actual organisation of objects in the system may be different.
Asset
Something of value which has to be protected. The asset may be the software system itself or data used by that system.
Operations: Recovery
Sooner or later every system fails because of hardware, software, operational, or security problems. The operating procedures must anticipate loss of data and damage to systems, which can happen at any moment. Backup techniques At regular intervals check point the system At regular intervals backup all data. Keep full audit trails of all important transactions Recovery software Recovery software is complex. It needs to be tested regularly in realistic situations. A good practice is to rebuild the entire system, but this may not be possible with large collections of data.
Advantages of explicit architecture
Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non-functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems Product-line architectures may be developed.
Minimizing Risks: Procedures
The operating procedures must anticipate security problems. A senior member of staff must have responsibility for security. Equipment All system software should be kept up to date with latest security patches. All systems should run up to date antivirus software. Rules about passwords, personal equipment, and non-standard software should be explicit. Routine checks Run network security tests regularly. Run password checkers Training Keep staff informed about security. Ask for their advice.
Security in the Software Development Process
The security goal The security goal is to make sure that the agents (people or external systems) who interact with a computer system, its data, and its resources, are those that the owner of the system would wish to have such interactions. Security considerations need to be part of the entire software development process. They may have a major impact on the system architecture chosen.
Minimizing Risks: Programming
The software development challenge develop secure and reliable components protect whole system so that security problems in parts of it do not spread to the entire system A large system will have many agents and components Each is potentially unreliable and insecure components acquired from third parties may have unknown security problems The commercial off-the-shelf problem Developers of off-the-shelf software have considerable incentives to supply software that has many options and features In developing such software rapidly they have fewer incentives to be thorough about security.
Minimizing Risks: System Architecture
The system architecture can minimize risks in various ways: Secure protocols, e.g., HTTPS encryption. Authentication, e.g., encryption of passwords in transmission and when stored, two factor authentication. Barriers, e.g., firewalls, private networks, and virtual private networks. Data security, e.g., encryption of stored data, backup.
External Intruders: Minimizing Risk
There is no way to guarantee security from external intruders, but careful software development can make a major difference. How to minimize the risks: System design — secure protocols, authentication, barriers to access Programming — defensive programming and extensive testing Operating procedures — backup, auditing, vulnerability testing Training and monitoring personnel
Cohesion
a measure of dependencies within a subsystem. If a subsystem contains many closely related functions, its cohesion is high
Subsystems
grouping of elements that form part of a system
design
he requirements describe the function of a system as seen by the client.Given a set of requirements, the software development team must design a system that will meet those requirements. Software development Software development is a craft. Software developers have a variety of tools that can be applied in different situations. Part of the art of software development is to select the appropriate tool for a given implementation. Creativity and design System and program design are a particularly creative part of software development, as are user interfaces. You hope that people will describe your designs as "elegant", "easy to implement, test, and maintain." Above all strive for simplicity. The aim is find simple ways to implement complex requirements.
Coupling
measure of the dependencies between two subsystems. If the subsystems are strongly coupled, it is hard to modify one without modifying the other