1. Systems Analysis and Design with UML Version 2.0, Second Edition
Chapter 7: Structural Modeling

2. Structural Modeling
Chapter 7

3. Key Ideas
A structural or conceptual model describes the structure of the data that supports the business processes in an organization..
The structure of data used in the system is represented through CRD cards, class diagrams, and object diagrams.

4. STRUCTURAL MODELS

5. Purpose of Structural Models
Reduce the “semantic gap” between the real world and the world of software
Create a vocabulary for analysts and users
Represent things, ideas, and concepts of importance in the application domain
One of the more important challenges that face developers in a new domain is gap between how the user talks about the system (real world) and how we frame those thoughts to build software and his/her vocabulary is a stumbling block for both. If you are designing a airline reservation system your vocabulary will include things like flight path, flight plan. If you are building a system for manufacturing your acronyms will include things like JIT, BOM… These structural models will aid in bridging these gaps in vocabulary and the way we think.

6. Classes Templates for creating instances or objects Typical examples:
Concrete
Abstract
Typical examples:
Application domain, user interface, data structure, file structure, operating environment, document, and multimedia classes
During analysis classes are simple real things in the application domain. As we proceed classes can be database manipulation classes, design pattern classes, user interface controller classes and many more. But for now they are simply real world objects in the application domain.

7. Attributes
Units of information relevant to the description of the class
Only attributes important to the task should be included
Attributes represent a piece of information relevant to the application domain usually associated with a particular class. Eventually all attributes will be associated with some class.

8. Operations Action that instances/objects can take
Focus on relevant problem-specific operations (at this point)
Operations are simply a service, behavior, method where we place code to manipulate the attributes, etc.

9. Relationships Generalization Aggregation Association
Enables inheritance of attributes and operations
Aggregation
Relates parts to wholes
Association
Miscellaneous relationships between classes
Relationships are a logical connection that two things have for one another. A child has a relationship with their parent. A student has a relationship with their schedule, a book has a relationship with a class. There are several types of relationships. The research to discover types of relationships is ongoing but today the accepted relations are generalization where it represents an “IS A” relationship. For example a student “IS A” person. And a student inherits all the characteristics of a person. Aggregation is a “PARTS OF” relationship. A tire is “PART OF” a car. Is a car still a car without the tire… Well that depends on the domain. If you are a rental company then maybe not you would not want to rent a car without a tire. However, if you are a repair shop then yes, it is still a car. Some parts seem more important than others. If you loose your arm (a part) are you still a person. If you loose your heart are you still a person. Depends on the domain. All other relationships that are not “IS A”, generalization, or “PARTS OF” , aggregation, are classified as associations. The research to break these associations down into categories that have value in software development is proceeding.

10. CLASS-RESPONSIBILITY-COLLABORATION CARDS

11. Responsibilities and Collaborations
Knowing
Doing
Collaboration
Objects working together to service a request
Responsibilities for classes is a term typically used by Rebecca Wirths-Brock who advocates a technique for object-oriented design called responsibility driven design. In this approach, responsibilities are the methods of a class. Those responsibilities are divided into two types. The first is knowing which includes methods that allow you to KNOW what data values a class might have. The other responsibilities are doing methods which allow the class to do things– manipulate its data, change controls, set up values, etc.
Collaboration is the process of objects of classes working together to perform a task that cannot be done by only one class but takes methods from many to get the class done. If you want to register for a section of a class. It will take more than one object/class to do this. You will have to have a student class, student financial class, a section class, a course class (a course may have more than one section), and a registration class. All of those classes have to collaborate to register. The student has to KNOW what classification you are to assure that you do not break any rules for that classification such as register for too many hours, register out of major, etc. It has to know if you have any holds from your finances. Then it must check the section to see if the section is full and get the course name and credits from the course class WHEN… Lots of collaboration.

12. A CRC Card
One technique to help you identify your classes of a class diagram AND to aid in understanding its attributes and responsiblities is the CRC card. If you struggle with identifying classes, this is certainly a good technique. Also on large projects, it proves to be a great documentation aid since many people want to know the candidate responsibilities as they design and analyze their own classes. When you are working with a system that has 4000 classes, this will really be needed. If you have 10 classes, it may not be as relevant. It does get too cumbersome once analysis is complete but is often used when you are looking at the collaborations of one use case during design as a tool for conversations and deciding who should have what responsibility. There are two parts of the CRC card. The first part, the front< contains the name of the candidate class, an ID assigned by the project just to help you keep up with the CRC cards, the type of class proposed. Note the example shows it is a domain class meaning it is part of the application domain, not of the GUI, database, etc. A brief description and if this class is involved in other use cases (this associated use case data gets out of sync quickly as development progresses), the proposed responsibilities, and the collaborators this class may have in accomplishing those responsibilities. In the second part of the card, the back, it shows the attributes, and types of relationships this class has. This is not a document that is forever, it is a working tool to help you identify classes, identify their responsibilities, identify attributes, and identify collaborations and relationships. It also helps you work out disagreements on which class a responsibility or attribute should be assigned to. This often becomes a stumbling block in development.

