Structural Modeling
Objectives Define the purpose of structural models
Structural Models: Introduction Use-case and activities describe how a system behaves Structural models describe a static view of The data stored in a system The interface describing how that data is accessed Structural models ultimately become class diagrams This data and interface together form a class We are back to OOP
Classes and their Members A class is a template or blueprint for an object It’s attributes store data It’s operations (method) act on the data Triggers are a special form of method Responsibilities
Class Relationships Some classes have relationships to each other They fall into 3 categories Generalization Aggregation Association
Generalization We again talk about an “IS-A” relationship Your book calls it a “a kind of” relationship We inherit attributes and methods from other classes The inherited class is called the base class or super class The inheriting class is called the derived class or subclass
Aggregation Aggregation relates to “the parts of a whole” X is a part of Y A transmission is part of a car An engine is part of a car The inverse of aggregation is decomposition An engine can be part of other things than a car
Association You saw association related to use-case diagrams Associations between classes are more loosely defined than generalization and aggregation A professor writes a book
The Process of Identifying Objects So how do we figure out how to structure classes, their attributes and their methods? What are the relationships between classes? There are a few common techniques to do this Textual analysis Brainstorming Use-case narratives and diagrams CRC cards
Identifying Objects: Textual Analysis Review use-case diagrams and text in use-case descriptions based on the following rules Common nouns imply a class objects Adjectives imply attributes A doing verb implies an operation (method) A transitive verb implies an operation A doable activity with a direct object A having verb implies an aggregation or association relationship
Identifying Objects: Other Brainstorming is designed to think up new and non-obvious ideas Common object lists Lists of objects belonging to a particular category
CRC Cards Class-Responsibility-Collaboration diagram They provide a rough cut analysis of a class interface
CRC Card: Example
CRC Card: Parts Header Class name Description Type (concrete or abstract) Associated use-cases (optional)
CRC Card: Parts A two-column layout of responsibilities and collaborators Responsibilities Collaborators CreatePurchaseOrder Vendor / Material EditPurchaseOrder CancelOrder Vendor ApprovePurchaseOrder ReceiveGoods Material PayVendor Vendor / AccountsPayable
CRC Card: Parts Lists of attributes and relationships Attributes PurchaseOrderID PurchaseOrderAmount Vendor Relationships Type Generalization Order Aggregation OrderItem ShippingInstructions
Class Diagrams From the CRC cards, we can create more formal class diagrams They depict Classes having attributes and methods Relationships between classes Cardinality
Class Diagrams: Members A class diagram lists the class name, attributes and operations in sections Attributes appear as name: type Methods appear as name(parameter list)
Class Diagrams: Inheritance Drawn a line from the derived class to the base class Abstract members appear in italics
Class Diagrams: Interfaces An interface is a contract and classes implement interfaces Depict with dotted lines instead of solid lines
Class Diagram: Association A general bi-directional link between classes Both classes are aware of each other
Class Diagram: Aggregation Remember that aggregation is a special type of association used to model the whole to its parts Basic aggregation depicted with a hollow diamond The child instance can outlive the parent instance Composition depicted with a filled diamond The child instance cannot outlive the parent instance
Relationships: Multiplicity Relationships also have multiplicity How object instances are related to other object instance Symbol Meaning 1 Attribute has a single value 0..1 Attribute can be null * A collection of values 1..* A collection containing at least one value n..m A collection containing between n and m values
Visibility Object-oriented program supports a notion of visibility Mark Visibility Description + Public Visible by other classes and packages # Protected Visible to derived types - Private Visible only to the owner type ~ Package Visible to other types in the same package
Refactoring This whole process is iterative And we refine how classes are organized and their attributes