Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
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
|
C++
Java C PHP Python ... Fortran Ada 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. |
|
|
Encapsulation
|
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" |
|
|
Inheritance
|
Permits software reusability
New classes can be created from old classes` |
|
|
Polymorphism
|
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. |
|
|
Class
|
A blueprint for how to make an object
|
|
|
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
|
NAME EXAMPLE
Class Person ___________________________________ Attributes name:string address:string age:string ______________________________________ Functions born(string,string) die() get_age():int |
|
|
UML
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. |
|
|
CONOPS
|
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 constraints. 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.
|
|
|
Goals
|
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
|
|
|
|
Reliability
|
• The probability of failure-free system operation over a specified time in a given environment for a given purpose
|
|
|
Availability
|
• 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. |
|
|
SWEBOK
|
Software Engineering Body of Knowledge
|
|
|
Software
|
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
|
|
|
CASE
|
Computer-Aided Software Engineering
|
|
|
Safety
|
Is a judgment of how likely it is that the system will ause damage to people or its enviornment
|
|
|
Security
|
Is a judgement of how likely it is that the system can resist accidental or deliberate intrusions
|
