MIS 321 Test 1

who introduced design patterns to IT?

"Gang of Four" (GoF) - Design Patterns: Elements of Reusable Object-Oriented Software - Published in 1994 - Dr. Erich Gamma - Dr. Richard Helm - Dr. Ralph Johnson - Dr. John Vlissides

Encapsulation

- bundling data and methods that work on that data within a single unit (i.e. the object) - used to hide the internal representation, or state, of an object from the outside Procedural vs. OOP "The best functions are those with no parameters!" - Robert C. Martin (Uncle Bob)

Extreme Programming

- Efficiency, customer focus and feedback, and quality - Kent Beck

Lean Software Development

- Eliminate work that does not create customer value - Mary and Tom Poppendieck

HLR Examples

- Good: *the system should track lost tools by department and type *the outcome should reduce yearly cost of lost tools by half - Bad: *the system will maintain a database of tools (id, type, checked out status, date,...) lost, by by department and type Each HLR will become many detailed requirements during the Analyze Stage!

Feature-Driven Development

- Interactive development of user-focused features - Jeff DeLuca

4 essential elements of design patterns

- Name: Identifies a pattern - Problem: describes when to apply the pattern in terms of the problem and the context - Solutions: describes elements that make up the design, their relationships, responsibilities, and collaborations - Consequences: results and trade-offs of applying the pattern

Crystal Family

- People, communication, process rigor maps to product and organization dynamics - Listair CockburnAi

Scrum (part 2)

- Product Owners maintain a prioritized list of requirements in a product backlog. - Requirements take the form of user stories - Daily stand-ups or "scrums" are held to track progress - The Scrum Master helps remove outside distractions and ensures daily scrums stay on point

Dynamic Systems Development Method

- Structured approach to rapid development, collection of best practices - DSDM Consortium

Scrum

- Teaming, organizing work - Jeff Suthewwrland and Ken Schwaber

Kanban Method

- Visualize and manage workflow, just-in-time development - David Anderson

Open / Closed Example

- a SalaryCalculator class that takes in a list of developers with Level, Hourly Rate, and HoursWorked

what is a methodology?

- a body of practices, procedures, and rules used by those who work in a discipline (process, artifacts, terms, etc.)

1. Single Responsibility

- a class should have one, and only one, reason to change - there is a place for everything and everything is in its place ... Uncle Bob ... Ben Franklin - find one reason to change and take everything else out of the class - very small classes with precise names > Large classes with generic names

Single Responsibility Example

- a class that keeps up with books

3. Liskov Substitution Principle

- a subclass should behave in such a way that it will not cause problems when used instead of the superclass - derived class should be able to substitute its parent class without the consumer knowing it - every class that implements an interface, must be able to substitute any reference throughout the code that implements that same interface - every part of the code should get the expected result no matter what instance of a class you send to it, given it implements the same interface

Abstract Class Example

- abstract classes are easiest understood looking at an example. Let's return to the shapes example we looked at previously.

how are abstract classes different from an interface or normal class?

- abstract classes are similar to other classes, but has the keyword abstract - any method that must be overridden in its subclasses must also have the abstract keyword - unlike an interface, abstract classes can have normal properties, fields, methods, etc.

Crystal Family (continued)

- advocates that when a team is using an iterative process, the amount of structure should be tailored to the dynamics of the team - "no two crystals are the same"

History of Agile Development

- agile is an overarching term that includes iterative approaches to software development that embrace the values of the Manifesto for Agile Software Development - not new *IBM was using iterative approaches as early as 1957 *Today includes methodologies such as XP, Scrum and Kanban

what is Project Management?

- as defined by PMI, a project is a temporary endeavor undertaken to create a unique product, service or result - a project has a defined beginning and end in time (consequence means it must have bound scope and resources) - project management this is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements

4. Interface Segregation Principle

- clients should not be forced to depend upon interfaces that they don't use - "who cares if a client gets a bit more than it needs. It can just ignore it..." NO! - instead, break down interfaces into smaller pieces to make them easier to implement and offering more control over who sees what

simplified design principles (part 2)

- code to an interface, not an implementation - term interface is overloaded here... really means super type. Could be an interface or an abstract or super class - an example is to use an interface to represent behaviors - then create a set of classes whose entire reason for being is to represent the behavior implementing the interface - the point of this principle is to exploit polymorphism

what is a strategy pattern?

