Details regarding any terms or concepts mentioned below can be found in
· Chapters 1, 2, 7, 4, 9, and 5 of the textbook and the accompanying slides posted under Course Content at Blackboard
· Supplemental materials covered by slides under Course Content at Blackboard, including
· Scrum (Introduction and INVEST in user stories)
· Git (for Volition)
Software Engineering Terminology
You should be able to define and answer questions involving the following terms. I’ve supplied definitions for some where it seems to me that the book or other materials have not provided a clear (or good) definition.
· Requirements, both functional and non-functional
· Elapsed time
· Iterative development process: repeatedly perform the entire set of software development activities (analyze, design, implement, test, integrate).
· Architectural design
· System view
· Architectural style: generic definition and specific definitions for each of the following styles:
· Database centric
· Architectural tactic
· Reference architecture
· Functional decomposition
· Relational database: a set of two-dimensional tables of data that can be related to one another via keys
· Primary key
· Foreign key
· Levels of database design
· Conceptual modeling
· Logical design
· Physical design
· ER (Entity-Relationship) Diagram: diagram for showing a system’s data and relationships among data elements that is readily convertible to a description of a relational database.
· Weak vs normal
· Attribute, including:
· Multi-valued (e.g., a person can have multiple email addresses)
· Composite (e.g., a person’s name can consist of title, first name, middle initial, last name, and suffix components)
· Modifiers on relationship, including how these appear on an ER diagram
· Cardinality: number of occurrences of entities
· Modality: necessities of relationships
· UML (Unified Modeling Language): a graphical language used for providing a variety of views of the design of object-oriented software
· UML use case diagram: illustrates relationships between actors and use cases/user stories
· UML class diagram: illustrates pertinent fields and methods of classes and static relationships between classes
· Association: any relationship between classes
· Aggregation (diamond symbol on aggregating class): One or more classes are “part of” another, aggregate, class
· Composition: Like aggregation, but in addition the “parts” do not exist independently of the whole. In coding terms, the composing object is responsible for creating and destroying its part objects.
· Inheritance (triangular arrow symbol pointing to superclass): One class inherits from another
· UML state transition diagram: diagram showing the states that a system can be in and how events cause transitions between states
· UML sequence diagram: diagram illustrating dynamic interactions between classes, specifically, how methods are called (messages are passed between) classes over time
· Object-oriented/relational mapping: Software the facilitates the transfer of data between object-oriented software and a relational database. Room is an example.
· Process model
· Waterfall model
· Incremental model with continuous integration
· Incremental model with multiple releases
· Risk: Anything that could cause a software project to fail to achieve its goals.
· Refactoring: modifying code in order to improve its design and/or implementation, not in order to change its functionality.
· Pair programming: two programmers working together at one machine.
· User story
· Story points
· Product backlog
· Task (in the context of user stories)
· Sprint backlog
· Product Owner
· Sprint planning meeting
· Daily stand-up (what is supposed to occur)
· Sprint review meeting
· Sprint retrospective meeting
· Sprint burndown chart
· Scrum of scrums
· Planning poker
· Git: particular set of software for sharing software and managing different versions of software
· Git commands (describe what each does conceptually; you do not need to know exact syntax)
You should be able to explain, discuss, compare, work with, etc. the following concepts. For some concepts I’ve provided a brief description/explanation; others you should look up if you’re unsure about them.
· Essentially every software project has these four activities: analysis, design, implementation, testing
· What differs from project to project is when these activities are performed and how they are carried out
· Major differences between school homework assignments and building systems: increases in complexity, particularly increases in number and types of interactions between elements of the system
· Real-world systems also include packaging/distribution and maintenance activities along with the other four activities
· What are three approaches to dealing with complexity?
· “Simplification” (divide and conquer): decompose problem, employ incremental development, etc.
· “Technology”: use better software development and support tools such as Android Studio IDE, Git, Jira, etc.
· “Process”: follow best practices for organizing and managing activities and people, such as Scrum
· Project coordination involves three P’s: Processes, Products, and People
· Design is often described at two levels: architectural and detailed.
· List and/or briefly describe at least four of the seven architectural patterns covered in Section 7.2.3 and be able to compare/contrast architectures and determine which of several options is most suitable for certain problems.
· Give an example of an architectural tactic
· Name an example of a reference architecture
· List and/or briefly describe at least two of the four levels of database design and be able to identify which of a pair of levels is conceptually higher (would come earlier in a development process) than the other
· Be able to interpret an ER diagram, specifying the entities, relationships, and attributes, including weak entities, multi-valued attributes, identifying (key) attributes, and cardinalities
· Be able to construct an ER diagram given a simple problem domain description
· Be able to logically design appropriate database tables, indicating primary and foreign keys, for a given simple ER diagram
· Be able to list/briefly describe at least three different types of UML diagrams
· Be able to draw or interpret a simple UML class diagram illustrating classes (appropriately broken into three areas for name, fields, and methods) and various associations, including those showing aggregation and inheritance.
· Be able to interpret a simple UML state diagram
· Be able to interpret a simple UML sequence diagram
· UI design involves two distinct aspects: designing flow of interactions and designing look-and-feel
· Consistency, both internal and external, is a key UI design heuristic
· List and/or briefly describe at least two of the seven other-than-consistency “other issues” for UIs beginning on p. 156 (Chapter 7 slide 56)
· Iterative development is also necessarily incremental, but the converse does not necessarily hold. For instance, all analysis and design might be done at one time and only the coding and testing be done incrementally.
· The waterfall model was an improvement over having no process methodology at all, but for the most part it cannot be followed in real-world practice because requirements change over time, mistakes are discovered that require reworking analysis and design, etc.
· The spiral model is an example of an iterative process that focuses on reducing risk.
· A good implementation will have features including readability, maintainability, good performance, traceability to requirements, correctness, and completeness; you should be able to list at least four of these
· Why coding guidelines are important: consistency
· What coding guidelines usually cover (naming, formatting, language usage)
· The best comments describe what the code is intended to do and provide external references when appropriate
· List at least two of the four values of the Agile Manifesto.
· Know that Pair Programming is a “key practice” of Extreme Programming (XP).
· Scrum: Popular agile development methodology based on the notion of sprints, leading to highly incremental and iterative approach to developement.
· Name and briefly describe the three main roles in Scrum.
· Name and briefly describe the four meetings that are part of every Scrum sprint (daily stand-up, planning, review, retrospective)
· Name and/or briefly describe at least four of the elements of INVESTing in good user stories (four of the six attributes represented by INVEST)
· Briefly explain how Planning Poker is “played” and for what purpose we have used it.
· Git repository
· Commit objects: what they are, what they point to
· Graph structure of Git repository: commit graph, tree objects
· Which way does a commit object point, toward an earlier commit object or a later one?
· When will a commit object contain pointers to two or more other commit objects rather than to one?
· Compression and the Git repository
· A branch in Git is a named pointer to a commit object that is updated to track subsequent commits.
· Git branches facilitate individuals working in parallel from a shared starting point and merging their completed code back to the shared branch.
· What a merge conflict is and how a conflict can arise
· Describe (at a high level; the exact syntax is not important) how Git represents a merge conflict
· Git “index” (staging area): what is it, which Git commands interact with it and how
Software Engineering Terms and Concepts learned in the context of Android Architecture Components
Related reading: Android Architecture Components slides 1-20 and/or Google codelabs referenced in the final slide
· Design patterns: Standard approaches to handling common situations/problems that arise when developing object-oriented software.
· Observer design pattern: used to provide data from a background asynchronous thread to a main thread
§ Subject object produces data asynchronously
§ Example: LiveData object
§ Observer object registers itself with subject; method of the observer is called when subject has new data.
§ Example: Adroid Observer object, passed to observe() method of a LiveData object, has onChanged() method called when LiveData object has new data
· Singleton: used when, for performance or sharing reasons, we wish to create only a single instance of a class
§ Class has a private constructor and a public static method that invokes the constructor the first time called and on subsequent calls returns a cached copy of the object created on the first call.
§ Example: Singleton pattern should normally be used in an Android app creating a database object.
· Data Access Object (DAO): Object that provides methods for interacting with a persistent data store, such as a database.
· Example: The Room architecture component provides a DAO interface for mapping Java method calls to SQL statements and mapping to Java objects any data returned by executing those statements.