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;
54 Cards in this Set
- Front
- Back
|
What is engineering, as a discipline?
|
The application of scientific, economic, social, and
practical knowledge in order to design, build, and maintain structures, machines, devices, systems, materials and processes |
|
|
What is software?
|
Computer programs and related documentation of
requirements, designs, models, and manuals. |
|
|
Software Engineering
|
Engineering discipline that is concerned with all
aspects of software production |
|
|
Theories, methods and tools for professional software
development |
– Computer Code/Programs
– Requirements Documents – Design Documents – Data, Process, and other models – User manuals |
|
|
What is the high-level process?
|
Problem -> Requirements Analysis -> Design ->
Implementation -> Testing ->Release -> Maintenance ->Problem |
|
|
Software Development life cycle: problem
|
Some entity (program, process, etc) that
requires software to be created as the preferred solution. – Usually, the older software is no longer needed |
|
|
Software Development life cycle: Requirements
|
The explicit, well defined, thorough
goals of the software. I.e., what should it do? |
|
|
Software Development life cycle: Design
|
The detailed plans that will facilitate the
construction of computer code to sufficiently solve the problem. |
|
|
Software Development life cycle: Implementation
|
The construction of the computer
program that is a solution to the problem. |
|
|
Software Development life cycle: Testing
|
Validating the requirements are met and the
outcomes of computer programs match the expectations set forth in the Requirements and Design stages. |
|
|
Software Development life cycle: Release
|
The transition of computer programs from
the developers to the users. |
|
|
Software Development life cycle:Maintenance
|
The continual upkeep of the software,
including computer programs, documentation, requirements, design, testing, and enhancement/bug-fix implementation. -Designed to evolve to meet the changing needs of the customer |
|
|
Characteristic Goals for software Engineering
|
• Maintainability
• Dependability • Security • Efficiency • Acceptability (compatibility |
|
|
What are the types of software that we engineer?
|
• Stand-alone applications
• Interactive Transaction-based Systems • Embedded System (often real-time) • Batch-processing Systems • Entertainment Systems: • Modeling and Simulation Systems • Data Collection Systems: • Systems of Systems |
|
|
Functional Requirements
|
• Details of services the software must provide
– e.g., what activities must the software perform or facilitate? |
|
|
Non-Functional Requirements
|
• Constraints on the functionalities of the software
– e.g., how should these functionalities be done to adhere to the acceptable business process? |
|
|
Requirements Validation
|
• Validity
• Consistency • Completeness • Realism – Can the requirements realistically be met given resource constraints of the environment • Verifiability |
|
|
SE process Models
|
• Multiple Models
• Waterfall • Incremental Models • Reuse-oriented Models |
|
|
Waterfall Model (Process)
|
Principal stages:
– Requirements Analysis and Definition – System & Software Design – Implementation & Unit Testing – Integration & System Testing – Operation & Maintenance |
|
|
Benefits over waterfall process
|
– Cost of changing/evolving requirements reduced
– Easier to receive / incorporate user feedback |
|
|
Incremental Development Process
|
• Spiral Model
• Prototyping – Design to basic requirements – Develop prototype – Collect feedback and further requirements – Extend prototype |
|
|
Boehm's Spiral Model
|
• A 1998 proposed model
• Risk analysis driven • Cycle: – Set objectives – Assess risk, plan risk mitigation – Develop and validate – Review and Plan |
|
|
Rational Unified Process
|
• A 2003 model, derived from UML-based
work • Iterative steps: – Inception – Elaboration – Construction – Transition |
|
|
Reuse-oriented Process
|
• looks to maximize use of existing
software to build a composite software system |
|
|
Reuse-oriented Process stages
|
• Stages:
– Component Analysis – Requirements modification – System design with reuse – Development and Integration |
|
|
Software Design Activities
|
• Architecture Design
• Interface Design • Component Design • Database Design |
|
|
What are the design inputs?
|
– Platform
- PHP framework, PostgreSQL – Requirements Specification – Data Descriptions |
|
|
Software Design Outputs
|
• System Architecture
• Database Specification – ERD – Data flows • Interface Specification • Component Specification – Including Sub-components |
|
|
Software/System Architecture
|
• The high-level design and linkage of
– Sub-systems – Components – Sub-components |
|
|
Architecture Design Objectives
|
• Understand how to make appropriate
architecture design decisions • Understand typical architectural patterns • Understand which patterns are applicable to which types of software |
|
|
Standard Architecture Types
|
Repository
Client-Server Layered Object Oriented Data processing (pipeline) Program (executable) Event-driven processing User Interface centric applications |
|
|
Repository Architecture and its advantages and disadvantages
|
Sub-systems must exchange data. Either the data is accessible to all subsystems or data is explicitly passed to other sub-systems
• Advantages – Efficient way to share large amounts of data; • Disadvantages – Data evolution is difficult and expensive; – Difficult to distribute efficiently. |
|
|
Client-Server Architecture and its advantages and disadvantages
|
• Distributed system model in which data and
processing is distributed across a range of components. • Advantages – Distribution of data is straightforward; • Disadvantages – No shared data model so sub-systems use different data organization; |
|
|
Layered Architecture and its advantages and disadvantages
|
• Used to model the interfacing of sub-systems
• Advantages – Internal changes in layers have no effect on other components • Disadvantages – Difficult in practice to achieve pure layered architecture |
|
|
Object Architecture and its advantages and disadvantages
|
• Structure the system into a set of loosely
coupled objects with well-defined interfaces. • Advantages – Objects are loosely coupled so their implementation can be modified without affecting other objects • Disadvantages – Object interfaces may change |
|
|
Pipeline Architecture and its advantages and disadvantages
|
• Functional transformations process their
inputs to produce outputs. • May be referred to as a pipe and filter model (as in UNIX shell). • Advantages – Supports transformation reuse. • Disadvantages – Requires a common format for data transfer along the pipeline |
|
|
Program Architecture
|
• Typically sequential execution
– Sub-routine calls affected by data or user interaction logic |
|
|
Event-driven Architecture
|
• Driven by externally generated events
• Two principal event-driven models |
|
|
Two principal event-driven models
|
Broadcast models. An event is broadcast to all
sub-systems. Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing. |
|
|
User Interface Architectures
|
Facilitates interactive software processes
-Model-View-Controller (MVC) is dominant |
|
|
Model-View-Controller
|
• Client-Server
– Client = view – Server = controller + model • N-tier – Database (model) – Application Services (business logic / controllers) – Web Server (views) • Application |
|
|
MVC Architecture
|
• Models (Data)
• Controllers (Logic) • View (User-interface) -Dominant web application framework architecture |
|
|
MVC Architecture advantages and disadvantages
|
• Advantages
– Allows data to change independent of presentation – Allows presentation to change independent of data • Disadvantages – Can lead to complex code, even when data models are simple |
|
|
Transaction Processing Architecture
|
• Often a sub-sytem of a larger architecture
• Driving goals are – minimal transaction latency – ACID : atomic, consistent, isolated, durable |
|
|
UML
|
-Unified Modeling Language (UML) is the most
common standardization of software design models |
|
|
Use Case Diagrams
|
• Gives a top down perspective of the system
• Shows and describes the functional requirements of the system |
|
|
Use case basic symbols and players
|
Actors – key players to the system
Use Cases – key functions to the system Included Functions – required functions Extended Functions – optional functions Use Case Descriptions |
|
|
Activity Diagrams
|
• Used to describe procedural logic and work flow
• Similar to a flowchart |
|
|
Activity Diagrams Basic Symbols
|
• Action
- Initial function to describe • Fork / Join - Parallel processes not needed to run in order • Decision / Merge - Conditional statements - If-then-else statements • Flow / Edges |
|
|
Sequence Diagrams
|
• Interactive Design
‒ Passes messages between participants (objects) |
|
|
Sequence Diagrams Basic Symbols
|
• Object
• Timeline ‒ How long each object is active • Active Object • Method Call ‒ Reaching the next object with a call • Messages |
|
|
State Machines
|
• Another way to describe the behavior of a system
• State Machines model the change of states and the events that cause them |
|
|
State Machines Basic Symbols
|
• Initial State – Starting Position
• Final State – Ending Position • Do Behavior • Event / Transition • State Internal Behavior |
|
|
Entity-Relationship Diagrams (ERD) and its basic symbols
|
• Data Model to describe a database in an abstract way
• Chen Notation vs. Crow’s Foot Notation • Entity • Relationship • Attribute |
