Architecture

Lecture 1

Contents
Introduction. System development. Object orientation,conceptual modeling block design. System development is model building. Models. Architecture. Development processes. Processes and models. &

Introduction
System development:OOSE may be used from the time that the requirement specification exists in some form and all through the systems life time until it is replaced by another system; That is we include new development, further development and maintenance of the system in the period of OOSE use.

Object orientation,conceptual modeling and block design: the basis of OOSE originates from three totally different techniques which have all been used for a long time Object oriented programming. Conceptual modeling. Block design.

Object Oriented Programming

Object oriented programming essentially means programming using objects and the other concepts related to objects. This style of programming has been used , until recently , only on a small scale. The major strengths of object oriented programming are that it encourages the reuse of code It is usually easier to understand and maintain than other types of programming.

Object Oriented Programming

An object oriented language must support the following: Encapsulated objects The class and instance concepts Inheritance between classes Polymorphism

Conceptual modeling: conceptual modeling is used to create models of the system or organization to be analyzed ,depending on which system and which aspects one wishes to model, different conceptual models are created. In OOSE, we have expended the technique with object oriented concepts and the ability to express dynamic behavior.The model we develop are used mainly to understand the system and to obtain a good system architecture. These models form the basis for the actual system design.

Block design:the idea of block design is taken from hardware design where a no. Of modules, each providing a specific functionality, are connected together with well defined interfaces . one should be able to do the same thing with software: collect together programs and data into modules(blocks) and describe their mutual communication through interfaces. The OOSE has satisfied this need.

System Development Is Model Building

Models:system development is a complex task and several different aspects must be taken into consideration. What we wish to achieve is a reliable computer program that performs its task properly. We do this by working with different models, each focusing on a certain aspect of the system. By introducing the complexity gradually in a specific order in successive models, we are able to manage the system complexity.

We work with five different models: The requirement model: this model aims to capture the functional requirements. The analysis model: this model aims to give the system a robust and changeable object structure. The design model: aims to adopt and refine the object structure to the current implementation environment. The implementation model: aims to implement the system, The test model: aims to verify the system.

The models developed associated with the processes that produce them

Analysis

Construction

Testing

Requirements model Analysis model

Design model

Test model

Implementation model

Models(contd.) Each model tries to capture some part or aspect of the system to be built. These models are the output of the activities shown in figure on the last slide. The basic idea with these models is to capture right from the start all the functional requirements of the system from the users perspective.

Architecture:system development includes the development of different models of a software system. Our goal is to find out a powerful modeling technique( language or notation) for each of these models. Such a set of modeling techniques( one for each model) defines the architecture upon which the system development method is based. Or architecture of a method is the denotation of its set of modeling techniques.

A modeling technique is described by means of syntax,semantics and pragmatics. By syntax we mean how it looks, semantics is what it means and by pragmatics we mean the heuristics and other rules of thumb for using the modeling technique. To build models, we require a method to show us how to work with the modeling techniques in order to develop systems. The method describes how we, with the aid of modeling techniques, can create models of different systems. The specific system architecture is therefore the result obtained after applying a method to the system.

Architecture(contd.) In concern with object orientation we can regard the architecture as a class. For each system we design, we create an instance of this class. All system architectures have the same characteristics(modifiable, understandable and so on) but they can all look different. The development method can be seen as an operation on this architecture, where parameters can be requirement specification , implementation environment and so on.

New system(Req. spec, impl. environment

Architecture New instances are created System A instance System B instance System C instance

Development processes: instead of describing a project in a waterfall description , the development work for a specific product is divided among processes, where each of these processes describes one activity of the management of a product. Each process handles a specific activity of the system development. The main processes are the analysis, construction and testing processes. There is also a component development process.

Analysis process: in this process we create a conceptual picture of the system we want to build. Here the requirements model and the analysis model are build. Here the requirement model and the analysis model are developed in order to understand the system and to communicate it to its orderer and to the construction process. Construction process: in this process we develop the system from the models created within the analysis process . this process develops two models: the design model and the implementation model. This process thus includes the implementation and results in a complete system.

Testing process: this process integrates the system, verifies it and decides whether it should be passed on for delivery. This process develops test model. Component development process: this process mainly communicates with the construction process. This process develops and maintains components to be used during construction. The components are implemented code that can be used in several different applications.

Processes and models: during a development we create models of the system we are to design. To design these models,we work from a process description that describes the process with which we develop the system. Each process takes one or several models and transforms it into other models. The final model should be a complete and tested description of the system. This description normally consists of source code and documentation. Systems requirement specification can be regarded as an initial model within our chain of transformations.

Requirement model Design Analysis model

Design model Implementation Model

Implement ation

The construction process with its major sub processes

Requirement model Design Model Implementation model

Test model

Unit testing

Integration testing

System testing

Testing processes with its major sub processes

Model Architecture
The system development is basically concerned with developing models of the system. The work is concerned with both identifying and describing objects, and with building models using these objects. For each model we develop, there exist different types of objects. By modeling with objects in all models , we gain all the benefits of object-orientation.

Model Architecture
The object should be obvious, tangible things, things that we can focus on. Model architecture basically describes how good an object model is? The most important criterion is that it should be robust against modification and help the understanding of the system. As we know for certain that all systems we build will be modified, we must create a robust model structure.

Model Architecture
Therefore we must analyze how modification will affect the system. Our structure should be affected by this analysis.

Requirement Model
The requirement model aims to capture the functional requirements of the system. This model consists of.. A use case model. Interface description. A problem domain model.

Use Case Model

The use case model uses actors and use cases. These concepts are simply an aid to define what exists outside the system(actors) and what should be performed by the system (use cases). The actors represent what interacts with the system. They represent everything that needs to exchange information with the system.

Use Case Model(contd.)

Actors are not like other objects in the sense that their actions are non deterministic. Besides this the user is the actual person who uses the system whereas the actor is the certain role played by the user. For example for a system we may have the actors pilot and clerk and Rahul may be a user who acts sometimes as clerk and some times a pilot. Actors can be considered as an actor and user as an instance of the actor class.

Use Case Model(contd.)

An instance of an actor carries out a number of different operations on the system. When a user uses the system he will perform a behaviorally related sequence of transactions with the system. We call such a special sequence as a use case. Basically use cases represent the different ways in which a system can be used by the users. For example for a library system the use cases should be.

Use Case Model(contd.)

Issue-book. Query book. Return-book. Create member. Add-book etc.

Use Case Model(contd.)

Roughly speaking use cases correspond to the high level requirements of the system. A use case typically represents a sequence of interactions between the user and the system. These interactions consists of one main line sequence which is the normal sequence of interactions between the user and the system. Several variations to the main line sequence may also exist. Which are known as alternate paths. The main line sequence and each of the variations are called scenarios or instances of the use cases.

Use Case Model(contd.)

A use case can be viewed as a set of related scenarios. Each scenario is a single path of user events and system activity through the use case. Use cases can be represented by drawing a use case diagram and writing an accompanying text elaborating the drawing. A use case is shown by an ellipse with the name of the use case written inside the ellipse.

Use Case Model(contd.)

All the ellipses of the system are enclosed within a rectangle which represents the system boundary. The name of the system appears inside the rectangle. The different users of the system are represented by using the stick person icon which is normally referred as an actor.

Play move Player Tic-tac-toe game

Use case model

Interface description: This specifies in detail what the user interface will look like where the use cases are performed.

Problem domain model: This model is used to identify objects that represent occurrences in the problem domain to give a conceptual picture and better understanding of the system.

Use Case Driven Design

Since the requirement model is based on use case model, the whole system model will be use case driven. When we need to change the system behavior, we remodel the appropriate actors and use cases. As we have traceability through all the models, we will be able to modify the system from new requirements. We ask the users what they want to change and see directly where these changes should be made in the other models.

Use Case Driven Design

We can discuss the requirement model with the users and find out their requirements and preferences. This model is easy to understand and formulate from the user perspective, so we can easily talk to the users and see if we are building the correct system according to their requirements.

Use Case Driven Design

Use case model can also be supported by using a proto type of user interface. In this way we can simulate the use cases for the users by showing the user the views that she or he will see when executing the use case in the system to be built. Use case model controls the formulation of all other models .

Use case model

May be expressed in terms of Implemented Structured Realized by Tested in by by Domain Object model Analysis model Design model Implementation model Testing model

Analysis Model
After developing the requirement model which aims to define the limitations of the system and to specify its behavior, and getting approval from the orderer, the development of the actual system starts with the development of the analysis model. This model aims to structure the system independently of the actual implementation environment. The focus is on the logical structure of the system which would be robust and maintainable structure that is also extensible.

The objects of the analysis model: Many future changes may come from changes in the implementation environment, but since our system is independent of the actual implementation environment, these changes will not affect this logical structuring. Using very few changes in this logical structure we can adapt the actual implementation environment.

In the information space of this model, there are three dimensions Information, behavior and presentation. Information dimension specifies the information held in the system. The systems internal state is defined along this dimension. In the behavior dimension, we specify the behavior which the system will adopt. The presentation dimension provides the details for presenting the system to the outside world.

Behavior

Information

Presentation The dimensions of the analysis model

The analysis model is built by specifying objects in this information space. The object types used in this analysis model are entity type, interface type and control type. The entity object models information that should be held for a longer time and should typically survive a use case. All behavior naturally coupled with this information should also be placed in the entity object. Example may be a person in the system.

Entity object

Interface object

Control object

The interface object models behavior and information that is dependent on the interface to the system. An example of the interface object is the user interface functionality for requesting information about a person. The control object models functionality that is not naturally tied to any other object.

For example behavior that consists of operating on several different entity objects such as a control object calculating taxes using several different factors. The basic assumption of having three different objects is that any system change will affect only one object in the system.

The requirement model is structured in the analysis model: the analysis model is formed from the use case model. Each use case will be entirely divided into objects of three types(entity, interface and control). In the requirement model we specify the entire functionality of the system. This functionality is now structured to obtain a robust and extensible structure. The functionality specified in the use cases should be allocated to different objects. An object can be common to several use cases.

Use cases are partitioned according to the following principles.. Those use case functionalities which are directly dependent on the systems environment are placed in interface objects. Those functionalities dealing with storage and handling of information which are not naturally placed in any interface object are placed in the entity object.

Functionalities specific to one or a few use cases and not naturally placed in any of the other objects are placed in control objects. By performing this division we obtain a structure which helps us to understand the system from a logical view and also one which gives high localization of changes and thus less sensitivity to modification. As the objects are identified and specified, the relationship among the objects is also described through different types of association.

Design Model
In the construction process, we construct the system using both the requirement model and the analysis model. First we create a design model that is refinement and formalization of analysis model. The initial work when developing the design model is to adapt to the actual implementation environment.

Design Model
The analysis model is developed assuming the ideal conditions which is then adapted to the reality. The implementation environment is not introduced earlier due to the following reasons. We do not want it to affect the basic structuring of the system, since the current circumstances may change during the system life cycle.

Design Model
We can not focus on the essentials when developing the analysis model due to the complexity typically introduced while looking at the implementation environment. Design model can be regarded as a formalization of the analysis space, where we adapt the analysis model so that it fits into our implementation environment. Thus in the information space of the design model a new dimension implementation environment is added.

behavior Implementation environment Information Presentation

In design model the concept of the block is used which describes the intension of how the code should be produced. The blocks are the design objects and are represented by the rectangle. One block normally represents one analysis object. It could be possible to use several types of blocks such as interface block, entity block and control block. Changes are desirable in the design model such as split of one block into two, but it should not affect the analysis model.

The design model should be a drawing of how the source code should be structured , managed and written. To describe the communication between blocks the concept of stimuli is used. A stimulus is sent from one block to another to trigger an execution in that block. This execution may send new stimuli to other blocks. To describe a sequence of stimuli, interaction diagram in which we can describe how several blocks communicate by sending stimuli to each other, is used. Here we use use case model and describe in detail for each use case, how and which stimuli will be sent and in which order.

s1

s2 a1 a2

s3 s4 s5 a4 a3 a5

Interaction diagram where si is stimulus and ai is activity initiated

Working with design model: during the construction work we proceed from the analysis model . For each object in the analysis model, we assign a block in the design model. This transformation occurs totally mechanically and can be performed by a tool. Depending on the implementation environment we may need to make a deviation so that this one to one relationship may be modified.

When we have created the block structure, we draw the interaction diagrams to show how these blocks communicates . normally we draw an interaction diagram for every use case. Thus requirement model also forms the basis for the construction process and we can guarantee that the system we construct is exactly what the user wants.

Implementation Model
The implementation model consists of the annotated source code. The information space is the one that the programming language uses . This is not necessary to have an object oriented programming language but it is desirable since all fundamental concepts can easily be mapped on to language constructs.

Implementation Model
The base for implementation model is design model where the interface of each block is specified and the behavior of what is expected behind this interface is described. It is strongly desirable to have an easy match between a block and the actual object module. When the implementation environment is smooth, it is easy.

Implementation Model
But in case of a complex implementation environment one block may map onto 1-5 classes. The ability to use components is very powerful implementation tool.

Test Model
This is the last model developed in the system development. It describes the result of testing. The fundamental concepts in testing are mainly the test specification and the test result. Initially the lower levels such as object modules or blocks are tested by the designers. The lower subsystem levels are then tested.

Test Model
One tool for integration testing involves using the use case model to integrate one use case at a time. This is normally performed by an independent testing group. Then the whole system is tested. The requirement model again forms a powerful tool here and we see that the requirement model is verified by the testing process.

Analysis
Why an analysis process: The aim of the analysis phase is to analyze, specify and define the system to be built. The models developed in this phase describe what the system is to do. The basis of this modeling is basically the requirements of the system. It is important to carry on a dialogue with the perspective orderers and users so that the system that is built is really what is wanted.

Analysis
The models developed during analysis are fully application oriented, and no consideration is paid to the real implementation environment where the system is to be realized, for example the programming languages, DBMS, h/w configuration etc. The advantage with this procedure is that

Analysis
The architecture of the system will be based on the problems and not on the conditions prevailing during the implementation. Analysis model will remain intact, if and when the implementation conditions change.

Analysis
What is done in analysis: two different models are developed in analysis, the requirement model and the analysis model. The real base is the requirement specification and the discussion with the prospective users.

Analysis
The requirement model , delimits the system and defines its functionality. For this purpose a conceptual picture of the system is drawn using problem domain objects and specific interface description of the system is given if it is meaningful. The system is also described as a number of use cases that are performed by a no of actors.

Analysis
The analysis model gives a conceptual configuration of the system, consisting of control objects, entity objects and interface objects. The purpose of this model is to develop a robust and extensible structure as a base for construction. The analysis model comprises a total functional specification of the system we wish to develop, without any reference to the implementation environment. In the construction process the system is constructed from the analysis model.

Example System:
Following system will be used to understand the requirement model and the analysis model. The system controls a recycling machine for returnable bottles, cans and crates. The machine can be used by several customers at the same time and each customer can return all three types of items on the same occasion.

Example System:
The system will register how many items each customer returns and when the customer asks for the receipt, the system will print out what he or she deposited, the value of the returned items and the total return sum that will be paid to the customer. The system is also used by an operator. The operator wants to know how many items of each type have been returned during the day.

Example System:
At the end of the day, the operator asks for a printout of the total no. Of items that have been deposited on that machine on that particular day. The operator should also be able to change information in the system such as the deposit values of the items. If there is something amiss, for instance if a can gets stuck , the operator will be called by a special alarm signal.

Requirements Model
System development based on user requirements: the requirement model aims to delimit the system and define the functionality that the system should offer. This model could function as a contract between the developer and the orderer of the system and thus forms the developers view of what the customer wants.

Requirements Model
The requirement model will govern the development of all other models , so this model is central throughout the whole system development. The requirement model will be structured by the analysis model, realized by the design model, implemented by the implementation model and tested by the testing model. Not only will the other models be verified against the requirement model but the other models will actually be developed directly from it.

Requirements Model
Since the whole system development starts from what the users wish to be able to do with the system, we build the system from the users point of view. The requirement model consists of three parts.. 1. Use case model. 2. The problem domain object model. 3. User interface descriptions.

Use Case Model

Actors: actors model the prospective users of the system. The actor is a user type or category and when a user does something he or she acts as an occurrence of this type. For example customer in our example is an actor as well as the operator is also an actor. The same user may play more than one role.

Use Case Model

For example same person may be the operator or the customer. To differentiate between user and the actor we can think of an actor as a class and user is an instance of this class.

Use Case Model

The actors who are going to use the system directly we call primary actors. Each of these actors will perform one or some of the main tasks of the system. In our example customer is the primary actor. Besides these primary actors there are actors supervising and maintaining the system. These are secondary actors. In our example operator is the secondary actor.

Use Case Model

Use cases: A use case is a specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of events initiated by an actor and it specifies the interaction which takes place between the actor and the system.

Use Case Model

The use cases are identified through the actors. For every complete course of events initiated by an actor we identify one use case. Following questions are asked in concern of an actor. What are the main tasks of each actor?

Use Case Model

Will the actor have to read/ write/ change any of the system information? Will the actor have to inform the system about outside changes? Does the actor wish to be informed about unexpected changes? in the recycling system we can identify the use cases as returning item initiated by the customer, generate daily report and change item generated by the operator.

Generate daily report customer Returning item Change item

Operator

Use case model

All these use cases need some description which is given with this use case diagram. Extension: A powerful concept that is used to structure and relate use case descriptions is the extension association. Extension specifies how one use case description may be inserted into, and thus extend, another use case description. Extensions to use cases can be described in a very simple way and in particular changes and additions to functionality are more easily made.

In our example when an item is stuck the system should issue an alarm. We can describe this alarm as a use case description that extends the returning item use case description. The extension association is drawn with a dashed arrow since it is a class association. The instance associations are drawn with full lines. Instance associations are associations between an actor and a use case, because these are the instances of actors which communicate to the instances of the use cases.

Returning item extends

Item stuck

An other example may be a login/logout use case which is extended by all the use cases of the system.

compile extends extends

Word processing extends

mail

Login/logout

Extending use case continues the behavior of a base use case. The extending use case accomplishes this by conceptually inserting additional action sequences into the base use-case sequence. This allows an extending use case to continue the activity sequence of a base use case when the appropriate extension point is reached in the base use case and the extension condition is fulfilled. When the extending use case activity sequence is completed, the base use case continues.

Extensions are used in the following cases To model optional parts of use cases. To model complex and alternative courses which seldom occur, for instance item stuck in our example. To model separate sub-courses which are executed only in certain cases. To model the situation where several different use cases can be inserted into a special use case such as login/logout example.

Interface Description
This specifies in detail what the user interface will look like when the use cases are performed. By sketching or by using a user interface management system (UIMS) we can simulate the use cases as they will appear to the user before even thinking about how to realize them.

Interface Description
When designing user interfaces, it is essential to have users involved. By doing user interface design at this early stage, this can be guaranteed. At this stage other system interfaces such as a communication protocol that should be standardized can also be defined.

Interface Description
The recycling machine example has different kinds of interfaces. There is a customer panel including buttons, holes and alarm devices.There is also a receipt lay out, interface for operator to change information, resetting alarms, requesting day summaries and so on.

Problem Domain Objects

When working with the requirement model it can sometimes be difficult to define task of the system and especially the system boundaries. This is the case when the requirement specification is not very clear. Thus the logical view of the system is developed by using problem domain objects, the objects which have direct counterpart in the application environment.

Problem Domain Objects

This problem domain object model is used to design use cases. The problem domain objects should be identified along with the following attributes. Object name. Logical attributes. Instance associations. Inheritance.

Problem Domain Objects

Operations. In the recycling example the problem domain objects would be deposit item which would be of type can, bottle or crate , receipt and customer.

Returned item Deposit item

My receipt

receipt

customer

can

crate bottle

Problem domain model

Problem domain model can be used for following purposes. It supports in the formulation of use case description To gain a better understanding of the system. This is used when doing enterprise modeling.

Further Refinement of the Requirement Model

The requirement model can be elaborated further to enhance reuse and to prepare the transition to the analysis model. The refinement is mainly done by identifying similar parts of the use cases and extracting these similar parts. In this way we only describe the similar part only once instead of in all use cases showing this behavior.

Further Refinement of the Requirement Model

Any change to this part will automatically affect all use cases that share this part. We call the use cases that we extract abstract use cases since they will not be instantiated on their own but are only meaningful to describe parts that are common to other use cases. We call the use cases that really will be instantiated concrete use cases. The relationship between the abstract use case and the concrete use case is called uses.

Further Refinement of the Requirement Model

In our example the returning item and generate daily report will both print out a receipt. We can thus identify an abstract use case print that performs the printing.

uses

Print

uses

Returning item

Generate daily report

Further Refinement of the Requirement Model

A technique to extract abstract use cases is to identify abstract actors. An abstract actor typically describes a role that should be played against the system by more than one actor. When different actors play similar roles, they may inherit a common abstract actor. The advantage of abstract actor modeling is that it expresses similarities in use cases. If same use case is performed by several actors, the use cases need be specified only with respect to one actor instead of several actors.

Further Refinement of the Requirement Model

In our example the operator and the customer both receives the receipt. We can thus find out an abstract actor receipt receiver.
inherits inherits Receipt receiver operator

customer

The Analysis Model

When the requirement model has been developed and often also signed off by the orderers, analysis model is developed to focus on the structuring of the system. In the analysis model we describe the system using three different types of object: interface object, entity object and control object. Each of these objects has its own purpose and will model one specific aspect of the system.

The Analysis Model

Subsystem are used to group these objects into manageable units. The analysis model aims at creating a good platform for the system design. The requirement model is thus structured by the analysis model. In analysis model the behavior specified in the use case description is distributed among the objects.

The Analysis Model

An object can be common to several different use cases. Thus it should be explicitly specified that which object is responsible for which behavior in the use case. Interface objects: all functionality specified in the use case descriptions that is directly dependent on the system environment is placed in interface objects. It is through these objects that the actors communicate with the system.

The Analysis Model

The task of an interface object is to translate the actors input to the system into events in the system and to translate those events in the system that the actor is interested in into something which is presented to the actor. There are three strategies to identify interface objects They are clearly identified from the system interface description accompanying the requirement model.

The Analysis Model

Starting from the actor. Reading the use case description and extracting the functionality that is interface specific. In our example of recycling machine, the customer actor needs an interface object to the system. The customer needs a panel with a push button and a slot to insert the item.

The Analysis Model

The operator needs his panel to change the information in the system and to generate the daily report. As well as we need an interface object to call the operator when an alarm is issued and an interface object to print out the receipt. The short description for the interface objects should be given. The same interface objects are identified from the use case description.

The Analysis Model

Customer panel: the functionality that manages the sensors in the deposit slot, start button and receipt buttons. Operator panel: interface for changing information in the system and for generating daily reports.

The Analysis Model

Alarm device: controls a signal device and also has a reset button for that device. Receipt printer: writes text on a paper roll. After print out the paper is cut off. When the paper roll is almost finished the operator should be called through the alarm device.

The Analysis Model

The interface objects are not independent of each other. They must know of each other. For instance the receipt printer should know which alarm device to sound when the paper roll is finished. This is solved by the acquaintance associations between the objects.

The Analysis Model

An acquaintance association is a static association between instances and means that an instance knows of the existence of another instance but does not give the right to exchange information with the other object. The cardinality of an association says how many same class instances can be associated to an object. Acquaintance association is given a name clarifying what the relationship entails.

The Interface Objects and Acquaintance Associations of the Recycling Machine

Receipt printer

Operator panel

Customer panel Alarm device

Analysis Model
A special type of acquaintance association is the consists of association which is used to state that an object is composed of other objects. For example the customer panel contains the buttons and slots to insert the deposit item which can become interface objects in their own right. The customer panel is then called the central interface object and the hierarchy thus formed is called the containment hierarchy or the partition hierarchy.

Example of Containment Hierarchy

Customer panel Crate slot

Can slot Receipt button

Bottle slot

Analysis Model
To identify which part of the flow in a use case should be allocated to interface object, ,the interaction between the actors and use cases is analyzed. Look for the units displaying one or more of the following characteristics They present information to the actor or request information from them.

Analysis Model
Their functionality is changed if the actors behavior is changed. Their course is dependent on a particular interface type.

Analysis Model
Following are some strategies for allocating the functionality among different types of objects.. Computation dominant control or embedded control: is where we place the controlling functionality inside the system i.e. In the control objects and in the entity objects. Here the interface objects do not have very much functionality. This structuring can be efficient in execution but hard to prototype from.

Analysis Model
Dialogue dominant control: is where we place much control functionality in the interface objects and these objects model much of the functionality of the system. In this case we do not have many control objects in the model. This strategy is easy to prototype from but increases the complexity of the interfaces. Mixed control: places the control on both sides allowing invocation of dialog from the computational side and vice versa.

Analysis Model
Balanced control: is where we separate the control from both the dialogue and the computation. The global control component which typically is a control object, governs sequencing among invocation of dialogue and computational functions.

Analysis Model
Entity objects: to model the information that the system will handle over a longer period of time, entity objects are used. Besides the information to be handled, the behavior that naturally belongs to this information is also allocated to the entity object. The entity objects are identified from the use cases.

Analysis Model
For example consider the use case description from the recycling machine example When the customer returns a deposit item, it is measured by the system. The measurements are used to determine what kind of can, bottles or crates has been deposited. If accepted the customer total is incremented as is the daily total for that specific item type. If the item is not accepted , the light for NOT VALID is highlighted on the panel.

Analysis Model
When the customer presses the receipt button , the printer prints the date. The customer total is calculated and the following information is printed on receipt for each item type. Name. Number returned. Deposit value.

Analysis Model
Total for this type. Finally the sum that the customer should receive is printed on the receipt.

Analysis Model
By analyzing this use case we can identify the entity objects can, bottle and crate which have some common properties inherited from the entity object deposit item. Another entity object is receipt basis which will model the information for the items deposited by a specific customer.

Analysis Model
Any entity object and its attributes can be shown in the following manner.
Attribute[1] Type

Here type is the data type of the attribute such as String, Integer etc.

Analysis Model
For example
ECU Name[1] Deposit item String Integer

Analysis Model
Entity Objects necessary to deposit items in the recycling machine
Item[0-n] Receipt basis Deposit item inherits inherits inherits can bottle crate

Analysis Model
Operations on entity objects: The only way to manipulate an entity object is via the operations. Therefore the identified operations must be sufficient for all those who wish to use the entity objects. The detailed description of the use cases is the extremely valuable means of finding the desired operations.

Analysis Model
The whole course of events is described in the use cases, and by extracting those parts that concern our entity object, the operation will appear. The following is a list of typical operations that must be offered by an entity object. Storing and fetching information.

Analysis Model
Behavior that must be changed if the entity object is changed. Creating and removing the entity object.

Analysis Model
An operation on an entity object may mean that the entity object contacts another entity object and asks for information about something. This communication takes place through communication associations. A communication association models communication between two objects. Through this association an object sends and receives stimuli.

Analysis Model
The association starts from the object that is to perform manipulation and is directed to the object where the manipulation is to take place. Since it is an instance association, it is solid and it is dynamic association.
Receipt basis Deposit item

Receipt basis increments the deposit item no when a new item has been received

Analysis Model
Control Objects: In more complex use cases, there often remains behavior that is not naturally placed in either of two object types. Such behavior is placed in control objects. The control objects typically act as glue which unites the other objects so that they form one use case.

Analysis Model
Control objects are normally found directly from the use cases. Typical types of functionality placed in the control objects are transaction-related behavior or. Control sequence specific to one or a few use cases or. Functionality that separates the entity objects from the interface objects.

Analysis Model
In our recycling machine example following are the control objects

Deposit item receiver extends Alarmist

Report generator

Information administrator

Analysis Model
Working with the analysis objects: When working on the development of the analysis model, normally we are working with one use case at a time. Thus for one specific use case we identify interface objects , entity objects and control objects before continuing with the next use case. Since one object may participate in several use cases, this process is iterative.

Analysis Model
This means that when a set of objects already exist, these may be modified to fit also the new use case. The goal is to form as stable a structure as possible. The specification of the objects should be written in text form. Each objects role and responsibilities should be described.

Analysis Model
When the objects have been identified and described, though we may describe how the objects offer the use case, not as formally as specifying what stimuli will be sent between the objects, but in a more prose-like form. A use case view of the objects is created initially which shows how they will be used in the use case. Then we may describe the the use case in terms of these objects to show how they will provide the use case.

Customer panel

Deposit item receiver Item[0..n]

Receipt printer

Receipt basis

Deposit item inherits inherits can bottle inherits

crate

Use case view for the objects of use case returning items

Use case description: When the customer returns a deposit item, it is measured by the system. The measurements are used to determine what kind of can, bottles or crates has been deposited. If accepted the customer total is incremented as is the daily total for that specific item type. If the item is not accepted , the light for NOT VALID is highlighted on the panel.

When the customer presses the receipt button , the printer prints the date. The customer total is calculated and the following information is printed on receipt for each item type. Name. Number returned. Deposit value. Total for this type. Finally the sum that the customer should receive is printed on the receipt.

When the customer returns a deposit item the customer panels sensor measure its dimensions. These measurements are sent to the control object Deposit item receiver which checks via Deposit item whether it is acceptable. If so ,, Receipt Basis increments the customer total and the daily total is also incremented. If it is not accepted, Deposit Item receiver signals this back to Customer panel which signals NOT VALID.

When the customer presses the receipt button, customer panel detects this and sends this message to deposit item receiver. Deposit item receiver first prints the date via receipt printer and then asks the receipt basis to go through the customers returned item and sum them. This information is sent back to deposit item receiver which asks receipt printer to print it.

Sub systems: when the analysis objects have been identified, the system will contain a large no of objects.for a medium sized project, typically between 30 & 100 objects will be specified. These objects need to be placed in a group to find the clear overview of the system. Such groups of objects are called subsystems. The system thus consists of a no. of sub systems. Which can themselves contain sub systems.

Subsystems are thus a way of structuring the system for further development and maintenance. The task of sub systems is to package the objects so that the complexity is reduced. The lowest level of sub systems is to be viewed as a change unit. We call these units service packages. These should be viewed as atomic, I.e. if the customer wants it, he will have whole of it, otherwise he will get nothing.

The most important criterion in subsystem division is predicting what the system changes will look like and then making the division on the basis of this assumption. The division into subsystems should also be based on functionality of the system. All objects which have a strong mutual functional coupling will be placed in the same sub system.

Another criterion for the division is that there should be as little communication between different subsystems as possible.

In our recycling machine example the following subsystems can be considered. Alarm: consisting of all the objects concerning alarm activity. Deposit: consisting of all the objects related to deposit of the items. Administration: consisting of all the objects involved in the management of the system.

alarm alarmist extends deposit Receipt printer Operator panel

Report generator Customer panel Deposit item receiver Receipt printer Item[0..n] Deposit item Receipt basis inherits inherits inherits crate

Alarm device

administration

can

bottle

In small systems the subsystem division is done in the end of analysis while in large system may be done much earlier.Thus for large systems there may be some other criteria for division. Following are few of these criteria Different development groups have different competence or resources and it may be desirable to distribute the development work accordingly. In a distributed environment , a subsystem may be required at each logical node. If an existing product can be used in this system,this product may be regarded as a subsystem.

Assignment 1
Compare various life cycle models of software development. Explain Object oriented approach of software development. How requirement elicitation is managed? Explain requirement elicitation activities in detail.