Object Oriented Programming Lect. Dr. Daniel POP Universitatea de Vest din Timişoara Facultatea de Matematică şi Informatică

2Programming IIObject-Oriented Programming Course #11 Agenda Software Development Process Activities Models Object-Oriented Analysis Overview Discovering objects Object relationships Use cases Designing the user interface Case study

3Programming IIObject-Oriented Programming Software development process DEFINITION [Software development process, Software lifecycle, Software process] A software development process is a structure imposed on the development of a software product. There are several models for such processes, each describing approaches to a variety of tasks (activities) that take place during the process. Activities and steps: requirements analysis specifications software architecture implementation testing deployment maintenance

4Programming IIObject-Oriented Programming Software development life cycle image © NoteTech Software

5Programming IIObject-Oriented Programming Software development activities (I) Requirements analysis. The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Specification. Specifications is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. Software architecture. The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.

6Programming IIObject-Oriented Programming Software development activities (II) Implementation (coding). Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. Testing. Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer. Software deployment. Software deployment include all the activities that make a software system available for use. It’s a general process that has to be customized according to specific requirements. It can be split in the following sub-activities: release, install, activate, deactivate, adapt, uninstall, retire.

7Programming IIObject-Oriented Programming Software development activities (III) Maintenance. Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About ⅔ of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work. In comparison, about ⅔ of all civil engineering, architecture, and construction work is maintenance in a similar way. Other activities: Documentation. An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces. Training and support. Very important because people are occasionally resistant to change. training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software.

8Programming IIObject-Oriented Programming Software development models Waterfall: oldest, best-known; various steps (requirements, analysis, design, implementation, test, etc.) are followed in order V-model; introduced by German federal administration; 2 streams: specifications (req. analysis, functional specs, design specs) and testing (installation, operational, performance) + implementation Iterative: develop the software in small iterations; helps to uncover important issues early in the dvlp. process: Objectory Sprial: combines the features of the prototyping model and the waterfall model Rational Unified Process (RUP) Agile Extreme programming (XP) Scrum Rapid Application Development (RAD); construction of prototypes and use of Computer-aided software engineering (CASE) tools Cleanroom: combines formal methods in specs in design phases with incremental implementation and statistically sound testing Formal methods: math. approaches to solving SW/HW problems at the requirements, specs, and design levels (e.g.B-method, Petri nets, RAISE=Rigorous Approach to Industrial Software Engineering, VDM = Vienna Development Method)

9Programming IIObject-Oriented Programming Object-oriented analysis (I) DEFINITION [Object-oriented analysis] OOA aims to model the problem domain, the problem we want to solve by developing an object-oriented system. Can be applied to any software development process model. Inputs of OOA step: requirements (problem) statement, specifications (can include use cases or other UML diagrams) Deliverables (output) of OOA step: Conceptual model : Conceptual model is the result of object-oriented analysis, it captures concepts and relationships between them in the problem domain. The conceptual model is explicitly chosen to be independent of implementation details (such as concurrency or data storage) and describes what is to be built. Use case : Use case is description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with actors (end-users or other systems) to achieve a specific business goal or function. Any other documentation that is needed to describe what is to be built (e.g. user interface mock-up model)