- defines a family of algorithms, encapsulates each one, and makes them interchangeable. strategy lets the algorithm vary independently from clients that use it - used when you want to choose the algorithm to use at runtime

Inheritance overview

- deriving a new class from an existing class - primary benefit: eliminate redundant code

Inheritance

- deriving a new class from an existing class forming a hierarchy of classes - the derived class or subclass inherits methods and properties from the parent or super class - intended to help with reuse of existing code with little or no modification - for example, a TA "is a" person. The TA class could inherit from the Person class forming an "isa" relationship between the two classes - derived classes can be treated like the parent class. i.e. we can call all methods from the Person class on an object type of TA Mammals: Dogs: Cats: Humans: (as part of Cats) Lions: Tigers: Leopards:

Kanban Method (continued)

- developed by David Anderson in an attempt to build a "just in time" software delivery system - Kanban translates to "signboard" in Japanese Six core principles: - visualize workflow - limit work in progress - manage the flow through the system - provide explicit policies - improve collaboratively - ensure feedback

History of Waterfall Methodologies

- emerged in the 50's - advocates sequential phases of development - first and most popular model *fits with organizational hierarchy *taken from other fields (construction, manufacturing) *fits well with outsourcing model

Information Gathering Techniques

- examine existing documents - benchmarking - direct observation - questionnaires - interviews (individual, group) There are advantages and disadvantages to each. It is common to use a combination of techniques.

simplified design principles (part 3)

- favor composition over inheritance - composition provides more flexibility - composition allows changing behavior at runtime!!!

Lean Software Development (continued)

- first book on the topic appeared in 2003 - stems from Lean manufacturing which is built on the idea that all process and resources must directly contribute to creating something of value to the customer - seven key principles are: Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build integrity in, See the whole

Extreme Programming (XP) (part 1)

- first used at Chrysler in 1996 - developed in an attempt to release quality code faster and more efficiently - introduction of Test Driven Development (TDD)

Plan Driven Methodologies

- formalized process with well defined stages - plan, analyze (requirements), design, develop, test, implement, support - document THEN implement - examples include Waterfall, ADM, SDLC, etc. (look at flowchart pics)

Encapsulation overview

- group related data and functions together - primary benefit: reduce complexity and increase reusability

Abstraction

- handle complexity by hiding unnecessary details from the user, enabling the user to implement more complex logic on top of the abstraction without needing to understand the hidden complexity - simpler interface - reduces the impact of change

Abstraction overview

- hide the details and complexity, show only essentials - primary benefit: reduce complexity and isolate impact of changes

High Level Requirements

- high-level description of what the product must do - describe the major business processes, capabilities, interfaces, and functions in scope - basis for development the more detailed and precise requirements during the Analyze stage each requirement should be: - necessary - concise - implementation free - attainable - consistent - unambiguous - verifiable

Plan Stage objectives

- identify stakeholders *needs, expectations, constraints, etc. - define scope *high-level requirements *resources (budget) *interfaces / interaction points - assess current capabilities (internal and external) - create high-level design or blueprint - define a change plan - identify risks - assess team skills, and create training plan - define transition / cutover strategy - requirements traceability

simplified design principles (part 1)

- identify the aspects of your application that vary and separate them from what stays the same - the OO term is to "encapsulate" what varies so it won't affect the rest of your code - should result in fewer unintended consequences when code changes and more flexibility in your application

what is a design pattern?

- in all likelihood, "someone has already solved your problem" - a general, reusable solution to a commonly occurring problem within a given context in software design (there have only been 7 stories ever told...) - "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem..." - Christopher Alexander

Requirements Traceability

- links high-level requirements, the detailed product requirements, and the various analysis, design, build, and test components - maintains cross-reference as analysis, design, build, and test components are created and updated

Polymorphism

- literally means many forms. it describes the idea that different classes can be used with the same interface. - each class can provide its own implementation of the interface - allows us to eliminate long if-else structures or case statements .Speak() for bark(); meow(); talk();

Open / Closed Violation

- method in the class returns total salary for all developers relying on an instance method to calc individual salaries - management wants to give junior devs a bonus. Can we accomplish this without changing the Salary Calculator class? no

Scrum (part 1)

- originally developed in 1993 - tends to focus primarily on the "teaming" or project management aspects of Agile - focuses on time boxing work to create a sense of urgency - each time box is referred to as a "sprint". Shippable code is produced at the end of each sprint.

Dynamic Systems Development Method (continued)

