Are you in the right course?

1. Are you in the right course? Software Engineering 430 Object Oriented Modeling SE 430: Lecture 1

2. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 1

3. Administrivia: Introduction Dennis Mumaugh Undergraduate: BSEE – University of California, Berkeley MS Computer Science – University of Maryland Ph.D. Studies – University of Maryland Teaching at DePaul since September 2000 Work Senior Engineer – National Security Agency ARPANet Pioneer, Unix™ Technology Transfer Member of the Technical Staff – Bell Labs/Lucent Technologies Unix Development – Current Engineering IS&R Systems – Knowledge Based Systems Software Tools and OO Technology Interests Operating Systems and System Programming Software Productivity, Compilers and Software Metrics Software Engineering SE 430: Lecture 1

4. Administrivia: Basic Information • Contact Information: • Email: dmumaugh@cdm.depaul.edu • Phone: 630-983-1221 (10:00 am - 11:00 pm) except just before class (After 3pm) • Office Hours • Thursday: 4:00 pm to 5:30 pm, Loop, CDM, Room 428 • By arrangement SE 430: Lecture 1

5. Administrivia: Basic Information • Class home pagehttp://condor.depaul.edu/dmumaugh/classes/SE430F17, contains syllabus and schedule, lecture notes, homework, more reading material • About the Lecture Notes – look at “notes” section of the slides • Also look at the expanded readings page:http://condor.depaul.edu/dmumaugh/readings/SE430readings.html • Desire2Learn: • Course materials, assignments, assignment submissions, assignment solutions, examinations and quizzes and grades will be available on the Desire2learn – https://d2l.depaul.edu/ SE 430: Lecture 1

6. Administrivia: Basic Information • Email • All students are expected to have a email address. • Please make sure it is valid and make sure Campus Connection has the current email address. • Course mailing list: • se430@mailman.depaul.edu • To subscribe to the list or unsubscribe from it, go to http://mailman.depaul.edu/mailman/listinfo/se430. • I’ll bulk subscribe on Wednesday. • If necessary, update your spam filter to accept messages from the mailing list. • Unless your message is personal, send it to the course mailing list! • Last minute information will go to the mailing list SE 430: Lecture 1

7. Administrivia: reading materials Textbooks Arlow, Jim and Neustadt, Ila (2005). UML 2 and the Unified Process, Second Edition: Practical Object-Oriented Analysis and Design.Addison-Wesley, ISBN 0-321-32127-8. Deemer, Pete, Benefield, Gabrielle, Larman, Craig, and Vodde, Bas (2012). The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum, Version 2.0. Download available free at http://www.scrumprimer.org/. Another book you may want UML Distilled: A Brief Guide to the Standard Object Modeling Language,Third Edition, Martin Fowler (with Kendall Scott), Addison-Wesley Prof./Pearson, 2004. ISBN-13: 9780321193681 SE 430: Lecture 1

8. Administrivia: reading materials • A note on reading list • You are not expected to read all of the material on the reading list. • Look at the various articles as you have time. • Many say the same thing but with a different perspective. • Don't get overwhelmed in reading SE 430: Lecture 1

9. Administrivia: Course structure • Ten classes + Midterm Exam + team project + Final Exam • Weekly reading, assignments (7) and critique. • Common domain problem (The Museum Automation Problem) for examples and for assignments. • Team project: • Choose topic and get approval by October 20. • Deliver end of classes (November 17) • Class structure: lecture (with short break near the middle). • Topics and reading assignments are on the class web page SE 430: Lecture 1

10. Administrivia: required software • Access to MS Word. • Access to a drawing program such as Visio (see next slide). • Useful: • Commercial CASE tools: • Rational Rose • Together Soft • See reading list for URLs and pointers • Freeware CASE Tool • Poseidon for UML: http://www.gentleware.com SE 430: Lecture 1

