![Page 1: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/1.jpg)
1
1
Software EngineeringG22.2440-001
Session 7 - Main ThemeFrom Analysis and Design to Software Architectures
(Part II)
Dr. Jean-Claude Franchitti
New York UniversityComputer Science Department
Courant Institute of Mathematical Sciences
2
Agenda
• Review• OOAD Using UML
• Use Cases Review• Use Case Design• GRASP Patterns• System Design• UML and OOAD Summarized• UML to Java Mapping• Sample OCL Problem
• Introduction to Design and Architectural Patterns• Micro/Macro Architecture• Design and Architectural Patterns• Summary
• Individual Assignment #4 - ongoing• Project (Part 2) - ongoing
![Page 2: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/2.jpg)
2
3
Summary of Previous Session
• Towards Agile Enterprise Architecture Models• Building an Object Model Using UML• Architectural Analysis• Design Patterns• Architectural Patterns• Architecture Design Methodology
• Achieving Optimum-Quality Results• Selecting Kits and Frameworks• Using Open Source vs. Commercial Infrastructures
• Summary• Individual Assignment #4• Project (Part 2)
4
Part I
ReviewSee: Sub-Topic 6 Presentation on
“Introduction to OOAD Modeling and UML”and
Sub-Topic 7 Presentation on“Use Case Modeling”
![Page 3: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/3.jpg)
3
5
Part II
OOAD Using UML
6
UML Notation Baseline(review)
DeliveryStaticPackageDeliveryDynamicDeployment
DesignDynamicCollaborationDesignDynamicSequenceDesignDynamicEvent Trace (Interaction)
AnalysisDynamicState-TransitionAnalysisDynamic**ActivityAnalysisStaticClassAnalysisStatic*Use Case
PhaseTypeDiagram Name
*Static describes structural system properties**Dynamic describes behavioral system properties.
![Page 4: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/4.jpg)
4
7
What can you Model with UML?UML defines twelve types of diagrams, divided into three categories• Four diagram types represent static application structure:
• Class Diagram• Object Diagram• Component Diagram• Deployment Diagram
• Five represent different aspects of dynamic behavior• Use Case Diagram• Sequence Diagram• Activity Diagram• Collaboration Diagram• Statechart Diagram
• Three represent ways you can organize and manage your application modules
• Packages• Subsystems• Models
Source: http://www.omg.org/gettingstarted/what_is_uml.htm
8
Part II.1
Use Cases Review
![Page 5: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/5.jpg)
5
9
Use Cases: Scenario Based Requirements Modeling
• Recommended: UML distilled...
10
Use Cases
Use case • specifies the behavior of a system • sequence of actions to yield an observable result
of value to an actor• Capture the intended behavior (the what) of the
system omitting the implementation of the behavior (the how)
• customer requirements/ early analysis
![Page 6: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/6.jpg)
6
11
What is a Use Case?
• Description of a sequence of actions, including variants (specifies desired behavior)
• Represents a functional requirement on the system• Use case involves interaction of actors and the
system
Market Analysis
Financial Officer
12
Use Cases: Terms and Concepts
• Unique name• Sequence of actions (event flows)
– textual (informal, formal, semi formal)Main flow of events: The use case starts when the system
prompts the Customer for a PIN number. The Customer can now enter a pin number...
– interaction diagrams
![Page 7: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/7.jpg)
7
13
Use Cases: Summary
• A use case encodes a typical user interaction with the system. In particular, it:– captures some user-visible function.– achieves some concrete goal for the user.
• A complete set of use cases largely defines the requirements for your system: everything the user can see, and would like to do.
• The granularity of your use cases determines the number of them (for you system). A clear design depends on showing the right level of detail.
• A use case maps actors to functions. The actors need not be people.
14
Actors
• Role that a user plays with respect to the system
• Actors carry out use cases– look for actors, then their use cases
• Actors do not need to be humans!• Actors can get value from the use case or
participate in it
![Page 8: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/8.jpg)
8
15
Actors
• Actors can be specialized
• connected to use cases only by association• association = communication relationship (each
one sending, or receiving messages)
Officer
Financial Officer
16
Use Case Description
• Generic, step-by-step written description of a use case’s event flow
• Includes interactions between the actor(s) and a use case
• May contain extension points• Clear, precise, short descriptions
![Page 9: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/9.jpg)
9
17
Example Use Case Description
• Capture deal1. Enter the user name & bank account2. Check that they are valid3. Enter number of shares to buy & share ID4. Determine price5. Check limit6. Send order to NYSE7. Store confirmation number
18
Organizing Use Cases
• Generalization• Use/Include• Extend
![Page 10: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/10.jpg)
10
19
Generalization Relationship
• child use case inherits behavior and meaning of the parent use case
• child may add or override the parent’s behavior
• child may substitute any place the parent appears
Validate user
Check password Retinal scan
20
Extends Relationship
• Allows to model the part of a use case the user may see as optional
• Allows to model conditional subflows• Allows to insert subflows at a certain
point, governed by actor interaction
• represented by an extend dependency• extension points (in textual event flows)
Limit exceeded
Capture deal
<<extend>>
![Page 11: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/11.jpg)
11
21
Extends Relationship
• Allows to model the part of a use case the user may see as optional
• Allows to model conditional subflows• Allows to insert subflows at a certain point,
governed by actor interactionCapture the base use caseFor every step ask
what could go wronghow might this work out differently
Plot every variation as an extension of the use case
Limit exceeded
Capture deal
<<extends>>
22
Example: Extension Points
• Capture deal1. Enter the user name & bank account2. Check that they are validextension point: reenter data in case they are invalid3. Enter number of shares to buy & share ID4. Determine price5. Check limit6. Send order to NYSE7. Store confirmation number
![Page 12: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/12.jpg)
12
23
Uses/Includes Relationship
• Used to avoid describingthe same flow of events several times, by putting the common behavior in a use case of its own
• Avoids copy-and-paste of parts of use case descriptions
ValuationAnalyze risks
<<uses>>
Price details
<<uses>
24
Comparing Extends/Uses
• Different intent– extends
• to distinguish variants• set of actors perform use case and all extensions• actor is linked to “base” case
– uses/includes• to extract common behavior• often no actor associated with the common use case• different actors for “caller” cases possible
![Page 13: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/13.jpg)
13
25
A Use Case Diagram
Valuation
Limit exceeded
Analyze risks
<<uses>>
TraderPrice details
<<uses>
Capture deal
<<extends>>
Sales system
26
Use Case Diagrams (Functional)
Diagram: UML Distilled, Martin Fowler, Kendall Scott, 1997, Addison-Wesley, Copyright 1997, Addison-Wesley
![Page 14: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/14.jpg)
14
27
Properties of Use Cases
• Granularity: fine or course• Achieve a discrete goal• Use cases describe externally required
functionality• Often: Capture user-visible function
28
When and How
• Requirements capture - first thing to do• Use case: Every discrete thing your
customer wants to do with the system– give it a name– describe it shortly (some paragraphs)– add details later
![Page 15: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/15.jpg)
15
29
Use Case Examples, 1(High-level use case for powerpoint.)
30
About the Last Example...
• Although this is a valid use case for powerpoint, and it completely captures user interaction with powerpoint, it’s too vague to be useful.
![Page 16: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/16.jpg)
16
31
Use Case Examples, 2(Finer-grained use cases for powerpoint.)
32
About the Last Example...
• The last example gives a more useful view of powerpoint (or any similar application).
• The cases are vague, but they focus your attention the key features, and would help in developing a more detailed requirements specification.
• It still doesn’t give enough information to characterize powerpoint, which could be specified with tens or hundreds of use cases (though doing so might not be very useful either).
![Page 17: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/17.jpg)
17
33
Use Case Examples, 3(Relationships in a news web site.)
34
About the Last Example...
• The last is more complicated and realistic use case diagram. It captures several key use cases for the system.
• Note the multiple actors. In particular, ‘AP wire’ is an actor, with an important interaction with the system, but is not a person (or even a computer system, necessarily).
• The notes between << >> marks are stereotypes:identifiers added to make the diagram more informative. Here they differentiate between different roles (i.e., different meanings of an arrow in this diagram).
![Page 18: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/18.jpg)
18
35
Use Case Diagrams
36
About the Next Slide…
• The next slide shows a full use case diagram.• The stick figures denote actors, and the ovals are use cases (a function
or behavior or interface your software provides).• The arrows indicate ‘use’ or dependency. For example, the “Student”
uses the function “Register for Courses”, which in turn uses theexternal “Catalog System”.
• The <<uses>> tokens attached to some of the associations (arrows) are stereotypes, an indication of what the association means. In this diagram, <<uses>> indicates that the association means a direct software link, i.e., that the function “Register for Courses” will directly use the function “Login”. This is different than the unmarked arrows, which indicate “use” in the vague sense of manipulating or interacting.
![Page 19: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/19.jpg)
19
37
Use Case Relationships
38
About the Next Slide…
• The next slide shows how documentation (notes, etc) can be added to a particular element.
• Here, they’re adding the documentation via the Specification dialogue.
![Page 20: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/20.jpg)
20
39
Brief Description -- Register for Courses
40
More ExamplesUse Case Diagrams
• Means of capturing requirements• Document interactions between user(s) and
the system– User (actor) is not part of the system itself– But an actor can be another system
• An individual use case represents a task to be done with support from the system (thus it is a ‘coherent unit of functionality’)
![Page 21: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/21.jpg)
21
41
Simple Use Case Diagram
Reserve book
Borrow book
Return book
42
Use Case Diagram with Multiple Actors
![Page 22: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/22.jpg)
22
43
Use Cases
• Are actually defined as text, including descriptions of all of the normal and exception behavior expected
• Do not reveal the structure of the system• Collectively define the boundaries of the
system to be implemented• Provide the basis for defining development
iterations
44
Example Use Case Diagram (Advanced Features)
![Page 23: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/23.jpg)
23
45
Practical (Agile) UML
• You don't typically use all the diagrams– You'll choose between them based on preference and
particular situation
• You typically use many diagrams– A single use case may not capture all scenarios– If you are going to use statecharts, there are probably lots of
objects with states– Each sequence/collaboration diagram only shows one
interaction
46
Example: Student Registration System
• Not going to do all the diagrams– Not all types, not even all that completely
specify the system• But this is an application you know, so the
examples may help make sense
![Page 24: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/24.jpg)
24
47
Student Registration Class Diagram
*
prereqs
0..30..30..3prereqs
0..30..30..3
Course
namenumberdepartmentcreditHoursprerequisites
1
*****1
CourseGrade
coursegradetermEnrolled
Transcript
courseGrades
gradeForCourse:takenCourse:
1 ***
1
******
1..3 ******
*
111111
Department
coursesrequiredCourses
111Student
transcriptmajor
enrollInClass:gradeInCourse:takenCourse:
Section
coursedaysAndTimeroster
addStudentremoveStudent *
1* sections
Registrar
courses
getSectionsFor:enrollInSection:
dropFromSection:
scheduleregistrar
1*
1
48
Partial Use Case Diagram
Withdrawfrom a Course
Apply forAdmission
Student
Enroll inthe University
Enroll ina Course
Admissions
![Page 25: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/25.jpg)
25
49
States of a Student
EnrollInClass ( Add a Transcript )
EnrolledApply [ Must be accepted first ]
Graduate [ All courses must be completed ]
AddCourseRegisteredWithdraw
50
Sequence Diagram: Registering for Course
theRegistrar aSection theTranscriptaStudent
state of prereqhave prereq
enrolled
enrollInSection:
return sections
getSectionsFor:
addStudent:
enrolled
takenCourse: prerequisitetakenCourse: prerequisite
![Page 26: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/26.jpg)
26
51
Process to Representations
• OOA– CRC Cards (but they’re not officially UML)– Use Cases
• OOD– Just about all of the rest– But variations—some detail is later
• OOP– Can actually go UML->code with some tools!
52
Summary
• This lesson only describes how to write UML
• It does not answer the big question on how to come up with the model !
• A System Sequence Diagram is an excellent first cut
• Both sets of artifacts are used in the sequence and collaborations diagrams
![Page 27: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/27.jpg)
27
53
Part II.2
Use Case Design
See: Sub-Topic 1 Presentation on “UML and the SDLC”
54
Objectives: Use-Case Design
• Understand the purpose of Use-Case Design and when in the lifecycle it is performed
• Verify that there is consistency in the use-case implementation
• Refine the use-case realizations from Use-Case Analysis using defined design model elements
![Page 28: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/28.jpg)
28
55
Use-Case Design in Context
Use-CaseDesign Designer
56
Use-Case Design Overview
SupplementarySpecifications
Use-CaseDesignUse-Case Realization Use-Case Realization
(Refined)
Design Subsystems and Interfaces
Design Classesuse-case
![Page 29: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/29.jpg)
29
57
Use-Case Design Steps
• Describe interaction between design objects
• Simplify sequence diagrams using subsystems
• Describe persistence related behavior
• Refine the flow of events description
• Unify classes and subsystems
58
Use-Case Design Steps
• Describe interaction between design objects• Simplify sequence diagrams using
subsystems• Describe persistence related behavior• Refine the flow of events description• Unify classes and subsystems
![Page 30: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/30.jpg)
30
59
Review: Use-Case Realization
Class Diagrams
Sequence Diagrams
use-case
Use-Case Model Design Model
use-case Use-Case Realization
Collaboration Diagrams
60
Analysis Classes Design Elements
Many-to-Many Mapping
Review: From Analysis Classes to Design Elements
<<boundary>>
<<control>>
<<entity>>
<<boundary>>
![Page 31: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/31.jpg)
31
61Sequence Diagrams Class Diagrams
Use-Case Realization Refinement
• Identify participating objects• Allocate responsibilities amongst objects• Model messages between objects• Describe processing resulting from messages• Model associated class relationships
62
• Identify each object that participates in the flow of the use-case
• Represent each participating object in a sequence diagram
• Incrementally incorporate applicable architectural mechanisms
Use-Case Realization Refinement Steps
![Page 32: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/32.jpg)
32
63
Representing Subsystems on a Sequence Diagram
• Interfaces– Represents any model element that realizes the interface– No message should be drawn from the interface
• Proxy class– Represent a specific subsystem– Messages can be drawn from the proxy
Object A Interface Object B
1: Message 12: Message 2
Object A Proxy Object B
1: Message 12: Message 2X
Invalid message Valid message
64
All other analysis classes mapped directly to design classes
Analysis Classes Design Elements
Example: Incorporating Subsystem Interfaces
Bi llingSystem
//submit bill()
<<boundary>> Billing System<<subsystem>>
IBillingSystem
submitBill(forTuition : Double, forStudent : Student)
CourseCatalogSystem
//get course offerings()
<<boundary>>Course Catalog
System
<<subsystem>>
ICourseCatalogSystem
getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingListinitialize()
![Page 33: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/33.jpg)
33
65
Example: Incorporating Subsystem Interfaces (Before)Analysis class that is to be replaced with an interface
: Student: RegisterForCoursesForm : RegistrationController : Schedule : Student: CourseCatalogSystem
A list of the available course offerings for this semester are displayed
Student wishes to create a new schedule
1. // create schedule( )
1.2. // display course offerings( )
1.1. // get course offerings( )
1.1.1. // get course offerings(forSemester)
1.3. // display blank schedule( )
2. // select 4 primary and 2 alternate offerings( )
2.1. // create schedule with offerings( ) 2.1.1. // create with offerings( )
A blank schedule is displayed for the students to select offerings
2.1.2. // add schedule(Schedule)
At this point, the Submit Schedule subflow is executed
66
Example: Incorporating Subsystem Interfaces (After)Replaced with subsystem interface
: Student: RegisterFor
CoursesForm: Registration
Controller: Schedule : Student: ICourseCatalog
System
A list of the available course offerings for this semester are displayed
Student wishes to create a new schedule
1: // create schedule( )
1.2: // display course offerings( )
1.1: // get course offerings( )
2.1.2: // add schedule(Schedule)
1.1.1: getCourseOfferings(Semester)
1.3: // display blank schedule( )
At this, point the Submit Schedule subflow is executed.
2: // select 4 primary and 2 alternate offerings( )
2.1: // create schedule with offerings( )2.1.1: // create with offerings( )
A blank schedule is displayed for the students to select offerings
![Page 34: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/34.jpg)
34
67
Example: Incorporating Subsystem Interfaces (VOPC)
ICourseCatalogSystem
getCourseOfferings()initialize()
(from External System Interfaces)
<<Interface>>
RegisterForCoursesForm
// submit schedule()// display course offerings()// display schedule()// save schedule()// create schedule()// select 4 primary and 2 alternate offerings()// display blank schedule()
(from Registration)
<<boundary>>
Student.
- name- address- studentID : int
// addSchedule()// getSchedule()// hasPrerequisites()// passed()
(from University Artifacts)
<<entity>>
RegistrationController
// submit schedule()// save schedule()// create schedule with offerings()// getCourseOfferings()
(from Registration)
<<control>>
0..1
0..1registrant
1 1 Schedule
semester
// submit()// save()// any conflicts?()// new()
(from University Artifacts)
<<entity>>
0..*
1
0..1
0..1
currentSchedule
CourseOffering
numberstartTimeendTimedays
// addStudent()// removeStudent()// new()// setData()
(from University Artifacts)
<<entity>>
0..*
0..4primaryCourses
0..*
0..2alternateCourses
0..*1
Subsystem interface
68
Analysis Class Analysis Mechanism(s)
Student
CourseOfferingCourse
RegistrationController
Persistency, Security
Persistency, Legacy InterfacePersistency, Legacy Interface
Distribution
Incorporating Architectural Mechanisms: Security
• Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Schedule Persistency, Security
![Page 35: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/35.jpg)
35
69
Analysis Class Analysis Mechanism(s)
Student
CourseOfferingCourse
RegistrationController
Persistency, Security
Persistency, Legacy InterfacePersistency, Legacy Interface
Distribution
Incorporating Architectural Mechanisms: Distribution
• Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Schedule Persistency, Security
70(continued)
Review: Incorporating RMI: Steps
• Provide access to RMI support classes (e.g., Remote and Serializable interfaces, Naming Service)– java.rmi and java.io package in Middleware
layer• For each class to be distributed:
– Controllers to be distributed are in Application layer
– Need dependency from Application layer to Middleware layer to access java packages
– Define interface for class that realizes Remote– Have class inherit from UnicastRemoteObject
√
√
√
![Page 36: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/36.jpg)
36
71
• Have classes for data passed to distributed objects realize the Serializable interface– Core data types are in Business Services layer– Need dependency from Business Services layer
to Middleware layer to get access to java.rmi– Add the realization relationships
• Run pre-processor
Out of scope
Review: Incorporating RMI: Steps (contd)
√√
72
Review: Incorporating RMI: Steps
• Have distributed class clients lookup the remote objects using the Naming service– Most Distributed Class Clients are Forms– Forms are in Application layer– Need dependency from Application layer to
Middleware layer to get access to java.rmi– Add relationship from Distributed Class Clients
to Naming Service• Create/update interaction diagrams with
distribution processing (optional)
√
√√
![Page 37: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/37.jpg)
37
73
Example: Incorporating RMI
UnicastRemoteObject(from Server)
Naming.
lookup()
(from java.rmi)
Remote
(from java.rmi)
Serializable
(from java.io)
Schedule(from University Artifacts)
<<entity>>
Student.(from University Artifacts)
<<entity>>
IRegistrationController
getCurrentSchedule(forStudent : Student, forSemester : Semester) : ScheduledeleteCurrentSchedule()submitSchedule()saveSchedule()getCourseOfferings() : CourseOfferingListnew(forStudent : string)getStudent(withID : string) : Student
(from Registration)
<<Interface>>
RegisterForCoursesForm(from Registration)
<<boundary>>
RegistrationController(from Registration)
<<control>> currentSchedule
0..1
0..*
1
registrant
0..1
11
0..1
0..1Distributed Class
Distributed Class Client
Passed Class
CourseOfferingList.(from University Artifacts)
Passed Class
74
Example: Incorporating RMI (contd)
<<layer>>Business Services
<<layer>>Middleware
<<layer>>Application
SampleApplication
University Artifacts(from Business Services)
Middleware<<layer>>
Application<<layer>>
Business Services
<<layer>>
java.rmi
<<interface>>remote
(from java.rmi)
Naming(from java.rmi)
UnicastRemoteObject
(from Server)
Server<<interface>>Serializable(from java.io)
Java.io
![Page 38: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/38.jpg)
38
75
Example: Incorporating RMI (contd)Added to support distribution
All calls to the distributed class interface areforwarded to the remote instance.
RegisterForCoursesForm : Naming. :IRegistrationController
Lookup remote object by specifying it's URL1: lookup(string)
2: doSomething
76
Use-Case Design Steps
Describe interaction between design objectsSimplify sequence diagrams using subsystemsDescribe persistence related behaviorRefine the flow of events descriptionUnify classes and subsystems
![Page 39: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/39.jpg)
39
77
Raises the level of abstraction
Encapsulating Subsystem Interactions
• Interactions can be described at several levels• Subsystem interactions can be described in their
own interaction diagrams
78
When to Encapsulate Sub-Flows in a Subsystem
Encapsulate a Sub-flow when it:– occurs in multiple use-case realizations– has reuse potential– is complex and easily encapsulated– is responsibility of one person/team– produces a well-defined result– is encapsulated within a single Implementation
Model component
![Page 40: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/40.jpg)
40
79
InterfaceA
op1()
<<subsystem>>MySubsystem
Op1()
:InterfaceA
Guidelines: Encapsulating Subsystem Interactions
• Subsystems should be represented by their interfaces on interaction diagrams
• Messages to subsystems are modeled as messages to the subsystem interface
• Messages to subsystems correspond to operations of the subsystem interface
• Interactions within subsystems modeled in Subsystem Design
80
Advantages of Encapsulating Subsystem Interactions
Use-case realizations: – Are less cluttered– Can be created before the internal designs of
subsystems are created (parallel development)– Are more generic and easier to change
(subsystems can be substituted)
![Page 41: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/41.jpg)
41
81
Use subsystem interfaces as synchronization points
Parallel Subsystem Development
• Concentrate on requirements that affect subsystem interfaces
• Outline required interfaces• Model messages that cross subsystem boundaries • Draw interaction diagrams in terms of subsystem
interfaces for each use-case • Refine the interfaces needed to provide messages• Develop each subsystem in parallel
82
Use-Case Design Steps
Describe interaction between design objectsSimplify sequence diagrams using subsystemsDescribe persistence related behaviorRefine the flow of events descriptionUnify classes and subsystems
![Page 42: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/42.jpg)
42
83
Use-Case Design Steps: Describe Persistence-related Behavior
• Describe Persistence-related Behavior – Modeling Transactions – Writing Persistent Objects– Reading Persistent Objects– Deleting Persistent Objects
84
Modeling Transactions• What is a Transaction?
– Atomic operation invocations– “All or nothing”– Provide consistency
• Modeling Options– Textually (scripts)– Explicit messages
• Error conditions– Rollback– Failure modes– May require separate interaction diagrams
![Page 43: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/43.jpg)
43
85
Analysis Class Analysis Mechanism(s)
Student
CourseOfferingCourse
RegistrationController
Persistency, Security
Persistency, Legacy InterfacePersistency, Legacy Interface
Distribution
Incorporating the Architectural Mechanisms: Persistency
• Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Schedule Persistency, Security
Legacy Persistency (RDBMS ) deferred to Subsystem Design
OODBMS Persistency
RDBMS Persistency
86
Use-Case Design Steps
Describe interaction between design objectsSimplify sequence diagrams using subsystemsDescribe persistence related behaviorRefine the flow of events descriptionUnify classes and subsystems
![Page 44: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/44.jpg)
44
87
Detailed Flow of Events Description Options
• Annotate the interaction diagrams
: Actor1 : ClassA : ClassB
1: Do Something
2: Do Something MoreScripts can be used to describe the details surrounding these messages.
Notes can include more information about a particular diagram element
Script
Note
88
Use-Case Design Steps
Describe interaction between design objectsSimplify sequence diagrams using subsystemsDescribe persistence related behaviorRefine the flow of events descriptionUnify classes and subsystems
![Page 45: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/45.jpg)
45
89
• Model element names should describe their function• Merge similar model elements• Use inheritance to abstract model elements• Keep model elements and flows of events consistent
Design Model Unification Considerations
90
Checkpoints: Use-Case Design
• Is package/subsystem partitioning logical and consistent?
• Are the names of the packages/subsystems descriptive?
• Do the public package classes and subsystem interfaces provide a single, logically consistent set of services?
• Do the package/subsystem dependencies correspond to the relationships between the contained classes?
• Do the classes contained in a package belong there according to the criteria for the package division?
• Are there classes or collaborations of classes which can be separated into an independent package/subsystem?
![Page 46: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/46.jpg)
46
91
Checkpoints: Use-Case Design• Have all the main and/or sub-flows for
this iteration been handled?• Has all behavior been distributed
among the participating design elements?
• Has behavior been distributed to the right design elements?
• If there are several interaction diagrams for the use-case realization, is it easy to understand which collaboration diagrams relate to which flow of events?
92
Review: Use-Case Design
• What is the purpose of Use-Case Design?• What is meant by encapsulating subsystem
interactions? Why is it a good thing to do?
![Page 47: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/47.jpg)
47
93
(continued)
Exercise: Use-Case Design
• Given the following:– Analysis use-case realizations
(VOPCs and interaction diagrams)
– The analysis-class-to-design-element map
– The analysis-class-to-analysis-mechanism map
– Analysis-to-design-mechanism map
– Patterns of use for the architectural mechanisms
94
(continued)
Exercise: Use-Case Design (cont.)
• Identify the following:– The design elements that replaced the
analysis classes in the analysis use-case realizations
– The architectural mechanisms that affect the use-case realizations
– The design element collaborations needed to implement the use-case
– The relationships between the design elements needed to support the collaborations
![Page 48: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/48.jpg)
48
95
Exercise: Use-Case Design
• Produce the following:– Design use-case realization
• Interaction diagram(s) per use-case flow of events that describes the design element collaborations required to implement the use-case
• Class diagram (VOPC) that includes the design elements that must collaborate to perform the use-case, and their relationships
(continued)
96
Exercise: Review
Compare your Use-Case Realizations
Have all the main and/or sub-flows for this iteration been handled?Has all behavior been distributed among the participating design elements?Has behavior been distributed to the right design elements?Are there any messages coming from the interfaces?
![Page 49: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/49.jpg)
49
97
Part II.3
Grasp Patterns
98
GRASP Patterns I
• What are Patterns• The Five GRASP Patterns
![Page 50: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/50.jpg)
50
99
What are Patterns
• Pattern - Principles and idiomatic solutions codified in a structured format describing a problem and a solution
• Or• A named problem/solution pair that can be
applied in new contexts
100
What are Patterns
• It is advice from previous designers to help designers in new situations
• There are many books on the subject• The best of all the books Design Patterns
by Erich Gamma which covers 23 patterns
![Page 51: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/51.jpg)
51
101
What are Patterns
Some definitions• Coupling - How strongly one class has
knowledge of another class• It is a measure of how related one class is to
another• Can you guess it is best for classes to be
independent. Why ?
102
What are Patterns
Some definitions• Cohesion - How strongly related the
responsibilities are• It is a measure of how related all the
attributes and behavior in a class are• Can you guess it is best attributes and
behavior in classes to be related. Why ?
![Page 52: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/52.jpg)
52
103
What are Patterns
Some definitions• Responsibilities - An obligation of a class• Note a responsibility is really a behavior the
other classes depend on• Thus it must be a responsible behavior• Thus many authors refer to behaviors as
responsibilities as they are of little value otherwise. Why ?
104
What are Patterns
• GRASP– General Responsibility Assignment Software
Patterns
![Page 53: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/53.jpg)
53
105
The Five GRASP Patterns
• There first five GRASP Patterns are– Expert– Creator– Low Coupling– High Cohesion– Controller
106
An Example
POST Application
Customer
Buy Items
Cashier Manager
![Page 54: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/54.jpg)
54
107
The GRASP Pattern Expert
• Any responsibility must be accomplished by the class that has or will have the data
• This means a class must populate all of its attributes
• It also must trigger the creation of all things that it contains
108
The GRASP Pattern Expert
• The conceptual diagram becomes important because it shows the attributes of each concept which is a potential class
• Also an expert should be responsible to make calculated values that are required by the class
![Page 55: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/55.jpg)
55
109
The GRASP Pattern Expert
Computing calculated values:• Sale knows how to total itself• Sales Line Item knows how to compute the
extended value of price times quantity
110
The GRASP Pattern Creator
• Each object-oriented language has a message called new that is sent to the class
• Thus the class must create its own objects• In UML this message is called ‘create’• It was felt the using ‘new’ would show a
bias to a particular object-oriented language
![Page 56: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/56.jpg)
56
111
The GRASP Pattern Creator
Clarification:• An expert is responsible to create its
attributes• But each attribute is itself a class• This is accomplished by the expert sending
a message to the class of the attribute• The attribute’s class knows how to create
itself
112
The GRASP Pattern Low Coupling
• Assign a responsibility so that the coupling remains low
• Recall coupling is how strongly one class has knowledge of another class
• The best example of this is not to have POST (buy-item use case) talking to every class
• POST (buy-item use case) should not have knowledge of any more classes than its has to
![Page 57: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/57.jpg)
57
113
The GRASP Pattern High Cohesion
• Assign a responsibility so that all the responsibilities in a class are related
• Recall cohesion is how strongly related the responsibilities are
• Best example is to not use POST (buy-item use case) to create payment
• Sale has all the similar responsibilities that create its attributes
114
The GRASP Pattern Controller
• Every business system should have a controller
• A controller is class whose job it is to coordinate the system events
• It sees to it the messages are sent to the correct expert in the model
• The most common one is a Use Case controller which we will use
![Page 58: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/58.jpg)
58
115
The GRASP Pattern Controller
• The reason to have a controller is to separate the business model called domain objects from the visual logic called view objects
• This is often called a MVC (Model View Controller) separation
116
The GRASP Pattern Controller
• Advantage - is that the changes to the model (domain) do not affect the GUI (view) objects
• Advantage - is that the changes to the GUI (view) do not affect the model (domain) objects
• It provides a buffer between the visual and the business logic
![Page 59: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/59.jpg)
59
117
The GRASP Pattern Controller
• Since the decision to have a controller is decided, the real question is choosing which concept is to be the controller class
• This is relatively easy as the concept that processes the system events is the logical choice
• In the Buy Item use case, it is the POST
118
The GRASP Pattern Controller
• Other choices are Store and Cashier• POST was chosen over store as it is
conceptually closer to the system event• POST was chosen over Cashier as cashier is
really an actor the runs the POST• Thus POST is the logical choice
![Page 60: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/60.jpg)
60
119
Summary
• There a five initial GRASP Patterns that complement each other
• MVC (Model View Controller) separation builds systems that are maintainable
• This is still an art as it is not yet a science• A good idea is to practice by creating this
example from scratch
120
Part II.4
System Design
![Page 61: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/61.jpg)
61
121
Designing the System
• Collecting Artifacts• Using Patterns
122
Collecting Artifacts
• One needs the following deliverables from previous steps
• They are:– Use Case– Conceptual Diagram– System Sequence Diagram– Contracts
![Page 62: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/62.jpg)
62
123
Using Patterns
• The following patterns are used:• First a controller must be chosen• Second all creator objects must be identified• Third all experts must be identified• Fourth adjustments are made to reduce
coupling
124
Example
• It is easiest to build a sequence diagram• This is because the System Sequence
Diagram is already completed• We will break this up into five steps
![Page 63: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/63.jpg)
63
125
Example
• Step One - Choosing a controller• Since the use case works with the POST the
POST makes the most sense• It serves as a bridge between the GUI and
the Model• Then change the class System to POST in
the System Sequence Diagram
126
Example
• Step Two - Look for containment's in the Conceptual diagram that suggests that the parent will create the child
• Thus the creator pattern will be used• The containment's are
– POST contains (creates) Sale– Sale contains (creates) SaleLineItem– Sale contains (creates) Payment
![Page 64: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/64.jpg)
64
127
Example
• Step Three - Look for attributes that need to modified or calculated by their experts
• Thus the expert pattern will be used• The experts are
– Sale knows how to set the attribute isComplete to true - becomeComplete ( )
– Sale knows how to compute the total - total ( )– SaleLineItem knows how to compute the
subtotal - subtotal ( )
128
Example
• Step Four - Look for ways to lower coupling thus the Low Coupling pattern will be used
• The concerns are – To make SalesLineItem one must send a
message to Sale to contain it and a Message to to SalesLineItem to create it
– Better to send one message to Sale and have it create it - makeLineItem (productSpecification, quantity)
![Page 65: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/65.jpg)
65
129
Example
• Step Four Continued - Look for ways to lower coupling
• The concerns are – To make Payment one must send a message to
Sale to contain it and a Message to Payment to create it
– Better to send one message to Sale and have it create it - makePayment (amount)
130
Example
• Step Five - Look for problems• A concern is
– To make SalesLineItem POST must send a message to Sale to create it
– But it needs productSpecification which POST does not know
– Thus POST must send a message to the expert ProductCatalog to get the information -getProductSpecification (upc)
![Page 66: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/66.jpg)
66
131
Example
• Step Five Continued - Look for problems• Another concern is
– To place the sale in the sales ledger someone must do it
– The expert (who has the information) is POST– POST must send a message to SalesLedger to
which will know how to add it to itself -addSale(sale)
132
Summary
• Patterns help us with the design• All previous work is used
– Use Case – Conceptual Diagram– System Sequence Diagram– Contracts
![Page 67: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/67.jpg)
67
133
Part II.5
UML and OOAD Summarized
See: Sub-Topic 2 Presentation on “UML Review”
134
Section Outline
• Introduction• Software Development• Object-Oriented Analysis• Object-Oriented Design• Summary
![Page 68: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/68.jpg)
68
135
Introduction
• UML?– The successor to the wave of OOA&D
methods that appeared in the late ’80s and early ’90s
– Unification of the methods of Booch, Rumbaugh, and Jacobson
– The standard of OMG (Object Management Group)
136
History(1/2)
• UML motivation– To create a set of semantics and notation that
can adequately address all scales of architectural complexity across all domains
• Each of OO methods were recognized as having certain strengths
• Base methods– Booch, Rumbaugh(OMT), Jacobson(OOSE)
![Page 69: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/69.jpg)
69
137
History(2/2)
other methods
UML 1.0
UML 0.9 & 0.91
Unified Method 0.8
Booch ’93 OMT-2
Booch ‘91 OMT-1 OOSE
UML Partner s’Expertise
Fragmentation
Unification
Standardization
Industrialization
Publication ofUML 1.0, Jan ‘97
Jun ‘96 & Oct ‘96
OOPSLA ‘95
Standard Object Modeling Language by OMG, Sep ‘97
UML 2.0
138
Scope of the UML(1/2)
• Language for specifying constructing, visualizing, and documenting the artifacts of a software-intensive system
• Fusing the concepts of Booch, OMT, and OOSE• Envelop of what can be done with existing
methods• Standard object modeling language adopted by
OMG, Sep., 1997
![Page 70: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/70.jpg)
70
139
Scope of the UML(2/2)
• Object-Oriented Analysis– Use Case diagram– Object interaction diagram– Class diagram– State diagram– Activity diagram
• Object-Oriented Design– Process diagram– Architecture diagram– Deployment diagram
140
Comparing to Others(1/2)
• Not a radical departure from Booch, OMT, and OOSE
• Legitimate successor to all three methods• More expressive yet cleaner and more uniform• Value in moving to the UML
– It will allow projects to model things they could not have done before
– It removes the unnecessary differences in notation and terminology
![Page 71: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/71.jpg)
71
141
Comparing to Others(2/2)
UML Class Association Generalization Aggregation
Booch Class Uses Inherits Containing
Coad Class & Object
Instance Connection Gen-Spec Part-Whole
Jacobson Object AcquaintanceAssociation Inherits Consists of
Odell Object type Relationship Subtype Composition
OMT Class Association Generalization Aggregation
Shlaer/Mellor Object Relationship Subtype N/A
Class Diagram Terminology
142
Section Outline
• Introduction• Software Development• Object-Oriented Analysis• Object-Oriented Design• Summary
![Page 72: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/72.jpg)
72
143
Phases of a Development Cycle
0. Requirementanalysis
1. Analysis
2. Design
3. Code
4. Test
UMLdiagram
UMLdiagram
Use Caseanalysis
Requirementspecification
144
Phase of Development
• Requirement Analysis• Analysis• Design• Code• Test
![Page 73: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/73.jpg)
73
145
Section Outline
• Introduction• Software Development• Object-Oriented Analysis• Object-Oriented Design• Summary
146
OO Analysis
Phase 1. Use Case ModelingPhase 2. Class Finding & RefinementPhase 3. Object FindingPhase 4. Class RelationshipPhase 5. Class SpecificationPhase 6. Analysis Refinement
![Page 74: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/74.jpg)
74
147
OOA Phase 1. Use Case Modeling
• Introduced by Jacobson(1994)• Use Case modeling by user requirement• Relationship among actors and Use Cases• Actors carry out Use Cases• Use Case is a typical interaction between a user
and a computer system– <<extends>> relationship : similar but do a bit more– <<uses>> relationship : a chunk of behavior similar
across more than one use case
148
Use Case Diagram
Trading Manager
Set Limits
Capture Deal
Trader
Limits Exceeded
Valuation
Salesperson
Price Deal
Analyze Risk
UpdateAccounts Accounting
System
<<uses>>
<<uses>>
Use Case
Actor
<<extends>>
Use Case for a financial trading system
![Page 75: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/75.jpg)
75
149
OOA Phase 2. Class Finding & Refinement
• For each Use Case, finding classes– Class Finding
• Class Diagram– Class Refinement
• Remove redundant• Name same, semantics different
150
Class
• The name of a class has scope within the package in which it is declared and the name must be unique (among class names) within its package
• References– Show a reference to a class defined in another
package– Package-name::class-name
![Page 76: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/76.jpg)
76
151
Class Diagram
• Showing the static structure of the system• A graph of modeling elements shown on a
two-dimensional surface• A collection of (static) declarative model
elements, such as classes, types, and their relationships, connected as a graph to each other and to their contents
152
Type
• A type is descriptor for objects with abstract state, concrete external operation specification, and no operation implementations
• Classes implement types• Shown as a stereotype of a class symbol with the
stereotype <<type>>• May contain lists of abstract attributes and of
operations• May contain a context and specifications of its
operations accordingly
![Page 77: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/77.jpg)
77
153
Examples of Class Diagram
Windows
Windows
size: Areavisibility: Boolean
display ( )hide ( )
Windows{abstract, author = Joe,status=tested}
+size: Area=(100,100)#visible: Boolean=invisible+default-size: Rectangle#maximum-size: Rectangle-xptr: Xwindow*
+display ( )+hide ( )+create ( )-attachXWindow(xwin:Xwin*)
attributes
methods
class name
154
Name Compartment
• Displays the name of the class and other properties in up to 3 sections
• An optional stereotype keyword, the name, a property list
<< controller >>PenTracker
{ abstract }
![Page 78: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/78.jpg)
78
155
OOA Phase 3. Object Finding
• For each class, finding objects, and making object interaction diagram
– Sequence Diagram– Collaboration Diagram
• Finding messages within objects
156
Object Diagram
• A graph of instances• Static object diagram is an instance of a class
diagram• Dynamic object diagram shows the detailed state
of a system over some period of time• Class diagrams can contain objects, so a class
diagram with objects and no classes is an “object diagram”
![Page 79: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/79.jpg)
79
157
Sequence Diagram(1/2)
• Showing an interaction arranged in time sequence
• Showing the explicit sequence of messages
• Better for real-time specifications and for complex scenarios
158
Sequence Diagram(2/2)
:caller :exchange :receiver
a
b
cd
d’
lift receiver
dial tone
dial digit....route
phone rings
answer phone
stop ringingstop tone
ringing tone
{b-a < 1 sec.}
{c-b < 10 sec.}
The call isrouted throughthe network{d’-d < 5 sec.}
At this pointthe partiescan talk
The horizontal dimension represents different objects
The vertical dimension represents time
Sequence diagram for concurrent objects
![Page 80: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/80.jpg)
80
159
Collaboration Diagram(1/2)
• Showing the relationships among objects• Better for understanding all of the effects
on a given object and for procedural design
• Showing an interaction organized around the objects in the interaction and their links to each other
• Not showing time as a separate dimension
160
Collaboration Diagram(2/2)
: Order Entry Window
: Order
Macallan line : Order Line
: Delivery Item
Macallan stock : Stock Item
: Reorder Item
Object
1: prepare()
2* : prepare()
7: [check == true] new
3: check()4: [check == true] remove()
6: new
Message
Sequence number
Self-Delegation
5 : needToReOrder()
![Page 81: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/81.jpg)
81
161
OOA Phase 4. Class Relationship
• Finding class relationships from Object Diagrams
• Is-A• Aggregation• Link
– Relationship which is not Is-A, nor Aggregation
– Between classes that exchange messages
162
Association Relationship
• Association relationship is drawn as a solid path connecting two class symbols
• OR-association– Only one of several potential associations may be
instantiated at one time for any single object
Company Person* 3Works-for 1..*employer employee
Jobsalary
boss
wManages
0..1worker *
Account
Person
Corporation
{or}
![Page 82: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/82.jpg)
82
163
Aggregation & Composition
• Aggregation– Part of relationship
• Composition Relationship– Form of aggregation with strong ownership
and coincident lifetime of part with the whole– The multiplicity of the aggregate end may not
exceed one
164
Example of Aggregation and Composition
Graphics Bundlecolortexture
Polygon
Point
{ordered} 3..*
1
11
Aggregation relationship
Composition relationship
Aggregation and Composition
![Page 83: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/83.jpg)
83
165
Generalization
• Taxonomic relationship between a more general element and a more specific element
Shape
Polygon Ellipse Spline
{overlapping}
Shape
Polygon Ellipse Spline
{overlapping}
166
OOA Phase 5. Class Specification
• Attribute• Behavior
– By object interaction diagrams– Operation
![Page 84: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/84.jpg)
84
167
Attribute
• A text string that can be parsed into the various properties of an attribute model element
• The default syntax– Visibility name:type-expression=initial-
value{property-string}– Visibility
• + public• # protected• - private
– A class-scope attribute is shown by underlining the entire string
168
Operation
• A text string that can be parsed into the various properties of an operation model element
• Visibility name (parameter-list): return-type-expression=initial-value{property-string}
– Visibility• + public• # protected• - private
– Parameter-list• name: : type-expression = default-value
![Page 85: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/85.jpg)
85
169
Examples of Attributes and Operations
Windows
Windows
size: Areavisibility: Boolean
display ( )hide ( )
Windows{abstract, author = Joe,status=tested}
+size: Area=(100,100)#visible: Boolean=invisible+default-size: Rectangle#maximum-size: Rectangle-xptr: Xwindow*
+display ( )+hide ( )+create ( )-attachXWindow(xwin:Xwin*)
attributes
methods
class name
170
OOA Phase 6. Analysis Refinement
• Review all processes of analysis
![Page 86: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/86.jpg)
86
171
Other UML Diagrams
• By user needs• State Diagram• Activity Diagram
172
State Diagram(1/2)
• A familiar technique to describe the behavior of a system
• Describe all the possible states a particular object can get into and how the object’s state changes as a result of events
• Drawn for a single class to show the lifetime behavior of a single object
![Page 87: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/87.jpg)
87
173
State Diagram(2/2)
Activephone#
Timeoutdo/play message
DialTonedo/play dial tone
Dialing
Invaliddo/play message Connecting
Idle
lift receiver/get dial tone
caller hangs up/disconnect
15 sec. 15 sec.dial digit(n)[incomplete]
dial digit(n)
dial digit(n)[invalid] dial digit(n)[valid]/connect
state
transition
guard
transition : event[guard(logical condition)]/action
start
174
Activity Diagram(1/2)
• A special case of a state diagram in which all of the states are action states and in which all of the transitions are triggered by completion of the actions in the source states
• Use activity diagrams in situations where all or most of the events represent the completion of internally-generated actions
• Use ordinary state diagrams in situations where asynchronous events occur
![Page 88: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/88.jpg)
88
175
Activity Diagram(2/2)
Find Beverage
Put Coffee in Filter Add Water to Reservoir Get Cups
Put Filter in Machine
Turn on Machine
Brew coffee
Pour Coffee
Get cans of cola
Drink
[no coffee]
[found coffee]
[no cola]
[found cola]
^coffeePot.turnOn
light goes out
176
Section Outline
• Introduction• Software Development• Object-Oriented Analysis• Object-Oriented Design• Summary
![Page 89: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/89.jpg)
89
177
OO Design
• Add implementation classes (DLL, …)• Process
– Consider the performance• Deployment Diagram
– Architecture diagram– System placement
• Component Diagram– Interface
178
Interface
• The use of type to describe the externally-visible behavior of a class component, or other entity
String.....isEqual(String):Booleanhash():Integer
HashTable*contents
Hashable
Comparable
<<interface>>Comparable
isEqual(String) : Booleanhash():Integer
<<uses>>
![Page 90: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/90.jpg)
90
179
Types and Implementation Class
<<type>>Collection
<<implementation class>>HashTable
<<type>>Set
elements : Collection
addElement(Object)removeElement(Object)testElement(Object) : Boolean
<<implementation class>>HashTableSet
elements : Collection
addElement(Object)removeElement(Object)testElement(Object) : BooleansetTableSize(Integer)
Realize relationship
180
Implementation Diagram
• Show aspects of implementation, including source code structure and run-time implementation structure
• Component Diagrams– Show the structure of the code itself
• Deployment Diagrams– Show the structure of the runtime system
![Page 91: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/91.jpg)
91
181
Deployment Diagram
Scheduler
Planner
GUI
reservations
update
Scheduler
Planner
<<database>>meetingsDB
AdminServer:HostMachine
Joe’sMachine:PC
reservations
182
Summary
• UML is a standard for OOA&D• Software Development
– Requirement Analysis– Object-Oriented Analysis– Object-Oriented Design– Code– Test
![Page 92: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/92.jpg)
92
183
Part II.6UML to Java Mapping
// Notes will be used in the// rest of the presentation// to contain Java code for// the attached UML elements
public class Course{
Course() { }protected void finalize()
throws Throwable {super.finalize();
}};
Course
Mapping Representation: Notes
![Page 93: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/93.jpg)
93
public class Student{
private String name;
public void addSchedule (Schedule theSchedule; Semester forSemester) {}
public boolean hasPrerequisites(CourseOffering forCourseOffering) {}
protected booleanpassed(CourseOffering theCourseOffering) {
}}
Visibility for Attributes and OperationsStudent
- name : String
+ addSchedule (theSchedule: Schedule, forSemester: Semester)+ hasPrerequisites(forCourseOffering: CourseOffering) : int# passed(theCourseOffering: CourseOffering) : int
class Student {
private static int nextAvailID = 1;
public static int getNextAvaiIID() {}
}
Class Scope Attributes and Operations
Student
- nextAvailID : int = 1
+ getNextAvaiIID() : int
![Page 94: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/94.jpg)
94
<<utility>>MathPack
-randomSeed : long = 0-pi : double = 3.14159265358979
+sin (angle : double) : double+cos (angle : double) : double+random() : double
import java.lang.Math;import java.util.Random;class MathPack {
private static randomSeed long = 0;private final static double pi =
3.14159265358979;public static double sin(double angle) {
return Math.sin(angle);}static double cos(double angle) {
return Math.cos(angle);}static double random() {
return newRandom(seed).nextDouble();
}}
void somefunction() {. . .
myCos = MathPack.cos(90.0);. . .
Utility Class• A grouping of global attributes and
operations
Outer
Outer::Inner
class Outer{
public outer() { }
class Inner {public Inner() { }
}}
Nested Class
• Hide a class that is relevant only for implementation
![Page 95: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/95.jpg)
95
Schedule
Student
class Student{
public Student() { }private Schedule theSchedule;
}
// no need to import if in same package
class Schedule{
public Schedule() { }private theStudent;
}
Associations
• Bi-directional associations
Schedule
Student
class Student{
public Student() { }private Schedule theSchedule;
}
class Schedule{
public Schedule() { }}
Association Navigability• Uni-directional associations
![Page 96: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/96.jpg)
96
Professor
CourseOffering
instructor
class Professor {public Professor() {}private CourseOffering theCourseOffering;}
class CourseOffering {public CourseOffering() {}private Professor instructor;}
Association Roles
CourseOffering
Schedule
class Schedule{public Schedule() {}private CourseOffering[] primaryCourses =
new CourseOffering[4]}
class CourseOffering{public CourseOffering() {}}
0..4 primaryCourses
Association Multiplicity
![Page 97: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/97.jpg)
97
193
// No need to import if in the same package
class PrimaryScheduleOfferingInfo{
public PrimaryScheduleOfferingInfo() {}
public CourseOffering get_theCourseOffering(){return theCourseOffering;
}public void set_theCourseOffering(CourseOffering toValue){
theCourseOffering = toValue;}private char get_Grade (){ return grade; }private void set_Grade(char toValue) { grade = toValue; }private char grade = ‘I’;private CourseOffering theCourseOffering;
}
Association Class
Schedule CourseOffering
0..40..*
primaryCourses
PrimaryScheduleOfferingInfo
- grade: char = I
alternateCourses
0..20..*
0..*
Schedule CourseOffering
11 0..4
0..20..*alternateCourses
primaryCourseOfferingInfo PrimaryScheduleOfferingInfo
- grade: char = I
Design Decisions
Course
prerequisites0..* import java.util.Vector;
class Course {
public Course() {}// The unbounded multiple association// is stored in a vector
private Vector prerequisites;}
Reflexive Associations
![Page 98: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/98.jpg)
98
Schedule
Student
class Schedule{public Schedule() { }private Student theStudent;}0..*
1 import java.util.Vector;
class Student{
public Student() { }private Vector theSchedule;
}
Aggregation
Schedule
Student
class Schedule{public Schedule() { }private Student theStudent;}0..*
1
import java.util.Vector;
class Student{public Student() { }private Vector theSchedule = new Vector();}
Composition
![Page 99: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/99.jpg)
99
Serializable<<Interface>>
Schedule<<entity>>
interface Serializable {
}
class Schedule implements Serializable {
}
Interfaces and Realizes Relationships
GroundVehicle
class Truck extends GroundVehicle{
public float tonnage;public void getTax() { }
}
class GroundVehicle{
public int licenseNumber;public void register() { }
}
+licenseNumber: int
+register()
Truck+tonnage: float
+getTax()
Generalization
![Page 100: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/100.jpg)
100
AmphibiousVehicle
<<Interface>>IVehicle
<<Interface>>IWaterVehicle
LandVehicle
{overlapping}
class AmphibiousVehicleextends LandVehicle implements WaterVehicle
{. . .
}
<<realize>>
<<realize>>interface IWaterVehicle :
implements IVehicle{. . .
}
In Java, a class can only inherit from one superclass. It can, however implement multiple interfaces
Multiple Inheritance
200
Multiple Inheritance (contd)
AmphibiousVehicle
LandVehicle IAmphibiousVehicle<<Interface>>
IHobby<<Interface>>
IWaterVehicle<<Interface>>
ILandVehicle<<Interface>>
In Java, a class can inherit from one superclass.It can, however implement multiple interfaces.
An interface can inherit from many interfaces.
![Page 101: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/101.jpg)
101
abstract class Animal {
public abstract void talk();}
Animal{abstract}
Lion
+talk()
Tiger
+talk()
class Tiger extends Animal{
public Tiger() { }public void talk() { }
}
+talk() {abstract}
Abstract Class
SetT, n:int
<<bind>>
mySetOfFloats
insert(T)remove(T)
<float, 100>
Java does not (yet) support parameterized classes
Parameterized Class
![Page 102: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/102.jpg)
102
package CourseCatalog;
public interface ICourseCatalog {
public CourseOfferingList getCourseOfferings();
}
CourseCatalog<<subsystem>>
ICourseCatalog
getCourseOfferings() : CourseOfferingList
Subsystems
204
Part II.7
Sample OCL Problem
![Page 103: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/103.jpg)
103
205
Sample Problem• Problem Statement (Tower of Hanoi)
There are 3 needles and a tower of 5 disks on the first one, with the smaller on the top and the bigger on the bottom. The purpose of the puzzle is to move the whole tower from the first needle to the second, by moving only one disk every time and by observing not to put a bigger disk atop of a smaller one.
• Typical OCL Deliverables - annotate the appropriate diagrams with:
1. Invariants2. Pre-conditions3. Post-conditions4. Guards
206
Scenarios 1 and 2Normal Scenario
1. Monk selects top most disk
2. Places disk on third needle
3. Selects next disk4. Places disk on second
needle5. Moves disk on third
needle to second needle6. Selects next ring7. Places ring on third
needle8. Continues until done
Abnormal Scenario1. Monk selects top most
disk2. Places disk on third
needle3. Selects next disk4. Places disk on third
needle5. Larger disk on smaller
disk
![Page 104: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/104.jpg)
104
207
Use Case Diagram
208
Class Diagram
![Page 105: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/105.jpg)
105
209
State Transition Diagram
210
Sequence Diagram
![Page 106: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/106.jpg)
106
211
Problem Analysis
• Numeric Values Available– 3 needles– 5 disks
• Rules– Move tower from disk 1 to 2– 1 disk per move– Never put a bigger disk on a smaller disk
212
Object Constraint Language (OCL)
• Invariants - ALWAYS coupled to classes– Number of Needles– Number of Disks
• Pre-Conditions• Post Conditions• Guards - only on state transition diagrams
![Page 107: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/107.jpg)
107
213
Scenarios 1 and 2(NO OCL goes here!)
Normal Scenario1. Monk selects top most
disk2. Places disk on third
needle3. Selects next disk4. Places disk on second
needle5. Moves disk on third
needle to second needle6. Selects next ring7. Places ring on third
needle8. Continues until done
Abnormal Scenario1. Monk selects top most
disk2. Places disk on third
needle3. Selects next disk4. Places disk on third
needle5. Larger disk on smaller
disk
214
Use Case Diagram(NO OCL goes here!)
![Page 108: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/108.jpg)
108
215
Class Diagram(Invariants go here!)
DiskNumber_of_disks = 5
NeedleNumber_of_Needles = 3
216
State Transition Diagram for Tower(Guards go here!)
Tower :: move(disk : integer)Pre: not Disk_Selected and not Needle_Selected and not Disk_Placed_on_NeedlePost: New_Tower_Complete = TrueTower :: Needle_Available()Pre: Disk_Selected = TruePost: Needle_Selected = FalseTower :: Needle_Not_AvailablePre: Disk_Selected = TruePost: Disk_Selected = False
Note: All state names and events are transformed into Bool attributes
![Page 109: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/109.jpg)
109
217
Sequence Diagram(Pre and Post Conditions go here!)
Note: The context of pre-and post conditions is always an operation or a method.OCL text pg. 23
Monk :Pre: NonePost: Select_Disk = True
Needle :Pre: Select_Needle = TruePost: None
OrSelect_Another = True
Disk :Pre: Select_Disk = TruePost: Select_Needle = True
OrSelect_Another = True
218
Part III
Introduction to Design and Architectural Patterns
See: Sub-Topic 3 Presentation on “Introduction to Design and Architectural Patterns”
![Page 110: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/110.jpg)
110
219
Part IV
Micro / Macro Architecture
See: Sub-Topic 4 Presentation on “Micro / Macro Architecture”
220
Part V
Design and Architectural Patterns
See: Sub-Topic 5 Presentation on “Design and Architectural Patterns”
![Page 111: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/111.jpg)
111
221
Part VI
Conclusion
222
Course Assignments• Individual Assignments
• Problems and reports based on case studies or exercises
• Project-Related Assignments• All assignments (other than the individual assessments) will
correspond to milestones in the team project.• As the course progresses, students will be applying various
methodologies to a project of their choice. The project and related software system should relate to a real-world scenario chosen by each team. The project will consists inter-related deliverables which are due on a (bi-) weekly basis.
• There will be only one submission per team per deliverable and all teams must demonstrate their projects to the course instructor.
• A sample project description and additional details will be available under handouts on the course Web site.
![Page 112: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/112.jpg)
112
223
Course Project• Project Logistics
• Teams will pick their own projects, within certain constraints: for instance, all projects should involve multiple distributed subsystems (e.g., web-based electronic services projects including client, application server, and database tiers). Students will need to come up to speed on whatever programming languages and/or software technologies they choose for their projects - which will not necessarily be covered in class.
• Students will be required to form themselves into "pairs" of exactly two (2) members each; if there is an odd number of students in the class, then one (1) team of three (3) members will be permitted. There may not be any "pairs" of only one member! The instructor and TA(s) will then assist the pairs in forming "teams", ideally each consisting of two (2) "pairs", possibly three (3) pairs if necessary due to enrollment, but students are encouraged to form their own 2-pair teams in advance. If some students drop the course, any remaining pair or team members may be arbitrarily reassigned to other pairs/teams at the discretion of the instructor (but are strongly encouraged to reform pairs/teams on their own). Students will develop and test their project code together with the other member of their programming pair.
224
Sample Project MethodologyVery eXtreme Programming (VXP)
• After teams formed, 1/2 week to Project Concept
• 1/2 week to Revised Project Concept• 2 to 3 iterations• For each iteration:
– 1/2 week to plan– 1 week to iteration report and demo
![Page 113: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/113.jpg)
113
225
Sample Project MethodologyVery eXtreme Programming (VXP)
(continued)
• Requirements: Your project focuses on two application services
• Planning: User stories and work breakdown• Doing: Pair programming, write test cases before coding,
automate testing• Demoing: 5 minute presentation plus 15 minute demo• Reporting: What got done, what didn’t, what tests show• 1st iteration: Any• 2nd iteration: Use some component model framework• 3rd iteration: Refactoring, do it right this time
226
Revised Project Concept (Tips)
1. Cover page (max 1 page)2. Basic concept (max 3 pages): Briefly
describe the system your team proposes to build. Write this description in the form of either user stories or use cases (your choice). Illustrations do not count towards page limits.
3. Controversies (max 1 page)
![Page 114: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/114.jpg)
114
227
First Iteration Plan (Tips)• Requirements (max 2 pages):• Select user stories or use cases to implement in
your first iteration, to produce a demo by the last week of class
• Assign priorities and points to each unit - A point should correspond to the amount of work you expect one pair to be able to accomplish within one week
• You may optionally include additional medium priority points to do “if you have time”
• It is acceptable to include fewer, more or different use cases or user stories than actually appeared in your Revised Project Concept
228
First Iteration Plan (Tips)
• Work Breakdown (max 3 pages): • Refine as engineering tasks and assign to pairs• Describe specifically what will need to be coded
in order to complete each task• Also describe what unit and integration tests will
be implemented and performed• You may need additional engineering tasks that do
not match one-to-one with your user stories/use cases
• Map out a schedule for the next weeks• Be realistic – demo has to been shown before the
end of the semester
![Page 115: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/115.jpg)
115
229
2nd Iteration Plan (Tips): Requirements
• Max 3 pages• Redesign/reengineer your system to use a
component framework (e.g., COM+, EJB, CCM, .NET or Web Services)
• Select the user stories to include in the new system– Could be identical to those completed for your 1st
Iteration– Could be brand new (but explain how they fit)
• Aim to maintain project velocity from 1st iteration• Consider what will require new coding vs. major
rework vs. minor rework vs. can be reused “as is”
230
2nd Iteration Plan (Tips): Breakdown
• Max 4 pages• Define engineering tasks, again try to maintain
project velocity• Describe new unit and integration testing• Describe regression testing
– Can you reuse tests from 1st iteration?– If not, how will you know you didn’t break something
that previously worked?• 2nd iteration report and demo to be presented
before the end of the semester
![Page 116: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/116.jpg)
116
231
2nd Iteration Report (Tips): Requirements
• Max 2 pages• For each engineering task from your 2nd Iteration
Plan, indicate whether it succeeded, partially succeeded (and to what extent), failed (and how so?), or was not attempted
• Estimate how many user story points were actually completed (these might be fractional)
• Discuss specifically your success, or lack thereof, in porting to or reengineering for your chosen component model framework(s)
232
2nd Iteration Report (Tips): Testing
• Max 3 pages• Describe the general strategy you followed for
unit testing, integration testing and regression testing
• Were you able to reuse unit and/or integration tests, with little or no change, from your 1st
Iteration as regression tests?• What was most difficult to test?• Did using a component model framework help or
hinder your testing?
![Page 117: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/117.jpg)
117
233
Project Presentation and Demo
• All Iterations Due• Presentation slides (optional)
234
Readings
• Readings• Slides and Handouts posted on the course web site• Documentation provided with business and application modeling tools
(e.g., Popkin Software Architect)• SE Textbook: Chapters 8-12 (Part 2), 18-19 (Part 3), 30 (Part 5)
• Project Frameworks Setup (ongoing)• As per references provided on the course Web site
• Individual Assignment• See Session 6 Handout: “Assignment #4”
• Team Assignment• See Session 6 Handout: “Team Project” (Part 2)
![Page 118: Software Engineering G22.2440-001 · • Architecture Design Methodology • Achieving Optimum-Quality Results ... Student Registration System • Not going to do all the diagrams](https://reader033.vdocuments.us/reader033/viewer/2022042019/5e76e823e9a67b7127239b8a/html5/thumbnails/118.jpg)
118
235
Next Session:From Analysis and Design to Software Architectures
(Part III)
• Enterprise Architectural Patterns• Sample Middleware Reference
Architectures• Architectural Capabilities• Object-Oriented Design Guidelines• Summary
• Individual Assignment #5• Project (Part 3)