10Programming IIObject-Oriented Programming Object-oriented analysis (II) OOA doesn’t deal with implementation details (database structure, persistence models etc.); there are decided in the OOD phase Several graphical notations to represent concepts and relationships between them: Coad-Yourdon Rumbaugh Booch Firesmith Embley-Kurtz etc. Unified Modeling Language ( (UML) - de facto standard for OO Analysis & Designwww.uml.org Tasks performed during OOA phase (How to perform OO analysis?) [Yourdon, 1994]: discover objects discover objects relationships discover use cases design the UI (if applicable)

11Programming IIObject-Oriented Programming Unified Modeling Language Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. activity, state machine, use case + interaction diagrams Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. communication, interaction overview, sequence, timing diagrams. Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. class, composite structure, component, deployment, object, package diagrams.

12Programming IIObject-Oriented Programming Discovering objects Think the system in terms of objects that interact to each other Choose a strategy to discover objects, based on system’s characteristics: Data perspective: identify nouns (what is an object); look at problem space, physical devices, events, roles (actors), geographical distribution, organizational units (departments, groups etc.) Functional perspective: look for verbs (what does an object); identify objects by responsibilities they have Behavioral perspective: How do objects communicate? With whom?; suited for real-time or distributed systems Criteria for evaluating candidate objects: data to store more than one attribute needed functionality essential functionality common attributes to all objects common functionality Group classes and objects into package/subsystem for an easier presentation and understanding

13Programming IIObject-Oriented Programming Object relationships Relationships are static relations between object, not collaboration diagrams. Binary relationships (association, composition, aggregation). Example: A customer places 1..N orders. Extended relationship – involve three or more concepts and should be transformed to two or many binary relationships; they are difficult to draw and understand. Example: A customer places 1..N orders containing one or more products and is handled by a sales-person. Special cases: Many-to-many instance connections (e.g. Many customers can purchase the same or many products.) Recursive instance connections (e.g. Person manages other persons. Each person is managed by another person.) Multiple instance connections between classes (e.g. A customer purchases products. A customer recommends products. A mechanical change tires of an automobile. A mechanical change oil of an automobile.) Unary (unidirectional) connections between classes (e.g. I know the president, but president doesn’t know about me.) Consequences of mandatory connections when adding/deleting instances

14Programming IIObject-Oriented Programming Use cases (I) DEFINITION [Use case, Scenario] A use case is a technique for capturing functional requirements of systems. They allow the description of sequences of events that taken together lead to a system doing something useful. Describes the interaction between external actors and the system, treated as a black-box. Actors: end-users or other systems Use the language of end-user (domain expert) Can be graphically represented using UML Use Case diagrams A UC have: name, preconditions, triggers, basic course of events (scenario), postconditions, business rules used, notes, author, history of change Guidelines for writing a use case Should contain what should be done, not how Have no implementation-specific language Be at an appropriate level of detail (brief, casual or complex) Not include details related to UI or screens

15Programming IIObject-Oriented Programming Use cases (II) UC09 – Upload an offer Priority 1 Author John Smith Goal Upload an offer to the central database Summary This action will upload an offer stored in local database to the central offer repository. Actors Offer Manager (OM) Preconditions The offer has to be saved in local database. Triggers Menu option: Offer > Upload Scenario 1. Check the server connection; if not online then ERROR and abort the upload. 2. If the revision on the server is higher than the local one then the following message appears: "The revision on the server is more recent then yours. Do you want to upload it and replace the revision on the server? Yes/No". If the user selects No then abort the upload. 3. If the offer's status is changed localy (e.g. from on-going to submited-to-sales) then the user is adviced to increment the edition (ie Increment edition combobox is set to checked), otherwise, the user can increment the edition if he/she wants 4. Upload the offer on the server 5. If Edition has been incremented then increment the edition on the server (initial value = 1) 6. Increment the revision (initial value = 1)

16Programming IIObject-Oriented Programming Designing the user interface Not applicable for all systems; when applicable is extremely important because of its high impact. Classify the people who use the system Identify events to which users must respond Define the command hierarchy: menus (menu bar, popup/context menus), toolbars Detail the interactions between users and the system: how user enters inputs, left/right mouse click, drag-and-drop actions, how error messages are displayed, copy-cut-paste functionality, keyboard shortcuts etc. Provide customization of the user interface (colors, fonts etc.) Context-based UI Wizards Intelligent assistants (agents)

17Programming IIObject-Oriented Programming Case study (I) University Registration System [Sussenbach – Object-oriented analysis and design, 1999] (1) Problem Statement To: I&S Department From: Melissa Ward Subject: Course Registration System The paper-based registration system that we have been using has proven unable to handle the increased number of courses and students that we have at DSU. I am requesting a software application that will handle the load and allow students to register for courses via their telephone or computer. We would also like to be able to print course information, including a course catalog containing department, course number and title, a course list for each student, and a course roster for the teacher. The system only needs to handle one semester at a time. Each course includes a title, number, description, and credit hours. Each course is offered by a department, taught by teachers, and taken by students. A teacher is employed by a department, and can only teach courses within that department. A student may register for up to five courses, which can be offered by any department. For example, Jim Turley may register for Math 101 (Calculus 1), CS 122 (C Programming), CS 101 (Fundamentals of Computing), History 103 (US History Since 1876), and English 103 (American Literature). Students register by year (freshman, sophomore, junior, senior), which is defined by total number of credits. A freshman has less than 30 credit hours, a sophomore less than 60, a junior less than 90, and a senior less than 120. We need to know the name and a mailing address for every student and teacher in the system. The registrar’s office will be responsible for setting up each department in the system and for printing the course catalog. Department secretaries will add courses, teachers, and students, and print course rosters for teachers. Students are responsible for registering for courses and printing their course list. Melissa Ward Registrar, Denver State University

18Programming IIObject-Oriented Programming Case study (II) (2) Conceptual Model – shows concepts and relationships between them 1.Each University object contains a name, an address, and a phone number. A University manages zero or more Departments. 2.Each Department object contains a name. A department offers courses, each referenced through a course number. A department supervises students, each referenced through the student’s name. A department employs teachers, each referenced through the teacher’s name. A department is managed by a University. 3.Each Course object contains a title, a course number, a description, and number of credits. A course is taught in zero or more sections. A course is offered by a department. 4.A student takes zero to five sections and is supervised by a department. A student may or may not have an advisor. 5.A teacher advises zero or more students. A teacher teaches zero to three sections. A teacher is employed by a department. 6.Each Section object contains a section number, days of the week when it is held, and the start and end time when it is held. A section teaches a course. A section is taken by zero to thirty students. A section is taught by one teacher

19Programming IIObject-Oriented Programming Case study (III) (3) Functional requirements represented as Use Cases Actors University’s Secretary Department’s Secretary Student

20Programming IIObject-Oriented Programming Case study (IV) (3’) Functional requirements as plain English Add departments and courses to the system Print a course catalog containing: CS 100 BASIC 201 ANSI C 302 C++ Eng 100 The American Novel Math 100 Algebra 200 Geometry Add teachers to the system Mary Smith (CS dept) Fred Peterson (Eng dept) Add sections to the system (section number after “=”) CS 302 taught by Smith MWF 10:00 to 10:50 =1 Eng 100 taught by Peterson MWF 15:00 to 15:50=1 TTh 8:45 to 10:05 =2 Add students to the system Jim Turley Betty King Sam Rye Register students for classes Jim Turley registers for CS 302 Section 1 Betty King registers for CS 302 Section 1 Betty King registers for Eng 100 Section 1 Sam Rye registers for Eng 100 Section 2 Print a student’s course list and total hours for this semester. Print a teacher’s course roster.

21Programming IIObject-Oriented Programming Case study (V) UC04 – Add a teacher Priority 1 Author John Smith Goal Add a new teacher in the system Summary The secretary adds a new teacher in the system. Actors Secretary of a Department Preconditions Name, address and department. Triggers The actor selects the option ‘Add Teacher’ Notes Courses taught by this teacher are not added here; they will be added by UC05. Scenario 1.Prompt a form to read teacher’s personal information. 2.The actor fills in the form 3.The system validates the inputs using business rules described in section X. 4.If errors are find, the errorneous fields are marked and the control is returned to the form. 5.If there are no errors, the system adds a new teacher object and set its properties accodinglly.

22Programming IIObject-Oriented Programming Case study (VI) (4) Other documents. User interface mock-up

23Programming IIObject-Oriented Programming Further Reading [Sussenbach, 1999] Rick Sussenbach – Object-oriented Analysis & Design (5 Days), DDC Publishing Inc, 1999, ISBN , [Chapter 13] [Yourdon, 1994] Edward Yourdon – Object-oriented Systems Design, Prentice-Hall International Inc, 1994 [Chapter 9, 11, 18] [Fowler, 1997] Martin Fowler – Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997 [Meyer, 1997] Bertrand Meyer – Object-oriented software construction, Prentice Hall, 1997 [Booch, 1994] Grady Booch – Object-oriented analysis and design with applications, 2 nd Edition, Benjamin/Cummings,1994