UML Diagrams Class Diagrams The Static Analysis Model

  • Slides: 49
Download presentation
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept.

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

outline The Requirements Model and the Analysis model q The Static Analysis Model –

outline The Requirements Model and the Analysis model q 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 q q Examples

UML Development - Overview ACTORS REQUIREMENTS ELICITATION SCENARIOS Requirements Engineering ANALYSIS Specify Domain Objects

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

The Requirements Model and the Analysis Model Requirements Elicitation Process The Analysis Process Functional/

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

Static Modeling Class Diagrams A Class is defined as –Real world entity type about

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

outline n n The Requirements Model and the Analysis model The Static Analysis Model

outline n n 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

The Static Model Defines the static structure of the logical model n Represents classes,

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

The conceptual Level n n At the conceptual phase, classes are defined based on

The conceptual Level n n 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

Context Class Diagram Defines the Boundary of the system <<external>> Input Devices <<external>> Other

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

The conceptual Level n n The system package is defined by a diagram representing

The conceptual Level n n 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

The conceptual Level Identify the system classes as Interface objects, Monitors objects, controllers objects,

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

Example of System packages

Example of System packages

outline n n The Requirements Model and the Analysis model The Static Analysis Model

outline n n 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

The Analysis Level n n At the analysis level, class diagrams are refined by

The Analysis Level n n 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

The Class Diagram Notation n n Identify classes, attributes of each class, and operations

The Class Diagram Notation n n 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

Identify Class relationships Pilot Commands Association Aggregate/ Whole Aircraft Control Aggregated/ Part Aggregation (hollow

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

Associations Between Classes Associations between classes are generally shown as solid lines connecting the

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

Associations n Association is –static, structural relationship between classes –E. g, Employee works in

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

Dependency: A Special Case of Association Dependency Client Command. Manager (Client class) depends on

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

Aggregation Relation n Aggregation – A hollow diamond is attached to the end of

Aggregation Relation n 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

Aggregation Example

Aggregation Example

Composition: A Special Case of Aggregation Composition is shown as a solid filled diamond,

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

Composition example

Composition example

Aggregation vs Composition

Aggregation vs Composition

Generalization/Specialization Relation n Generalization is shown as a solid-line arrow from the child (the

Generalization/Specialization Relation n 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. n Should be used to define class hierarchies based on abstraction

Generalization/Specialization Relation

Generalization/Specialization Relation

Multiplicity of Relationships Multiplici ties Meaning 0. . 1 zero or one instance. The

Multiplicity of Relationships Multiplici ties 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

Example of identifying Class Multiplicities, Attributes and operations

Example of identifying Class Multiplicities, Attributes and operations

outline The Requirements Model and the Analysis model q The Static Analysis Model –

outline The Requirements Model and the Analysis model q 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 q q Examples

Recall the Digital Sound Recorder Case Study Requirements Model

Recall the Digital Sound Recorder Case Study Requirements Model

The Sound Recorder Analysis Level Class Diagram

The Sound Recorder Analysis Level Class Diagram

Emergency Monitoring System

Emergency Monitoring System

The ATM Banking System

The ATM Banking System

Example of Software Architecture Using UML 2 n SATELLITE CONTROL SYSTEM Architecture

Example of Software Architecture Using UML 2 n SATELLITE CONTROL SYSTEM Architecture

A Simple Example of Software Architecture Using UML 2 n SATELLITE CONTROL SYSTEM Architecture

A Simple Example of Software Architecture Using UML 2 n SATELLITE CONTROL SYSTEM Architecture

Example: Auto Cruise Control and Monitoring (The Cruise Cont. Subsys)

Example: Auto Cruise Control and Monitoring (The Cruise Cont. Subsys)

Example: Auto Cruise Control and Monitoring (The Monitoring Subsys)

Example: Auto Cruise Control and Monitoring (The Monitoring Subsys)

Example of a Design Level Class Diagram http: //www. codeproject. com/library/Win. SNMPWrapper. asp? df=100&forumid=21

Example of a Design Level Class Diagram http: //www. codeproject. com/library/Win. SNMPWrapper. asp? df=100&forumid=21 6441&exp=0&select=1259211