11. Administrivia: Diagramming resources See readings list on CASE tools for more details • A good, free, fully-featured UML modeling tool is Poseidon for UML Community Edition • Available at www.gentleware.com (free registration required) • To export a diagram, go to File  Save Graphics… • I recommend using the Portable Network Graphics format (.png). Do NOT use JPEG—it obliterates fine details in a diagram • You can get Microsoft Visio 2003 for free at: • https://my.cdm.depaul.edu/resources/msdnaa.aspInstructions are at the bottom of the page • You can directly embed Visio diagrams in Word documents • Visio 2003 has UML drawing templates • Apple Macintosh users have some resources as well • OmniGraffle is a high quality drawing tool with UML diagrams • UseCaseBench is a tool for developing use cases. SE 430: Lecture 1

12. Administrivia: Miscellany • Communications development: • An essential part of this course is communicating your ideas in prose, as well as in technical graphical artifacts. • The ability to communicate clearly and effectively is a skill that will pay off both in and out of class. • Motivation from a recent NPR business report: • Robert Half surveyed their corporate customers concerning resumes they had received. • Corporate reviewers spent about 10-15 seconds deciding whether to examine the resume further. • They instantly tossed the resume if they detected any grammatical or spelling errors. • Treat your coursework as if it were being reviewed by the manager who does your performance review and sets your salary. SE 430: Lecture 1

13. Administrivia: Miscellany • There will be a lot of ambiguity and lack of firm direction in the assignments and the information. • That is typical of much of engineering. • This requires you to provide your own experience. Or to research and discover your information. • Using previous solutions/techniques will not necessarily work. You may have to invent something. • Understanding a problem (statement): • An essential part of this course is understanding written material, ideas in prose. The ability to understand a document, to "read between the lines", is a skill that will pay off both in and out of class. • Areas of concern: • Projects are implemented with the wrong features. • Students answer the wrong question on a test. • People confuse the subsystems of a design. • People do not read, really read things. SE 430: Lecture 1

14. Administrivia: Miscellany • Intellectual property issues: • All material in this course is property of either the instructor or Harold Streeter. • You are permitted to download and print copies of the material. • You are not permitted to redistribute the material in any form. • Plagiarism: • All individual assignments must represent your own work. • It's a great idea to get together in study groups to discuss the problems, but you should then do the assignments individually. • Plagiarism is to take and use as one’s own, or copy without acknowledgement, the works of another person. The provider of such material can be ruled equally culpable. • If you hand in late homework with prior permission, it must be your own work, not a copy of the solutions presented in class. SE 430: Lecture 1

15. Administrivia: Support • Technical questions can be addressed during office hours or by email • Use the mailing list for all technical questions • Provide appropriate support to each other • I do not preview homework, but I will answer questions or make suggestions to generic problems • If you contact me by e-mail • Please include your name and the course number in all correspondence SE 430: Lecture 1

16. Administrivia: Feedback/Participation • Feedback/Participation • Share your thoughts • Ask questions – wave your hand forcefully to get my attention • Speak loudly so all can hear • Give me verbal and non-verbal feedback • Don't just sit there . . . nod, smile, frown, shake your head • Make sure your email address is correct and works SE 430: Lecture 1

17. Administrivia: assessment • Regular assignments (7) + critique • A team/term project • Midterm examination • Final examination • Each of the above will be weighted as follows: • Homework 30% • Midterm Exam 20% • Term paper activities 30% • Final Examination 20% Grading will be done on the usual 60/70/80/90 bands but will be adjusted to account for clustering and banding of scores. Bands may be adjusted if there seems to be a systemic bias to the scores. SE 430: Lecture 1

18. Homework logistics • Homework must be submitted via Desire2Learn by 11:59 PM Chicago Time on the assignment due date. • Submit MS Word or Adobe PDF files only [I accept either format of MS Word] • All figures must be embedded in the file, not bundled in a ‘.zip’ file • No extra credit assignments. SE 430: Lecture 1

19. Team project logistics All students must work in a team on the final project There is no option for individual final projects Project teams will be chosen by the Week 3 class. On-line students will be part of the team. This means you will need to devise ways of working with remote members. SE 430: Lecture 1

20. Introduction • Roll • On-line students: you must send me an email confirming that you are taking the course. The email must include the “magic word” – that is: ______________ • You must confirm attendance by September 14. • You are welcome to send a message to the mailing list with (after it is in place) • Your Background • Day Job (if any) • Major • Programming Experience • Industry Experience • Optional: Expectations & goals from the class SE 430: Lecture 1