13. Back of CRC Card

14. CLASS DIAGRAMS

15. Class Diagram Static model showing classes, and their relationships.
It also shows attributes and relationships.
Its components are:
Class Definition
Relationships
A class diagram during analysis will define the DOMAIN classes often referred to as to concepts of the system. Initially it may not list the attributes and methods but as the definition of the system becomes more clear these will be added. Begin by trying to come up with your classes then add attributes, then relationships, then methods. This is not a hard rule just a helpful hint.

16. Example Class Diagram
Here is an example of a class diagram. It is a work in progress since all the classes are not completed. Lets look at how we might read this diagram. There is a person class with attributes of last name, first name, etc. There are two types of persons – an employee and a patient. An employee “IS A” person and a patient “IS A” person. We can see that be the triangle below person. Reading the more completed portion of the diagram we see the patient has a medical history part. It know it is a “PART OF” relationship by the diamond. I also know he had one and only one of these history classes associated with one patient by the numbers beside the relationship. A patient suffers from 1..* read 1 to many symptoms . That symptom may be associated with 1 to many illnesses. And the relationship of the symptom to the illness may have a treatment.

17. Class Diagram Syntax A CLASS Class 1 -attribute +operation ()
AN ATTRIBUTE
AN OPERATION
AN ASSOCIATION
Class 1
-attribute
+operation ()
Attribute name/
derived attribute name
operation name ()
1..* 0..1
______verb phrase____
The syntax of the diagram is as follows
A class is documented in a rectangle. The rectangle is divided into three parts (the first is the class name, the second is the class attributes, and the third is the operations. Note the attributes have a minus sign in from of their name and the operations have a plus sign. Note also the operations have open and close parens at the end of their name. The associations denoted on the line are named with a VERB PHRASE and (with the exception of generalization relationships), must have a cardinality – the numbers on the relationship.

18. More on Attributes Derived attributes Visibility
/age, for example can be calculated from birth date and current date
Visibility
Public
Protected
Private
Attributes are simply properties of a class. Some attributes are derived and while it is discouraged, you may wish to have them in the class. For example AGE, it is an attribute that changes each year (don’t we know it). So having it stored permanently does not work and calculating all persons age each day isn’t practical. But if need be for some reason you can store it. Balance due is another calculated attribute. However you could update it everytime you have a transaction – as long as you remember to do just that for EVERY transaction. Attributes can be public – viewable to EVERYONE . This is STRONGLY not recommended. Methods called gets and sets should be used to access attributes AT ALL TIMES WITHOUT EXCEPTION WITH NO FRIENDS – NOT ACCESS. I hope this clears this up. NO good software engineering accesses variables WITHOUT a get and set from ANYWHERE even within the class. (Note VB feels so strongly about this that they simply set up you a default get and set so when you access the attribute you do so automatically with a get and set WITHOUT you knowledge. ) So ALL attributes should be either protected or private (preferrably private). Protected means it can be accessible from all other classes except subclasses. Private attributes are hidden from all other classes (THIS IS PERFERRED).

19. More on Operations Constructor Query Update Creates object
Makes information about state available
Update
Changes values of some or all attributes
Operations are actions or functions that the class performs, its responsibilities or services. Constructor operations create instances of the class called an object. Queries make attributes and state information available. The gets would be in this category. Updates change values or states of attributes. Sets are in this category.

20. Generalization and Aggregation
Generalization shows that a subclass inherits from a superclass
Doctors, nurses, admin personnel are kinds of employees
Aggregation classes comprise other classes
Health team class comprised of doctor, nurses, admin personnel classes

21. More on Relationships Class can be related to itself (role)
Multiplicity
Exactly one, zero or more, one or more, zero or one, specified range, multiple disjoint ranges
Association class

22. Simplifying Class Diagrams
The view mechanism shows a subset of information
Packages show aggregations of classes (or any elements in UML)

23. Object Diagrams
Although class diagrams are needed to document the structure of classes, at times an object diagram can be useful. An object diagram is an instantiation ( a created instance) of all or part of a class diagram. Object diagrams are not a deliverable but help you think about situations regarding the real instances and how they interact. When you are having problems understanding some of the relationships within a class diagram, these help to show how each attribute value changes as relationships exist.

24. CREATING CRC CARDS AND CLASS DIAGRAMS

25. Object Identification
Textual analysis of use-case information
Nouns suggest classes
Verbs suggest operations
Creates a rough first cut
Common object list
Incidents
Roles
There are numerous methods that have been defined to identify classes in a problem domain. They are categorized into three different types. Those include Testural Analysis in which you analyze some text about the system and drive out the classes by allowing the nouns of the text to be candidate and eliminating unneeded ones and keeping those required.
Common Object List is a technique that list the most common objects you can think of in a discovery model of thinking. Again eliminate those not needed and keep those that are required.
The third technique is patterns, a relatively new technique. There is some literature on these patterns under Analysis Patterns. The basic idea is to recognize that many systems have a similar pattern of structure. For example checking out a book at the library or renting a video item are similar transactions. Buying an items in a online is also a similar transaction. They have similar collaborating classes. For example they include a customer (library client, video customer, online customer), a product (book, video, online product), a transaction record (including date, amount, how many etc), and perhaps other classes. Using these standard patterns for similar domains helps you know what the classes are.

26. Object Identification
Textual analysis AND Common Object List Process
Either use text, CRC, or discovery to identify candidate classes.
Eliminate those not needed and keep those required
In both textural analysis (reviewing documents such as user manuals, use case descriptions, proposals, notes taken in JADs or interviews, other documentation) or in building common object lists you end up with what is called a list of candidate objects. The hard part is to eliminate what is not an class and to keep those you need. A big list is better but knowing how to cull out those not needed is tough. Here are some clues. Generally speaking these are the rules but not always.
Classes usually have more than one instance. If only one is known it may not be an objects
Classes have attributes. If two of your candidate classes have the same attributes then they may be the same class or a subtype of one or the other. If the class has not attributes it probably is not a class
Classes have operations, if two of your candidate classes have the same operations, they may be the same class or a subclass. If a class has no operations, it is suspicious.
Domain classes (those identified at this point) are not reports, screens, or other Input/Output items. Those come later during design. They are design classes. There are some exceptions to this but rare.
Classes are usually not I/O devices such as a printer UNLESS you are writing a printer driver then of course it would be a class since it would be within the domain of what you are building. But if the printer is just an I/O device your are using it is not a class.
These rules are not cut in stone but may give you some guildelines.

27. Patterns Useful groupings of classes that recur in various situations
Transactions
Transaction class
Transaction line item class
Item class
Location class
Participant class
Identifying objects with patterns is more difficult. I teach a graduate class in this but it is certainly an advanced topic. Here are some of the typical analysis classes others include Person usually a class with subclasses of things like employees, customers, patients, etc.
Other typical analysis classes are accounting classes such as payment, debit, credit, etc. There are numerous of these classes and interesting as this portion of software engineering evolves.

28. Steps for Object Identification and Structural Modeling
1. Create CRC cards by performing textual analysis on the use-cases.
2. Brainstorm additional candidate classes, attributes, operations, and
relationships by using the common object list approach.
3. Role-play each use-case using the CRC cards.
4. Create the class diagram based on the CRC cards.
5. Review the structural model for missing and/or unnecessary classes,
attributes, operations, and relationships.
6. Incorporate useful patterns.
7. Review the structural model.
Here are the steps for using the CRC cards for object identification and structural modeling
1. Create CRC cards by performing textural analysis on the use-cases. Actually you can create the CRC cards classes by any one of the three techniques. If you have use case descriptions and they are written in the SVDPI form, then it becomes easy to get the classes out. If these have not yet been completed then other text or discovery may have to do. Role playing each use case by thinking about what happens is helpful. Role playing involves thinking of your self as one of the instances (the role) and walking through what you would do. You can even have several people and let each of them play a class as you walk through a use case. It becomes a performance of the use case. Create the class diagram based on the information you have gathered. You will know most of the attributes but perhaps not all of the responsibilities (methods). Try to fill out as many as possible. Incorporate any usefule patterns you are aware of and then review the model.

29. Summary CRC cards capture the essential elements of a class.
Class and object diagrams show the underlying structure of an object-oriented system.
Constructing the structural model is an iterative process involving: textual analysis, brainstorming objects, role playing, creating the diagrams, and incorporating useful patterns.

30. Expanding the Domain
A quirky and interesting tutorial regarding CRC cards can be found at: