Lecture 1

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

System development:OOSE may be used from the time that the requirement specification exists in some form and all through the system¶s 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. ‡ Block design.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.

. 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. This style of programming has been used .Object Oriented Programming Object oriented programming essentially means programming using objects and the other concepts related to objects. until recently .

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

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

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. .Block design:the idea of block design is taken from hardware design where a no. each providing a specific functionality. Of modules. are connected together with well defined interfaces . The OOSE has satisfied this need.

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

We work with five different models: The requirement model: this model aims to capture the functional requirements. The test model: aims to verify the system. The design model: aims to adopt and refine the object structure to the current implementation environment. . The analysis model: this model aims to give the system a robust and changeable object structure. The implementation model: aims to implement 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 user¶s 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. Or architecture of a method is the denotation of its set of modeling techniques. Such a set of modeling techniques( one for each model) defines the architecture upon which the system development method is based. .

we require a method to show us how to work with the modeling techniques in order to develop systems. with the aid of modeling techniques. The method describes how we. 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. can create models of different systems. The specific system architecture is therefore the result obtained after applying a method to the system.A modeling technique is described by means of syntax.semantics and pragmatics. . By syntax we mean how it looks.

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

New system(Req. impl. spec. environment Architecture New instances are created System A instance System B instance System C instance .

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

. 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. This process thus includes the implementation and results in a complete system. 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. Here the requirements model and the analysis model are build.Analysis process: in this process we create a conceptual picture of the system we want to build.

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

.Processes and models: during a development we create models of the system we are to design. The final model should be a complete and tested description of the system.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. This description normally consists of source code and documentation. To design these models. System¶s 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 .

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

tangible things. 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.Model Architecture The object should be obvious. . we must create a robust model structure. things that we can focus on.

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

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

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

. 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.Use Case Model(contd.) Actors are not like other objects in the sense that their actions are non deterministic. Actors can be considered as an actor and user as an instance of the actor class.

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«.) An instance of an actor carries out a number of different operations on the system.Use Case Model(contd.

Create member. Add-book etc. .Use Case Model(contd. Query book.) Issue-book. Return-book.

) Roughly speaking use cases correspond to the high level requirements of the system. Which are known as alternate paths. 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. The main line sequence and each of the variations are called scenarios or instances of the use cases. Several variations to the main line sequence may also exist.Use Case Model(contd.

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

.Use Case Model(contd. The name of the system appears inside the rectangle.) All the ellipses of the system are enclosed within a rectangle which represents the system boundary. 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.

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

. 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 We can discuss the requirement model with the users and find out their requirements and preferences.

Use case model controls the formulation of all other models . .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 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. the development of the actual system starts with the development of the analysis model. and getting approval from the orderer. 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. these changes will not affect this logical structuring. but since our system is independent of the actual implementation environment. Using very few changes in this logical structure we can adapt the actual implementation environment. .

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

Behavior Information Presentation The dimensions of the analysis model .

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

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

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

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

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

As the objects are identified and specified. . 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.Functionalities specific to one or a few use cases and not naturally placed in any of the other objects are placed in control objects. the relationship among the objects is also described through different types of association.

. 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. we construct the system using both the requirement model and the analysis model.Design Model In the construction process.

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

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. Design model can be regarded as a formalization of the analysis space.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. .

behavior Implementation environment Information Presentation .

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

interaction diagram in which we can describe how several blocks communicate by sending stimuli to each other. 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 the communication between blocks the concept of stimuli is used. To describe a sequence of stimuli. how and which stimuli will be sent and in which order. . managed and written.The design model should be a drawing of how the source code should be structured . is used. Here we use use case model and describe in detail for each use case.

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 . 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. For each object in the analysis model. we assign a block in the design model.

normally we draw an interaction diagram for every use case. .When we have created the block structure. we draw the interaction diagrams to show how these blocks communicates . 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. 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. . The information space is the one that the programming language uses .

When the implementation environment is smooth. it is easy. .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.

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

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

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.

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.

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 «

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.

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

The system is also described as a number of use cases that are performed by a no of actors. 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. .Analysis The requirement model .

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

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. The system controls a recycling machine for returnable bottles.Example System: Following system will be used to understand the requirement model and the analysis model«. . cans and crates.

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. the value of the returned items and the total return sum that will be paid to the customer. the system will print out what he or she deposited.Example System: The system will register how many items each customer returns and when the customer asks for the receipt.

Of items that have been deposited on that machine on that particular day. the operator asks for a printout of the total no.Example System: At the end of the day. If there is something amiss. for instance if a can gets stuck . The operator should also be able to change information in the system such as the deposit values of the items. 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 developer¶s 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.

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

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 Use cases: A use case is a specific way of using the system by performing some part of the functionality. .

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

generate daily report and change item generated by the operator.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 customer Returning item Change item Operator Use case model .

and thus extend. Extension specifies how one use case description may be inserted into.All these use cases need some description which is given with this use case diagram. 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. . Extension: A powerful concept that is used to structure and relate use case descriptions is the extension association.

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

Returning item extends Item stuck .

compile extends extends Word processing extends mail Login/logout .An other example may be a login/logout use case which is extended by all the use cases of the system.

When the extending use case activity sequence is completed. the base use case continues. The extending use case accomplishes this by conceptually inserting additional action sequences into the base use-case sequence. .Extending use case continues the behavior of a base use case. 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.


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

. 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 This specifies in detail what the user interface will look like when the use cases are performed.

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

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

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.

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

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

Returned item Deposit item My receipt receipt customer can crate bottle Problem domain model .

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

In this way we only describe the similar part only once instead of in all use cases showing this behavior. The refinement is mainly done by identifying similar parts of the use cases and extracting these similar parts.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. .

.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. The relationship between the abstract use case and the concrete use case is called uses. We call the use cases that really will be instantiated concrete use cases.

Further Refinement of the Requirement Model In our example the returning item and generate daily report will both print out a receipt. uses Print uses Returning item Generate daily report . We can thus identify an abstract use case print that performs the printing.

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

inherits inherits Receipt receiver operator customer . We can thus find out an abstract actor ³receipt receiver´.Further Refinement of the Requirement Model In our example the operator and the customer both receives the receipt.

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

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 Subsystem are used to group these objects into manageable units. The analysis model aims at creating a good platform for the system design.

The Analysis Model An object can be common to several different use cases. . Interface objects: all functionality specified in the use case descriptions that is directly dependent on the system environment is placed in interface objects. Thus it should be explicitly specified that which object is responsible for which behavior in the use case. 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 actor¶s 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. .

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

. The short description for the interface objects should be given. 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 same interface objects are identified from the use case description.The Analysis Model The operator needs his panel to change the information in the system and to generate the daily report.

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.

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

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

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. . Acquaintance association is given a name clarifying what the relationship entails. The cardinality of an association says how many same class instances can be associated to an object.

The Interface Objects and Acquaintance Associations of the Recycling Machine Receipt printer Operator panel Customer panel Alarm device .

The customer panel is then called the central interface object and the hierarchy thus formed is called the containment hierarchy or the partition hierarchy.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. .

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.

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

. Computation dominant control or embedded control: is where we place the controlling functionality inside the system i. Here the interface objects do not have very much functionality. In the control objects and in the entity objects.e. .Analysis Model Following are some strategies for allocating the functionality among different types of objects. 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. . Mixed control: places the control on both sides allowing invocation of dialog from the computational side and vice versa. This strategy is easy to prototype from but increases the complexity of the interfaces.

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

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

the light for NOT VALID is highlighted on the panel.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. . If the item is not accepted . bottles or crates has been deposited. The measurements are used to determine what kind of can. If accepted the customer total is incremented as is the daily total for that specific item type.

Deposit value. Number returned. Name. .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.

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

Another entity object is receipt basis which will model the information for the items deposited by a specific customer.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. .

Integer etc. .Analysis Model Any entity object and it¶s attributes can be shown in the following manner. Attribute[1] Type Here type is the data type of the attribute such as String.

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. . The detailed description of the use cases is the extremely valuable means of finding the desired operations. Therefore the identified operations must be sufficient for all those who wish to use the entity objects.

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

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

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

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. it is solid and it is dynamic association. Since it is an instance 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.

Control sequence specific to one or a few use cases or.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. . 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. . Thus for one specific use case we identify interface objects . Since one object may participate in several use cases. this process is iterative. normally we are working with one use case at a time. entity objects and control objects before continuing with the next use case.

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

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

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 ..

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

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

When the customer returns a deposit item the customer panel¶s sensor measure it¶s 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 customer¶s 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.

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

All objects which have a strong mutual functional coupling will be placed in the same sub system. . The division into subsystems should also be based on functionality of the system.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.

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

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

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 .

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 .this product may be regarded as a subsystem. .In small systems the subsystem division is done in the end of analysis while in large system may be done much earlier. a subsystem may be required at each logical node. If an existing product can be used in this system.

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

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.