21. Course goals • Learn techniques for analyzing a problem • Use patterns and UML notation to formalize solutions. • Provide the background and skills needed to solve software engineering problems using object-oriented techniques. • Present techniques and practices suitable for complex, large-scale systems. • Develop an understanding of object oriented concepts • Solidify and apply knowledge of core O-O concepts. • Develop skills in a practical O-O analysis and design process which: • Uses the industry-standard UML notation • Uses the most effective parts of the Unified Process methodology. • May be used ‘as is’ or tweaked for effectiveness. SE 430: Lecture 1

22. Course objectives After taking this course, the student should be able to Read and understand some of the basic object oriented modeling notations (especially UML) Analyze simple problems using use cases and the CRC card techniques Create a list of the responsibilities or services that describe the external interface of a class Describe the interactions between objects Use simple state machines to model the time-dependent behavior of a class Create examples of classes where inheritance is useful in an object oriented design Develop models for a problem SE 430: Lecture 1

23. Goals and Objectives A good programmer, using whatever language, needs to be able to think in terms of levels-of-abstraction and reason in an orderly way. However, there are other criteria, too. We could add, The ability to see patterns The ability to decompose a design into appropriate modules The ability to know when to generalize or specialize a design artifact The ability to know what to eliminate from a design The ability to keep a design simple, understandable, maintainable, and readable Programming is a human activity. Knuth makes the point that we need to write software that is readable by other humans rather than focus so intensely on programs that are targeted to the machine. SE 430: Lecture 1

24. Engineering Methodology What is engineering and how does it differ from science? Engineering is the application of science to the needs of humanity. This is accomplished through the application of knowledge, mathematics, and practical experience to the design of useful objects or processes in a cost effective way. • One of the objectives of this course is to teach some of the methodology of engineering • Understanding the problem • How to approach a problem • Developing and following requirements • Writing and reading specifications • Analyzing a problem • Designing a solution • Verifying each step • Testing the design against the original problem statement SE 430: Lecture 1

25. Surviving SE430 • Make sure you read things, sometimes more than once. People do not seem to read assignments and web pages (or do not follow instructions). • The pace is quick. The intent of the course is to learn by doing, not by reading; but there is a lot of information to process. • Read the assignments carefully. Note special requirements, such as formats and use of predefined templates! • Start your assignments right after they are handed out (assigned). They will take some time and starting on the night before it is due is not a good strategy. • Reading list: • Is it required? No. • Is it useful? Yes, especially if you are serious about a career in software development. • The articles are usually short but informative. Most are supplemental – useful for understanding but the notes cover the major points. • Reading should be done in parallel with the lectures. • Pace yourself. Remember: “This too shall pass.” SE 430: Lecture 1

26. Course Summary I Overview of OO (Inheritance, polymorphism, etc.); Overview of  Software Development Methodology and Software Development Life Cycle; UML: O-O A & D Communicating Design: Problem Statement; Defining Requirements; Requirements Analysis;  Business Rules; Activity Diagrams;  Use cases:  High level use cases; Use Case Diagrams, Ranking Use Cases. Detailed use cases. System Sequence Diagrams. Static Structure: Requirements Traceability; Building a Beginning Conceptual Model: System Sequence Diagrams; Class Diagram; CRC Cards;  Domain model basic principles; Domain model associations; Domain model attributes; System Glossary. Transition to Design:  Software Architecture, Architectural Planning; Tools and Techniques for Transition to Design: Design scenarios; The Human Computer Interface: Tiered Architecture; Robustness Analysis; Function-Class Decomposition SE 430: Lecture 1

