Partitioning system & how clearly modules are separated from one another is called coupling. Cohesion is how activities within a single module are related to one another. These two are important for measuring partitioning & interdependent.

Designers should create strong, highly cohesive modules that is the elements of one module should not be strongly related to another module. Here are some characteristics of good & bad cohesion:

• Functional cohesion

Functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task e.g. read transaction record. Another example is calculate net employee salary which is a very complicated module and has may sub-functions but if you can sum up everything it accomplishes as one problem related function, then it’s functionally cohesive.

However there are many jobs that cannot be summed up as a single problem-related function. In this case the level of cohesion depends on how different activities are related to one another. Functional cohesion is the easiest and cheapest type of cohesion.

• Sequential cohesion

Sequentially cohesive modules are those with elements involved in activities that output from one activity serves as input to the next. Advantage of sequential cohesion is good coupling on the other hand not being able to re-use it can be seen as disadvantage. Not to mention that the order of carrying out activities are important in sequentially cohesive modules and more importantly just data flow from one module to another not the control.

• Communicational cohesion

Refers to cohesion between modules which use same input or output. The problem of communicational cohesion is the temptation to share code among activities within that module as result change in part will destroy other parts of module.

• Procedural cohesion

Higher level of cohesion where elements of modules are involved in different and possibly unrelated activities in which control flow from each activity to the next. In this kind of cohesion, control flows from one module to another. These kinds of modules are composed of functions that have little relationship to one another.

• Temporal cohesion

Modules with elements that are involved in activities that are related in time but activities may have no relationship among themselves.

• Logical cohesion

Modules which their elements contribute to activities of same general category in which activities to be executed are selected from outside the module. So in this kind of modules there should be a specific thing which is shared among all of them.

• Coincidental cohesion

Modules those their elements contribute to activities with no meaningful relationship to one another so it’s a bit similar to logically cohesive modules. Activities here are related neither by flow of data nor by flow of control.

There are different ways to determine level of cohesion of a module; one way is to write a short sentence that accurately, honestly, and fully names modules and their functions. These sentences will reveal the level of cohesion among modules. Another way is by drawing decision tree

Moving from structured analysis to structured design is a very challenging task in terms of both complexity and correctness. One of the tools which can assist us is CAST (Computer-Aided Structured Transformation) which automatically translates requirement specs to design specs.

CAST accepts DFD diagram as input – the diagram which we already use for software requirement specification. CAST consists of:

• Description language:

• Rule base: contains info on structured design methodology to help which methods should be applied

• Automatic transformation system: helps with intelligent decision making to determine suitable architectural design.

Structured system development consists of notations such as DFD which represents processes and data. In this kind of system development (structured) lower levels represents composition of higher level. These are the most important diagrams in analysis & design & implementation phase: DFD in analysis and structured chart for design & implementation which provides basis for evaluating coupling & cohesion.

When converting diagrams to descriptive language; DFD is decomposed into 5 components: source, sink dataflow, process & file. Structured chart is represented in modules, structure & relation.

Additionally for structure chart transform & transaction analysis are used.

In transform analysis input & output from DFD helps us to determine the central portion of system responsible for transforming data. In this type of analysis, DFD contains: transform centre which is centre of collection of processes which make up major functions of system, afferent stream which starts by reading from physical source & converts it to some suitable form for transform and efferent stream which converts the data from transformation centre to more physical form for output to real world.

In transaction analysis we try to isolate transaction centres which capture transactions by determining their types and then sending them to appropriate branch.

Like the analysis phase, there are also models in the design phase most important of them are system implementation model (includes processor model & task model) and program implementation model.

Processor model aims to allocate essential models to different CPUs and how CPUs should communicate among themselves e.g. entire essential model can be allocated to a single processor or each bubble in DFD can be allocated to a different CPU. Data stores should be allocated to different processors as well.

In any of the cases which more than 1 CPU is used, communication mechanism among CPUs should be considered. This communication can happen by direct link between processors with a cable or channel or LAN or indirectly by writing to a magnetic type or anything which can be read by another processor as input.

