• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key


Play button


Play button




Click to flip

46 Cards in this Set

  • Front
  • Back
Five Pillars of Aerospace Engineering
Fluid dynamics and Thermophysics
Guidance, Control and Dynamics
Computing, information and Communication
Propulsion and power
Structural Mechanics and Materials
Top Languages
Matlab etc.
Types of Languages
Procedural - C, Fortran, Basic, Ada, Pascal
Object Oriented - C++, Java, Ada, Python
Functional - Scheme, Lisp
Interpreted - Python, Matlab
Assembly - Varies with hardware
Web programming - hyml, xml
Parallel programming - MPI,
Logic programming - Prolog
Object Oriented Propgramming
Allows programmers to more closely model the real world.
Rapid prototyping - built and modified quickly
Produces reusable code
encapsulates data and methods
Benefits = Modifiability, Readability, Maintainability, Reliability, Reusability.
Data and methods (ie functions) are stored together in a "class"
Objects communicate with each other thru well defined interfaces
Knowledgeable Things
Writing good code is an art (~5 yrs of experience)
C and Fortran are "action oriented"
Java and C++ are "object oriented"
Permits software reusability
New classes can be created from old classes`
An objects ability to decide what method to apply to itself.
Allows you to avoid very complicated swith or if/else constructs that are required in other languages to treat special cases.
A blueprint for how to make an object
An instance of a class
Dot notation
myCat.size (could returen the size of the cat)
Other Knowlegable stuff
Vehicle "has-a" engine (containment)
Aircraft "is-a" vehicle (inheritance)
UML Example
Class Person
Attributes name:string
Functions born(string,string)
Unified Modeling Language
Structure Diagrams
- Class diagram: describes the structure of a system by showing the system's classes, their attributes and relationships among the classes
- Component diagram: describes how a software system is split up into components and shows the dependencies

Behavior Diagrams
- Activity diagram: describes the business and operational step-by-step workflows of components in a system

Interaction Diagrams
- Communication diagram: shows the interactions between objects or parts in terms of sequenced messages.
- Interaction overview diagram; provides an overview in which the nodes represent interaction diagrams
- Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
- Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.

Class Diagrams: the main building block in Object oriented modeling.
Concept of Operations
A user-oriented document that describes system characteristics for a propsed system from the user's viewpoint
User Requirement
May be the basis for a bid for a contract - therefore
must be open to interpretation

Statements in natural language plus diagrams of the
services the system provides and its operational
Written for customers.
System Requirement
May be the basis for the contract itself - therefore
must be defined in detail
A structured document setting out detailed
descriptions of the system’s functions, services and
operational constraints.
Defines what should be implemented so may be
part of a contract between client and contractor.
Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Product requirements
Requirements which specify that the delivered product must behave in a particular way
• e.g. execution speed, reliability, etc.
Organisational requirements
Requirements which are a consequence of organisational policies and procedures
• e.g. process standards used, implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to the system and its development process
• e.g. interoperability requirements, legislative requirements, etc.
Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain.
Are helpful to developers as they convey the intentions of the system users. (but people need to understand that they might lead to misunderstanding)
Waterfall model
The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.
The phases might overlap a small amount, but generally follow one after the other
At the end of each phase a report or document is past to the next phase (after being signed off)
Architecture and system characteristics
- Need Performance
• Localize critical operations and minimize communications.
• Use large rather than fine-grain components.
- Need Security
• Use a layered architecture with critical assets in the inner layers.
- Need Safety
• Localize safety-critical features in a small number of subsystems.
- Need Availability
• Include redundant components and mechanisms for fault tolerance.
- Need Maintainability
• Use fine-grain, replaceable components.
Four Types of Critical Systems
• The probability of failure-free system operation over a specified time in a given environment for a given purpose
• The probability that a system, at a point in time, will be operational and able to deliver the requested services
Hardware Failure
• Hardware fails because of design and manufacturing errors or because components have reached the end of their natural life (or combat, or environment).
Software Failure
• Software fails due to errors in its specification, design or implementation.
Operational Failure
• Human operators make mistakes. Now perhaps the largest single cause of system failures.
Reliability Terminology
System failure: An event that occurs at some point in time when the system does not deliver a service as expected by its users
System error: An erroneous system state that can lead to system behavior that is unexpected by system users.
System fault: A characteristic of a software system that can lead to a system error. For example, failure to initialize a variable could lead to that variable having the wrong value when it is used.
Human error or mistake: Human behavior that results in the introduction of faults into a system.
Primary safety-critical systems
• Embedded software systems whose failure can cause the associated hardware to fail and directly threaten people. (e.g. avionics)
Secondary safety-critical systems
• Systems whose failure results in faults in other systems which can threaten people (e.g. radar)
Emergent Property
Entities arise out of more fundamental entities and yet are irreducible with respect to them. (relationship of all of the hands have with each other (second, minute, hour)

Functional EX: Bicycle has the functional propert of being a transporatation device once it has been assembled form its components

Non Functional EX: Reliability, performance, safety and security
Functional Examples
1. Each hand shall have 60 ticks where each tick comprises of moving the hand 6 degrees.
2. The watch should be adjustable in order to fit a variety of wrist sizes.
3. If the watch were to be shaken or dropped, the components in the watch should not fail.
Non Functional Examples
1. The system shall never stop until its battery is depleted
2. There should be no extensive training for the watch
3. The ticks of the hands shall have an error percentage of less than 10-7% (+/- 6 seconds per 2 years)
Critical Systems Examples
1. Safety – The relation between the safety and the trigger on a weapon. If the trigger does not do its job properly, the gun can cause severe damage or death.
2. Security – Password protected The system shall lock all files when a password is entered incorrectly.
3. Business – Stocks in the stock market. If stocks drop, the business can loose a lot of money.
4. Mission – GPS for an aircraft. If the GPS goes down, the aircraft will have a hard time navigating.
Software Engineering Body of Knowledge
DEF: Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market
Software Engineering
DEF: An einginerring discipline which is concerned with all aspects of software production
Difference between Software Engineering and computer science
Computer science is concerned with theory and fundamentals; SE is concerned with practicaliites of developing and delievering useful software
Computer-Aided Software Engineering
Is a judgment of how likely it is that the system will ause damage to people or its enviornment
Is a judgement of how likely it is that the system can resist accidental or deliberate intrusions