1. 1 UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard Podeswa Instructor: Mrs. Eman ElAjrami 2008 University Of Palestine

2. 2 Introduction Who this course is for?? This course is intended for the IT Business Analyst The IT Business Analyst is an integral part of a software development team responsible for documenting and verifying the business and user requirements for a software system.

3. 3 Introduction How you and your organization can benefit from B.O.O.A? Many organizations are good at developing a good software products, but they are often week in developing the right software product. The mismatch is between what the user wants, and what the developer delivers.

4. 4 INTRODUCTON In addition, many IT projects are experiencing time and cost over runs due to the difficulty in responding to a rapidly changing business environment. Finally, Many projects failure due to faulty communication between those who know the business, and those who write and construct the software. With B.O.O.M, the business analyst documents business rules and requirement using the same type of diagrams and concepts that used by the developer.

5. 5 Chapter Objectives At the end of this chapter, we will: Understand the role of the IT business analyst throughout a project’s life cycle. Understand what is meant by a business model, dynamic model and static model.

6. 6 The IT and Non-IT BA There are two types of business analysis: A Business Analyst is someone who works within the context of the business. This person is involved in process improvement, cost-cutting, and so on. An Information Technology Business Analyst (IT BA) works within the context of IT projects – projects to buy, purchase, or modify some software. This course is directed to the IT BA.

7. 7 Why modeling is a good thing? A business model is an abstract representation of a clearly delimited area of a business. It may take many forms, for example, pictures with supporting text or the underlying format used by a tool such as Rational Rose to produce diagrams and generate code. In this course, you’ll be asked to draw a lot of diagrams. What's the point ? After all, most users can’t read them, and they are reluctant to sign off on anything but text !!

8. 8 Why modeling is a good thing? (cont.) So, What are those diagrams and models for?? Use the diagrams to drive the interviews : There is a logical step – by – step process to drawing a diagram. At each step, you have to ask the user certain questions to discover what to draw next. The act of drawing the diagram tells you what questions to ask and when, and even when the interview is complete Use diagrams whenever you need to reconcile differing viewpoints

9. 9 Chapter 2 The BA’s Perspective on Object Orientation

10. 10 Chapter Objectives At the end of this chapter, you will Understand how OO affects the BA role on IT projects. Understand key OO concepts: Objects Operations and attributes Encapsulation Classes Entity classes Relationships Generalization

11. 11 What Is OO? OO is an acronym for “object-oriented.” The OO analyst sees a system as a set of objects that collaborate by sending messages (that is, requests) to each other. OO affects the way the BA analyzes and models the requirements. OO affects the way the software engineer (technical systems analyst) designs the system specifications. OO affects the way the code itself is structured: Object-Oriented Programming Languages (OOPL) such as C++ and the.NET languages, support OO concepts and structures.

12. 12 The UML Standard UML is an acronym for Unified Modeling Language, a widely accepted standard for OO. The UML standards cover terminology and diagramming conventions. This book uses the latest version of that standard, UML 2.

13. 13 Cognitive Psychology and OO? As a Business Analyst, your job is to get inside the heads of your stakeholders so that you can extract what they know about a piece of the real world—a business system—and pass it on to the developers, who will simulate that system on a computer.

14. 14 Objects Are the physical and conceptual things we find in the universe around us. Hardware, software, documents, human beings, and even concepts are all examples of objects. For purposes of modeling his or her company, a System Analyst could view employees, buildings, divisions, documents, and benefits packages as objects.

15. 15 The BA Perspective on Objects You begin to analyze a business system by asking stakeholders to describe its business objects. A business object is something the business (and the IT system that automates it) must keep track of, or that participates in business processes. Examples of such an object might include an invoice, a customer service representative, and a call.

16. 16 Attributes and Operations Because we are able to recognize an object again after having seen it once, the internal representation of the object must include a record of its properties. For example, we remember that a shirt object’s color is blue and its size is large. In OO, color and size are referred to as attributes; blue and large are attribute values. Every object has its own set of attribute values

17. 17 Attributes and Operations (Cont.) Something else we remember about an object is its function. For example, the first time you saw a crayonقلم ملون, it took you some time to learn that it could be used to scribble on the walls. Unfortunately for your parents, the next time you saw that crayon, you knew exactly what to do with it. Why? Because you remembered that scribble was something you could do with that object. In OO, scribble is referred to as an operation.

18. 18 The BA Perspective on Attributes and Operations The next step in analyzing a business system is to find out what attributes and business operations apply to each object. For example, two attributes that apply to an account object Attributes and Operations are balance and date last accessed; two operations that relate to the object are deposit and withdraw.

19. 19 Operations and Methods Going one step further, you don’t just remember what you can do with an object, you also remember how you do it. For example, you know that you can place a call with a particular mobile phone—but you also remember that to do so, you must follow a particular procedure: first you enter the phone number and then you press the send key. In OO terms, place a call is an operation; the procedure used to carry it out is called a method.

20. 20 The BA Perspective on Operations and methods Next, you take each operation and ask stakeholders what procedure they use to carry it out. You document the procedure as a method. For example, you ask stakeholders what procedure they follow when withdrawing funds from an account. They tell you that they first check to see if there is a hold on the account and whether there are sufficient funds available for withdrawal. You document this procedure as the method used to carry out the withdraw operation.

21. 21 C++ Example: class Student { private: int stunum; public: void setstunum(int sn); int getstunum(); }; void Student::setstunum(int sn) { stunum = sn; } int Student::getstunum() { return stunum; }

22. 22 Encapsulation Every day you use objects without knowing how they work or what their internal structure is. This is the OO principle of encapsulation: Only an object’s operations are visible to other objects. Attributes and methods remain hidden from view.

23. 23 OO Concept: Classes Class: A classifier that describes a set of objects that share the same specifications of features, constraints, and semantics. A class is a category. All objects that belong to the same category have the same attributes and operations (but the values of the attributes may change from object to object).

24. 24 Example: If you say that two objects belong to the class Samsung camera phone, you know a number of things about them: The same attributes apply to both objects. For example, you know that both objects will have a serial number, a phone number, and various camera settings. Each object will have its own values for these attributes. The same operations apply to both objects. For example, you can place a call and take a picture with each of these objects. The same methods apply. For example, the procedure for placing a call is the same for both phones.