System Analysis and Design Structural Modeling This presentation includes notes from System Analysis and Design with UML2.0 by Alan Dennis et al., and from Kostas Kontogiannis

Outline Structural Modeling Introduction Class diagrams Object diagrams

What is Structural Modeling? Structural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations.

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

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

Attributes Units of information relevant to the description of the class Only attributes important to the task should be included

Operations Action that instances/objects can take Focus on relevant problem-specific operations (at this point)

Relationships Generalization Aggregation Association Enables inheritance of attributes and operations Aggregation Relates parts to wholes Association Miscellaneous relationships between classes

CLASS-RESPONSIBILITY-COLLABORATION CARDS

Responsibilities and Collaborations Knowing Doing Collaboration Objects working together to service a request

A CRC Card

Back of CRC Card

From Use Cases to Class Diagrams A common or improper noun->class “fieldOfficer”, “patient” , “doctor” A proper noun or direct reference->object “Alice” A collective noun->class made up of instances of another class “department” An adjective->an attribute A doing verb->an operation A being verb->generalization A having verb-> aggregation or association Etc…( Fig 7-6, in System Analysis and Design with UML..)

Entity, Boundary and Control Entity classes represent persistent data in the system Data available between two sessions Recurring nouns (“ Incident”) Real world activities and entities (“Field Officer”, Dispatcher”) Boundary classes represent the interface with the actors input buttons and forms (“EmergencyButton”, “ReportEmergencyForm”) output messages and signals(“AcknowledgeMessage”) Control classes realize use cases and mediate between the entity and boundary classes One control object per use case One control object per actor and use case “ReportEmergencyControl” “ManageEmergencyControl”

Classes are Classifiers A classifier is a mechanism for describing structural and behavioral features. Nine classifiers in UML 2.0 Classes, interfaces, datatypes, signals, components, nodes, use cases, subsystems. Advanced features Multiplicity, visibility, signatures, polymorphism

Class name Window origin attributes size Open() operations Close() Move() Display() operations

Classes with more details PackageName::Agent Name: simple, path Height: Float Val : Boolean = false Attribute: all, only some, or none <<constructor>> New(p : policy) <<process>> Process(o : order) … Operations: services provided. Stereotype: group attributes/ops and put a descriptive prefix. Responsibilities Responsibility: obligation of a class. free-form text. -- determine risk of an order -- handle criteria for fraud

Visibility of attr. & ops. Public: Any outside classifier can use (+). Protected: Any descendant of the classifier can use (#). Private: Only the classifier itself can use (-). Package: Only visible within the package(~) Toolbar # currentSelection: Tool # toolCount: Integer + pickItem(i: integer) - compact()

(Owner) Scope Instance: Each instance of the classifier holds its own value for the feature. Classifier: There is just one value of the feature for all instances of the classifier. Frame instance Header : FrameHeader uniqueID : Long classifier (“static” in Java)

Multiplicity - Specification of the range of allowable cardinalities an entity may assume. 1 Car wheels : Wheel[4] persons: Person[1..5] Engine: Engine

Classes: operation body

Showing more details... Names of abstract classes and operations shown in italics

Relationships Window Event Open() Close() HandleEvent() dependency generalization association ConsoleWindow DialogBox Control DisplayPrompt() …

Generalization: Alternative notations

Generalization: Multiple Classification

More about association Works for Person Company Name an association to describe its nature. Direction triangle: direction of reading. employee employer Person Company Role: face presented to the other class.

More about association Navigability: An arrow may be attached to the end of the path to indicate that navigation is supported toward the classifier attached to the arrow. Works for Person Company

More about association Multiplicity: How many objects may be connected across an instance of an association. 1..* * Person Company employee employer Multiplicity at one end  for each object at the other end, there must be that many objects at the near end. Exactly one: 1 Zero or one: 0 .. 1 Many: 0 .. * One or more: 1 .. * Not shown  unspecified or suppressed

Aggregation Company whole 1 * Department part Plain association: peer relationship. Aggregation: whole/part relationship. - An object can be shared by other aggregates. Company whole 1 * Department part

More about association Composition (composite aggregation): - An object may be a part of ONLY one composite at a time. - Whole is responsible for the disposition of its parts. whole Window 1 * Frame part

Composition vs Aggregation Aggregation: does not link the lifetimes of the whole and its parts. Composition: Parts with nonfixed multiplicity can be created after the composite itself.  lifetime Such parts can be explicitly removed before the death of the composite.  lifetime An object may be a part of only one composite at a time.  strong ownership

Alternative notations for composition

More about association Association classes: specify properties of an association. employer employee Person Company 1..* * Job Description dateHired Salary

Ternary Associations

Constraints Constraints add new semantics or change existing rules. Portfolio Corporation {secure} {or} BankAccount Person

Constraints and Comments

Derived Attributes and Associations

More examples of associations

More examples of associations

Dependencies «permit» ClassA ClassB ClassC «instantiate » «call ClassD operationZ() «friend» Class D E « refine» ClassC combines two logical classes

Realization - A semantic relationship between classifiers. - One classifier specifies a contract that another guarantees. - Realization in two places: - between interfaces and classes/components that realize them. - between use cases and collaborations that realize them. - Graphical rendering: cross between generalization and dependency

Relationships: Summary

Core Relationships: Summary

Interface Defines a set of operation specs Never defines an implementation (no attributes, no associations, operations not implemented) Typically attached to a class or component

Interfaces: Shorthand Notation +create() +login(UserName, Passwd) +find(StoreId) +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item) -storeId: Integer -POSlist: List Store POSterminal POSterminalHome <<use>> StoreHome I I

Interfaces: Longhand Notation

Class Diagram-Order CDs

Class Diagram-Order CDs

Instances Concrete manifestation of an abstraction All objects are instances Not all instances are objects. (Instance of an association is a “link”) To indicate an instance, underline its name

Instances (named, anonymous, multiple) t: Transaction named myCustomer :Multimedia::AudioStream anonymous multiobject :keyCode

Object state Instance with attribute values myCustomer Id : SSN = “432 …..” Active = true Instance with explicit state c: Phone [WaitingForAnswer]

Object diagrams Model the instances of things contained in class diagrams. Show objects are their relationships at a point in time. No communication is shown.

An object diagram c:Company d1: Dept d2: Dept name = “R&D” name = “Sales” Objects, links, notes, constraints d3: Dept Name = …. p: Person : ContactInfo Name = “jk” Address=“200 U Av.”

Summary Class and object diagrams show the underlying structure of an object-oriented system. CRC cards capture the essential elements of a class. Relationships capture the collaboration between 2 or more classes( dependency, realization, generalization, associations, aggregation, composition) Constructing the structural model is an iterative process involving: textual analysis, brainstorming objects, role playing, creating the diagrams, and incorporating useful patterns.