1. Structural Modeling

2. Objectives O Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. O Understand the processes used to create CRC cards, class diagrams, and object diagrams. O Be able to create CRC cards, class diagrams, and object diagrams. O Understand the relationship between the structural and use case models.

3. Structural Model O A formal way of representing the objects that are used and created by a business system O People O Places O Things O Drawn using an iterative process O First drawn in a conceptual, business-centric way O Then refined in a technology-centric way describing the actual databases and files

4. Structural Models

5. O Main goal: to discover the key data contained in the problem domain and to build a structural model of the objects Problem Domain Solution Domain Structural Modeling

6. A Common Language O Structural models create a well-defined vocabulary shared by users and analysts O Classes created during analysis are not the classes that programmers develop during implementation O This refinement comes later O Typical structural models: O CRC cards O Class (and Object) diagrams

7. Classes, Attributes, & Operations O Classes O Templates for instances of people, places, or things O Attributes O Properties that describe the state of an instance of a class (an object) O Operations O Actions or functions that a class can perform

8. Relationships O Describe how classes relate to one another O Three basic types in UML O Generalization O Enables inheritance of attributes and operations O Aggregation O Relates parts to wholes O Association O Miscellaneous relationships between classes

9. CRC Cards

10. Responsibilities & Collaborations O Responsibilities O Knowing O Doing O Collaboration O Objects working together to service a request

11. Front-Side of a CRC Card

12. Back-Side of a CRC Card

13. Class Diagrams

14. Elements of a Class Diagram

15. Attribute Visibility O Attribute visibility can be specified in the class diagram O Public attributes (+) are visible to all classes O Private attributes (-) are visible only to an instance of the class in which they are defined O Protected attributes (#) are like private attributes, but are also visible to descendant classes O Visibility helps restrict access to the attributes and thus ensure consistency and integrity

16. Operations O Constructor O Creates object O Query O Makes information about state available O Update O Changes values of some or all attributes

17. More Elements of Class Diagrams

18. Multiplicities DepartmentBossEmployeeChildBossEmployee 11 10..* 11..* Exactly one: A department has one and only one boss Zero or more: An employee has zero to many children One or more: A boss is responsible for one or more employees

19. More Multiplicities EmployeeSpouseEmployeeVacationEmployeeCommittee 10..1 12..4 11..3, 5 Zero or one: An employee can be married to 0 or 1 spouse Specified range: An employee can take 2 to 4 vacations each year Multiple disjoint ranges: An employee can be in 1 to 3 or 5 committees

20. Sample Class Diagram

21. Domain Model : visualizing concept

22. PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights reserved. Object modeling might support a reduced “semantic gap” in models at different stages. But an exact 1-1 mapping is not always present or desirable.

23. Not A Diagram of Software Components O Conceptual models represent ideas, things, and objects in the real-world problem domain. O A conceptual model is not a picture of: O Software components. O Classes in an object-oriented programming language. O It illustrates real-world concepts.

24. 4 Steps to Domain Model O Make a list of candidate concepts O Create CRC Cards O Create the class diagram (Domain Model) O Review the class diagram

25. STEP 1 Make a list of candidate concepts

26. Strategies to Identify Conceptual Classes O Use a conceptual class category list O Make a list of candidate concepts O Use noun phrase identification O Identify noun ( and noun phrases) in textual descriptions of the problem domain, and consider them as concepts or attributes. O Use Cases are excellent description to draw for this analysis.

27. Object Identification O Textual analysis of use-case information O Creates a rough first cut O Common object list O Incidents O Roles

28. Textual analysis of use-case information O A Noun O A common or improper noun implies a class of objects. O A proper noun or direct reference implies an instance of a class. O A collective noun implies a class of objects made up of groups of instances of another class. O An adjective implies an attribute of an object. O A verb O A verb doing verb implies an operation. O A being verb implies a classification relationship between an object and its class. O A having verb implies an aggregation or association relationship. O A transitive verb implies an operation. O An intransitive verb implies an exception. O A predicate or descriptive verb phrase implies an operation. O An adverb implies an attribute of a relationship or an operation.

32. Step 2 Create CRC cards

33. Designing with CRC cards O CRC Cards—Classes, Responsibilities, Collaboration Cards. O OO design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case O Usually a manual process done in a brainstorming session O 3 X 5 note cards O One card per class O Front has responsibilities and collaborations O Back has attributes needed 33

34. Detailed Design with CRC cards O Design process O Identify class with primary responsibility O Identify other classes that collaborate with primary class (become requests for service to other classes) ‏ O Identify responsibilities within each class (these become methods) ‏ 34

35. CRC Card Notation 35

36. CRC Card Results 36

37. Step 3 Create Domain Model

38. O Using the CRC card you can identify the following: O Attributes related to each classes. O Association between classes.

43. Association Category O A is recorded in B O A uses or manages B O A is related to a transaction of B O A communicates with B O A is a transaction related to another transaction B O A is next to B O A is related to B via a transaction O A is recorded in B O A uses or manages B O A is related to a transaction of B O A communicates with B O A is a transaction related to another transaction B O A is next to B O A is related to B via a transaction

50. Summary O Structural Models O CRC Cards O Class Diagrams O Creating CRC cards and domain model

51. Reference O Alan R. Dennis, Barbara Haley Wixom, and David Tegarden. 2007. Systems Analysis and Design with UML Version 2.0: An Object- Oriented Approach (3rd ed.). John Wiley & Sons, Inc., New York, NY, USA.