1. UML Diagrams: Class Diagrams The Static Analysis Model
Instructor: Dr. Hany H. Ammar
Dept. of Computer Science and Electrical Engineering, WVU

2. outline The Requirements Model and the Analysis model
The Static Analysis Model – The Analysis Process
The Conceptual Level - Identifying the Classes of Objects (Step 6 Requirements Elicitation Process: Identify Initial Analysis Objects)
The Analysis Level – Identifying Class relationships, class attributes, and class operations

3. UML Development - Overview
ACTORS
USE CASES
REQUIREMENTS
ELICITATION
Time
SCENARIOS D
Requirements
Engineering
System/Object
SEQUENCE
DIAGRAMS A T A
ANALYSIS
CLASS DIAGRAM(S)
ANALYSIS
Specify Domain
Objects
StateChart
DIAGRAMs D I
OPERATION CONTRACTS C T
Architectural Design
Include
Design Objects I
SUBSYSTEM CLASS/
OR COMPONENT
DIAGRAMS
DESIGN SEQUENCE DIAG.
DEPLOYMENT DIAGRAM O N
DESIGN DIAGRAMS A
Detailed DESIGN R Y
Object
Design
IMPLEMENTATION
CHOICES
IMPLEMENTATION
Activity DIAGRAMS
IMPLEMENTATION
PROGRAM

4. The Requirements Model and the Analysis Model
Elicitation
Process
Functional/
Nonfunctional
Requirements
Use Case Diagrams/
Sequence Diagrams
(the system level)
The Analysis
Process
Static Analysis
Dynamic Analysis
- Class Diagrams
- State Diagrams/
Refined Sequence
Diagrams (The object
level)

5. Static Modeling Class Diagrams
A Class is defined as
–Real world entity type about which information is stored
–Represents a collection of identical objects (instances)–Described by means of attributes (data items)
–Has operations to access data maintained by objects
–Each object instance can be uniquely identified
Relationships between classes
–Associations
–Composition / Aggregation
–Generalization / Specialization

6. The Static Model Defines the static structure of the logical model
Represents classes, class hierarchies using packages, classes, and their relationships,
Evolve in three phases the conceptual phase, the analysis phase, and the design phase.

7. The conceptual Level
At the conceptual phase, classes are defined based on the classes found in the problem domain descriptions (based on the objects identified in step 6 in the Requirements Elicitation Process)
A context class diagram is defined first, where the system under development is represented by one package and external classes representing the actors

8. Context Class Diagram Defines the Boundary of the system
<<external>>
Input Devices
<<external>>
Output
Devices
System under
development
<<external>>
Other Actors
Specify the classes of the external input/output devices and
other actors (users, other systems, etc.) and the system classes

9. The conceptual Level
The system package is defined by a diagram representing the main classes and interface classes to external classes
Each subsystem is represented by a class diagram defining the classes of objects needed to realize the use cases defined in the use case diagrams
The stereotype words <<external>> or <<actor>> are used to specify external classes or packages
Names of external packages should reflective of the classes defined in the package

10. The conceptual Level
Identify the system classes as Interface objects, Monitors objects, controllers objects,
<<Interface>>
Input_devices
or actors
Monitors
Controllers
<<Interface>>
Output_devices
or actors

11. Example of System packages

12. The Analysis Level
At the analysis level, class diagrams are refined by adding relationships between classes, attributes and methods depicting how objects of the static view are used to realize use cases in sequence diagrams
Emphasis is placed on distributing behavior, resolving software interfaces, and identifying generalization relationships that will maximize the effectiveness of the object model

13. The Class Diagram Notation
Identify classes, attributes of each class, and operations of each class
Classes, their attributes and methods are specified based on the objects needed to realized use case and interfaces to external entities
Detailed
Attributes,
Data types,
And operations
Are defined/
refined
During design

14. Identify Class relationships
Pilot
Commands
Aircraft
Control
Parent
Association
Child
Aggregate/
Whole
Aggregated/
Part
Generalization
Aggregation (hollow diamond)/
Composition (solid diamond)

15. Associations Between Classes
Associations between classes are generally shown as solid lines connecting the associated classes.
A notable exceptions to the solid line rule are the use of dashed lines to depict dependencies as special case of association,

16. Associations Association is
–static, structural relationship between classes
–E.g, Employee works in Department
Multiplicity of Associations
Specifies how many instances of one class may relate to a single association, Company hasPresident
1-to-many association, Bank managesAccount
Optional association (0, 1, or many) –Customer ownsCredit Card instance of another class
1-to-1
Many-to-Many association –Course has Student, and
Student attends Course

17. Dependency: A Special Case of Association
Client
CommandManager (Client class) depends on services
provided by the other three server classes

18. Aggregation Relation
Aggregation – A hollow diamond is attached to the end of the path to indicate aggregation. The diamond is attached to the class that is the aggregate. Aggregation provides a definitive conceptual whole part relationship

19. Aggregation Example

20. Composition: A Special Case of Aggregation
Composition is shown as a solid filled diamond, with the diamond attached to the class that is the composite. Composition is a form of aggregation that requires coincident lifetime of the part with the whole and singular ownership; i.e. the part is owned by only one whole and is deleted when the whole is deleted

21. Composition example

22. Aggregation vs Composition

23. Generalization/Specialization Relation
Generalization is shown as a solid-line arrow from the child (the more specific element) to the parent (the more general element) this type of relationship is also called inheritance.
Should be used to define class hierarchies based on abstraction

24. Generalization/Specialization Relation

25. Multiplicity of Relationships
Multiplicities
Meaning
0..1
zero or one instance. The notation n . . m indicates n to m instances.
0..*  or  *
no limit on the number of instances (including none). 1
exactly one instance (the default)
1..*
at least one instance

26. Example of identifying Class Multiplicities, Attributes and operations

27. Recall the Digital Sound Recorder Case Study Requirements Model

28. The Sound Recorder Analysis Level Class Diagram

29. Example of a Design Level Class Diagram http://www. codeproject

30. Example of Software Architecture Using UML2
SATELLITE CONTROL SYSTEM Architecture

31. A Simple Example of Software Architecture Using UML2
SATELLITE CONTROL SYSTEM Architecture

32. Example: Auto Cruise Control
and Monitoring

33. Example: Auto Cruise Control and Monitoring

34. Example: Auto Cruise Control and Monitoring