- originally developed in 1994 to add structure to RAD - RAD focuses on creating prototypes as efficiently as possible - DSDM focuses on the project management aspects of Agile - requirements are deemed as "must, should, could, and won't haves"

Feature-Driven Development (continued)

- originally developed in 1997 by Jeff De Luca - planning and development focus on the specific features that address customer requirements - unlike other Agile methods, the development plan is based on ordering features and assigning them to classes

Formal Coordination Mechanisms include: (3)

- planning - project team structure - project team roles

Waterfall Criticisms

- process heavy - unresponsive to change - little room for user feedback - long development cycles

what are interfaces?

- similar to a class in terms of syntax, but fundamentally different public interface IShape { double GetArea(); }

2. Open / Closed Principle

- software entities should be open for extension but closed for modification - extend functionality by adding new code instead of changing existing code - separate behaviors so the system can easily be extended and not broken *overriding goal is to never break the core system as you add new functionality!

Stakeholder Goals and Expectations (part 2)

- sponsor's vision and business objectives - business rationale - business problems faced - what results are expected and how will they be measured? *will the data be available to calculate the metrics? *are the expected metrics realistic? - do the goals address needs of all stakeholders?

Agile Methodologies

- structured but informal process - process repeated frequently - generate stories, code, test, repeat - implement THEN document - examples include Scrum, XP, Crystal, FDD

what are abstract classes

- the abstract modifier indicates that the thing being modified has a missing or incomplete implementation - the abstract modifier can be used with classes, methods, properties, etc. - an abstract class is a class with the abstract modifier indicating the class is incomplete - an abstract class by definition cannot be instantiated. It must be used as a parent class.

Single Responsibility Violation

- the same class keeps up with saving to a file - the same class loads data from a file - the same class loads data from a url - this would violate the Single Responsibility principle

where did the term come from?

- the term design pattern was originally used by Christopher Alexander to describe building architecture, but has seen many applications since Problem: highway crossing Pattern: clover leaf

why do we need abstract classes?

- there are common implementations such as color and filled that I want to inherit - but now I must remember to override the GetArea and GetPerimeter methods in every subclass created... lots of potential for error... - if we have some methods that must be overridden we can make the method abstract - if a method is abstract the class must be abstract

Common HLR Traps

- too vague (flexible, adaptable, user friendly, may, etc.) - too detailed (must record Employee ID, must be, etc.)

Polymorphism overview

- using different classes with the same interface - primary benefit: refactor nested if statements and switch statements

Stakeholder Goals and Expectations (part 1)

- who are the stakeholders? *sponsor the project *generate, review, and approve requirements *participate in the decision making process (committees, user group representatives, etc) *develop the solution *use the solution *are impacted by changes (technical or process) *support the changes (technical or process)

categories of design patterns (3)

1. Creational Patterns (5) - deals with initializing and configuring classes and objects 2. Structural Patterns (7) - deals with decoupling interface and implementation of classes and objects 3. Behavioral Patterns (11) - deals with dynamic interactions among societies of classes and objects (i.e. how they distribute responsibilities)

4 Pillars of OOP

1. Encapsulation 2. Abstraction 3. Inheritance 4. Polymorphism

what are they? (5)

1. Single Responsibility Principle (SRP) 2. Open/Closed Principle (OCP) 3. Liskovs Substitution Principle (LSP) 4. Interface Segregation Principle (ISP) 5. Dependency Inversion Principle (DIP)

Comparing Agile Methodologies

1. extreme programming 2. scrum 3. feature-driven development 4. dynamic systems development method 5. lean software development 6. kanban method 7. crystal family

why do we use methodologies?

1. guide post - provide structure in a chaotic world 2. ability to scale 3. reuse 4. more predictable results 5. reduce costs/risks *31% of all projects are cancelled before completion *88% of projects run over schedule, over budget or both *52% of projects will cost 189% of their original estimates *average time overrun is 222% of original estimates

why do we study design patterns? (part 1)

1. tried and proven solutions - provides a starting point - provides known tradeoffs - easier to alter than create from scratch 2. provides common vocabulary - similar to mythologies, it provides a way to speak to each other - i.e. "We could use the observer pattern" is a lot easier than describing the potential solution every time you think it should be used 3. Gets us out of the weeds early in the design process

why do we study design patterns? (part 2)

4. Helps ensure adherence to design principles when appropriate 5. Improves understanding of OO principles - less conceptual... easier to understand looking at actual design 6. Broadly understanding patterns makes maintenance easier