A very important issue to be considered is that communication between processes (bubbles) is much much faster than CPU-to-CPU communication therefore system designer should group processes & stores to have high volume of communication within each process. Of course other factors such as cost, efficiency, security and reliability should be considered too.

Task model aims to assign tasks & data stores to individual tasks on each processor. All the terms partition, job step, overlay or control point implies the notion of task. The types of activities (synchronized or asynchronized) have impact on processors’ activity as well.

The program implementation model

At level of each individual task where usually only one activity can take place at the same time, program implementation model is used to organize activities of a single unit in structured chart.

Two of the most design goals and objectives are high cohesion and low coupling as well as other objectives such as module size, span of control and scope of effect/scope of control:

Cohesion: the degree to which components of a module are sufficient and necessary to carry out one single well-defined function. Essential processes shouldn’t be split to different modules and no unrelated tasks are gathered in a module. High cohesion is desired which means each module carries out one single task.

Coupling: the degree to which modules are interconnected or related or linked to one another. Strong coupling between modules i.e. high level on communication between modules in system makes the system complex & difficult to implement and maintain. Also a change in one part of a system may have unpredictable effect in another part of the system. Low or loose coupling is desired which means keeping modules small, simple with minimum number of data element shared between modules.

Span of control refers to number of immediate subordinates that can be called by manager module. To increase span of control an intermediate level of manage module can be put in place

Scope of effect/scope of control: refers to how much a module is dependent or affected by outcome of decision of other modules. If this is the case, the module should be subordinate to the module that makes decision.

Structured design was developed in 1970s to deal with complex information systems which have many different functions. Structured design uses structure chart as main primary modeling technique to provide guidance for deciding what set of programs should be, what each program should achieve and how each program should be organized in hierarchy.

Structured design describes functions and subfunctions of each part of system, it shows relationship between modules of a computer program uses two main concepts of coupling & cohesion to structure and organize modules. Detailed explanation of these modules are explained in the next posts.

Structured design assumes the designer knows what the system needs to do & what the main functions are, what are inputs and outputs therefore a key aspect of user-interface is done in conjunction with structured design especially after the database is used in the system and users have to interact with it.

The weakness of structured design is that it only addresses some but not all of the activities in analysis and design which makes it more like an art where people like more comprehensive & rigorous technique like engineering principles. Another weakness of structured design is the transition from DFD to structured chart didn’t work well on the other hand many believed that data modeling is more important than process modeling – in structured analysis & design process is centre of focus of system.

Object oriented approach views system as collection of interacting objects that work together to accomplish tasks therefore conceptually there is no data entities or files, no program or process. OO design defines all kinds of objects necessary for communication, showing how objects interact to complete tasks and refining definition of each object so it can be implemented with specific language or environment.

Two main important models used in OO design are design class diagram and interaction diagram. Class diagrams are developed for domain, view & data access layer. Interaction diagram extend system sequence diagram.

As said; in OO approach it’s only objects and they send each other messages to collaborate and support functions of main program.

According to Rob (2004) :” The steps of developing a system (planning, analysis, design, implementation) do not change but how they are performed can be different.”

In structured Approach we use DFD, in OO approach we use Use Cases. likewise; in structured approach design of system components i.e. input, output, modules of program and DB are evolved from DFD. In OO approach we use UML and there is no clear-cut step and no single model that components evlove from it.

In practice, organisations use combination of structured and OO approach however Rob (2004) believes that in the era of OO programing, OO modeling and OO design is desired and mixing up structured methodology & OO methodology can be confusing. He believes we need clear definition of models and steps as an analyst moves from the activities of analysis to design to implementation.

REFERENCES:

* Systems Anslysis And Design in a Changing World – SJB

* Rob Mohammad A., (2004). “Issues of Structured VS. Object-Oriented Methodology of System Analysis and Design“. University of Houston-Clear Lake.