27. Course Summary II Design by Contract: Operation Contracts: Assigning Responsibilities, System [Operation] Contracts and Dependencies; System Behavior Modeling: Object behavior: Object interaction diagram -- Communication (Collaboration) Diagrams and Message Sequence Diagrams; Object visibility; Object state charts -- State Diagrams, State Space and Behavior; Start of Design: Frameworks and Packages; Patterns: Overview of patterns; Architectural patterns; Coupling and Cohesion; GRASP patterns; Responsibility-Based Modeling and Responsibility-Driven Design; Design Scenarios System Organization and Architecture: Real Use Cases; Use case realizations and Design Scenarios;  Case study; More on Design Putting it all together: Design model: Design class diagrams, package and deployment diagrams; Architecture patterns Overview of Systems Development Life Cycle Methodologies: Sequential Methodologies, Evolutionary Methodologies; Agile Methodologies; Wrap-up: Best practices; Review SE 430: Lecture 1

28. SE 430 – Class 1 Topics: Introduction and Overview • Course Logistics and Administrivia • Important Object-Oriented Concepts • Software Development Life Cycle • Object-Oriented Analysis & Design and the Unified Process Reading: • Arlow & Neustadt: Preface; Ch. 7, Ch's 1-2 • Phillip G. Armour, "Twenty Percent: Planning to fail on software projects", CACM, Vol 50, No. 6 (June 2007), pp. 21-23. (local mirror) • Core Object Principles in OO Programming (Thinking with Objects) • Review concepts and vocabulary in this lecture and be sure you understand them. We’ll be using them extensively throughout the quarter SE 430: Lecture 1

29. Preliminary Assignment • Review concepts and vocabulary in this lecture and be sure you understand them. We’ll be using them extensively throughout the quarter. • Start understanding the domain information we will use for the class: • Start reading the Museum Automation Problem Description • and the Mobile Guide. • Much of this is general knowledge and not new. SE 430: Lecture 1

30. Assignments Critique – Due at the end of the term Students must write and submit a brief critique of their own work on the assignments after reviewing the sample solution(s). The critique is due at the end of the term. The assignment critiques (taken together) will count as one homework assignment. SE 430: Lecture 1

31. Thought for the Day "Object technology means object-oriented thinking; shifting to object-centered development requires adopting new; discarding old ways." "The most important aspect of the system that must be object oriented is the thinking of the design team." SE 430: Lecture 1

32. Important Object Oriented Concepts SE 430: Lecture 1

33. 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 SE 430: Lecture 1

34. 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. SE 430: Lecture 1

35. O-O building blocks: types, classes, and objects • A type is an idealized description of an entity • It specifies the interface (externally visible behavior) for the entity • It does not deal with the entity’s internal structure (implementation) • Example: A software product customer • A class represents a particular realization (implementation) of a type • A class defines mechanisms for behavior of a type • Example: A customer • A class acts as a template for defining instances of the class (objects) • Example: Erasmus Darwin, a customer for three software products, all with support contracts SE 430: Lecture 1

36. Types, classes, and objects • Types define interfaces, a class is an implementation of a type. • A type specifies the externally visible interface for an entity, but does not deal with its implementation • Classes act as abstract templates for producinginstances (objects). • A class represents an implementation of a type and acts as an abstract template for producing instances (objects) via constructors • Every object is an instance of a class. • A class has zero or more instances • Example: Consider static class members in Java • Class issues are static: attributes (fields), interfaces, and relationships • Objects are dynamic: creation, attribute values, collaborations, and destruction. • Conceptual overlap among types, classes, and objects allows us to sometimes speak of their characteristics interchangeably, what the UML refers to as type-instance correspondence SE 430: Lecture 1

37. 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 SE 430: Lecture 1

38. Types, classes, and objects Type distinguishes among kinds of objects; its purpose is to control what values can be assigned to variables or used in operations Most popular object-oriented programming languages do not distinguish between types and classes Distinctions between types and classes do become important when discussing generalization/specialization and the related topic of inheritance. SE 430: Lecture 1

39. Essential components of O-O paradigm • Abstraction: captures essential behavioral characteristics. • Encapsulation: hides behavioral mechanisms. • Hierarchy: structures abstractions. • Typing: enforces type of object. • Modularity: decomposes a system into manageable pieces. SE 430: Lecture 1

40. 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. SE 430: Lecture 1

