An investigation of business processes and workflow is important, as well as any understanding you have of the Rational Unified Process OO model. Project management of an e-business application is required, along with careful selection of packaged solutions for E-business and the Software Development Process. Let us have a closer look at what I described in Topic 2.
Business modelling advice for client-server application developers
E-systems developers need to improve and 'scale-down' the development and communication effectiveness of the final design for a small-to-medium sized vendor. I suggested using four strategic techniques in Topic 2 as part of your business intelligence strategy. These included:
1. the Balance Scorecard (BSC) method (recommended by Microsoft);
2. use of self-service approach for SME solution development;
3. value-added ethical model dealing with integrity, security and social impact, across all business decision-making activity;
4. use of a peer review evaluation process, to help tie it all together.
This will be important in any client/server design report where you must give time and effort to defining the Problem Domain of the application, including cost/benefit analysis and defining the nature of the project team members. Some useful headings to use here are:
1.1 Define the problem
1.2 Business needs of the organisation and the audience/end-users
1.3 Scope (limits) to designing a solution.
The Balanced Scorecard methodology and 4E Business goals of economy, efficiency, effectiveness and empowerment, helps organisations determine why software applications play a vital part in any scorecard implementation process – e.g. using Client/server applications like Web services. It was interesting to note that the business decision may lead to .NET being used in BSC categories of customer relationship, while J2EE may best be deployed in the category of business processes.
I would also add stakeholder analysis in the client/server design, which includes examining the skill sets of all stakeholders:
The developer The vendor The customer | (you) (your client) (the vendor's customer) |
Business process modelling
According to Fournier (1999) and Sparks (2000), a business process is defined as:
Sparks (2000) has a diagram (Figure 9.1) that illustrates how the various model elements may be grouped together to produce a coherent picture of a named business process. Included are the inputs, outputs, events, goals and other resources which are of significance.
Towards a value-added ethical design
E-commerce applications in client/server development grow so quickly that it makes it very hard to maintain ethics in online systems with problems in protecting personal integrity, privacy and securing against events such as identity theft. Lind (1997) suggests that a conceptual understanding of how business process modelling is needed can include ethical values as a way of increasing value created by the business process. High satisfaction with the delivery promise and payment systems builds the trust needed in the long run. People value privacy and their personal integrity, but computerised record keeping in online databases can disturb feelings of trust in online information exchange. Add to that e‑mail spamming where some users have second thoughts about filling in a form requesting an e-mail address.
It is in the client/server application design process where it is necessary to address security problems in such a way as to bring back feelings of trust in all stakeholders.
The mystique of the 'afterlife'
Each software system has a product lifecycle and an 'afterlife' involving evaluation by the vendor and customers. By getting a group of peers to pose as customers or users, this 'afterlife' can be simulated. Consider the likely 'shelf-life' and software maintenance plan for your design. This will build trust in you and your application.
Project management workflows
Software engineering requires project management techniques for configuration and change management, and the early use of quality assurance methods. Make sure that plenty of time is allocated to requirements gathering, as noted in the textbook. Remember to analyse the impact of the nature of the project on proceedings and the four roles of a software development process:
· To provide guidance to the order of the team’s activities
· To define the artefacts of the process
· To direct the tasks of the team
· To offer criteria and methods for monitoring and measuring progress.
Model-View-Control Architecture
Model View Controller (MVC) modeling began with Smalltalk and has been rediscovered by the latest Web application frameworks that are based on the Model View Controller architecture. If the design requires an n-tier, Web application, then the UML tools and techniques should support designing with MVC architecture.
MVC modeling support with UML will organise and provide a detailed design within the MVC layers. Hence the readability of the model is enhanced by use of an overall design approach that is a blend of:
· Business process modeling
· Web framework with the MVC design architecture
· UML support within MVC
Analysis of requirements and use cases
Defining the process begins with describing the underlying client/server architecture. One of the activities that Conallen (2003) states, is to examine the Use Case Model from a technical viewpoint.
A requirements specification, a project plan and the construction of an object-oriented model for a software system that will function on the Web, are required. This chapter provides some guidelines for gathering, prioritising and writing the requirements specification document. Some students with an object modelling background will have a chance to sharpen their skill.
Cockburn, A 1997, Surviving Object-Oriented Projects, Addison-Wesley is a good reference for those wishing to concentrate on the project management of a Web application, with an emphasis on incremental development.
In some ways this subject is an introduction to object modelling with the Use Case model, (if you have not done an object modelling subject before), where Use Case diagrams are a big part of the Unified Modelling Language (UML). CASE tools for UML exist for C++ and Java developers, such as Rational Rose (http://www.rational.com). You may like to draw pencil diagrams or use any drawing program to help draw any of the eight (8) main modelling diagrams in UML, where required. Your draft designs can be in pencil! Old habits in IT die hard . . . . I still like to think and design with paper!
Use Case, Class, Sequence, Collaboration, State chart, Activity, Component and Deployment diagrams are used in UML. Describe each of the eight (8) main diagrams used in UML.
Use Case and Activity Diagrams help you to describe system functional requirements - it is important to note that the user may be a human or another software or hardware process. In either case it is referred to as an actor.
Use Cases help with the problem of definition of requirements and analysis. Use a table (see below) to start your thinking, where business processes are taken from the SME and an object modelling table is used to help show development of your ideas, using very simple object modelling techniques. Here is a simple way to model your objects. Use the level 1 and 3 tables for designing any object in the e-business application:
Level 1 – User and system tasks table
Make a list of things done by the user and the system.
Level 2 – Abstraction
The next step is called finding the level of abstraction, where the business objects build on each other to form classes from the most general and abstract – root class, to the more refined and concrete. What could be more concrete than an automatic telling machine (ATM)? Here the actor is human and the use case are withdraw cash; make a deposit; or request a balance.
So, by the end of this step, you should have a good idea about which list classes to use or make, for your design.
Level 3 – Object description table
· Use the level 3 table below to detail your design with the example used in object-oriented design.
In my days as a structured programmer, it was revealed how Pseudocode describes in general terms what any method is supposed to do.
Object No. | Object name | Class | Description | Verbs | Properties |
Relationships can exist between use cases in use case diagrams, while activity diagrams are useful in describing the temporal sequencing of use cases.
Use Case model and the online customer (actors)
Use Case diagrams describe an external view of the system and its interactions with the outside world – similar to the use of a context diagram. An actor, playing a role by various people or computer process, sees this external view.
The actor’s goals and not the systems functions are described. A person may play many roles, and a role may have many people playing it – familiar to the one-to-many relationships in a data model. Use case diagrams:
· are connected to scenarios;
· have a communication association with an actor;
· are a collection of actors, use cases and communications;
· help to determine system requirements;
· help develops to explain the system to clients; and
· are used to produce test cases.
Figure 9.2 is an example of a Use Case diagram for the customer role at an online bookstore.
Rapid evolutionary prototyping for Web applications
This approach mentioned at the beginning of the Study Guide, has an exploration phase and a development phase. In the exploration phase, the developer is used to find the use cases, as well as to model the problem domain and define the architecture. It is in the development stage that the rapid prototyping takes place, with the client and developers seeing a visible, tangible system as construction unfolds. Evolutionary development is often called incremental or iterative development, where each increment contains a full cycle of analysis, design, coding, testing and integration. After each increment is completed, a prototype may or may not be delivered to the client. Each delivery requires 'finishing school' – this where the system may become unstable or hard to maintain, once it is moved to the production site.
Agile software design: Extreme programming
If you feel the need to learn more about software design principles, UML modelling and agile software design are gaining popularity. Extreme Programming (XP) appears to be the most popular of agile methods, and is having success with businesses (SME's and students) who struggle with conventional paradigms. XP is a set of practices that are simple, but interdependent among team members. It has shorter cycles delivering 'working software' every two weeks, with all production code written by pairs of programmers (with possible reduction in the defect rate). User stories and acceptance testing methods vary on user stories and using QA people to help. A book to help here is:
Martin, R. C. (2003). Agile software development: Principles, patterns and practices. Upper Saddle River, New Jersey: Prentice Hall.
At this point you should have your requirements and use cases determined for your project as it is developing under a project management plan using the rapid evolutionary prototyping approach or an agile software development method. Inside each increment you may need to do the analysis and produce a model of the Web application, with the design on the horizon as a refinement of the analysis model. This is where an OO analysis and design methodology can save costs by moving faster into the implementation of the design.
Packages for the Online Shopfront analysis model
'Packaging' helps to manage the size and complexity of the analysis model by breaking it down into chunks called packages. Each package contains parts of the model such as class, diagrams, components, interfaces etc. You can see the similarities here with the way the hierarchies work in the Java language, where classes can be declared public or private. Conallen (2003) describes how a package can also be a hierarchy of packages, by using the example of a User Interface package, which is shown graphically as a 'tabbed folder' in the top-level use case diagrams.
User Interface Package contains:
ActiveX – enabled UI package
Java – enabled UI package
E-commerce system packages
The development of the Online store package containing sub-packages for an E‑catalogue, Shopping Cart, and Customer Profile is a common solution to core business processes. Start with the top-level use case diagram packages and examine the use cases and functional requirements, so that you can further sub-divide the model – eventually into classes of objects. The Java language hierarchy works in a similar way.
Object Modelling and UML extension for WEB
The problem-solving process at some stage requires algorithm descriptions for methods and actions - when passing a message to an object, particularly for the event-driven processes that may exist behind fields and buttons in a user interface. However it becomes apparent that a holistic model of the development environment is required; this process is part of the Object Modeling Technique (OMT), which can be used to describe Java Classes. Class diagrams, using symbolic notation, are an important part of the object modeling process, and can be extended by the use of Form diagrams. When a new Java construct is introduced, its syntax is shown in a form or template style, revealing how a feature is constructed using Java statements.
Object modeling (class design) consists of a set of one or more interrelated classes. Classes describe the properties and actions of the object in real life that the program has to manipulate. Once a class is described, many objects of that same class can be created, but not every class is related to every other class and relationships can vary. Depending upon which OMT style you adopt, the notation used to illustrate object-oriented programs will reveal the different relationships with various symbols such as arrows, diamonds and triangles. An object is a real-life example of a class description. Many objects can be considered as nouns - book, pen, and student. When the program generates new objects, they exist as a new instance of a class.
Declarations, methods and constructors
The properties of a class are given by declaration of data items that its objects can use to store information. The action or capabilities of a class are expressed in one or more methods. A method is a named sequence of instructions usually requiring an algorithm description. Java statements can be categorised into five groups:
· Invocation - invoking or causing a method to be performed
· Assignment - using a value of the same type to change the state of a variable
· Repetition
· Selection
· Exception - detecting and reacting to unusual circumstances
In Java, an object is created when its declaration automatically calls a constructor method. So it seems that methods are a way of grouping Java statements, while classes are a way of grouping methods (and including data items).
The design of the class in terms of the methods and data it provides is the main feature of pragmatic object modeling techniques.
Data as object structures
The changing notion of data as object structures rather than the typical data structure/file structure paradigm of purely structured programming is investigated using resources on the WEB about Java and Python.
User interface objects
In object-oriented programming, statements are not thought of as imperative actions to be carried out, one after the other, but as messages or requests to change objects. Hypermedia applications support a limited version of the OO paradigm. Here actions are messages sent from one object to another. When such an event occurs, the WWW browser executes the corresponding request via an existing algorithm inside the object. For example the STOP button on Netscape may contain a message:
on mouseUp
close file
end mouseUp
Component diagrams
During the design stage, the component view is added to the class, with interaction diagrams done using an analysis model to provide an implementation or physical view of modules and executables. Each component is mapped to an executable file, Java class file, static libraries, or DLLs. Further refinements of classes, the interface, and the flow of activity involved with the business processes, is carried out. This may also include partitioning into tiers such as 2, 3 or n tier client/server architecture, depending of course on the chosen architecture and the separate defining of the user interface as a set of Web pages.
Posts
0 comments:
Post a Comment