The document describes a module view decomposition style guide. It defines the style guide sections including overview, design criteria, elements catalog, constraints, usage, notation, relation to other styles, and notes. It provides examples of decomposing a system into modules and submodules based on separation of concerns, quality attributes, reusable components, and team allocation. The decomposition aims to divide responsibilities into manageable implementation units.

1. MODULE VIEW
DECOMPOSITION
VERSION (1.0)
MOUDLE NAME
MODULE VIEW - DECOMPOSITION
SUBMITTED BY
ELM

2. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 2
TABLE OF CONTENT
TABLE OF CONTENT............................................................................................................................2
1. MODULE VIEW...........................................................................................................................3
1.1. OVERVIEW.....................................................................................................................................4
2. DECOMPOSITION DOCUMENTATION GUIDE..............................................................................5
2.1. STYLE GUIDE .................................................................................................................................5
2.2. STYLE DECUMENTATION ...............................................................................................................6
2.2.1. Overview...................................................................................................................6
2.2.2. Design criteria...........................................................................................................7
2.2.3. Elements catalog.......................................................................................................7
2.2.4. constraints ................................................................................................................8
2.2.5. style used for ............................................................................................................9
2.2.6. style notation..........................................................................................................10
2.2.7. relation to other styles ...........................................................................................11
2.2.8. Style notes ..............................................................................................................12
2.2.9. Real Example...........................................................................................................14

3. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 3
TABLE OF FIGURES
Figure 1: Decomposition using named text list........................................................................................... 11
Figure 2: Decomposition using UML ............................................................................................................... 11
Figure 3 : SchoolSystem Decomposition Real Example............................................................................ 14

4. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 4
1. MODULE VIEW
1.1.Overview
Module view used to show implementation units of system and how these
implementation units are related to each other
Module view represented by modules and submodules

5. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 5
2. DECOMPOSITION DOCUMENTATION GUIDE
2.1.Style guide
1. OVERVIEW
 Show introduction overview for the style
2. DESIGN CRITERIA
 Show what is the criteria to achieve the style
3. ELEMNET CATALOG
 Show the element of style, relations between elements and properties of
elements
4. CONSTRAINTS
 Show what constraints you will face with the style
5. STYLE USED FOR
 Show what is the usage of the style
6. STYLE NOTATION
 How to show the style in obvious way with notations
7. RELATION TO OTHER STYLES
 Show the nature of relation to other styles
8. NOTES
 Style design notes
9. REAL EXAMPLE
 Show real example of style

6. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 6
2.2.Style decumentation
2.2.1. Overview
Show the structure of modules and submodules (containment relations
between modules) which represent is part of relationship, this will result to
divide responsibilities into manageable pieces (implementation units)
Code organization into modules and submodules and show how system
responsibilities Are partitioned across them
Usually decomposition is first step architect start with to model their system
Decomposition defined modules that may appear in other styles like uses,
generalization, layered, other module based views, so it is the first step
towards details architecture
Architect tend to attach a problem by use of divide and conquer technique

7. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 7
2.2.2. Design criteria
Decomposition criteria for decomposing module into submodules as follows
2.2.2.1. Separation of concern
 Divide complex problem into pieces.
 Concern is feature or behaviour that specified as part of requirements
model of the software.
 Eg. Separate distribution of mail from processing mail.
2.2.2.2. Achievement of certain quality attributes
For example, to support Modifiability:
 Information hiding design principle used for encapsulate the changeable
aspects of the system in a separate module.
 This will reduce side effects.
 Limit global impact of local design changes.
 Relations to other modules done across managed interface.
 Bridge pattern in design pattern represent information hiding
 Eg. Remote control with TV or with air conditioner
2.2.2.3. Build versus buy decisions
 Some modules may be bought from market place, or reuse of old
projects or obtained as open source.
 These modules will represent set of responsibilities
 The remaining modules are discomposed around these established
modules.
 Eg. Telerik controls
2.2.2.4. Product line implementation
 To make products of product family, make some sort of separation
 Separate common modules from variable modules that differ across
