SE 430 Object Oriented Modeling Dennis Mumaugh Instructor
SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm. depaul. edu Office: CDM, Room 428 Office Hours: Thursday, 4: 00 – 5: 30 November 10, 2016 SE 430: Lecture 10 1 of 75
Administrivia § Comments and feedback § Last Assignments Ø Ø Assignment 7 » Due tonight Assignment Critique » Due November 17, 2016 Term Project » Due November 17, 2016 Final Examination » November 12 to November 18. » Given on Desire 2 Learn » See study guide on-line November 10, 2016 SE 430: Lecture 10 2 of 75
Team Project § The final report should use standard business report format. Due date: Thursday, November 17, 2016 Ø Use D 2 L to submit. I need only one copy from the team! The document should be reasonably smooth and coherent. Ø Cut and paste doesn’t always work well. Different styles and formats are jarring. Have a logical organization. Proofread your submission: Ø Spelling Ø Print it out and check format and layout Ø Names and identifiers are spelled consistently All team members should read the entire submission. Ø Remember your grade depends on how good the submission is. Questions Ø What to do about Design Class Diagram if it is too big Group (peer) evaluations due at the same time: use email Ø § § § November 10, 2016 SE 430: Lecture 10 3 of 75
Peer review § See instructions on § § § http: //condor. depaul. edu/dmumaugh/se 430/assignments/rating. html Each student must review the other team members and rank them on their performance. This is the place for team members to talk about members who did not contribute or contributed poor work, etc. I use this to adjust the team project grades. Ø I give a grade for the project and then adjust the individual contributors accordingly. Ø It is possible for a person to get a very low score if they have not contributed or did and required total rewriting by other team members. Send me an email directly with your comments. See details on web page. Due same time as project November 10, 2016 SE 430: Lecture 10 4 of 75
Things to Ponder ü Some people don’t read the book or notes or spend time on the ü ü ü lectures ü Some skip over the administrivia and then wonder why they weren’t told things. ü Some anecdotal evidence that people who skip classes tend to do worse on exams. Some don't read the descriptions thoroughly. Some do not follow instructions; explicit instructions Some solve problems not requested to be solved; systems not within the scope of the problem. Engineering is a precise discipline and uses the written word to describe things concisely. Terminology is important. November 10, 2016 SE 430: Lecture 10 5 of 75
SE 430 – Class 10 Topic: Wrap-up: Ø Overview of Systems Development Life Cycle Methodologies » Sequential Methodologies » Evolutionary Methodologies » Agile Methodologies Ø Best practices Ø Review Reading: Ø Arlow & Neustadt, Ch. 's 1, 2, 10 Ø Scrum Primer (all) Ø The New Methodology (Martin Fowler) Ø Important Object Oriented Concepts, Lecture 1, Slides 32 -70 Ø Software Development Life Cycle, Lecture 1, Slides 71 -88 November 10, 2016 SE 430: Lecture 10 6 of 75
Thought for the Day “It doesn’t matter what process you use as long as you use one, and you follow it fully. ” - James Coplien November 10, 2016 SE 430: Lecture 10 7 of 75
Last time Topics: Ø Design Model » Design Model in the UP » Constructing Design Class Diagrams » Package and Deployment Diagrams » Non-Graphical Design Model Documentation Ø Architecture » Architectural Patterns for the Assemble Document System November 10, 2016 SE 430: Lecture 10 8 of 75
Cleanup – After the DCD § Use scenarios to validate the responsibilities of each object. Ø Check the interaction diagram for each scenario to check the completeness of the validation. § Take each use case and trace its actions on the Design Class Diagram Ø Use this to validate associations and other items § Make sure terminology and names are consistent and included in Glossary November 10, 2016 SE 430: Lecture 10 9 of 75
Overview of Systems Development Life Cycle Methodologies November 10, 2016 SE 430: Lecture 10 10 of 75
The systems development lifecycle § “The systems development life cycle (SDLC) is the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users”* § A methodology is a formalized approach to implementing the SDLC § What differentiates one methodology from another: Ø Ø The specific activities that must be performed When, how, and how often the activities are performed Who performs the activities The amount of emphasis placed on an activity at a specific point in time * Dennis, Alan (2012 -05 -01). Systems Analysis and Design with UML, 4 th Edition (Page 2). Wiley. Kindle Edition. November 10, 2016 SE 430: Lecture 10 11 of 75
Software Development Process § Ad hoc Code and Fix Ø Rapid Prototyping § Prescriptive Ø Linear/sequential (Classic and Waterfall) Ø Evolutionary (Iterative/incremental or spiral) Ø Unified Process § Adaptive Ø Lean and agile methods Ø November 10, 2016 SE 430: Lecture 10 12 of 75
Sequential Methodologies November 10, 2016 SE 430: Lecture 10 13 of 75
Sequential (‘waterfall’) methodology § The term waterfall was coined by Winston Royce in a 1970 paper titled Managing the Development of Large Software Systems, in the Proceedings of IEEE WESCON § The paper used the sequential waterfall approach as an example of an ill-conceived, risk-prone practice for developing large systems § Royce advocated a series of iterative feedback loops among the development stages, incrementally gaining learning value from working software § Instead of adopting the approach Royce advocated, managers and practitioners adopted its anti-form, without feedback loops November 10, 2016 SE 430: Lecture 10 14 of 75
Waterfall SDLC § Each phase is marked by completion of Deliverables § The primary software project phases: Ø Ø Ø Requirements Analysis Design Construction Quality Assurance (aka Testing) Deployment November 10, 2016 SE 430: Lecture 10 15 of 75
Waterfall SDLC November 10, 2016 SE 430: Lecture 10 16 of 75
Waterfall system development model § Highly-sequential process § Failure symptoms: Protracted integration and late design breakage Ø Late risk resolution Ø Requirements-driven functional decomposition Ø Adversarial stakeholder relationships Ø Focus on documents and review meetings § Still followed (in name or practice) by many organizations, usually a modified version Ø November 10, 2016 SE 430: Lecture 10 17 of 75
Waterfall system development model Sequential: suitable projects and management approaches § A sequential SDLC is suitable for projects with: Ø Ø Ø Clear, unambiguous, and stable user requirements Familiar, proven technology Low complexity Adequate time Stable schedule § A project meeting most of these criteria can use conventional project management practices, such as big, up -front planning and conventional risk assessment November 10, 2016 SE 430: Lecture 10 18 of 75
Evolutionary methodologies November 10, 2016 SE 430: Lecture 10 19 of 75
Evolutionary Model (Spiral) § Software is developed in a series of incremental releases ranging from early prototypes to complete engineered versions of the system. § Characterized by Ø Risk driven approach Ø Milestones § Weaknesses Ø Convincing customers that evolutionary approach is controllable. Ø Demands expertise in risk assessment. § Strengths Ø Matches the natural progression of a project. Ø Reduces risk November 10, 2016 SE 430: Lecture 10 20 of 75
Evolutionary methodologies § An evolutionary methodology follows an iterative and incremental approach that allows the start of development with incomplete, imperfect knowledge § An iterative and incremental process is like solving a jigsaw puzzle: neither top-down nor bottom-up but accretionary and convergent § An iterative and incremental process offers these advantages: Ø Logical progress toward evolving a robust architecture Ø Effective management of changing requirements Ø Effective means to address changes in planning Ø Ability to perform continuous integration Ø Early understanding of the system (the ‘Hello world!’ effect) Ø Ongoing risk assessment § Evolutionary methodologies are incremental at both the macro (projectscale) and micro (working team) process levels November 10, 2016 SE 430: Lecture 10 21 of 75
Iterative Development Successive enlargement and refinement of a system through multiple development cycles of analysis, design, implementation and testing. Spiral Model § Developed by Barry Boehm at TRW in 1988 § Incorporates risk management as an integral part of the life cycle § Prior to every major phase, risks are identified analyzed, and steps are taken to avert them § If progress is not adequate, the project may be abandoned November 10, 2016 SE 430: Lecture 10 22 of 75
Iterative Development November 10, 2016 SE 430: Lecture 10 23 of 75
Iterative system development model § Non-linear approach to system development § Incorporates top five principles of modern development processes: Ø Architecture first. Provides the central design element Ø Iterative life-cycle process. Provides the essential risk management element Ø Component-based development. Provides the technology element Ø Change management environment. Provides the control element Ø Round-trip engineering. Provides the automation element November 10, 2016 SE 430: Lecture 10 24 of 75
5, 000 foot view of Iterative SDLC § Iterative SD model defines four life-cycle phases: Ø Inception Ø Elaboration Ø Construction Ø Transition § We iterate through each phase, and repeat as needed. § Now, for a quick survey of the phases… November 10, 2016 SE 430: Lecture 10 25 of 75
Inception phase § Essential activities Ø Ø Formulate product scope. Capture requirements and operational concept Perform feasibility analysis. Determine whether the organization has the resources and technical capabilities to meet customer's needs Synthesize the system architecture. Evaluate essential system design constraints and trade-offs, as well as available solutions Plan and prepare business case. Address risk management, staffing, iteration plans, cost, and infrastructure November 10, 2016 SE 430: Lecture 10 26 of 75
Elaboration phase § Most critical phase of the four § Essential activities Ø Ø Ø Elaborate the vision. Detail elements of the vision that drive architectural or planning decisions Elaborate the process and infrastructure. The construction process and environment are established here Elaborate the architecture and select reusable (internal or COTS) components. Baseline the architecture as quickly as possible and demonstrate that the architecture will support the vision at reasonable cost in reasonable time November 10, 2016 SE 430: Lecture 10 27 of 75
Construction phase § Essential activities Ø Ø Achieve useful versions (intermediate, alpha, beta, and other test releases) Perform resource management, control, and process optimization Complete component development and test Assess product releases against acceptance criteria November 10, 2016 SE 430: Lecture 10 28 of 75
Transition phase § Essential activities Ø Ø Ø Perform deployment-specific engineering tasks. Commercial packaging and production, sales kit development, field personnel training Assess deployment baselines against complete vision and acceptance criteria. Examine and compare what is being delivered to what was envisioned and delineated by acceptance criteria Plan for next iteration November 10, 2016 SE 430: Lecture 10 29 of 75
Suitable Projects And Management Approaches § An evolutionary SDLC is suitable for projects with: Ø Ø Ø Reasonably–but not perfectly–clear user requirements Unfamiliar or unproven technology High complexity Short time schedule Schedule variability § Such a project would use rolling wave planning rather than big, up-front planning and use a continuous, adaptive approach to risk assessment and management November 10, 2016 SE 430: Lecture 10 30 of 75
Agile Methodologies November 10, 2016 SE 430: Lecture 10 31 of 75
Agile Modeling November 10, 2016 SE 430: Lecture 10 32 of 75
New Modeling Paradigms The New Methodology, (Martin Fowler) http: //www. martinfowler. com/articles/new. Methodology. html Ø The Manifesto for Agile Software Development Ø XP (Extreme Programming) Ø Lean Programming Ø Cockburn's Crystal Family Ø Open Source Ø Feature Driven Development Ø Scrum Ø DSDM (Dynamic System Development Method) Ø Context Driven Testing aka Test Driven Development November 10, 2016 SE 430: Lecture 10 33 of 75
The Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. ” Kent Beck et al http: //www. martinfowler. com/articles/new. Methodology. html November 10, 2016 SE 430: Lecture 10 34 of 75
Agile § The word ‘agile’ has become closely associated with specific forms of agile development, such as Extreme Programming (XP) and Scrum § In fact, agility spans a broad spectrum that now extends well beyond these specific forms and encompasses various hybrid approaches § The core aspects of agility include: Ø Ø Ø Rapid and productive response to change Rapid re-prioritization of resource use Rapid response to market changes, risks, and opportunities Use of incremental and iterative development processes Use of just-enough and just-in-time principles § Agile principles and practices have, in fact, spread far beyond their software roots November 10, 2016 SE 430: Lecture 10 35 of 75
Agile Projects § An agile project is completed in small sections called iterations, or in scrum, sprints. § Each iteration is reviewed and critiqued by the project team, which may include representatives of the client business as well as employees. § Insights gained from the critique of an iteration are used to determine what the next step should be in the project. § Each project iteration is typically scheduled to be completed within two weeks. November 10, 2016 SE 430: Lecture 10 36 of 75
Agile Modeling § Agile development is a response to the problems of traditional "heavyweight" software development processes Ø Too many artifacts Ø Too much documentation Ø Inflexible plans Ø Late, over budget and buggy software § Process has to be lightweight and sufficient Ø Lightweight helps us adapt and move Ø Sufficient recognizes our ineffectiveness to be complete and relies on strong communication November 10, 2016 SE 430: Lecture 10 37 of 75
Agile Modeling § Originally proposed by Scott Ambler § Suggests a set of agile modeling principles Ø Ø Ø Model with a purpose Use multiple models Travel light Content is more important than representation Know the models and the tools you use to create them Adapt locally November 10, 2016 SE 430: Lecture 10 38 of 75
An Agile Process § Is driven by customer descriptions of what is § § required (scenarios) – user stories Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Delivers multiple ‘software increments’ Adapts as changes occur November 10, 2016 SE 430: Lecture 10 39 of 75
Agile Development Process Iterative and evolutionary development § Adaptive planning § Incremental delivery § Timeboxing Ø Ø Set amount of time for iteration Adapt future iteration based on the realities § Agility Ø More focused on success than sticking with a plan § Working software is valued and considered measure of progress November 10, 2016 SE 430: Lecture 10 40 of 75
What is “Agility”? § § Effective (rapid and adaptive) response to change Effective communication among all stakeholders Drawing the customer onto the team Organizing a team so that it is in control of the work performed Yielding … § Rapid, incremental delivery of software November 10, 2016 SE 430: Lecture 10 41 of 75
Agile Modeling § “User Stories” - informal use cases § CRC Cards § Use UML as appropriate: Ø Ø Ø Activity diagrams Interaction diagrams Class diagrams § Minimalist philosophy November 10, 2016 SE 430: Lecture 10 42 of 75
User Stories § User stories are one of the primary development artifacts for Scrum and § § § Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. User stories are the Agile equivalent of Use Cases November 10, 2016 SE 430: Lecture 10 43 of 75
Methodologies share common principles, but differ in practices § Lean Programming § e. Xtreme Programming (XP) § Scrum November 10, 2016 SE 430: Lecture 10 44 of 75
Scrum http: //en. wikipedia. org/wiki/Image: Rugby_union_scrummage. jpg http: //www. controlchaos. com November 10, 2016 SE 430: Lecture 10 45 of 75
Scrum § Developed by Ken Schwaber and Jeff Sutherland § Name derived from Rugby Group effort to move quickly to counter the opposite team, adjusting the move along progress § Divides a project into iterations (sprints) of 30 days Ø Sprint – 30 days iteration cycle with pre-sprint and postsprint activities Ø Define functionality for sprint Ø Leave team alone to deliver § Sprint Goal – minimum success criterion to steer and keep focus Ø November 10, 2016 SE 430: Lecture 10 46 of 75
Scrum § Scrum is a “a development framework in which cross-functional teams develop products or projects in an iterative, incremental manner. ” 1 § Scrum focuses on defining the boundaries of the software development process rather than on specifying practice details § Because of its less-prescriptive nature, Scrum has been well-received in organizations transitioning from plan-driven to more agile processes Ø In fact, Scrum can be adapted readily to non-software projects, as well, such as product development and advertising campaigns § Note: ‘Scrum’ is not an acronym 1 From: Deemer et al. , The Scrum Primer v 2. 0, 2012 November 10, 2016 SE 430: Lecture 10 47 of 75
Scrum § Scrum iterations are called sprints and last no more than one month § Sprints are time-boxed: they are never extended, but may be restarted § Scrum defines three roles: The product owner is responsible for managing the product feature list Ø The team does the work Ø The scrum master facilitates the scrum process; the scrum master is not a ‘conventional’ project manager § Scrum produces an executable, potentially shippable product increment at the end of each sprint Ø Potentially shippable means ‘done’ in the scrum sense: all commitments for the sprint have been met–no “it's 80% done” is allowed Ø This demonstrates value iteratively to the product owner and to other stakeholders Ø November 10, 2016 SE 430: Lecture 10 48 of 75
The Sprint Cycle § Planning meeting at the start of the sprint § During the sprint, team members attend a daily Scrum meeting, § At the end of the sprint, there is a sprint review § At the end of each sprint is the sprint retrospective. November 10, 2016 SE 430: Lecture 10 49 of 75
The Sprint § Planning meeting at the start of the sprint create a sprint backlog – a list of the tasks to perform during the sprint. § During the sprint, the team takes a small set of features from idea to coded and tested functionality. § At the end, these features are done, meaning coded, tested and integrated into the evolving product or system. Ø November 10, 2016 SE 430: Lecture 10 50 of 75
Scrum § Every day the team holds a short (fifteen minute) meeting, called a scrum, Ø Scrum meeting – Short standup meeting to communicate and monitor progress Ø The team runs through what it will do in the next day Ø Surfaces roadblocks Ø Some recommend all participants stand (to keep the meeting short) § Scrum Master – coach for the team Ø Looks outward keeping distractions out Ø Trusts the self-managed team to get work done § Backlog – used for planning Ø Features and estimate of duration for each task Ø Task for sprint picked from the pool of tasks Ø Used to decide features for sprint and plan out the work November 10, 2016 SE 430: Lecture 10 51 of 75
Scrum Lifecycle § Planning Ø Vision, expectations, funding § Staging Ø Identify requirements, prioritize iteration § Development Ø Implement system ready for release in each sprint § Release Ø Operational deployment November 10, 2016 SE 430: Lecture 10 52 of 75
Scrum … § Leaves documentation depth to specifics of projects – may need more or less Ø aim for as little as possible § Self-directed and self-organized team Ø § § Competent focused people Demo to stakeholder at iteration end Client-driven adaptive planning No work added during iteration Lends itself to experimenting on certain parts of the application development November 10, 2016 SE 430: Lecture 10 53 of 75
Scrum Values § Commitment Team takes responsibility to complete the Sprint. To avoid things that will stand in its way Focus Ø Team's focus is maintained. Distractions, interruptions are fielded Openness Ø Overall and individual status and commitments kept open. Respect Ø Team responsibility rather than scapegoating. Courage Ø Management and team have the courage to take responsibility to do what is necessary Ø § § November 10, 2016 SE 430: Lecture 10 54 of 75
Balancing Agility and Discipline 1. 2. 3. 4. 5. 6. There is no agile or plan-driven silver bullet. Agile and plan-driven methods each have their own home grounds. Future projects will need both agility and discipline. Balanced agility-discipline methods are emerging. Build your method up; don't tailor it down. Focus less on methods and more on people, values, communication and expectations management. Barry Boehm and Richard Turner, Balancing Agility and Discipline, November 10, 2016 SE 430: Lecture 10 55 of 75
Best Practices How do you tell if a design is good or bad? November 10, 2016 SE 430: Lecture 10 56 of 75
Best Practices Object Oriented Design Heuristics (Arthur J Riel) ISBN 0 -201 -63385 -X § All data should be hidden within its class § A class should only use operations in the public interface of another class § Users of a class should be dependent on its public interface, but a class should not be dependent on its users § Minimize the number of messages in the protocol of a class (keep the class easy to understand) § A class should capture one and only one key abstraction § Keep related data and behavior in one place § Distribute system intelligence as uniformly as possible § [Beware the “god” class. ] November 10, 2016 SE 430: Lecture 10 57 of 75
Best Practices Object Oriented Design Heuristics (Arthur J Riel) ISBN 0 -20163385 -X § The model should never be dependent on the interface. The interface § § should be dependent on the model Model the real world whenever possible. (This heuristic is often violated for reasons for system intelligence distribution, and the keeping of related data and behavior in one place. ) Eliminate irrelevant classes from the design (classes without operations besides get(), set() and print() ) Minimize the number of different messages sent between a class and its collaborator. Classes should not contain more attributes [and operations] than a developer can fit in short-term memory. [seven plus or minus 1]. November 10, 2016 SE 430: Lecture 10 58 of 75
Best Practices When to use § Use Cases: Virtually always. Every Use Case is a potential requirement § Conceptual Models: Virtually always. Get a handle on the domain. § Design by Contract: As much as possible. Valued technique for building clear interfaces. § Robustness Diagrams: When you are using a three tier architecture to allocate roles to objects. Use in parallel with interaction diagrams. Use the rules even when not using a tier architecture. § Class Diagrams: Used all the time – backbone of Object Oriented methods. Class Diagrams can overwhelm so don't use all the notation available. Don't draw design class diagrams all the time – primarily for key areas which will be updated. November 10, 2016 SE 430: Lecture 10 59 of 75
Best Practices When to use § Interaction Diagrams: When looking at the collaborative behavior of several objects within a single Use Case. § State diagrams: are used for behavior of a single object across many use cases § Activity diagrams: are used for parallel behavior across many use cases or across multiple threads of execution. § Package Diagrams: When looking at large projects or when the class diagram for the whole system no longer fits on a single letter -size sheet of paper November 10, 2016 SE 430: Lecture 10 60 of 75
Best Practices § Tackle high-risk and high-value issues early § Continuously engage users for evaluation, feedback and § § § requirements. Build a cohesive, core architecture in early iterations Continuously verify quality; test early, often and realistically Apply use cases where appropriate Do some visual modeling (with UML) Carefully manage requirements Practice change request and configuration management November 10, 2016 SE 430: Lecture 10 61 of 75
Core Object Principles in OO Programming Thinking with Objects November 10, 2016 SE 430: Lecture 10 62 of 75
Object § Objects Ø Ø Ø The most basic concept in an OO language is that of an object. Objects communicate by calling each other's methods. This concept is called messaging. Objects provide services and have responsibilities. § An object consists of three things Ø Ø Ø State Behavior Identity § A class is the template from which objects are made Ø Ø Classes have responsibilities A class without responsibilities (or operations) is not really a class November 10, 2016 SE 430: Lecture 10 63 of 75
Object § An object has Ø Ø Ø State [Attributes|Data] Behavior [Responsibilities|Operations|Methods] Identity [Handle|Reference] § An object Ø Ø Owns its data Is responsible for the data’s processing § An object should embody one abstraction § An object should do one thing and do it well. November 10, 2016 SE 430: Lecture 10 64 of 75
Class and object characteristics § Every object is an instance of a class—it must have a generating class § A class has zero or more instances Ø Example: Consider how static class members in Java allow one to build a class that requires no instances § Class characteristics are static: their attributes, behavior, and relationships are defined and fixed for all instances Ø Examples: Attributes (e. g. , Java fields), interfaces, and relationships § Objects are dynamic: they are created, have varying attribute values and collaborations, and they can be destroyed Ø Example: Erasmus Darwin became a customer; he can add or delete products or change their contract status; he can terminate his relationship with the company November 10, 2016 SE 430: Lecture 10 65 of 75
Core Object Principles § Coherence Ø Coherence is the concept of modeling objects in such a way that they reflect, as accurately as possible, the actual properties and behaviors of real-world entities. § Inheritance Ø Inheritance provides the capabilities for one object to automatically contain attributes and behaviors of another object. November 10, 2016 SE 430: Lecture 10 66 of 75
Core Object Principles § Encapsulation Ø Ø Encapsulation revolves around the principle of exposing only as much information about an object as is absolutely necessary. Two forms of encapsulation » "implementation hiding" » "information hiding. ” § Interfaces Ø Ø An interface is a contract specifying what properties and behaviors an object will support. Interfaces allow the processing of objects based on a type rather than a class. November 10, 2016 SE 430: Lecture 10 67 of 75
Core Object Principles § Polymorphism Ø Polymorphism is the concept of an object changing its form to conform to a generic object abstraction. Ø Parametric polymorphism uses the concept of a common interface or lowest common denominator in terms of inheritance to implement a single abstraction across a number of types. Ø Polymorphism is usually seen in objects having methods with the same name but supporting different parameters. Foo bar = new Foo(42); out. println("42"); out. println(42. 0); out. println(bar); November 10, 2016 SE 430: Lecture 10 68 of 75
Concepts § Separation of concerns Ø “An object has one responsibility and does it well. ” § Chain of responsibility Ø If an object should/can not do something, it can delegate the responsibility/request/service to another object (Delegate pattern). § Objects should be viewed as providing services November 10, 2016 SE 430: Lecture 10 69 of 75
Things to Ponder § Concept of isolation of sub-systems Ø Ø Ø Classes should not randomly access other classes Law of Demeter – Don't talk to strangers Isolation needed to reduce complexity and interaction § A class that does more than one thing [bad] Ø Robustness diagram rules: entity objects and controllers. November 10, 2016 SE 430: Lecture 10 70 of 75
Final Thoughts "Instead of teaching people that OO is a type of design, and giving them design principles, people have taught that OO is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the language matters very little. The result is that people do bad designs with these languages and get very little value from them. " November 10, 2016 SE 430: Lecture 10 71 of 75
The Last Word "There is no silver bullet. " – Fred Brooks [See note] November 10, 2016 SE 430: Lecture 10 72 of 75
The Last Word § Object oriented technology cannot make-up for bad management, bad § § programmers, poor communications, changing requirements, and lack of defined goals and objectives. The object oriented way isn’t the only way Ø There are many problems that should be solved with a combination of techniques Ø But the object oriented modeling process is a good start Agile paradigms are gaining proponents. Ø Require a change in corporate culture to work. Most old line companies will never embrace the OO methodology completely. Ø Use what you can If one process or technique doesn’t work, adapt what you can. November 10, 2016 SE 430: Lecture 10 73 of 75
Final Examination “Nobody expects the Spanish Inquisition!” – Monty Python November 10, 2016 SE 430: Lecture 10 74 of 75
Final Examination § Midterm Examination will be on the Desire 2 Learn system starting Saturday, November 12, through Friday, November 18. § See important information about Taking Quizzes On-line § On Desire 2 Learn » It will be made available Saturday, November 12, 2016. » You must take the exam by COB Friday, November 18, 2016. » Allow 3 hours (should take about one hour if you are prepared); § Final exam study guide on the web page. November 10, 2016 SE 430: Lecture 10 75 of 75
The End November 10, 2016 SE 430: Lecture 10 76 of 75
- Slides: 76