Document

Transcript Document

Universitatea de Vest din Timişoara Facultatea de Matematică şi Informatică

Object Oriented Programming

Lect. Dr. Daniel POP

Course #12 Agenda

Software Development Process Activities Approaches (models) Object-Oriented Analysis Overview Discovering objects Object relationships Use cases Designing the user interface Case study Programming II Object-Oriented Programming 2

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 and design implementation testing and validation deployment maintenance Programming II Object-Oriented Programming 3

Software development life cycle

Programming II Object-Oriented Programming image © NoteTech Software 4

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.

Programming II Object-Oriented Programming 5

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.

Programming II Object-Oriented Programming 6

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 new work.

⅔ 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 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.

Programming II Object-Oriented Programming 7

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) Object-Oriented Programming 8

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) Programming II Object-Oriented Programming 9

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 ( www.uml.org

) (UML) - de facto standard for OO Analysis & Design 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) Programming II Object-Oriented Programming 10

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 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. Interaction diagrams. A subset of behavior diagrams which emphasize object interactions.

communication, interaction overview, sequence, timing diagrams. Programming II Object-Oriented Programming 11

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 Programming II Object-Oriented Programming 12

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 Programming II Object-Oriented Programming 13

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 Programming II Object-Oriented Programming 14

Use cases (II)

UC09 – Upload an offer Priority 1 Author Goal Summary Actors Preconditions Triggers Scenario John Smith Upload an offer to the central database This action will upload an offer stored in local database to the central offer repository.

Offer Manager (OM) The offer has to be saved in local database.

Menu option: Offer > Upload 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) Programming II Object-Oriented Programming 15

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) Programming II Object-Oriented Programming 16

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 Programming II Object-Oriented Programming 17

Case study (II): Highlighting use cases, concepts and rules

University Registration System [Sussenbach – Object-oriented analysis and design, 1999]

(1) Problem Statement

To: I&S Department From: Melissa Ward

• course roster for the teacher -> for Use Cases • Each course includes a title, number -> for Conceptual Model

Subject: Course Registration System

• A freshman has less than 30 credit -> for Business Rules 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 and a course roster for the teacher . We would also like to be able . The system only needs to handle one semester at a time. to print course information, including a course catalog containing department, course number and title, a course list for each student, 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.

History 103 (US History Since 1876), and English 103 (American Literature). sophomore less than 60, a junior less than 90, and a senior less than 120.

For example, Jim Turley may register for Math 101 (Calculus 1), CS 122 (C Programming), CS 101 (Fundamentals of Computing), 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 We need to know the name and a mailing address for every student and teacher in the system.

Melissa Ward Programming II Object-Oriented Programming 18

Case study (III)

(2) Conceptual Model – shows concepts and relationships between them

Programming II 1.

Object-Oriented Programming Each University object contains a name, an address, and a phone number.

A University manages zero or more Departments.

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.

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.

A student takes zero to five sections and is supervised by a department.

A student may or may not have an advisor.

A teacher advises zero or more students.

A teacher teaches zero to three sections.

A teacher is employed by a department.

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 19

(3) Functional requirements represented as Use Cases

Case study (IV)

Actors

University’s Secretary Department’s Secretary Student Programming II Object-Oriented Programming 20

Case study (V)

(3’) Functional requirements as plain English

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

Case study (VI)

UC04 – Add a teacher Priority 1 Author Goal Summary Actors Preconditions Triggers Notes Scenario John Smith Add a new teacher in the system The secretary adds a new teacher in the system.

Secretary of a Department Name, address and department.

The actor selects the option ‘Add Teacher’ Courses taught by this teacher are not added here; they will be added by UC05.

Prompt a form to read teacher’s personal information.

The actor fills in the form The system validates the inputs using business rules described in section X.

If errors are found, the erroneous fields are marked and the control is returned to the form.

If there are no errors, the system adds a new teacher object and set its properties accordinglly.

Programming II Object-Oriented Programming 22

Case study (VII)

(4) Other documents. User interface mock-up

Programming II Object-Oriented Programming 23