John Hurley: Overview Sina Sheikholeslami: Decomposition Xuan Yang: Uses (relationship type),

2. John Hurley: Overview Sina Sheikholeslami: Decomposition Xuan Yang: Uses (relationship type), • Generalization Anna Deghdzunyan: Layers part 1 Urvish Mehta: Layers Part 2

3. View: a representation of a coherent set of architectural elements and the relationships between them. • Depicts selected aspects of a model

4. Additional Source on Views: Clements et al, Documenting Software Architectures: Views and Beyond, 2nd Ed, Addison-Wesley SEI Series in Software Engineering, 2011 p. 55- 122

6. A Module View shows the principal implementation units, or modules, of a system, together with the relations among these units.

7. Modules vs. Components • Module is a unit of implementation, Component is a runtime entity • We are used to making a distinction between policy and implementation and thinking of implementation as the lower layer. Here components are where the rubber hits the road; implementation is the middle layer • Consider a server which serves a piece of info to ten identical clients. There are 11 components but only two modules.

8. Module structure contains the following relationship types: • Decomposition (‘is a submodule of”) • Uses (“requires the correct presence of”) • Layered (“uses the services of”) • Class / Generalization (“is an instance of; shares access methods of”)

20. Part II

27. Top level decomposition view forATIA system

28. Refinement ofATIA-M server-side Java modules showing how it is further decomposed into submodules

29. Decomposition of A7-E software architecture

30. Summary of the decomposition style

31. Part III

32. Uses Style • Focusing on depends-on relations • Enabling incremental development and deployment

33. Elements, Relationships, Properties

34. UML Notations

35. UML package diagram

36. DSM for the UML Diagram

37. What the Uses Style is for • Planning incremental development and subsets • Debugging and testing • Gauging the effect of changes

38. What the Uses Style is for (cont)

39. Generalization Style • Focusing on is-a relation • Supports extension and evolution • Implies inheritance of implementation and interface

40. Elements, Relationships, Properties

41. UML Diagrams

42. What the Generalization Style is For • Object-Oriented designs • Extension • Local change or variation • Reuse

43. Part IV

44. The Layered Style • The division of the software into units (layers) • Each partition (layer) provides through a public interface - a cohesive set of services.

45. Why isn’t this a layered style? • The layers are created to interact according to a strict ordering relation.

46. “allowed to use” relations • Using facilities of the immediate lower layer • Using facilities of any lower layer . bridging layers . if many exists - poorly structured

47. Bad Example • Upward usage

48. Observations • Cannot be constructed by examining source code • The way of defining layers can be . layers will work independently in different time scales . different people with different sets of skills will work on different layers

49. Elements, Relationships, Properties

50. What the Layered Style Is For • Modifiability and Portability • Information hiding • Grouping into layers same technology helps to assign to more specialized teams.