Modeling Software Architectures in the Unified Modeling Language

More documents

Recommendations

Info

Modeling Software Architectures in UML • 17received messages PrefSet may generate RemoveExclSet xorRequestWithdrawal xor MarkMtg;received messages ExclSet may generate AddPrefDatesxor RemoveExclSet xor RequestWithdrawal xor MarkMtg;received messages EquipReqts may generate AddPrefDates xorRemoveExclSet xor RequestWithdrawal xor MarkMtg;received messages LocPref always generate null;end MeetingInitiator;The Attendee and ImportantAttendee components receive meeting schedulingrequests from the Initiator and notify it of the appropriate information. Thetwo types of components only communicate with other parts of the architecturethrough their bottom ports.component Attendee isinterfacebottom domain isoutPrefSet (p : date rng);ExclSet (e : date rng);EquipReqts (eq : equip type);inGetPrefSet ();GetExclSet ();GetEquipReqts ();RemoveExclSet ();RequestWithdrawal ();AddPrefDates ();MarkMtg (d : date; l:loctype);behaviorreceived messages GetPrefSet always generate PrefSet;received messages AddPrefDates always generate PrefSet;received messages GetExclSet always generate ExclSet;received messages GetEquipReqts always generate EquipReqts;received messages RemoveExclSet always generate ExclSet;received messages RequestWithdrawal always generate null;received messages MarkMtg always generate null;end Attendee;ImportantAttendee is a specialization of the Attendee component: It duplicatesall of Attendee’s functionality and adds specification of meeting locationpreferences. ImportantAttendee is thus specified as a subtype of Attendee thatpreserves its interface and behavior (though it can implement that behavior ina new manner).component ImportantAttendee is subtype Attendee (int and beh)interfacebottom domain isoutLocPrefs (l : loc type);inGetLocPrefs ();behaviorreceived messages GetLocPrefs always generate LocPrefs;end ImportantAttendee;ACM Transactions on Software Engineering and Methodology, Vol. 11, No. 1, January 2002.
18 • N. Medvidovic et al.The MeetingScheduler architecture depicted in Figure 7 is shown below. Thearchitecture is specified with the conceptual components (i.e., component types)defined above. Each conceptual component (e.g., Attendee) can be instantiatedmultiple times in a system.architecture MeetingScheduler isconceptual componentsAttendee; ImportantAttendee; MeetingInitiator;connectorsconnector MainConn is message filter no filtering;connector AttConn is message filter no filtering;connector ImportantAttConn is message filter no filtering;architectural topologyconnector AttConn connectionstop ports Attendee;bottom ports MainConn;connector ImportantAttConn connectionstop ports ImportantAttendee;bottom ports MainConn;connector MainConn connectionstop ports AttConn; ImportantAttConn;bottom ports MeetingInitiator;end MeetingScheduler;An instance of the architecture (a system) is specified by instantiating thecomponents. For example, an instance of the meeting scheduler applicationwith three participants and two important participants is specified as follows:system MeetingScheduler 1 isarchitecture MeetingScheduler withAttendee instance Att 1, Att 2, Att 3;ImportantAttendee instance ImpAtt 1, ImpAtt 2;MeetingInitiator instance MtgInit 1;end MeetingScheduler 1;4.4 Modeling the C2-Style Meeting Scheduler in UMLUML provides constructs for modeling software components, their interfaces,and their deployment on hosts. 3 However, these built-in constructs are not suitablefor describing architecture-level components because they assume both toomuch and too little. Components in UML are assumed to be concrete, executableartifacts that consume machine resources such as memory. In contrast, architecturalcomponents are conceptual artifacts that decompose the system’s stateand behavior. Although instances of architectural components in a given systemmay be implemented by concrete UML component instances, the architecturalcomponents are not themselves concrete. Furthermore, components in UMLmay have any number of interfaces and any internal structure, whereas architecturalcomponents must satisfy the rules or constraints imposed on them3 Unless otherwise noted, “component” in this discussion refers to a component type, as opposed toa specific instance of that type. This is the case with both architectural components (modeled in anADL) and UML components.ACM Transactions on Software Engineering and Methodology, Vol. 11, No. 1, January 2002.
Page 1 and 2: Modeling Software Architectures in
Page 3 and 4: 4 • N. Medvidovic et al.Table I.
Page 5 and 6: 6 • N. Medvidovic et al.architect
Page 7 and 8: 8 • N. Medvidovic et al.Fig. 3.An
Page 9 and 10: 10 • N. Medvidovic et al.Fig. 4.
Page 11: 12 • N. Medvidovic et al.Fig. 5.T
Page 24: Modeling Software Architectures in
Page 27 and 28: 28 • N. Medvidovic et al.with the
Page 31 and 32: 32 • N. Medvidovic et al.Table II
Page 33 and 34: 34 • N. Medvidovic et al.self.par
Page 35 and 36: 36 • N. Medvidovic et al.placehol
Page 39 and 40: 40 • N. Medvidovic et al.(?A : Na
Page 43 and 44: 44 • N. Medvidovic et al.Rule2. U
Page 45 and 46: 46 • N. Medvidovic et al.componen
Page 47 and 48: 48 • N. Medvidovic et al.6.2 Arch
Page 49 and 50: 50 • N. Medvidovic et al.the “a
Page 51 and 52: 52 • N. Medvidovic et al.7.1.4 Ar
Page 53 and 54: 54 • N. Medvidovic et al.completi
Page 55 and 56: 56 • N. Medvidovic et al.MEDVIDOV

Modeling Software Architectures in the Unified Modeling Language

Create successful ePaper yourself

Delete template?

Save as template?