Presentation is loading. Please wait.

Presentation is loading. Please wait.

Kal Bugrara, Ph.DSoftware Engineering Northeastern University Fundamentals Of Software Engineering Lecture V.

Similar presentations


Presentation on theme: "Kal Bugrara, Ph.DSoftware Engineering Northeastern University Fundamentals Of Software Engineering Lecture V."— Presentation transcript:

1 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Fundamentals Of Software Engineering Lecture V

2 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Steps of the Modeling Process The Output: An Object Model

3 Kal Bugrara, Ph.DSoftware Engineering Northeastern University The steps 1. Scope the problem domain 2. Capture the key concepts within the problem domain 3. Generalize and specialize concepts as necessary 4. Surface any relationships between concepts 5. Formalize the concepts by mapping them to class definitions define class attributes define operations on the class class inheritance class relationships

4 Kal Bugrara, Ph.DSoftware Engineering Northeastern University An Object Model Objects Classes Attributes Class relationships Operations on the classes Inheritance relationships

5 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Object A concrete manifestation of an abstraction; an entity with a well-defined boundary and identity that encapsulates state and behavior; an instance of a class. (Booch, 1999) An object has: State (set of conditions in which an object exists, implemented by a set of properties (attributes) with their values and the relationships with other objects) Behavior (the way the object responds to events as well as how it interacts with other objects) Identity (makes two objects different even in case they have the same state and behavior)

6 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Classes A class denotes a set of objects that share the same attributes, operations, relationships, and semantics (Booch, 1999). An object is an instance of a class A class is an abstraction: Emphasizes relevant characteristics Hides details

7 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Classes vs. Objects A class is an abstract definition of an object. It defines the structure and the behavior of each object. A class is template for producing objects of a certain type. Objects are grouped into classes An object is a runtime instances of the corresponding class

8 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Object Model Examples

9 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Classes

10 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Attributes Operation Class: Student What other characteristics define the Student class?

11 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Attributes Operation Class: Course What other characteristics define the Course class?

12 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Attributes Operation Class: Student Account What other characteristics define the Student Account class?

13 Class Relationships Relationship

14 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Functions and Relationships There is the idea of a mapping from an object in one class (called the domain of the function) to a subclass of another class (called the range of the function) f Function[f] Domain(f)Range(f) Object Model

15 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Mapping When the function f is argumented with object “a”, it returns a set containing object “b”. b is passed as an argument to invoke some operation. f f(a) { b} a b

16 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Mapping f:employees employees(Ford) { John, Joe, Jim, etc} Ford Class: Company GM Class: Employee Ford employees

17 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Cardinality 0.. * 1.. * * 1.. 1 0.. 1 Abbreviated as 1 Zero to many One to many Zero to one One to one

18 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Cardinality f * B 0 to many A f 0..1 B 0 to 1 A f 1 B 1 to 1 A One of A is associated with 0 or more of B One of A is associated with 0 or 1 of B One of A is associated with 1 of B

19 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Cardinality f * B 0 to many A f 0..1 B 0 to 1 A f 1 B 1 to 1 A One of B is associated with 0 or more of A One of B is associated with 0 or 1 of A One of B is associated with 1 of A

20 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Cardinality Job positions * 0 to many Job Positions Internet user 0..1 User 0 to 1 Internet Connection customer 1 Customer 1 to 1 Invoice A business unit can have 0 or more job positions An Inertnet communication channel can be idle (0 users) or used by one user at the time An invoice is associated with one and only one customer Business Unit

21 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Cardinality Business unit 1..1 one to one i connections * zero to many invoices * A job position is associated with one an only one business unit A user can have zero or more internet connections A customer can have 0 or more invoices Job Positions User Customer Internet Connection Invoice Business Unit zero to many

22 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is the Cardinality on this relationship? Company Employee employer Employees

23 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is the Cardinality on this relationship? Job positions Business unit Business Unit Job Position

24 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is the Cardinality on this relationship? roles Job positions in role Job Function Job Postion

25 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Job Function Skill Set Activity Job Position Person Business Unit What is the Cardinality on these relationships?

26 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is the Cardinality on this relationship? Persons with address Person’s Address Address Person

