DOC PREVIEW
UA ECE 573 - Final Exam Study Guide
Type Study Guide
Pages 4

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

ECE 573 1st Edition Final Exam Study GuideLecture # 10 Model based Design of SoftwareEverything is an Object. Every object its own memory made up of other objects. Every objecthas a type. Two objects of the same type can receive the same messages .A program is a bunchof objects sending messages to each other. Model based design principles,1. Everything is a model 2. Model everything 3. Models must conform to a metamodel (It defines the run time associations and is an abstractsyntax) 4. Analysis should be performed on models 5. Programs are code that is generated from modelsDomain specific modelsThe model is first created and perform analysis and architecture exploration and simulation andgenerate configuration, code and executables. The application code structure uses the code structures to maintain the data for application.The population of the data model is done by modelling language and provides boilerplate code. With constraints on the kind of system being built, model-based design can fill in the pieces ofthe system that can be derived from high-level conceptsWith constraints in the UI for designing the system users can utilize a graphical interface toreduce confusion in designing high-level conceptsWith proper code generators tests can be generated based on the structure of the system asdesigned.With verification requirements for the system the models can be analyzed, and if deemedappropriate, the generated software will be more likely to be “correct”.With proper abstractions for the problem and platform code generators can work for more thanone deployment platform to reduce headaches in keeping revisions of a model based design upto date on various platforms.Lecture # 11: SPLA software product line is a set of software-intensive systems that share a common, managed set of features, and are developed from a common set of core assets in a prescribed way.SPLs are highly dependent on economies which determines whether they are cost effective or not. They can be made productive by, • A base of common assets• Pre-planned variation mechanisms• Component assembly is “construction”• Integration, not programming, is the predominant activityWhat are SPLs and what are they not?1. Fortuitous, small-grained reuse.2. Single system development with reuse.3. component-based or service-based development4. reconfigurable architecture5. releases and versions of single products6. a set of technical standardsDifference between application frameworks and SPL,Application frameworks mostly rely on OOP features such as inheritance and polymorphism andthey are made to framework classes and the framework is not updates.SPL is where the application components can be changed. There are no limits to the changes that is made while the integration process can remain the same.The code can be made agile by adoptinglow-cost, low-risk experiments through variation points.Each new system takes advantage of previous defect elimination. The cost of SPL are,Requirements: common requirements may require innovative/ strategic decisions that causeconflict among designers. Architecture: must support inherent product-line variations, requiringgreater talent to correctly identify variation. Components: must be robust and extensible, andvariation points must be built-in or anticipated; redesign requires no-loss of performance.Modeling/Analysis: reuse requires care, and correct identification of constraints (assumptionsmust hold, e.g.). Business cases: must accommodate product variations. Processes: must berobust, and configurable for unique needs of a single use case, if applicable. People: must behighly capable, and specifically trained on SPLs, and likely even trained for this specificarchitecture; transition between writing code and familiarity with the domain, and technologyforecastProduct line essential activities are core asset dept., product development and Management. The examples of SPLs are,Web hosting, Enterprise systems, Payroll management, conference registration sites, mobileapplications, inventory management.Some of the common SPL characteristics are that they are usually databases and web viewstructured. Lecture #12 Formal methods in software engineeringA finite state automaton is a tuple, (S,s0,L,T,F) where S is a finite set of states, s0 is adistinguished initial state, s0 \in S, L is a finite set of labels, T is a set of transitions, T \subseteq(S\times L \times S), and F is a set of final states, F \subseteq S. A.S is the state set S ofautomaton A, A.s0is the initial state, etc.A finite state automaton is deterministic iff ((s, l, s’) 2 T ^ (s, l, s’’) 2 T) =) s’ = s’’.A run of a finite state automaton is an ordered, possibly infinite, set of transitions (a sequence).An accepting run of a finite state automaton is a finite run in which the final transition(s(n-1),l(n-1),s(n)) has the property that s_n \in F. The run is considered accepted IFF itterminates in a final state of the automaton. An infinite run is often called an omega-run, andthus acceptance is considered differently. Properties of LTL,Recurrence, Stability. Lecture # 13 Metrics for SoftwareMetrics for Software:There are four metrics to assess the software:1. Code Coverage- Function coverage: If both linking and run time libraries work properly, then allthe function of the program get executed, else the claims are considered to besuspects.- Statement coverage: As the name suggests, all the statements are to beexecuted. Else, it indicates that there are parts of the program which are wrongand is difficult to identify them since those statements wouldn’t have beenexecuted.- Condition coverage: If our program logic is correct, then all the evaluation(true/false) points of the program would be executed, else it indicates that theremight be a mistake either in the logic or there might be state variables thatwould have resulted in an incorrect order of execution.- Path coverage: This indicates if every possible route of the program has beenexecuted. If there is no complete path coverage, then there might exist a pathwhere there might be errors or exceptions.- Entry/ Exit coverage: This indicates if all the call and return statements offunctions are executed.- File coverage:


View Full Document

UA ECE 573 - Final Exam Study Guide

Type: Study Guide
Pages: 4
Documents in this Course
Load more
Download Final Exam Study Guide
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Final Exam Study Guide and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Final Exam Study Guide 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?