Download - Requirements Modeling: Class-Based
![Page 1: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/1.jpg)
Requirements Modeling: Class-Based
Prof. Alex Bardas
![Page 2: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/2.jpg)
Class-Based Modeling
• A class-based model contains• Objects• What the system will manipulate
• Operations (methods or services)• What to be applied to the objects to effect the manipulation
• Relationships (some hierarchical) between objects• Collaborations between the classes that are defined
EECS 448 Software Engineering
![Page 3: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/3.jpg)
Identifying Classes
6 selection characteristics1. Retained information
The potential class will be useful during analysis only if information about it must be remembered so that the system can function.
2. Needed servicesThe potential class must have a set of identifiable operations that can change the value of its attributes in some way.
EECS 448 Software Engineering
![Page 4: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/4.jpg)
Identifying Classes
6 selection characteristics3. Multiple attributes
During requirement analysis, the focus should be on “major” information.A class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity.
4. Common attributesA set of attributes can be defined for the potential class and these attributes apply to all instances of the class.
EECS 448 Software Engineering
![Page 5: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/5.jpg)
Identifying Classes
6 selection characteristics5. Common operations
A set of operations can be defined for the potential class and these operations apply to all instances of the class.
6. Essential requirementsExternal entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model.
EECS 448 Software Engineering
![Page 6: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/6.jpg)
Attributes
• Attributes define a class• For the same class, attributes can be very different in different contexts• What data items fully define this class in the problem context?
The Player class for professional baseball players• Playing statistics software
• Name, position, batting average, fielding percentage, years played, and games played, …
• Pension fund software• Name, average salary, pension plan options chosen, mailing address, …
EECS 448 Software Engineering
![Page 7: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/7.jpg)
Operations
• Operations define the behavior of an object:• Manipulate data
• e.g., adding, deleting, reformatting, selecting
• Perform a computation• Inquire the state of an object• Monitor an object for the occurrence of a controlling event
• e.g., communications between objects
7EECS 448 Software Engineering
![Page 8: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/8.jpg)
Case Study: Safe Home
The SafeHome security function enables thehomeowner to configure the security system when it’sinstalled, monitors all sensors connected to thesecurity system, and interacts with the homeownerthrough the Internet, a PC, or a control panel.
8EECS 448 Software Engineering
Potential Class Type
![Page 9: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/9.jpg)
Case Study: Safe Home
The SafeHome security function enables thehomeowner to configure the security system when itis installed, monitors all sensors connected to thesecurity system, and interacts with the homeownerthrough the Internet, a PC, or a control panel.
9EECS 448 Software Engineering
Potential Class Type
homeowner role
(security) system thing
sensor external entity
control panel external entity
![Page 10: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/10.jpg)
Case Study: Safe Home
During installation, the SafeHome PC is used toprogram and configure the system. Each sensor isassigned a number and type, a master password isprogrammed for arming and disarming the system,and telephone number(s) are input for dialing when asensor event occurs.
10EECS 448 Software Engineering
Potential Class Type
homeowner role
system thing
sensor external entity
control panel external entity
![Page 11: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/11.jpg)
Case Study: Safe Home
During installation, the SafeHome PC is used toprogram and configure the system. Each sensor isassigned a number and type, a master password isprogrammed for arming and disarming the system,and telephone number(s) are input for dialing when asensor event occurs.
11EECS 448 Software Engineering
Potential Class Type
homeowner role
system thing
sensor external entity
control panel external entity
Installation event
number, type thing
master password thing
telephone number thing
sensor event event
![Page 12: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/12.jpg)
Case Study: Safe Home
When a sensor event is recognized, the softwareinvokes an audible alarm attached to the system. Aftera delay time that is specified by the homeowner duringsystem configuration activities, the software dials atelephone number of a monitoring service, providesinformation about the location, reporting the nature ofthe event that has been detected. The telephonenumber will be redialed every 20 seconds untiltelephone connection is obtained.
12EECS 448 Software Engineering
Potential Class Type
homeowner role
system thing
sensor external entity
control panel external entity
Installation event
number, type thing
master password thing
telephone number thing
sensor event event
![Page 13: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/13.jpg)
Case Study: Safe Home
When a sensor event is recognized, the softwareinvokes an audible alarm attached to the system. Aftera delay time that is specified by the homeowner duringsystem configuration activities, the software dials atelephone number of a monitoring service, providesinformation about the location, reporting the nature ofthe event that has been detected. The telephonenumber will be redialed every 20 seconds untiltelephone connection is obtained.
13EECS 448 Software Engineering
Potential Class Type
homeowner role
system thing
sensor external entity
control panel external entity
Installation event
number, type thing
master password thing
telephone number thing
sensor event event
audible alarm external entity
delay time thing
monitoring service external entity
![Page 14: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/14.jpg)
Recap: Identifying Classes
6 selection characteristics
1. Retained information
2. Needed services
3. Multiple attributes
4. Common attributes
5. Common operations
6. Essential requirements
![Page 15: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/15.jpg)
15EECS 448 Software Engineering
Potential Class Type
homeowner role
system thing
sensor external entity
control panel external entity
Installation event
number, type thing
master password thing
telephone number thing
sensor event event
audible alarm external entity
delay time thing
monitoring service external entity
Class SelectionCharacteristics
![Page 16: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/16.jpg)
16EECS 448 Software Engineering
Potential Class Type
homeowner role
system thing
sensor external entity
control panel external entity
Installation event
number, type thing
master password thing
telephone number thing
sensor event event
audible alarm external entity
delay time thing
monitoring service external entity
Class SelectionCharacteristics
No Does not retain info
Yes All 6 apply
Yes All 6 apply
Yes All 6 apply
No None applies
No Attributes of sensor class
No Does not have multiple attributes
No DoesnothavemultipleattributesYes All 6 apply
Yes All 6 apply
No Attribute of system class
No So far it does not need service
![Page 17: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/17.jpg)
Analyzing Class Elements (1/2)
• Consider more fine-grained element types• Roles and external entities (actors)
• Roles played by people who interact with the system• External entities that produce or consume information
• Organizational units that are relevant to an application• e.g., team, group, division
• Structures• Define a class of objects or related classes of objects
e.g., sensors, computers, four-wheeled vehicles
![Page 18: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/18.jpg)
Analyzing Class Elements (2/2)
• Consider more fine-grained element types• Things
• Part of the information domain for the problem• e.g., reports, displays, letters, signals
• Occurrences• Events occur within the context of system operation
• Places• The context of the problem and the overall function
![Page 19: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/19.jpg)
Case Study: Safe Home
• Let’s look at the system class• Alarm response information
• delayTime, telephoneNumber
• Activation/deactivation• masterPassword• number of tries• temporary password
• Identification• system ID, status
19EECS 448 Software Engineering
SystemdelayTime
telephoneNumbermasterPassword
![Page 20: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/20.jpg)
Case Study: Safe Home
• Let’s look at the system class• Alarm response information
• delayTime, telephoneNumber
• Activation/deactivation• masterPassword• number of tries• temporary password
• Identification• system ID, status
20EECS 448 Software Engineering
SystemsystemID
systemStatusdelayTime
telephoneNumbermasterPasswordtempPasswordnumberTries
![Page 21: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/21.jpg)
Case Study: Safe Home
During installation, the SafeHome PC is used toprogram and configure the system. Each sensor isassigned a number and type, a master password isprogrammed for arming and disarming the system,and telephone number(s) are input for dialing when asensor event occurs.
21EECS 448 Software Engineering
SystemsystemID
systemStatusdelayTime
telephoneNumbermasterPasswordtempPasswordnumberTries
![Page 22: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/22.jpg)
Case Study: Safe Home
During installation, the SafeHome PC is used toprogram and configure the system. Each sensor isassigned a number and type, a master password isprogrammed for arming and disarming the system,and telephone number(s) are input for dialing when asensor event occurs.
• Display() typically should exist too.
• Divide operations into sub-operations if needed• e.g., program()
22EECS 448 Software Engineering
SystemsystemID
systemStatusdelayTime
telephoneNumbermasterPasswordtempPasswordnumberTries
program()arm()
disarm()display()
![Page 23: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/23.jpg)
Class-Responsibility-Collaborator Modeling
•CRC model:
• Used to identify and organize classes
• Originally introduced as a technique for teaching object-
oriented concepts
• Use a collection of (actual or virtual) index cards
representing classes
23EECS 448 Software Engineering
![Page 24: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/24.jpg)
CRC Modeling
• A CRC model - index cards represent classes
24EECS 448 Software Engineering
Anything the class knows (attributes) or does (operations)
Classes required to provide info needed to
complete a responsibility
![Page 25: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/25.jpg)
Class:Description:
Responsibility: Collaborator:
Class:Description:
Responsibility: Collaborator:
Class:Description:
Responsibility: Collaborator:
Class: FloorPlanDescription:
Responsibility: Collaborator:
incorporates walls, doors and windowsshows position of video cameras
defines floor plan name/typemanages floor plan positioningscales floor plan for display
WallCamera
CRC Modeling
EECS 448 Software Engineering 25
![Page 26: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/26.jpg)
Classes• Entity classes• Extracted directly from the statement of the problem• Represent things to be stored or persist throughout the development
• Boundary classes • Create/display interface• Mange how to represent entity objects to users
• Controller classes• Create/update entity objects• Initiate boundary objects• Control communications• Validate data exchanged
26EECS 448 Software Engineering
![Page 27: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/27.jpg)
Responsibilities (1/3)
• System intelligence should be distributed across classes• Intelligence: what the system knows and what the system can do• How to distribute across classes?• Distributed more evenly to enhance maintainability: avoid extra long list
• Each responsibility should be stated as generally as possible• Responsibility reside high in the class hierarchy• Can be applied to subclasses
27EECS 448 Software Engineering
![Page 28: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/28.jpg)
Responsibilities (2/3)
• Information and the behavior related to a responsibility should reside within the same class• Achieves encapsulation
• Information about one thing should be localized with a single class, not distributed across multiple classes• Avoid spreading across classes• Encapsulation is good in testing and maintenance
28EECS 448 Software Engineering
![Page 29: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/29.jpg)
Responsibilities (3/3)
• Responsibilities should be shared among related classes, when appropriate• When some related objects need to exhibit the same behavior at
the same timee.g., Play, PlayerHead, PlayerBody classes in video game: update() and display()
29EECS 448 Software Engineering
![Page 30: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/30.jpg)
Collaborations
• A class may collaborate with other classes to fulfill responsibilities• If a class cannot fulfill every single responsibility itself, it must interact with
another class• Collaboration refers to identifying relationships between classes• is-part-of relationship
• Aggregation• has-knowledge-of relationship: one class must acquire information from
another class• Association
• depends-upon relationship: dependency other than the above two
30EECS 448 Software Engineering
![Page 31: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/31.jpg)
Relationships between Classes
31EECS 448 Software Engineering
Player
PlayerHead PlayerArms PlayerLegsPlayerBody
WallSegment Window Door
Wall
is used to buildis used to build
is used to build1..*
1 1 1
0..* 0..*
CameraDisplayWindow
{password}
<<access>>
composition association
dependency
![Page 32: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/32.jpg)
Class DiagramFloorPlan
typenameoutsideDimensionsdetermineType()positionFloorplan()scale()changColor()
Camera
typeIDlocationfieldViewpanAnglezoomSetting
determineType()translateLocation()displayID()displayView()displayZoom()
Is placed within
Wall
typewallDimensions
determineType()computeDimensions()
Is part of
WallSegment
typestartCoordinatesstopCoordinatesnextWallSegmentdetermineType()draw()
Is used to build
Window
typestartCoordinatesstopCoordinatesnextWindowdetermineType()draw()
Door
typestartCoordinatesstopCoordinatesnextDoordetermineType()draw()
Is used to build Is used to build
EECS 448 Software Engineering 32
![Page 33: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/33.jpg)
Validating a Class Diagram
• One of the most important, and often overlooked issues is how to validate a class diagram.
• Given a specification or a use-case, can you look at the class diagram and use features of it to manually “execute” the use case?
Coming up: Questions
![Page 34: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/34.jpg)
Reviewing a CRC Model
• Stakeholders review the CRC model once it is developed• All participants are given a subset of CRC index cards
• No reviewer should have two cards that collaborate• Organize all use-case scenarios into categories
• Review leader reads the use case• When it comes to an object, pass a token to the person holding the corresponding
class index card• Check the responsibility on this index card, find the collaborator• Pass the token to the person with the collaborator index card• Describe the responsibilities on the card• The entire group checks the responsibilities• If cannot accommodate the use case, make modifications
34EECS 448 Software Engineering
![Page 35: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/35.jpg)
• An object-oriented modeling language developed in 1997
• Models structure (static) and behavioral (dynamic) aspects of a system
• Semi-formal: UML 2.0 added much more formality
• Process-independent: can be used with a variety software
development process models
• Customizable and extensible
35EECS 448 Software Engineering
UML Class Modeling
![Page 36: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/36.jpg)
Abstraction Levels
• Three perspectives for class models• Analysis• Represents concepts in the domain• Drawn with no regard for implementation (language independent)
• Specification• Focus on interfaces not on how implementation is broken into classes
• Implementation• A blue-print for coding• Direct code implementation of each class in the diagram
36EECS 448 Software Engineering
![Page 37: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/37.jpg)
37EECS 448 Software Engineering
Student
{Joe, Sue, Mary, Frank, Tim, …}
Studentname
major
GPA
standing
interests
-- The set of students
known to the registration
system
Analysis:Student
name: String
major: String
GPA: real
standing: Scode
add(Course)
drop(Course)
-- Software representation of students;
support registration in courses
Specification
Student-major: String
-GPA: Real
-standing: String
+add(Course)
+drop(Course)
-- Handle a registration in
courses
CourseList
-- Display a dynamic list
courses
1
0..1
Implementation
Student Records Management System
![Page 38: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/38.jpg)
Classes in UML Diagrams
• An abstraction which describes a collection of objects sharing some commonalties• Syntax• Name: noun, singular
• centered, bold, first letter capitalized
• Attribute• left justified, lower cases
• Operations• Visibility
+ public- private# protected
38EECS 448 Software Engineering
![Page 39: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/39.jpg)
Attributes
• An attribute can be defined for individual objects or a class of objects• Static: if defined for a class, every object in the class has that attribute (place holder)
• An attribute relates an object to some other object
39EECS 448 Software Engineering
joe: Student
name: String = “Joe Jones”
joe: Student Joe Jones : Stringname
1
![Page 40: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/40.jpg)
Objects
• Object is an instance of a class
• Fundamental building blocks of object-oriented systems
• Instance name and class path are separated by a “:”
• Operation syntax:
name (params) : return type
• An instance may have some value
• Instance orderPaid of the Date class has
the value July 31, 2011 3:00 pm
40EECS 448 Software Engineering
joe: Student
major: String = “CS”
gpa: Real = 4.0
standing: String = “”
add(Class Section)
drop(Class Section)
![Page 41: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/41.jpg)
Type of Relationships in Class Diagrams
• Class diagrams show relationships between classes.
41EECS 448 Software Engineering
Relation
AssociationGeneralization Dependency
Aggregation
Binary Association N-ary Association
![Page 42: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/42.jpg)
Associations• An association is a structural relationship that specifies a connection
between classes• Classes A and B are associated if:• An object of class A sends a message to an object of B• An object of class A creates an instance of class B• An object of class A has an attribute of type B or collections of objects of type B• An object of class A receives a message with an argument that is an instance of
B (maybe…)• Depends whether it “uses” that argument
42EECS 448 Software Engineering
![Page 43: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/43.jpg)
Associations
• Associations• Links are instances of associations• Association names are typically verb phrases (in lower case)• The name should include an arrow indicating the direction in
which the name should be read• Often interaction diagrams are useful for modeling objects
43EECS 448 Software Engineering
![Page 44: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/44.jpg)
Associations
• A solid line connecting two classes
44EECS 448 Software Engineering
Student
Class Section
Course
Semester
Instructor
Department
takes>
is registered for>
teaches>
sponsors><wor
ks fo
r is instance of>
is held
during>
![Page 45: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/45.jpg)
N-ary Associations
• Associations can connect more than one class
45EECS 448 Software Engineering
Student Advisor
Major
![Page 46: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/46.jpg)
Multiplicity
• How many objects from two classes are linked?• An exact number: indicated by the number• A range: two dots between a pair of numbers• An arbitrary number: indicated by * symbol• (Rare) A comma-separated list of ranges
• e.g., 1 1..2 0..* 1..* * (same as 0..* )• Implementing associations depends on multiplicity
46EECS 448 Software Engineering
![Page 47: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/47.jpg)
Multiplicity
47EECS 448 Software Engineering
Student
Class Section
Course
Semester
Instructor
Department
takes>
is registered for>
teaches>
sponsors><wor
ks fo
r is instance of>
is held
during>
1..*1
1..*
1..*11
1..*
0..8
0..*
0..61..3
![Page 48: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/48.jpg)
Generalization
• Generalization is an association between classes• A subclass is connected to a superclass by an arrow
with a solid line with a hollow arrowhead.
• From an analysis perspective, it represents generalization/specialization:• Specialization is a subset of the generalization
48EECS 448 Software Engineering
Student
Person
Graduate Student
Generalization
Specialization
![Page 49: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/49.jpg)
Generalization
• Generalization represents implementation inheritance• You model “inheritance” early, but not implement it at the conceptual level
49EECS 448 Software Engineering
Studentmajor: StringGPA: Realstanding: String
add(Class Section)drop(Class Section)
Person
name: Stringaddress: String
changeAddress(new_address)
![Page 50: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/50.jpg)
Aggregation
• Aggregation: is a special kind of association that means “part of”• Aggregations should focus on a single type of composition (physical,
organization, etc.)
Coming up: Composition (very similar to aggregation)
1 1
*
4..*
1
1
1 1
1..3 1
0..9 1
Pizza Order
Slice
Crust
Sauce Serving
Cheese Serving
Topping Serving
![Page 51: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/51.jpg)
Composition
• Very similar to aggregation:• Think of composition as a stronger form of aggregation• Composition means something is a part of the whole, but cannot
survive on it’s own
Coming up: Using a class diagram
BuildingRoom
![Page 52: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/52.jpg)
Dependencies• A using relationship• A change in the specification of one class may affect the other• But not necessarily the reverse
Coming up: Dependencies
Student
add(Course)drop(Course)
Prerequisite
![Page 53: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/53.jpg)
Properties/Stereotypes
• Extends the “vocabulary” of UML• Syntax: <<property/stereotype>>
• UML predefines many:• Classes: <<interface>>, <<type>>, <<implementationClass>>,
<<enumeration>>, <<thread>>• Constraints: <<precondition>>• Dependencies: <<friend>>, <<use>>• Comments: <<requirement>>, <<responsibility>>• Packages: <<system>>, <<subsystem>> (maybe classes, too)• Or, create your own if needed
53EECS 448 Software Engineering
![Page 54: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/54.jpg)
Analysis Packages
Environment+Tree+Landscape+Road+Wall+Bridge+Building+VisualEffect+Scene
RulesOfTheGame+RulesOfMovement+ConstraintsOnAction
Characters+Player+Protagonist+Antagonist+SupportingRole
Package name
+ public
– hidden
# accessible only to a given package
EECS 448 Software Engineering 54
![Page 55: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/55.jpg)
Revisit Class Diagrams
• Class diagrams are like the paragraphs of a technical paper• Each diagram should focus on a specific topic• A diagram provides supporting details for the main concept that is
trying to communicate• The level of the abstraction used in the diagrams should be consistent
• Together, all the diagrams for a system comprise a “model” of that system
Coming up: Class Diagrams
![Page 56: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/56.jpg)
Class Diagrams
• Pitfalls of Class Diagrams• Using class diagrams alone can cause developers to focus
too much on structure and ignore behavior• Using the wrong (or a mixed) perspective can lead to
misunderstanding• Using the wrong level of abstraction can be confusing to the
target audience• Using mixed levels of abstraction can reduce the usefulness
of diagramComing up: Multiplicity Constraints
![Page 57: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/57.jpg)
Example
• University Courses• Some instructors are professors, while others have job title adjunct• Departments offer many courses, but a course may be offered by
more than 1 department• Courses are taught by instructors, who may teach up to three courses• Instructors are assigned to one (or more) departments• One instructor also serves a department chair
57EECS 448 Software Engineering
![Page 58: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/58.jpg)
Class Diagram
58EECS 448 Software Engineering
![Page 59: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/59.jpg)
Another Example
• Problem Reporting Tool: a CASE tool for storing and tracking problem reports• Employees are assigned to a project• A manager may add new artifacts and assign problem reports to developers• Each report contains a problem description and a status• Each problem can be assigned to someone• Problem reports are made in one of the “artifacts” of a project
59EECS 448 Software Engineering
![Page 60: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/60.jpg)
Class Diagram
60EECS 448 Software Engineering
Employee
+name : string
Manager Developer
Project
+name : string
Artifact
+name : string+status : enum
Problem Report
History Entry
-when : Date-whatDone : string
Code Bug Report
1
0..n
Responsible For
0..*
1
1
0..n
About
0..n
1
History Log
1..*
0..*Assigned To
1 0..*Managed By
![Page 61: Requirements Modeling: Class-Based](https://reader033.vdocuments.us/reader033/viewer/2022061101/629b86a2af110473e84b65ba/html5/thumbnails/61.jpg)
References
• Prof. Fengjun Li’s EECS 448 Fall 2015 slides
• This slide set has been extracted and updated from the slidesdesigned to accompany Software Engineering: A Practitioner’sApproach, 8/e (McGraw-Hill 2014) by Roger Pressman
61