41. Abstraction • Captures essential behavioral characteristics of a domain entity. • Communicates what an entity does, not how it does it. • Abstraction detail level depends upon viewer perspective. • Good abstraction follows the ‘just right’ principle: it captures entire behavior of an entity, no more and no less. • Alternative statement: An effective abstraction captures all the necessary and sufficient characteristics of an entity SE 430: Lecture 1

42. Abstraction • Quality of abstraction ranges from: • Most-desirable entity-level (useful model); a cohesive set of related characteristics and responsibilities to: • Example: Individual tools in a Swiss Army knife. • Example: Current java.util.Date • Least-desirable coincidental (convenient packaging); (possibly unrelated) characteristics and responsibilities • Example: The whole knife itself. • Example: JDK 1.0 java.util.Date • Practice suggestion: Employ a ‘pay-as-you-go’ approach to abstraction characteristics—take an additive approach rather than a subtractive approach to abstraction characteristics SE 430: Lecture 1

43. Abstraction • An abstraction is an essential representation of both the intrinsic and behavioral characteristics of an entity • Intrinsic characteristics are those that are static or relate to the state of the entity at a given time • Example: For a smartphone, size and shape are static, while ‘percent charge’ relates to the state of the battery and its state varies with time • Behavioral characteristics are dynamic • Behavior may be internally- or externally-induced • Example: Smartphone generates event reminders internally but dials phone number in response to (external) user button presses • Outstanding question: How do we determine the essential characteristics of an entity for purposes of abstraction? • Appropriate level of abstraction detail depends upon the specific problem to be solved: the problem requirements and constraints SE 430: Lecture 1

44. Encapsulation • Compartmentalizes elements of an abstraction, separating: • Contractual interface (what the abstraction does). • Implementation (how it does it). • Realized by information/implementation-hiding (security) features of a programming language. • Example: Java's public, private, and protected modifiers and the compile- and run-time mechanisms that implement the policies • Enforces dictum: “No part of a complex system should depend on the internal details of any other part.” SE 430: Lecture 1

45. Encapsulation & abstraction • Encapsulation and abstraction are complementary notions: • Abstraction defines (or ‘exposes’) the external behavior of an object through the object interface • Encapsulation hides the internal aspects of that behavior from public view SE 430: Lecture 1

46. Abstraction by specification • Provides a concrete approach to achieving the goals of abstraction and encapsulation • Provides behavioral information to allow use of an operation without looking at its implementation: • Preconditions specify what is assumed upon entering the operation • Postconditions specify what should be true when the operation completes, provided the preconditions were satisfied • Invariants specify what must always be true externally for an object • Embodied in the principles of design-by-contractas obligations and benefits • Test-Driven Development (TDD) encourages practical application of abstraction by specification SE 430: Lecture 1

47. Hierarchy • Most complex systems can be modeled as hierarchical in nature • Hierarchy is an ordering or structuring of abstractions • Two types of hierarchy: • Generalization/specialization (‘is kind of ’ or ‘is-a’ relationships) • Aggregation (‘part of ’ or ‘has part ’ relationships) • Aggregation structure: • More ‘natural’ hierarchy to develop in the early stages of analysis and design • Reflects readily-observable characteristics of the domain • Do not concentrate on generalization structure hierarchy in the early stages of analysis and design SE 430: Lecture 1

48. Hierarchy: aggregation • ‘Part of ’ hierarchies describe aggregation relationships • Permits physical grouping of logically-related structures, often in repeatable patterns • We’ll discuss the different types of aggregation later in the quarter • We’ll discuss an interplay of aggregation and generalization/specialization in a few slides SE 430: Lecture 1

49. Core Object Principles • Inheritance • Inheritance provides the capabilities for one object to automatically contain attributes and behaviors of another object. SE 430: Lecture 1

50. Hierarchy: generalization/specialization One form of hierarchical ordering leads to creation of a generalization/specialization (‘kind-of’) hierarchy Defines relationships among related types; the subtypes share the behavioral characteristics of one or more supertypes A related concept is inheritance: the sharing of code between two classes. A subclass shares the code of its superclass Most O-O programming languages do not distinguish between subtyping and subclassing Inheritance only involves sharing of code and does not imply that the subclass is a subtype of the supertype: not all subclasses are subtypes SE 430: Lecture 1