27 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is the Cardinality on this relationship? product part of catalog products Product Product Catalog Company

28 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is the Cardinality on this relationship? student directory students Student Department Directory Department

29 Kal Bugrara, Ph.DSoftware Engineering Northeastern University What is this? Sub account Super account Account

30 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Operation (Methods) An operation is the implementation of a service that can be requested from any object of the class to affect behavior (Booch, 1999) An operation can be: Question (does not change the value of the object) Command (may change the value of the object) For example: isFullTimeEmployee() CalculateTotalIncome(); getFullName()

31 For a more modular design financial matters are separated from the student class. The result is the addition of a Student Account class. We extracted the following classes from the original model. The focus is on classes to do with revenues. Detailed Object Model

32 Department related questions start here Student related questions start here The power behind Object Models

33 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Review of Object Oriented Paradigm Abstraction Encapsulation Modularity Hierarchy

34 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Abstraction Abstraction allows us to manage complexity by focusing on the features that matter. OO uses abstraction to define classes that make up the system.

35 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Encapsulation Encapsulation separates the implementation of objects operations from its public interface It is called “information hiding” -- it allows object’s behavior to be used without knowing its implementation Offers two kinds of security: Protects object’s internal state from being changed by outside users. Changes can be done to the behavior implementation without affecting other objects Data Operation Implementation public Interface

36 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Static Inheritance Person Employee Customer Kim Joe Joan Supplier Kevin Susan Lora May Larry Mary

37 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Static Inheritance Person EmployeeCustomer Supplier All instances of Customer, Employee, and Supplier, all inherit all the features of Person

38 Kal Bugrara, Ph.DSoftware Engineering Northeastern University For example Employee Person Customer Address address Customer and Employee will inherit the address relationship. Inhertance allows you to reuse what already defined. There is no need to define an Address for Customer and Employee

39 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Inheritance (contd.) Employee Person Customer Address

40 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Inheritance (contd.) Employee Person Customer Address Primary Address Home Address

41 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Modularity The process of breaking up of a complex situation into small, self contained pieces that can be managed independently Classes are independent modules (distribute responsibility across classes) Job Function Skill Set Task Job We could have lumped all these ideas to get one class

42 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Hierarchy Any ranking or ordering of abstractions into a complex structure. Type of hierarchies: Class Aggregation Containment Inheritance Partition Specialization Sub account Super account Account Person employee customer supplier

43 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Hierarchies and the OO Paradigm Dynamic using relationships for example, an organizational structure Static using inheritance for example, classification of different resource types that share common features OO paradigm allows you to capture two types hierachical structures:

44 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Generating a hierarchical structure where all the elements are instances of Business Unit Corporate Client Services Customer Service Call Center I Call Center II Operations Sales and Marketing Call Center III Sub unit super unit Business Unit

45 Kal Bugrara, Ph.DSoftware Engineering Northeastern University For each level of the hierarchy we generate 0 or more instances of job positions Corporate Client Services Customer Service Call Center I Call Center II Job Positions c1 c2 c3 s1 s2 s3 s4 j1 j2 j3 j4 At every level there are 0 or more Instances of job positions Business unit 1..1 Job positions * Sub unit super unit Business Unit

46 Kal Bugrara, Ph.DSoftware Engineering Northeastern University A job function (role) is a hierarchy of (sub) job functions (subroles) Sub role Super role Job Function Manager Client Representative Operations Manager Project Lead Service Representative Proposal Writer Performer

47 Kal Bugrara, Ph.DSoftware Engineering Northeastern University A job function describes a set of work responsiblities Sub role Super role Job Function Manager Client Representative Service Representative Proposal Writer Activity Activities (work resps) * a1 a2 a3 a4 a6 a5 Each instance of Job Function defines an associated set of activities (work responsibilities a7 a8 Each is an instance of Job Function

48 Kal Bugrara, Ph.DSoftware Engineering Northeastern University Basic Concepts of Object Orientation Object Class Relationships Attribute Operation Interface (Polymorphism)

49 Kal Bugrara, Ph.DSoftware Engineering Northeastern University


Download ppt "Kal Bugrara, Ph.DSoftware Engineering Northeastern University Fundamentals Of Software Engineering Lecture V."

Similar presentations


Ads by Google