products
 Eg. Common lookups (city – country – region)
2.2.2.5. Team Allocation
 make responsibilities done in parallel, separate modules that can be
allocated to different team should be defined
 The skills of development team may change decomposition, Eg. If web
developers are available, modules that handle web ui should kept
separate

8. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 8
2.2.3. Elements catalog
2.2.3.1. Elements
Modules, submodules, subsystem (aggregate of modules)
2.2.3.2. Relations
is-part-of relation (containment relation)
2.2.3.3. Properties
 Element name: Module-Name indicate role in name
 Element role: role of modules
 Element responsibility: in details what responsibility of modules in
whole system
 Properties: Visibility of interfaces inside module or delegate to
aggregate module interface

9. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 9
2.2.4. Constraints
Module is part of one parent only (one container)
No loops are allowed in decomposition
Decomposition can decide whether the submodule is visible within only the
aggregate or also for other modules through module interfaces
(like internal interfaces in electronic board)

10. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 10
2.2.5. Style used for
Show responsibilities of system in form of modules and submodule
Support the learning process about a system. Excellent learning and navigation tool
for newcomers to the project and other people who do not necessarily have
the whole functional structure of the system memorized
Useful basis for defining configuration items within a configuration management
framework.
Serves as the input for the work assignment view of a system, which maps parts of a
software system onto the organizational units, or teams
Show effects of change in addition to uses style (dependency)

11. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 11
2.2.6. Style notation
2.2.6.1. Informal
Modules in the decomposition style are usually depicted as named boxes
that contain other named boxes or, listing the module names and using
indentation to indicate is part of relation
Figure 1: Decomposition using named text list
2.2.6.2. UML
In UML, the package construct can be used to represent modules that
contain other modules. A package can contain classes and other
packages
Module Properties like modules responsibilities, are given textually,
perhaps using an annotation. Stereotypes can provide additional
information for the type of the module like <<subsystem>> stereotype
Figure 2: Decomposition using UML

12. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 12
2.2.7. Relation to other styles
Map between a decomposition view and one or more component-and-
connector views, mapping indicates how the software implementation
structures map onto runtime structures
A many-to many relationships. The same module might implement all or
parts of several components or connectors. Conversely, one component might
require several modules for its implementation
The decomposition style is closely related to the work assignment style, a kind
of allocation style. The work assignment style maps modules resulting from a
decomposition to a set of teams responsible for implementing and testing
those modules

13. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 13
2.2.8. Style notes
The real implementation of decomposition style as follows:
First: Deep think about the criteria defined before. (separation of concern –
achieve quality attributes – team allocation – Buy versus build – product line
implement (common, variable) modules)
Second: list as much as you can possible entities you have and try to group
these entities to formulate new modules, Eg. [Country, city, region entities]
formulate [locationSettings] module
Third: try to make containment relation to group modules together if possible
to formulate super (parent) module, Eg. [controlPanel] Module contain
[Locationsettings, generalsettings, postalsettings] modules

14. MODULE VIEW - DECOMPOSITION
‫به‬ ‫ينتفع‬ ‫علم‬
MODULE VIEW DECOMPOSITION Page | 14
2.2.9. Real Example: SchoolSystem Decomposition
1. PRIMARY PRESENTATION
Figure 3 : SchoolSystem Decomposition Real Example
2. ELEMENT CATALOG
 SchoolSystem: main system to handle school management
 ControlPanel: include definition of school data, lookups like classes, stages , locations
and other settings
 StaffPanel: Includes staff data, courses they present
 StudentPanel: includes student data , there classes , stages , courses and scores
 LibraryManagment: include books included , borrow books and other library activities
for staff and students
 HygieneManagement: manage dustmen their work, Hygiene schedule, etc.
 AccountManagement : include salary for staff , dustmen , bus drivers also include
student school fees
 TransportationManagement: include bus contract and bus drivers , bus schedule , etc.
 Statistics: report management for students, staff, dustmen, etc.
3. RELATED VIEW STYLES
 SchoolSystem Uses Style
 SchoolSystem Work Assignment Style