5. Dependency Inversion Principle

A) high-level modules should not depend on low-level modules, both should depend on abstraction. B) abstractions should not depend upon details, details should depend upon abstraction - ensuring classes don't depend on specific implementations, it becomes easy to change things around...

Interface vs. Abstract class (advantages & disadvantages)

Abstract: - does not provide full abstraction - cannot achieve multiple inheritance - can declare a member field - can provide complete, default code or just provide the signature that must be overridden Interface: - provides full abstraction - can achieve multiple inheritance - cannot declare a member field - cannot provide any code, just the signatures

Scrum (part 3)

Daily scrums take the form of: - what have I done since yesterday - what am I doing today - what roadblocks do I foresee - Team updates tasks daily to generate burn down charts

Extreme Programming (XP) (part 2)

Key themes include: - frequent releases - pair programming - regular builds - quality - simplicity of code - rapid and regular feedback

what are the drawbacks? (pros and cons)

PROS: - prevents conditional statements - algorithms are loosely coupled from the context entity (can be changed/replaced without changing the context entity) - easy to extend CONS: - application must be aware of all strategies to select the right one in the right situation - in some cases the context must supply relevant data to the strategy making them more tightly coupled - increases the number of objects in the application

Plan Driven vs Agile: Project Team Advice Network

Plan Driven: - Advice-sharing relationships develop vertically (between supervisors and supervisees). There is no need to seek advice horizontally. Agile: - Advice-sharing relationships develop both vertically and horizontally.

Plan Driven vs Agile: Early Project Risk

Plan Driven: - All project uncertainty can be managed before design & development begins Agile: - All project uncertainty cannot be managed upfront. Only the uncertainty in the first iteration is managed.

Plan Driven vs Agile: Late Project Risk

Plan Driven: - Not expected. If scope changes happen, the new uncertainty is managed in its entirety all at once. Agile: Expected. Uncertainty is managed as it arises.

Drawbacks of each

Plan Driven: - no unlimited customer access - no high potential for scope creep / evolving requirements - not many experts - no culture of empowerment Agile: - no well defined requirements - no high project team turnover - no large teams - no virtual teams

Advantages of each

Plan Driven: - well defined requirements - high project team turnover - large team - high project complexity - virtual teams Agile: - unlimited customer access - high potential for scope creep / evolving requirements - many experts - high project complexity - culture of empowerment

Plan Driven vs Agile: Use of Knowledge

Plan Driven: - Codified and explicit. It's discovered via training, manuals, and expert systems. Agile: - Tactic. Relies on having knowledge experts who are willing and able to share their knowledge.

Plan Driven vs Agile: Development Model

Plan Driven: - Formal, traditional 6-7 stage life cycle Agile: - Based on a repeated series of short iterations

Plan Driven vs Agile: Planning

Plan-Driven: - All planning can be complete at once during the early stages of the project. If scope changes arise, a new complete set of plans is developed. Agile: - Because systems emerge, planning can only take place via short-term iterations.

Plan Driven vs Agile: Project Team Structure

Plan-Driven: - Mechanistic (formal and unchanging). Divisional (each team member performs separate and independent roles). Agile: - Organic (flexible and cooperative). Cross-functional (team members belong to functional groups as well with occasional switching between groups).

Plan Driven vs Agile: Project Team Roles

Plan-Driven: Formal and unchanging. Agile: - Informal. Roles will often change as the requirements change.

what do you actually manage?

Scope (Features, Functionality) Schedule (Time) Resources (Cost, Budget) - mitigating risks - process facilitation - managing / meeting or exceeding expectations Balancing project goals: - scope - time - quality - resources

tightly coupled

StockBroker has a Purchaser object as a field

loosely coupled

StockBroker is part of an IPurchaser interface

Interface Segregation Violation

a substitution that doesn't work ex. a rectangle implementing a square class and it could give the wrong area bc the area formula isn't the same as the parent class

what are the advantages/disadvantages of interfaces?

advantage: to build LOOSELY COUPLED code

the strategy pattern is __ __ pattern

behavioral design

what type of pattern?

behavioral design pattern

Composition

hasa relationship - interfaces and abstract classes because they carry all the things

inheritance is an __ relationship

isa inheriting from a broader thing (cat -> tiger, lion, etc)

Liskov Substitution Example

m_width = width; m_height = width; m_width = height; m_height = height;